<nckx>raghavgururajan: I prefer that upstream behaviour over ignoring domains when csr is set. <nckx>So I prefer your patch without (if csr '(--csr) '(-d…)). <nckx>mekeor: Any cool new feats? <nckx>Is it just me or does (csr certificate-configuration-csr look borked again? <mekeor>also, thank y'all for working on certbot! :) <nckx>raghavgururajan: Looks good otherwise, thanks for testing. <nckx>That gigantic near-duplicate if-block is certainly something, but not your doing. <nckx>mekeor: Mwahahaa, I have been preparing for this moment for years! *nckx has always used & preferred that view. <nckx>raghavgururajan: It should line up with certificate-configuration-challenge & certificate-authentication-hook but doesn't here. <nckx>It's a minor detail but why not :) <mekeor>nckx: haha, actually i also started using that view some time ago but couldn't get used to it. do you know a nice overview over the keybindings? especially like actions with attachments etc <nckx>“Support mu’s new regexp-based personal addresses” YESS <raghavgururajan>nckx: Hmm, certificate-configuration-challenge doesn't line up with certificate-authentication-hook. <nckx>My ‘address’ is @me.com so this has been a long time coming. <nckx>That's ‘less’ but same in emacs. <nckx>Your editor may need poking :) <nckx>raghavgururajan: Also, I thought I fixed that indent-code.el bug years ago. <nckx>(Not detecting plain defines.) <nckx>Felt like years, anyway ☺ ***cadmium.libera.chat sets mode: +o ChanServ
<nckx>Why did I send that now. ***cadmium.libera.chat sets mode: +o ChanServ
***niko is now known as Guest5247
<nckx>mekeor: Add autoconf & automake to native-inputs. <nckx>(native-inputs `(("autoconf" ,autoconf) ("automake" ,automake) ,@(package-native-inputs mu))) <nckx>You'll eventually internalise the abuse and learn than 127 means command not found. ***nik0 is now known as niko
<mekeor>aha! alright, thank you, i'll try :) <leoprikler>I really wish I wasn't plagued with that knowledge <mekeor>i wish that knowledge was documented <leoprikler>I wish Guix could detect that error string and tell you "oops, did you forget autoconf and automake again? :P" <nckx>I wish I was 100% sure who's responsible for dropping that knowledge around the garden. <nckx>Is it Guile? UNIX? Bash? <mekeor>nckx: isn't 127 a return-value of autoconf? <nckx>The autoconf that doesn't exist and never ran? No. <leoprikler>but yeah, you can't really be sure which process was called last, so it's a little tedious <mekeor>indeed: "$ /bin/sh -c asdf" → "/bin/sh: 1: asdf: not found". "$ echo $?" → "127" <nckx>It would be one of those helpful things that is completely wrong and misleading once in a while. <nckx>That said, I think I'll add a hint. <raghavgururajan>leoprikler: Regarding pipe-viewer, foo_cmd lines doesn't have q{foo}. <leoprikler>I'm still not sure what exactly happens here, though <leoprikler>could be double substitution, could be less than enough substitution <leoprikler>your match seems pretty brittle for what it probably wants to achieve <nckx>Henselierung: Ain't that the point? <nckx>I wondered the same TBH. <raghavgururajan>Henselierung, nckx and leoprikler: youtube-viewer uses youtube API and requires google account. straw-viewer uses invidious API. pipe-viewer parses youtube website directly instead using youtube-api, so no google account required, and had fall-back for invidious API. <leoprikler>still, seems somewhat weird tbh, especially given that youtube-dl is a thing that exists <raghavgururajan>Yeah, foo-viewer vs youtube-dl is blurry. But gtk-foo-viewer vs youtube-dl-gui is too different. <nckx>I was *literally* looking at the repo considering trying it. Ta mekeor. <nckx>mekeor: Interesting use of news.txt. <mekeor>nckx: what else should i do? what am i supposed to do with it? :D <mekeor>i mean, i want my channel-users to comprehend the changes xD <nckx>Whatever your heart desires. I just wonder how it will scale. 😉 <nckx>Guix pull won't finish before I fall asleep. Night all. <dstolfa>nckx: good night & just saw the email. (gnu packages networking) is indeed no longer necessary :). thanks for the cleanup! <MysteriousSilver>> apapsch: until the precious byte you didn't know was precious is lost to the void ;-) ***erhandsome_ is now known as erhandsome
***erhandsome is now known as Guest286
***Guest286 is now known as erhandsome
<MysteriousSilver>nckx: not yet, dual booting was too much work and decided to just get rid of nix <daviid>raghavgururajan: sneek is back ... <dragestil>Question: how do I run a program installed on guix? <dragestil>ok, I need to get out of the guix environment I see... <dragestil>so if you installed something in `guix environment guix`, you have to exit to use it? <dragestil>I thought the emacs was installed inside the environment, but I could not run it without exiting the environment <dragestil>> The purpose of guix environment is to assist hackers in creating reproducible development environments without polluting their package profile. <dragestil>so I thought when I install something inside guix environment, it should be available inside, not outside <leoprikler>dragestil `guix environment ... -- guix install` will still affect your own profile <leoprikler>if you want stuff inside your guix environment, you either have to nest calls to guix environment or specify everything in one line <leoprikler>please note also that to have a given package rather than its inputs you need --ad-hoc <Aurora_v_kosmose>Does Anbox have some non-Free requirements that make it unsuitable for Guix or has it simply not been packaged yet? <solene>Aurora_v_kosmose: it's not even on flatpak <solene>snap is extremely hard to implement if I remember well, and as Anbox requires kernel modules I wonder how this works with snap. <solene>Anyway, at least they provide a snap package which is still more than only providing sources. <efraim>related to snap, apparently snap is backported to ubuntu 14.04 (or was it 16.04) which doesn't have systemd, so there is code in their repo somewhere to have it work with non-systemd systems <efraim>for anbox, I think just no one did yet <Aurora_v_kosmose>Ah, unavoidable systemd dependencies would've made that very complicated <efraim>last night I massaged guix.vim to handle :Guix with some command parsing, so ':Guix build foo' works and I suspect most other ':Guix <something> foo' should work <efraim>Still have to implement completions and work out which commands don't actually accept '-L /path/to/repo' or '--no-grafts' to not pass those <civodul>efraim: neat! do you think the manual should say more about it? <efraim>After I make it a bit better and tag a new release I'll send a patch for The Perfect Setup <efraim>Right now it only really works with the built-in vim terminal <efraim>I also wanted to implement :Guix! for the run in the background and let me know when it's done use case <ekaitz>civodul and efraim : I want to start to port Guix to RISC-V because I want to make some tests of other things I'm porting and I don't have the chance to run environments... (tar bootstrap binary not found) <ekaitz>I've been taking a look to the files, looks like bootstrap.scm has more or less everything I need, am I right? <civodul>so i guess you'll have to synchronize <civodul>if there are core-updates changes, now's a good time to get them in <ekaitz>I dind't check the link but I checked the bootstrap.scm file and it looks like there are many things already done yeah <civodul>all this RISC-V stuff is pretty exciting <civodul>that makes me more hopeful about the hardware situation <ekaitz>yes, but we need to make the guix port as soon as possible so we can work on other stuff <ekaitz>atm guix is not helping in the process :) <ekaitz>where should I upload the bootstrap binaries btw? <civodul>eventually, once they've been verified by several of us, we'll put them on ftp.gnu.org <civodul>in the meantime, you can put them anywhere <ekaitz>okay! i'll start with this process and try to synchronize with efraim <efraim>I've been putting my stuff on the wip-riscv branch mostly <ekaitz>oh efraim you have most of it working don't you? <sneek>mothacehe was last seen in #guix 6 days ago, saying: I thought it was mitigated by the keep-alive mechanism :(. <pineapples>I'd like to define my own *.patch files in a package definition only found in my $GUIX_PACKAGE_PATH, but I don't know how to enable Guix to find them since a directory structure is different from that it expects ("/custom/gnu/packages/patches/", not /gnu/packages/patches/). <dstolfa>sneek: later tell nckx: (gnu packages networking) is no longer required -- saw the email too late :). thanks for the cleanup! <efraim>I've run into issues based on the host kernel or the bootstrap bash I haven't worked out yet <zap>hey guix anyone using mntreform for development? <leoprikler>people have mentioned it recently, afaik they were planning to set it up <zap>cool. Eh perhaps not the time to choose as workstation. But the pricetag is not allowing to buy it as a toy <leoprikler>I feel kinda alienated by the thought of having a laptop as a workstation anyway <leoprikler>to me personally laptops are inherently less hackable (in a hardware sense) than the big bulky thingies <leoprikler>the thought of replacing one of these parts makes me cringe <yoctocell>is it just me or is ocaml4.07-utop broken? any ocaml peeps, roptat, munksgaard? <yoctocell>guix environment --ad-hoc ocaml4.07-utop -- utop <yoctocell>Fatal error: cannot load shared library dlllwt_unix_stubs <yoctocell>Reason: dlllwt_unix_stubs.so: cannot open shared object file: No such file or directory <zap>leoprikler: mnt refrorm is quiet big and bulky :) for me when you're changing places a lot it's an inevitable choice <dstolfa>leoprikler: i need a laptop as a workstation because i carry the work around, and sometimes do "bulky" stuff locally <roptat>yoctocell, you should add an ocaml package in your environment: guix environment --ad-hoc ocaml4.07-utop ocaml@4.07 -- utop <leoprikler>I think you're misinterpreting the way I mean bulky <leoprikler>But I understand, that you can't travel around with a full-blown desktop PCs and that powerful laptops, that can compile icecat on the go might be a necessity to some <dstolfa>leoprikler: ah, well yeah i prefer desktop pcs too with multiple screens and all that, but yeah travel is an issue :D <yoctocell>would be nice to update utop to work with the default ocaml version, but then the `bap' package and all its dependencies would also need to be updated. <dstolfa>the pandemic at least made that part easy, if anything <yoctocell>basically all of the janestreet packages would need to up updated as well <leoprikler>I think it's also a given in a modern business setting as you're expected to take your work home. <roptat>yoctocell, yeah, I plan to add the new versions of the janestreet packages this week-end <zap>leoprikler: Excuse me. It was bulky joke :) <yoctocell>roptat: ah, cool, looking forward to that :) <dstolfa>leoprikler: yeah, i agree it's a pretty toxic attitude for many companies, but i don't want to give the wrong impression. i work at a research university and am not forced to do that, i just choose to do that because i enjoy the work i do :P <zap>in modern business setiing your company gives you a laptop and locks you to it <leoprikler>yeah, I think the people working at our TU also do lots of stuff by laptop <leoprikler>they've also inherited parts of that laptop lock-in stuff modern businesses do, at least last time i checked <dstolfa>we don't really have any laptop lock-in here really <dstolfa>i'm running guix on my laptop with linux-libre and some customization on the laptop itself <leoprikler>when I was working as an intern some years ago, we've had a share of Linux machines (I guess they were mostly Ubuntu) and I also did some work on my personal laptop <leoprikler>whereas at least some of the others had uni-sponsored MS machines. <leoprikler>well, I think the manufacturer was Lenovo, but the operating system was the least free of them all :) <dstolfa>yeah, here we basically have a datacenter that runs whatever is needed for $WORK and the desktops/laptops can be managed by sysadmins if you choose so, but you can run anything you want if you are happy to manage it yourself <dstolfa>yeah, it works pretty well in practice <sneek>nckx, dstolfa says: (gnu packages networking) is no longer required -- saw the email too late :). thanks for the cleanup! <nckx>sneek: botsnack for you. <civodul>so when did tests/inferior.scm start failing? <nckx>I'm guessing your error is not the same as mine: guix/ui.scm:1412:19: In procedure terminal-window-size: Bad file descriptor <nckx>Because that is a (bizarre) Guile+bcachefs exclusive. *nckx hedges: …or so I thought :) <dstolfa>i still can't figure out why a fresh master branch checkout fails to run tests for me <dstolfa>i just get random failures on builders, cpan/ctan, etc <civodul>nckx: could you strace the thing to see which file descriptor is passed to the TIOCGWINSZ ioctl? <nckx>Many ENOTTYs and one EBADF. <nckx>Actually, don't rely on those, I patched my kernel to return different errors in different places to track down this exact bug on the bcachefs side. <nckx>Oh, I see what might be happening. <civodul>nckx: thanks; for now, we can just add EBADF to the list in (@ (guix build syscalls) terminal-dimension) <nckx>My hacky bcachefs debugging aid is interfering with the hacky fix(? :) from commit 17a102332a253f0e3b1f511fa7bda2094264a77c <nckx>So don't add it, but that hard-coded list is dodgy too. <nckx>I hope we'll be able to remove EPERM again once I figure out where & whether this is a bcachefs bug. <nckx>civodul: So the real error is the match error? <nckx>(match-error "match" "no matching pattern" ()) is what I'm getting now. <civodul>i'm trying to understand but i may have to just bisect <civodul>(meanwhile i'm not understanding much) <nckx>If even you don't understand it, I have chosen the right hammer. <civodul>nckx: it must in the 4985a42..HEAD range, given our current 'guix' package <nckx>Oh, I'm currently on HEAD~500. At least it should validate your hypothesis. <nckx>dstolfa: Please feel free to report all test bugs that aren't clearly ‘I disabled X in the kernel and now X fails’. <dstolfa>nckx: well, the main test that i have failing right now is in check-system, and it's to do with nix <nckx>I did update Nix yesterday, but I admit to not running the system tests (mainly because I didn't know we had a Nix test). <dstolfa>running on the latest commit now, will let you know if it fails again <dstolfa>takes about a minute before it errors out on nix <nckx>Throw to key `gnutls-error' with args `(#<gnutls-error-enum Resource temporarily unavailable, try again.> handshake)'. <civodul>i've seen too many TLS issues lately :-/ <nckx>Which *does* guix download. <dstolfa>so there's a TLS error on redirects? <nckx>I'll put the releases. URL in the package, since it looks sane. <nckx>But IWBN to find the cause regardless ☺ <dstolfa>do you want me to open a debbugs for it? <civodul>i think i have it, the inferior issue <civodul>nckx: 0a02abde88ce16315277239c081c6222a4db88d2 should fix it <dstolfa>pushed as in the email got through, or pushed as in you pushed a fix and i should test it :D <nckx>The previous URL was probably a canary for *something* that shouldn't be ignored, so it's good you filed a bug. <nckx>TBH I didn't check my mail, I looked at the last bug at issues.guix and added 1 to the URL 😛 <dstolfa>hopefully nothing too painful to chase down :D <nckx>TLS errors are always painful. <nckx>Personally, I find network debugging in general painful, and avoid it. <dstolfa>all `make check` tests pass, now running the system tests <dstolfa>nckx: hum, i think the gnutls issues may be caught by check-system <dstolfa>maybe it's a local failure on my part, but i don't really have any local diffs applied <nckx>civodul: It fixed it, thanks. <nckx>dstolfa: At first sniff, that smells like a parallel-build issue to me. Test it with ‘guix build -c1 /gnu/store/xa6dcd5r93plmjfqk3ygqm2p5zf32g1c-gnutls-3.6.16.drv’. <nckx>CCLD ecc/eccdata scrolls by… <nckx>successfully built /gnu/store/xa6dcd5r93plmjfqk3ygqm2p5zf32g1c-gnutls-3.6.16.drv <dstolfa>hmm, odd. maybe i should clean && distclean and try again <nckx>No, that shouldn't fix it, you seem to have run into a genuine but hard-to-reproduce bug. <nckx>It's been a while since you've submitted a bug report, don't you agree? <dstolfa>i'll try a clean re-run with a clean clone, if that triggers it i guess that time will have to change in not-so-long-ago <nckx>If it succeeds now I think you just got lucky this time. All should be contained in that /gnu/store/xa6dcd5r93plmjfqk3ygqm2p5zf32g1c-gnutls-3.6.16.drv hash, the build environment doesn't care about your feelings or local checkout. *nckx retries the build with --check… *nckx retries the build with --check -c1 (maybe it's an anti-parallelism bug?)… <nckx>All attempts remain disgustingly successful. *dstolfa is currently running make check for his checkout and then will try it again <dstolfa>i've prepared a tar.gz already with the log file <dstolfa>GnuTLS: Resource temporarily unavailable, try again. from wget, it seems like it's just an EAGAIN that needs to be handled by the library consumer? <dstolfa>nckx: annoyingly, i don't think gnutls failed this timie <dstolfa>still probably worth submitting as a bug i reckon? <nckx>I still think so. Since you saved the log I'd appreciate it, even if it never goes anywhere. <nckx>Not sure how to debug this unless you're a wizard who looks at the log, thinks ‘oh, this probably happened’ and can fix it on sight. <civodul>dstolfa, nckx: i have a fix! we should check for "non-fatal errors" (a misnomer...) around 'handshake' <dstolfa>if anything, the bug report existing might lead others to report that they've encountered it if it is a real bug <nckx>So it really does work if you retry? <dstolfa>civodul: i'm getting NET::ERR_SSL_OBSOLETE_VERSION when trying to open it in ungoogled-chromium <civodul>dstolfa: so i suspect their server is doing something suboptimal <civodul>unfortunately it looks like TLS' growing complexity is showing <nckx>Well, they use a CDN (Netlify) that seems to use another CDN (CF) judging by the headers. <civodul>and all that to talk to Amazon i guess <apapsch>with tls 1.3 things get simpler again, no DH parameter file, hard coded cipher suite <civodul>unfortunately, you can't just have a client that does nothing but TLS 1.3 <nckx>civodul: Argh, I'm confusing CloudFront with CloudFlare again. <civodul>so there are "only" two levels in the end? <civodul>Guix really looks like a craftsfolk project in comparison :-) <nathan_>hello everyone, I have perhaps a simple question <nathan_>I came here yesterday with some trouble with latex package subfiles <nathan_>with your help, I realize that subfiles comes in texlive; the issue is that the subfiles package in texlive is from 2018 and I am using features from 2020 <nathan_>so I decided to try to edit the texlive package and make it download the newer version <nathan_>now I have a huge .scm file which I obtained from guix edit texlive <nathan_>and I appended to it the download of the newer version of subfiles <nathan_>which I obtained with guix import texlive subfiles <nathan_>following the file, instead of just dropping the package in the end, I wrapped it in a define-public <nathan_>however I do not know what to do with this file! <nathan_>if I run guix package -f texlive.scm it complains that it cannot install non-package object <nathan_>my understanding is that guix package -f file.scm expects the last part of the file to evaluate to a package <nathan_>on the other hand, I am following what I understood from reading the file used by guix <apapsch>define-public defines a new binding, but does not evaluate to it (?) <nathan_>so I believe there is a way in which I can install all the packages I have defined <nathan_>apapsch: sure! but how do I install it? <nathan_>I have a bunch of (define-public texlive-latex-bla) <apapsch>it's easiest to make a git checkout of the guix repo and follow the guix manual on contributing. one moment... <nathan_>perhaps in a unified context, so that I know they are all of my texlive packages, and they do not clutter my package list <zhu_zihao>(packages->manifest (list desired-package-a desired-package-b ...)) <zhu_zihao>try add this to the end of your modified file. <zhu_zihao>and then run "guix package -m <yourfile>" or "guix environment -m <yourfile>" <nathan_>apapsch: thank you, I will take a look <nathan_>zhu_zihao: that is interesting too, I will read more about manifests <zhu_zihao>some methods I use to test new package (from easy -> hard) <zhu_zihao>1. guix build -f <file-contains-package-expression> <zhu_zihao>2. create a directory with proper directory structure and make sure files have correct define-module declaration, and guix build <new-package-name> -L <directory> <zhu_zihao>3. guix time-machine -C <channel-description-of-local-repo-and-test-branch> -- build <package>(this takes a long time because it builds packages cache, only do it before submitting a patch) <zhu_zihao>guix time-machine --disable-authentication -C <apapsch>I'd put hacking in the guix repo between your 1st and 2nd point. It's a bit more involved than invoking one command, but less involved than the custom module as all structure is already there and you just have to find your spot <char> Does anyone know how to fix broken adwaita icons on gnome? ***apteryx_ is now known as apteryx
<char>some icons are just un recognizable blobs. An example is the "annotate document" icon in the top left of pdf viewer. it is meant to be a pencil I think. <ecbrown>char: going from memeory here but there are some XDG_* env variables that help with this kind of stuff <ecbrown>char: imo these should be in the manual in a nice bloc, but they are not. *ecbrown looks to touch base with guix maintainer who may hold "physical sciences" portfolio <nckx>But I'm not convinced that (well, I fail to see how) dconf can fix the icons that look like they were physically damaged in transit. <nathan_>apapsch: just to be sure: you are telling me to clone guix itself and work with it; I may then use my modified version as a channel, and try to upstream some improvements I make? <char>nckx: I do already have dconf installed. <dstolfa>nckx: do you want me to report yet another test bug? :) *dstolfa is unsure what's causing it, but it's there... <nckx>char: I didn't really expect it to, sorry. Those icons have been damaged forever… <nckx>dstolfa: IMO all tests should pass, or what's the point? <char>nckx: at what point are they damaged, on substitute server? <nckx>I think they're not rendered correctly. <dstolfa>hmm, the drv file is not very useful here. nckx, can you reproduce this failure? it's nfs-root-fs-test, i've tested with -c1 and it still failed <nathan_>zhu_zihao: I really liked your approach. From what I understand, I have a manifest file I can keep on git, and after running guix package -m texlive.scm it will install all the packages in my current profile? <nckx>nathan_: Sounds correct. <nckx>dstolfa: It's taking a while because I had to rebuild Guix due to an unrelated ABI change. <leoprikler>char I think that is a bug in the SVG file itself, you basically solve it by using a different icon <leoprikler>sadly our gnome packages are somewhat outdated, so even if it's fixed in newer versions we won't have those until raghav finished packaging it <leoprikler>I don't think it's guix-specific, I rather think that it's the SVG file itself that is borked <leoprikler>If you use another icon theme the same button renders perfectly fine <leoprikler>but the thing is some folks are just really comfortable with adwaita and I don't fault them for that <nckx>I'm not disputing that, just that it's a simple upstream bug. <dstolfa>nckx: no worries, i'm doing like 10 things at once so i just context switch to things as i wait for something to run :D <dstolfa>turns out, all of my current acitivities are running tests and (and ideally, fixing them) <leoprikler>nckx: /gnu/store/81b0vv83gx6qk5yqq1q0mpvrk5bxr25p-adwaita-icon-theme-3.34.3.tar.xz/adwaita-icon-theme-3.34.3/Adwaita/scalable/actions/edit-clear-all-symbolic.svg looks pretty borked to me <leoprikler>it's differently borked if you use the one currently upstream <leoprikler>whereas e.g. categories/emoji-flags-symbolic is not borked <nckx>What even kind of store path is that. <leoprikler>I've appended the path in the archive to the store path <leoprikler>so you need to tar xfv /gnu/store/81b0vv83gx6qk5yqq1q0mpvrk5bxr25p-adwaita-icon-theme-3.34.3.tar.xz and then follow the rest <leoprikler>I thought you had your hurd translator set up for this purpse as clearly we're running on the hurd already :P <nckx>I'm not going to install the buggy SVG viewer so it can buggily render an SVG. <nckx>If only beause guix install: error: profile contains conflicting entries for dconf <leoprikler>I'd use environment --ad-hoc, but I get your point <nckx>I still don't see how this isn't just a rendering bug. <nckx>Which was my original point. <leoprikler>Well, it might be a rendering bug, but SVG does not equal SVG. <leoprikler>In particular, Inkscape has its own SVG format, that it confusingly markets as SVG. <leoprikler>and it's not compatible between Inkscape versions either <leoprikler>so "renders fine in inkscape" is no metric, especially if as a GNOME artist one expects things to be rendered through GdkPixbuf <leoprikler>now perhaps this is a bug in GdkPixbuf, that has since been fixed <rekado>Inkscape only has a couple of custom XML tags; that’s all fine and it can save a stripped variant. <leoprikler>but then too there is the problem that our current adwaita-icons don't all work for our current gdk-pixbuf *dstolfa hates C and naturally recursive problems in C <dstolfa>leoprikler: you know i don't even mind the unfolding of the recursive algorithm into an interative one... it's the fact that C lacks any semblence of commonly used data structures <nckx>dstolfa: Why are we using C today. <leoprikler>i wouldn't say that, there's plenty of libraries out there that provide the usual linked lists, stacks etc. <dstolfa>leoprikler: and yet i can't pull any of those into an operating system for 1 subroutine in a library (: <leoprikler>it's just that people programming C usually err on the side of "nah, let's not pull in another library and write that ourselves" rather than "npm install leftpad" <dstolfa>which roughly translates to: have fun implementing highschool data structures <leoprikler>dstolfa: if they're free software you can still copypasta them :) <leoprikler>given that operating systems are sometimes written in C++ i don't think linking a small std library into it should be too much of an issue <dstolfa>leoprikler: i think i can just get away with a foo_t *stack[...] and a size_t top <nckx>Oh we're writing an OS in C today. *dstolfa makes sure to add a snarky comment that he will remove later during the upstreaming process... but it needs to exist for now *raghavgururajan just knew that guix officially became is second-nature, when he typed foobar.scm insead of foobar.com in browser's address bar. xD <leoprikler>when Git is powerful enough to influence legislation *dstolfa would like a .scm TLD <nckx>I can almost see it happen for one of the more, er, ‘trendy’ languages with corporate backing with more money than they know what to do with. <raghavgururajan>Let us all strong-arm the ICANN for .guix .go (guile) .scm (scheme). <nckx>raghavgururajan: Hah, true, let's register .go and rent-profit. <nckx>In all seriousness: I've been hacking in Linux-land the past few weeks and the number of times I've typed .scm instead of .c is worrying. <dstolfa>nckx: i wouldn't say that's worrying... <nckx>I never accidentally type .c ☺ <dstolfa>i mostly write C and i never accidentally type .c because good god do i hate C with every braincell that i have *zap thinks that classic guiler behaviour is exiting bash with ,q <dstolfa>everywhere? i thought emacs is everywhere, and it doesn't work there <zap>C-c C-d is for documentation <zap>haha ,q RET is 3 keystrokes <nckx>FFS just power cycle the box like you have to do in vim. <zap>leoprikler: Okay C-c C-q is the winner <nckx>…but none of this works in bash which was the point, remember. <leoprikler>yeah, but using C-q to escape emacs feels natural to us emacsers *nckx doesn't want to escape emacs, perhaps this is Stockholm syndrome. <ixmpp>leoprikler: dont you mean c-x c-c <leoprikler>c-q is for inserting a literal character without emacs doing smart things <ixmpp>You were speaking of exiting? <leoprikler>which sometimes you want e.g. if you have smart quotes set up, but want to type a simple ' <ixmpp>c-x c-c is the counterpart of :q! <ixmpp>Am i being trolled or am i missing something <leoprikler>the joke is that in Emacs you can simply close a buffer… <leoprikler>or in the case of Geiser just the REPL while keeping the buffer <leoprikler>whereas in vi the only keybinding some (by far not all) will remember is :q! so you have to kill the entire process <leoprikler>which hey, maybe vi's short startup time makes up for that, idk *jonsger uses auditd for debuging .desktop files ^^ <nckx>jonsger: Is that overhead-free when not debugging? <ixmpp>It's actually not possible to close a buffer in vim in one command, i think <ixmpp>At best :new then close the other window, maybe? <nathan_>if anyone is following my quest: I noticed that I did not have to create a new manifest, nor clone guix. The file obtained from `guix edit texlive` has all the packages definitions. I added the one I want (subfiles) as an input for texlive-base and placed "texlive-base" at the end of the file. <nathan_>then `guix install -f` worked as a charm <nathan_>leoprikler: lol if I figure out how to make it work soon, I may have time to make a patch! ***Henselierung is now known as hrnz
<dstolfa>roptat: skimming through it, it looks a bit like hindley-milner but a bit simplified? <roptat>the fun part is that it does type inference/checking at build time <roptat>so, if this was a module, you could use it in any guile file, and add #? in front of any scheme expression you want to type-check <roptat>(well, it's extremely simplified, so it won't work for everything: only numbers, bools, anonymous functions with exactly one argument, no definition, let, etc) <dstolfa>the main difficulty with lisp and typing is quoted expressions and their manipulation <dstolfa>which basically brings a question of when you should type-check something, and ideally you'd do it at evaluation time, but that's undecidable <dstolfa>at least in general, you may be able to do it for some simple cases <roptat>well, in general, you manipulate structures that are well specified, you can't put anything in a sxml expression for instance <roptat>but in the worst case, you can say an sexpression is of type list any or something like that ^^' <roptat>then, if there's a pattern-matching that checks the type of expression, you can refine the typing environment inside it <dstolfa>yeah, you can always just type them as bottom and be fine <The_tubular>Does system.scm defines what is installed on the system or does it defines what everyone can use on the system ? <dstolfa>but i meant in the hindley-milner sense, you can't really deal with "data = code" thing that well unfortunately <The_tubular>I mean, I know system.scm is just a "standard" and you could probably name it whatever, but the file that defines your whole system <roptat>typically /etc/config.scm, you mean? <roptat>in that case, it defines what's installed for everyone on the system, in addition to how it boots and services <roptat>users can access these packages, but they can also install their own packages <dstolfa>well, you can manipulate sexps since they're just data right, and they can be evaluated anywhere in almost any context, but in that context you may not be able to infer the type of everything in the sexp in a decidable way because it'd just reduce to the halting problem <The_tubular>Got it, I'm trying to remove a bit of crust in %base-package <roptat>dstolfa, oh you mean if you want to execute the sexp as code? <The_tubular>And reading what package is in %base-pacakge I thought lots of those were in gnucoreutils <roptat>The_tubular, mh... what do you have in mind? <roptat>there's a package for coreutils, the other packages are not part of coreutils <The_tubular>I mean, there's like 3 text editors and wireless tools <roptat>oh, yeah, you can remove anything you don't want to have <The_tubular>And a few other things I don't need installed on most of my machines <roptat>dstolfa, do you know any system that could be helpful in that case? <nckx>The_tubular: Then remove them from %base-packages using (rnrs lists)'s remove procedure, or (less tediously) by removing %base-packages entirely and specifying (packages (list a mere handful of packages you actually want)). <dstolfa>roptat: unfortunately in general, such an algorithm doesn't exist, because if it did then you've solved the halting problem (and in turn you have an unsound logic since you've just proven completeness). however, it would be a cool research problem to identify how one could add gradual typing to guile in a way that can handle sexps at least in some cases and perhaps warn or automatically add runtime tags to <roptat>dstolfa, isn't the standard way to solve this issue to restrict the type system to something decidable? <dstolfa>roptat: yes, but then you've kind of removed the main thing of what makes lisp lisp, which is treating data as code and you end up with ML <dstolfa>but i would encourage you to pursue it further if you find it interesting, because there are probably a lot of cases you can deal with and others you can add runtime tags to check that the value is in whatever your semantic type set is <dstolfa>it would add overhead, but maybe that's acceptable at least in debugging scenarios <dstolfa>which could then improve error reporting <leoprikler>but wouldn't a scheme implementation of ML already be a win for ML bootstrapping purposes? <roptat>definitely, camlboot starts with a guile implementation :) <leoprikler>speaking about typed guile, I think tohoyn (frequents #guile) does Theme-D <dstolfa>ML is quite interesting because it's essentially the basis for any HOL implementation, so having a bootstrappable thing that implements a HOL kernel which can in turn be verified on paper would be really helpful when hitting bugs which are now hard to reproduce potentially across systems <dstolfa>so you could then implement HOL-mini or something to add to all the HOL-Zero, HOL-Light, etc names, but this one is bootstrappable! <civodul>now the fun thing is to turn that into a macro <roptat>do you know how I can get line numbers? <ixmpp>I heard someone mention types <apteryx>cbaines: guix challenge just became more useful with the new build farm connected; thanks for seeing it through! <drakonis>but the actual question is, how do you access typed guile? *ixmpp stops looking for the drool emoji <drakonis>i think someone even wrote a patch for that <roptat>very limited, but this results in a type error at compile time :) <leoprikler>that's why for Tsukundere I simply guess by file extension like every sane system :) <roptat>mh... Unbound variable: read-syntax <drakonis>racket's langs are cool but the one thing that bothers me a lot is that you cannot weave multiple languages in the same file <roptat>ok, and now I need to rewrite everything to use the syntax objects... <daveed>Hello. I install emacs-next-pgtk with guix on a foreign distro and it ruined font rendering for packages installed with flatpak. <daveed>A lot of variables that could go wrong with all the different package managers.. I removed guix from that user and it fixed the problem though. <leoprikler>make sure your user correctly sets up such important variables in their .bash_profile, .zprofile or whatever other shell .profile they're using <daveed>leoprikler: XDG_DATA_DIRS contains both guix and flatpak shares. Could it be that some library is being read from guix first instead of flatpak? <leoprikler>foreign distros have the habit of doing it in a weird way <leoprikler>that might be an issue, try putting flatpak first for flatpak invocations <leoprikler>but there could also be an issue of your system XDG_DATA_DIRS missing, make sure the default /usr/share etc. are all there <daveed>leoprikler: I just did printenv in the tty, in my wm, and for the flatpak program with and without guix set up for the user. With guix, it just added guix stuff to the PATH, XDG_DATA_DIRS, and INFOPATH variables and then added GUIX_PROFILE, GUIX_LOCPATH, and EMACLOADPATH. <daveed>For the flatpak though, the only difference was the prepended INFOPATH and the new EMACSLOADPATH. XDG_DATA_DIRS remained unchanged because flatpak creates the variable itself in the sandbox. <zap>drakonis: I the latest release is 3.0.7 Or you're talking about the release itself? <zap>improvmets in locating source is also cool. I dream of stepping debugger ala edebug <drakonis>i wish i could reuse successful build steps for iterating on a build <jonsger>some out here who got auditd running on Guix System? <drakonis>basically, i have a sucessful phase, except that the next one failed and i'd rather not rebuild the successful phases <dstolfa>i mean that works already if you have an initial successful build <dstolfa>i'd imagine it would be difficult to do right for package builds <dstolfa>you can probably `guix build /path/to/drv <dstolfa>but eh, that won't take into account your changes i think? <drakonis>package builds, yeah, so i have a big package that takes a few minutes per run to compile and i need to figure out what i'm doing wrong with regards to the scheme code <dstolfa>i think you have no choice here unfortunately, doing incremental build steps on failed builds sounds like a recipe for disaster <drakonis>the build systems a la carte paper seems to describe this <drakonis>basically, what i mean is that if i'm doing a build a dozen times, don't waste time rebuilding the same artifact <ixmpp>is there a simple way to install everything required for building with gcc? <ixmpp>i want to do some iterative dev <ixmpp>hearing complaints that crt1.o is missing <dstolfa>on that note... i wonder if there's something like build-essential in guix <ixmpp>that was what i was hoping for <dstolfa>just browsing through packages, that looks promising <ixmpp>yeah, i installed it into my user profile but seems that's not enough <ixmpp>maybe it has to be in system profile <dstolfa>hm, if you're building as a user i doubt it, but worth a try *shrug* <ixmpp>it works fine if i use guix environment <dstolfa>huh. i guess something in your shell setup maybe? <drakonis>guix environment by itself installs the dependencies for a package and --ad-hoc adds the package <dstolfa>drakonis: i'd assumed that ixmpp was doing something outside of a guix package, e.g. something in home <dstolfa>if it's a guix package then yeah, guix environment guix is pretty much necessary <ixmpp>yeah i used --ad-hoc, i'm doing iterative dev on stuff not managed by guix <ixmpp>which as i'm realising, is not trivial <ixmpp>you helped me but i didn't realise <ixmpp>(for a different issue though) <drakonis>it is doable to do iterative dev on stuff not managed by guix tho <drakonis>i did some python stuff and it is very nice <jonsger>ixmpp: and `--ad-hoc emacs -- emacs` let you directly run something <drakonis>dont have to worry about a damned thing regarding shells <ixmpp>jonsger, yeah, i'd been using that <ixmpp>now i wonder if i can have some arguments be ad-hoc, and some not? <leoprikler>ixmpp: it's not, just specify the ad-hoc bits after the non-ad-hoc ones <nckx>ixmpp: guix environment <not ad hoc things> --ad-hoc <ad hoc things> <nckx>So ‘guix environment emacs --ad-hoc emacs -- emacs’ runs emacs in an environment with emacs and everything required to build emacs for maximum emacs. <leoprikler>raghavgururajan: I think you can "simplify" the quoting styles by doing ("([\"'])command[\"']" all quotes) <leoprikler>though obviously that will allow 'command" and "command' as well <The_tubular>So I deleted bash from my "/root/.config/guix/system.scm" ***iskarian is now known as Guest2379
<leoprikler>The_tubular: nothing, deleting the config and reconfiguring guix should not delete bash <leoprikler>now assuming you have a system without bash and really really want it to go away, you can delete old generations and gc, but let me warn you, that's destructive <lispmacs[work]>The_tubular: how did you remove bash from the system config file? Did you remove it from the base-packages variable? <The_tubular>I remove the base-package variable and added manually what I wanted from the variable <dstolfa>do we have guix cloaks on libera? (: <drakonis>also we have multiple libera staff in here lol <nckx>Yes, we can cloak people. No, nobody is cloaked. <drakonis>by the way, we have a hidden nest of guix users over the doom emacs discord <dstolfa>nckx: i'd be happy to get cloaked and spread awareness :D <dstolfa>drakonis: it was easy yeah, the staff was the same staff that we have now <dstolfa>maybe they have better infra now though, idk <nckx>It was pretty easy on old Freenode. <drakonis>i recall that the nixos people had to poke staff to get cloaking done <nckx>drakonis: Is that not still the case? <drakonis>during the migration, they had set up a bot for requesting cloaks <nckx>drakonis: That's something else. <nckx>That's an unaffiliated peasant cloak. <drakonis>i'll have you know that my cloak is perfectly regal <nckx>Is that what that smell is called. <nckx>Regal piss. (Hm, wrong network.) <ixmpp>not sure what anyone would want with my IP but if you want it there it is, have fun. <nckx>Aha, that is why I have hidden my IP behind a—oh. Hm. <nckx>dstolfa: Look in the mirror. <ixmpp>long pieces of fabric that you attach to your shoulders <ixmpp>alternatively, things the irc server returns instead of your IP, as a fake vhost <The_tubular>I ran guix gc, and there's still plenty of things in /gnu/store that I don't have anymore <jlicht>(IRC n00b here): why would anyone think exposing IPs by default is a good default? <leoprikler>The_tubular: you have current system config, old system configs, current user configs, old user configs and running guix environments <The_tubular>I thought system configs didn't worked with generations <leoprikler>you have a boot menu that lists the past N configs even <nckx>leoprikler: The guix/contributor/dstolfa you see when you /whois dstolfa. Which you don't see when you /whois anyone else. <nckx>leoprikler: drakonis has a generic cloak, I just use my bouncer's rDNS. <The_tubular>guix package: error: profile '/var/guix/profiles/per-user/root/guix-profile' does not exist 
