<vagrantc>and ... is there what repology.org consumes to list packages in guix? <vagrantc>no, repology.org seems to be consuming something ancient ... it's got diffoscope at 199 and updates are up to 220 with a couple releases per month <cbaines>the packages page is part of the website, which is in guix-artwork I think, which is served by berlin <vagrantc>seems like there was also a discussion on guix-devel in early june <vagrantc>oh, it's due to *something* blocking russia <cbaines>given that bayfront is or at least has been building the website, switching to serving it from bayfront might be a way to avoid these networking restrictions <emacsomancer[m]>getting an error on "guix pull" - error: commit cea708413dd9d2d794b022f0f7bcfaba0bac97d7 not signed by an authorized key: A420 7B56 C255 109F 2CB3 157E 4990 97AE 5EA8 15D9 - is this a known issue? <FriendFX>Dear experts, I installed the `opencv` package a while ago (I think it came as a dependency of `python-imageio`) and it's kind of a pain because every time I do a `guix package -u`, `opencv` thinks it needs to be updated. This wouldn't be so bad if it didn't want to re-build itself including a lengthy 'check' phase. Looking through `guix package -l <FriendFX>|grep opencv`, I see that the version has always been 4.5.4 for me, but the `/gnu/store/` prefix is different every time. Is this normal? Can I somehow tell Guix to only update if there's a substantial change/improvement of this package? <apteryx>are trained models OK to be packaged? I guess these are more like nonfunctional data per the FSDG? <podiki[m]>I would think so, basically it means their parameters have been set <vagrantc>data that completely changes how the software behaves? *vagrantc finds trained models to be very dubious from a free software rights perspective <vagrantc>you can't reproduce it, you don't even know what went into it, and you can't change it <vagrantc>FriendFX: if guix is rebuilding it, there is almost certainly a reason <clever>vagrantc: i would just write a package that trains the model and have all of the data as inputs! <vagrantc>FriendFX: you can choose not to update some packages, but sometimes that will result in other issues <vagrantc>clever: sure, it is *possible* to create a trained model that would comply, though my understanding is it would not be possible to build it reproducibly <vagrantc>but i got the impression apteryx was talking about just using a pre-trained model <clever>vagrantc: just make sure your training algo is also deterministic <vagrantc>yes, there are corner cases, but i get the impression that is... not the common case <FriendFX>vagrantc: I would hope there is a reason for it, but I get the horrible feeling that the package definition points to a master dev branch somewhere instead of a release branch, which would explain (a) why it wants to be rebuilt frequently and (b) why the version number doesn't change. <apteryx>our tesseract package is useless without it <vagrantc>apteryx: i do see a bunch of tesseract-ocr-* packages on debian <FriendFX>vagrantc: Also, it is odd that the server never seems to have a pre-built substitute available, which makes me even more suspicious that what I'm getting something different from the rest of the world. <apteryx>yes, the trained models data is licensed Apache 2.0 <FriendFX[m]>atka: Sorry, just testing my mobile nick. Still green wrt IRC :-p <efraim>and on a couple of other architectures :) ***Xenguy_ is now known as Xenguy
<FriendFX>Does anyone else see the issues I'm having with the `opencv` package? <acrow>So, is lcsync going to be committed in the near future? <acrow>It looks to be a pretty cool tool. <vagrantc>acrow: it's still very rough around the edges <apteryx>singpolyma: how about the bootloader? apple things must be as locked as it gets ***devmsv_ is now known as devmsv
<apteryx>see #57151 if you'd like to play with it ***LispyLights is now known as Aurora_v_kosmose
<unciv>can a new phase be installed for variant packages for pre-configuration ? <unciv>so, I have created a package, but I wonder if it would be possible to add an extra step to add config files and directories with preinstalled data. <ekaitz>unciv: if I understood correctly it's perfectly possible <unmatched-paren>(package (inherit old-pkg) (name "my-variant") (arguments (substitute-keyword-arguments (package-arguments old-pkg) ((#:phases old-phases) #~(modify-phases #$old-phases (add-before 'configure 'add-configuration (lambda _ ...))))))) <ekaitz>unciv: where do you have that preinstalled data? <unciv>so, at the moment we use docker-compose and we keep it in a repo <unciv>but now I've taken the framework that we use which didn't have a guix package and I have created one in a new channel <unciv>so the actual app works, but I want to add extra steps to create a config file, and add our custom modules from another repo <unciv>hmm, that's a good question, I actually just run the binary and point it to a config file in my home dir at the moment <unciv>no, at the moment there's only a share/doc directory <ekaitz>unciv: the home dir is not writable from a package <unciv>ok, so if I created a new dir called config in the /share ? <unmatched-paren>you'd have to point the binary to the directory you create in some way <unciv>so it should be easy to just make a new .sh that calls the binary with flags <unciv>hmm, that's an interesting idea <unciv>the one I created does have a .-real as well <unciv>odoo and .odoo-real - both from Jan 1 1970 :) (lol) <unciv>the .odoo-real file is just the normal start script for odoo - the odoo file is a bunch of export GUIX PYTHON PATH <unciv>I'm just amazed that it works, because I have no idea how it worked <unciv>but if I can get it working automatically with all the configs, it would be cool to generate a new .scm every time when we merge <nckx>apteryx: What a difference! Thanks for testing it out. Pity we have to choose between worse OCR and hundreds of megabytes of very dubious ‘data’ :-/ <cizra>Hi, are other bootloaders than GRUB supported in Guix? Or am I on my own, if I do that? <pkill9>cvreated first iteration of guix wrapper \o/ <pkill9>plsu it means you can make other small changes like deleting .desktop files you don't use without rebuilding the entire package <devmsv>hello, I have my own running guix system. I want to install another system onto a USB stick so I can have a guis system on the go. I can't run ~herd start cow-store /mnt~ (it can't find the service) any tips on how to proceed? <devmsv>Maybe I haven't explain my self. I have my own gyix system on my laptop I want to isntall another guix system directly on the USB without another USB withguix installation USB iso (I don't have two USB sticks) <unmatched-paren>So you're using your laptop to install a full-fledged live Guix onto a USB? <unmatched-paren>I think you might want `sudo guix system image` for something like that, though it better be a large USB. <unmatched-paren>Guix takes up a lot of storage space, are you sure you can fit that in a USB? <devmsv>Its a 128GB USB, at least I want to try <nckx>cow-store redirects writes to /gnu/store, that would be writes to a very limited RAM drive (tmpfs) when installing from the installer USB/ISO, to the target partition /mnt. <nckx>It is not needed if you're noot booted from RAM. <nckx>So: simply skip that step, devmsv; it is not related to the success of the installation. <nckx>devmsv: Another point of note is to use the ‘grub-efi-removable-bootloader’ boot loader. <devmsv>unmatched-paren: nckx: Thanks. I'm doing ~dd if=$(guix time-machine -C channels.scm -- system image config.scm) of=/dev/sdb~ <nckx>I'd have gone with ‘guix system init’, but good luck! *unmatched-paren feels dumb <devmsv>well I have cancel the other process and found it now with system init <devmsv>for some reason grub is not correctly installed. <efraim>lilyp: your gobject-introspection patch on core-updates seems incomplete <some-one>Hello everyone. Is where any intentions to complete the idea of `guix git log`? How do you find the old versions of packages that are no longer in the upstream? Via git blame? Why we don't keep old version of packages in the guix channel? Is it really hard to support? <pkill9>because it's extra work for little payoff I guess, especially now you can build packages using an old version of guix <unmatched-paren>some-one: "... old versions of packages ..." <- Yes, keeping everything would be impossible. Also, security problems. <abrenon>how does guix capture the value of packages' fields to make them available to define other fields ? <abrenon>why can I apparently reuse version transparently to define commit in a git-reference, but not home-page in the url ? <abrenon>don't tell me it's about lines order… <abrenon>ok, lines order seem to be the explanation… -_-' <abrenon>then why isn't home-page usually found above the origin ? are there so few packages which have do not have another home page but the one of their repos ? <abrenon>I must find examples to see how they handle it <abrenon>I can't believe they all duplicate the url <abrenon>maybe a let variable right before the package declaration itself ? <nckx>unmatched-paren: Not dumb. There are probably more people who mistakenly use ‘init’ when they'd be better off with ‘image’ than vice versa. This is a rare exception. <abrenon>ok, that's the approach taken by casync <abrenon>so I guess if it's good enough for it it's good enough for my package <unmatched-paren>maybe we should modify (guix records) to allow referencing later fields <unmatched-paren>not sure how you'd do that though, other than literally traversing the literals to resolve dependencies <abrenon>I thought it was already the case when I saw "version" being reused like that <abrenon>I thought it was one of the cool features of "yeah, it's declarative, it's a fixed point or something" <abrenon>actually, I think I'd prefer no capture of properties at all (having to declare everything in a let in order to be able to share it later) than this stateful weirdness <abrenon>yes, which is why I'd prefer having the whole thing stateless and being able to refer to any field from any other, but the overall behaviour would be less surprising and look less "dirty" <nckx>That's why it's the way it is now. <abrenon>(oh, right, you can't hear me if I write like this) <nckx>Being able to use future fields would be surprising and dirty. Exactly like (foo "hello") (…lotsa code…) (define (foo …)) <nckx>I thought that was your point. <abrenon>ohhh, no, quite the opposite in fact *tschilptschilp23 wonders which package in my home-config pulls in half kde on a gnome-system *nckx hears strange whispers without origin. <abrenon>I'd prefer being able to refer to any field from any other because I feel that in a declarative system, no field should be understood as "future" to any other <abrenon>which is why we're giving names to them <apteryx>is anyone having "guix substitute: error: connect*: Connection timed out" with berlin today? <nckx>Sure, I guess this-package-input etc. already do so. <abrenon>(point (x 7) (y 2)) should in my opinion refer to the same point as (point (y 2) (x 7)) <abrenon>if not, then I'd rather have it (point 7 2), no name, then I know that only position can be meaningful <abrenon>here, I thought I was using a beautiful functional programming abstraction, when I'm in fact executing imperative statements of a language less readable than C <nckx>That's not really what's going on here though. (package (name …) (version …)) is the same as (package (version …) (name …)). <nckx>You're confusing two things. *unmatched-paren not really sure about "less readable than C" but okay :) *nckx thought this was serious; flies away again. <abrenon>yes, less readable, because the attributes names don't convey the information that they are indeed performing a side effect <abrenon>it is serious, I'm honestly disappointed to find such a bug in guix <abrenon>but I can understand that few people are ready to see this as a bug <unmatched-paren>tbh, it would be nice if guile's records could be fleshed out such that we could just kill off (guix records) <unmatched-paren>i think implementing guix-style records in guile might make declarative-style easier to implement, possibly? <abrenon>because you're right, I'm mistaking two things, and the fact that I've been able to mistake them up to now is a proof that until now I've been lucky enough to handle well-designed, unsurprising languages which are simpler and don't require to make an unneeded distinction between them <nckx>Because it's not a bug, you just wish it were so you wouldn't have to argue why your suggestion is better (which you've so far failed to do with the misleading (point…) example). *unmatched-paren tries something... <nckx>And I'm not going to join in if it's about winning at any cost. Sorry. ***daviid`` is now known as daviid
<Lumine>I tried something today too, and failed. But I learned! <abrenon>I'm not trying to win anything, I'm perfectly fine with the fact that people can see it as the best design choice <unmatched-paren>like several other problems with guix: annoying, but very difficult to elegantly fix <abrenon>is it a guix thing ? isn't that how records work in guile in general ? <nckx>abrenon: OK, fair. ‘Surprised to find such a bug in guix’ is pretty loaded language to me, is all. <abrenon>that's the second time you've used this expression, what do you mean "fleshed out" ? <nckx>Playful winks over text are dangerous at the best of times. <abrenon>especially since, as I've written above I thought it was a guile thing and not a guix thing <unmatched-paren>abrenon: something is considered "fleshed out" if it supports a wide range of useful features <unmatched-paren>Anyway, the guile records are constructed like so: (package "hello" "1.2.3" (origin ...) build-system ...) <abrenon>I guess I was just live-IRCing my disappointment at getting slightly less ignorant about how scheme languages can work and having to understand how deeply they differed from the other functional programming languages I'm more used to <abrenon>I was wary from the start for the lack of types, but it's even closer to Javascript than I originally thought ; ) <abrenon>unmatched-paren: ah, that's better, now that's pure and unsurprising : ) <unmatched-paren>(define-record-type <foo> (make-foo bars bazzes quuxen) foo? (bars foo-bars) (bazzes foo-buzzes) (quuxen foo-quuxen)) <nckx>abrenon: I can actually sympathise. There were a lot of dreamy (and almost certainly internally inconsistent) ideas I had about Lisps when I switched to Guix. Like everything would somehow magically know everything it would need to and somehow do the right thing and… This was coming from Nix, where attrsets do have that property sometimes, but unpredictably and poorly. Still took me a while to adjust to the reality, even though it didn't end up disappointin <nckx>It's not a bug, just a wart. <nckx>I guess the difference is it's part of you and you still love it and feed it and oh god ew ew ew. <apteryx>nckx: on berlin, the sshd process doesn't start on login (it's delayed too). points to a inet/pam problem, perhaps? <abrenon>I'm glad you can sympathize, and I like where you draw the line between bug and wart <unmatched-paren>(define-record-type* <foo> foo make-foo foo? (bars foo-name) (bazzes foo-bazzes) (quuxen foo-quuxen)) <nckx>apteryx: Everything kind of points to that, no? I'm not really sure where to look, though. TBQH, I tend to opt out of debugging networking/IPC stuff when I can get away with it… <unmatched-paren>but the guix records support many additional attributes in the field declarations <nckx>I'm also just not good at it. <unmatched-paren>and you can define "sanitizers" that are applied to the field's value <Lumine>nckx: did you figure out the missing bind package in emacs? <nckx>Lumine: It's not even ‘missing’, it's right there, bundled with use-package by the way. <Lumine>So somehow use-package is not acknowledging it? <nckx>PSA, and why I was briefly here in the first place: if you run Tor, you should stop it, run ‘guix pull’ instead, update Tor and make sure you're running 0.4.7.10. Even if you updated Tor yesterday. *unmatched-paren guesses and looks up 'tor cve' <Lumine>I'm drinking coffee and pretending I understand Guix <abrenon>apteryx: so a login must be performed physically on the machine before sshd starts ? <abrenon>unmatched-paren: thanks for the explanations about records <abrenon>though I still have to look thunks up <apteryx>abrenon: sorry, I wasn't clear. There's a problem on berlin currently that delays SSH login by about 30s. <unmatched-paren>thunking something = wrapping the thing in a lambda to stop its evaluation <Lumine>unmatched-paren: I basically hopped unto Guix wagon when I was still learning Linux, and I also happen to be very slow in learning :D <Lumine>So I'm just slowly taking everything in <unmatched-paren>Lumine: Well then, you won't have to unlearn things about traditional distros :P <apteryx>abrenon: sshd is now using an inetd style service, which fires it on demand <nckx>apteryx: Actually, no, another hypothesis that occurred to me y'day was that sshd was looking up PTRs for new connections and they were somehow being blocked on the MDC network (even though that would make no sense) and timing out. So sshd not starting does rule that out. Thanks. <Lumine>You could say that I'm a regular user that wants to learn Lisp but is having problems with basic concepts <unmatched-paren>Lumine: Which ones? Many of them look complex and mind-bending but are really simple once you get into them. <nckx>Lumine: <I'm drinking coffee and pretending> That is most of us here though, we just have various levels of pretending. *nckx really flies away now. <unmatched-paren>The only person who actually 100% understands guix is ludo, probably :) <abrenon>ok, so port 22 open, but daemon off, and spawned when packets arrive <Lumine>But I did learn how to change default shell today in Guix to something other than bash, just haven't figured out how to manage and make it co-exist with bash inside guix home yet <apteryx>abrenon: yes, excepts there's some unexplained 30 s delay between both (connection established to port 22... time passes... sshd launched) <abrenon>has anyone already logged in been able to strace the process spawning sshd ? <abrenon>couldn't it be some sort of reverse DNS misconfiguration or something ? <abrenon>it sounds like a symptom I once had in a VM, but that was an ugly systemd mess IIRC <pkill9>some people seem to think guix is some kind of virus, seeking to take over the world, but that's wrong, guix is just a tool... a tool for guile to take over the world <rekado>etc/committer.scm has some code to edit S-expressions, whereas the updaters use text-based editing. <rekado>perhaps we should move some of that editing code from etc/committer.scm <rekado>and then there’s the stuff used by “guix style” <tschilptschilp23>Does anyone know what the 'checkout' in ~PACKAGE-VERSION-checkout~ tells? <unmatched-paren>tschilptschilp23: that the output path you're looking at is a source checkout, not a package output <tschilptschilp23>unmatched-paren: thanks! I obviously once more forgot about guix-weather ;) <efraim>lilyp: it doesn't actually update the pacakge to 1.72.0, just adjusts the patch <lilyp>oh... someone else already updated it and I didn't notice <apteryx>abrenon: the process spawing it is PID 1 (shepherd); I tried stracing there but it's noisy <abrenon>so it's not a pam module directly spawning it ? <abrenon>no I'm still confused about this, how can PAM be called before sshd ? <apteryx>it uses a near-vanilla openssh-service-type from (gnu services ssh) <apteryx>and has a new enough Shepherd version to leverage the make-inetd-constructor <abrenon>oh, so inetd is the one asking shepherd to spawn sshd <apteryx>I think the way it's implemented by Shepherd, shepherd does what initd would normally do <apteryx>it listens to the port itself and spawns itself <abrenon>well seen from the outside, yes, it would appear so <apteryx>it listens for any interface on both IPv4 and IPv6 <apteryx>shepherd immediately accepts the connection and writes "Service sshd-5188 has been started." <apteryx>(with no actual sshd process spawned) <apteryx>hmm: 12.9g 12.3g 100.0 6.5 1:12.88 R shepherd <Not_Leader>wondering so i know if it should go in the main guix channel <nckx>Not_Leader: I see no reason why it wouldn't be, barring hidden blobs in one of the many source files (which I didn't audit). Have you already packaged it? <nckx>Well, I asked because it's .NET, which can't be the best mode of Guix packaging fun. We do have mono. We have mono from 2016. Go mono. <nckx>I don't know if mono is even close to being all you need to package .NET. <alethkit>Would it be a weird idea to mix Guile and Dhall together? Having guaranteed termination does sound very appealing. <unmatched-paren>(Also: on first sight, Dhall is (1) not extensible, (2) extremely complex, and (3) has yucky Haskell-like significant whitespace, all three of which aren't anything like Guile :) <apteryx>nckx: and it's built from binaries. perhaps we should drop it <nckx>Right. There's usually a theoretical path forward, but… <nckx>At your leisure, of course. <nckx>Anyway, big ups from me on dropping it as it is now. We pretend not to notice binaries when they are critical to the graph. Mono never has been that. Although it's not the leaf I expected it to be, either, seems like we'd lose a handful of mostly IM & gaming-related packages. Nothing major though. <apteryx>seems it can be worked out via some manual hacks (Debian apparently does so) <apteryx>Any other opinion about including trained data models from tesseract? It's licensed Apache 2.0. <nckx>Random .*mono.* dependencies of that are anywhere from 4.x/5.x/6.x. <nckx>Ah, 4.0 is the ‘CLI [run time] version’. <apteryx>wouldn't surprise me after reaching 13 GiB <nckx>One would expect a 50x, not a connexion error if that were the case. <davidl>nckx: hi, any status update reg. bash-bcu? <nckx>apteryx: Are you SSH'd in, at least? <nckx>apteryx: I'm getting ‘no route to host’ errors. <ggoes>yeah i just checked the channel because i'm getting the same error <podiki[m]>sites were slow in last several minutes, just noticed it went down <davidl>unmatched-paren: thx for your help with packaging tern (node package): I got a bit further - now Im stuck again :-( node-deno fails in the install phase with: "npm ERR! enoent ENOENT: no such file or directory, chmod '/gnu/store/0nkx2qm0b1k9lbhfajn4jd48nlxk8593-node-deno-0.1.1/lib/node_modules/deno/try-deno'". There's a bin file mentioned in package.json but Idk how to make it appear basically, https://github.com/YounGoat/nodejs.deno/blob/ <nckx>I'm at the serial console but can't get a prompt. <nckx>apteryx: OK to hard-reset? <unmatched-paren>davidl: Looks like it wants you to have installed try-deno so that it can... uh, perform the installation phase... <nckx>Is this a Node parody package? <nckx>Server power operation initiated successfully. <nckx>davidl: I've been kind of disappointed by the lack of feedback I got from the folks I pinged (I understand it's a weird package and we might be trying too hard to get things just right, but still). <nckx>I think I'll just finish up ‘our’ version and push. I'm in that kind of mood. <davidl>unmatched-paren: me neither, but it's mentioned in package.json, and if it's not significant, maybe I can just substitute* it away. However, i don't know if it's significant or not :/ *unmatched-paren looks at npm docs for package.json's "bin" <dirtcastle>I'm trying to hack on guix home. but andrew tropin's repo is not geiser compatible - meaning geiser -edit-symbol-at-point doesn't work because of the way the directories are structured. I'm emacs , lisp, scheme and guix noob btw and trying to learn thank you very much. <davidl>nckx: ok, thanks for letting me know what's going on. <apteryx>nckx: fyi I sent an email to guix-devel + mono issue about my proposal to remove the packgae <nckx>apteryx: Boot failed: Guix <dirtcastle>I am interested in implementing features. unmatched-paren <apteryx>nckx: neat. so you boot in pxe boot image and copy things by hand? <nckx>apteryx: Basically. I'm booting Ubuntu as we speak. <dirtcastle>like way to configure application through guile uk <apteryx>nckx: so I guess it was reconfigured :-/ <unmatched-paren>dirtcastle: oh, you want to add support for a new application configuration? <unmatched-paren>what you'll want to look at is gnu/home/services/*.scm in the guix repo <unmatched-paren>which will show you how to construct a dotfiles service with configuration <apteryx>nckx: would you mind keeping the commands used to send to guix-sysadmins in case someone else need to do it next time? <davidl>unmatched-paren: do you think itremove it then <nckx>Sure, if I can remember them. <dirtcastle>do I have to clone the repo or does it come with guix <devmsv>nckx: I know you are fixing berlin server. the web guix.gnu.org is down worldwide or just in Europe (I can't access right now) <unmatched-paren>make sure to read the contribution guidelines *thoroughly* to minimize pain :) <nckx>devmsv: World-wide baby. <unmatched-paren>i don't think it's possible for a single server to be up in one region but not in another. <nckx>None of that fancy big-city nonsense for us peasants. <nckx>apteryx: There are no missing files on the boot drive. I need to think, and I won't be liveblogging here whilst I try stuff. TTYL. <unmatched-paren>If you have multiple patches, you'll need to send one email to <guix-patches@gnu.org>, then wait for the debbugs (bot|daemon|mailer) to respond with the issue number <unmatched-paren>if you send them all to <guix-patches@gnu.org>, you'll create an issue for each one <unmatched-paren>a good way to do it is to use `git format-patch --cover-letter`, and send that as the first mail <unmatched-paren>which provides a summary of the patchset and allows you to write an introduction <unmatched-paren>also, there's apparently a better way to use `git send-email` than that recommended by git-send-email.io: instead of HEAD^~<number>, use -<number> <nckx>apteryx: Have you ever successfully pressed the virtual F11 to enter the ‘Boot Manager’? It doesn't do anything. I can enter the firmware setup with another Fn key (I forget which, but that one). <nckx>This 👏 is 👏 the 👏 GNU 👏 system 👏 welcome <dirtcastle>I have rudimentary knowledge of git, programming, guile. but I noted Everything you said. and the future (hopefully) Knowledgeable me will definitely look into everything you said , after coming up with something useful enough to make a pull request and get it merged. <nckx>Web sites should be back up. <unmatched-paren>Git does have a notion of sending "pull requests" over email, but that seems to be an advanced feature that isn't often used. <unmatched-paren>`git request-pull` allows you to send an email that literally requests that the maintainer pull some commits from your repo into theirs. <nckx>Linux uses it, it's ‘advanced’ in that it happens between subsystem maintainers, not randos like on GitHub. <nckx>apteryx: I think it's a timing issue. <unmatched-paren>dirtcastle: The `send-email` and `format-patch` "patchset" features allow you to send some emails containing .patch files in the universal format, which the maintainer can then apply with `git am` or `git apply`. <dirtcastle>nckx: most ppl I know irl do. emacs YouTubers introduced me to sourcehut. i didn't know u can do it through email until then <dirtcastle>what does am stand for. my guess is apply modification <unmatched-paren>funny/terrifying how github successfully became the only way to use git that many people know <nckx>dirtcastle: ‘Most people’, numerically, sure. Big difference. <unmatched-paren>dirtcastle: It allows you to take a `.mbox` (mailbox) file full of emails containing patchsets and apply it to a repo. <nckx>dirtcastle: You seem to assume all projects use GitHub. <unmatched-paren>dirtcastle: I would advise you read about Git's more advanced features, it's actually a really cool and elegant system once you get to know it <nckx>Lots of huge projects (and many more small ones) don't. That's why git is designed for e-mail in the first place, because it's mainly used over e-mail. <dirtcastle>unmatched-paren: I was committed to reading through git manual fully. my friends told me it's not worth the time. <unmatched-paren>The manual, maybe not. But your friends are mistaken if they think getting to know git properly isn't worth the time. *nckx → work, ping me if needed. <nckx>dirtcastle: Keep in mind that your friends might not know what they are talking about. <dirtcastle>nckx: I thought github and gitlab are most used.TIL I know gnu uses Savannah. <unmatched-paren>i think the software freedom conservacy is actually urging people to get rid of github now (because of copilot) <unmatched-paren>because it uses google cloud stuff (so there's tracking) on the gitlab.com site, and gitlab.com uses the proprietary version of gitlab (called "GitLab EE") <apteryx>gitlab won't even let you sign it without the right user-agent, yay <nckx>dirtcastle: Oh, I'm sure ‘most used’ is true, I'm sure! Doesn't mean other things are automatically true because of it. <unmatched-paren>obviously, *if you can afford it*, self-hosting something like cgit is probably best :) <nckx>I haven't been able to sign into GitLab.com for years. <nckx>So they seem to be doing great 👍 <dirtcastle>I like selfhosting. but I don't have the skills. guix is the best tool a sysadmin can have. <nckx>apteryx: Are you SSH'd in? <nckx>Just saw a ‘ocalhost sshd[6785]: error: kex_exchange_identification: Connection closed by remote host’ and want to make sure. <apteryx>nckx: in icecat, using the User-Agent Switcher plugin, I choose Linux / Firefox 83 for that site (gitlab.com), then it works <unmatched-paren>the horrific thing is that most people won't actually do anything about it <apteryx>nckx: I'm not curretnly connected, but perhaps I had an ssh pending <nckx>Or it was a random bot or anyone else on earth. <nckx>I just SSH'd in… stantly. <apteryx>so, shepherd's operation degrades over time <nckx>I am the greatest fixer of all things. Bow before me in puny submission. <apteryx>and eventually it stops working altogether <apteryx>reminds me I should hack that standalone? flag <apteryx>but that wouldn't have helped here.. hm <apteryx>so what was the issue? do we know? :-) <apteryx>(about the boot not working the first time) <nckx>I'm OK with the degradation hypothesis, but it was pretty consistently ~30s from when it started till when it crashed. <apteryx>I don't recally it was slow when we first had it working <nckx>I didn't mean that, just that there's no report of any point where there was a 1…29s delay. Nor did the delay increase today, whilst Shep was presumably dying. <apteryx>it was at like 40 s per the last strace I sent <dirtcastle>unmatched-paren: what is this sr.ht services you are talking abt? the way to selfhost them? <apteryx>so it did increase (it was more like 25/30s earlier) <nckx>The first day it was reported here I got results 27s…33s. <nckx>‘Like 40s’ is certainly longer but I'm sceptical that it's significant at all. But I certainly don't know more than you. <nckx>Actually it was more like 27s…35s at the long end. <nckx>It's very hard to test because of the ‘brute force’ iptables filter. <dirtcastle>they have packages for it right? writing package definitions for them is hard?. I'm too noob to understand why it's a hard problem? unmatched-paren <nckx>s/because of/without disabling/ <dirtcastle>recommendation for resources to learn guile scheme? I'm currently reading the reference manual. <unmatched-paren>you have to set up various core services before you can get things like git.sr.ht and paste.sr.ht up <unmatched-paren>the reference manual is okay for figuring out specific procedures and macros, but it's better to use a guided tutorial for getting started <unmatched-paren>like, it tells you what proc X does, and what purpose module (foo bar) serves <dirtcastle>I tried to learn how to setup email server. they say it's hard because of lots of moving parts. is this like that? <unmatched-paren>Although trial and error is a good introduction to many things, that's how i learned guile and guix :) <nckx>Is there even a ‘sr.ht’ (you know what I mean) *package*? <singpolyma>It would be a suite of packages / a manifest / a set or services <nckx>= (you know what I mean) <unmatched-paren>There's things like hub.sr.ht (provides the stuff that appears at https://sr.ht), hg.sr.ht, paste.sr.ht, git.sr.ht, scm.sr.ht, meta.sr.ht, core.sr.ht, man.sr.ht, lists.sr.ht, builds.sr.ht, and todo.sr.ht <nckx>unmatched-paren knew what I mean. We r best buds. <dirtcastle>I suspect a docker container already exist for it <unmatched-paren>i think chat.sr.ht is a seperate package (gamja) that isn't developed as part of sr.ht <unmatched-paren>dirtcastle: Using a docker container entirely circumvents Guix's services <unmatched-paren>And dispatch.sr.ht, but that's getting deprecated and eventually removed. <apteryx>nckx: to test, I just 'ssh localhost' locally on berlin <nckx>apteryx: Duh. I forgot that it happened everywhere. <alethkit>unmatched-paren: By not being Turing-complete <alethkit>It's just that I needed something to model g-expressions with <unmatched-paren>Without Turing-completeness, we couldn't execute arbitrary build code :) <dirtcastle>I think native package preferably managed by guix is superior to containers <unmatched-paren>alethkit: Executed at build time, sure, but still turing-complete Scheme. <alethkit>I guess I'm going to have to muck about for a while <dirtcastle>alright,it's 2:30 am here. gotta sleep. good night folks. learnt a lot today. thanks for your time folks. thanks to guix. <3 <nckx>apteryx: Pretty sure the firewall applies to localhost too (didn't check, not going to debug it now). <alethkit>unmatched-paren: I have, yes. The issue is that I have non-Guix tools to integrate with <alethkit>unmatched-paren: The Greek helmsman, to be precise. <alethkit>Otherwise, I would be in Guile all day long <pkill9>guile is too powerful for humans <pkill9>the gods themselves accidentally dropped it into the mortal world <nckx>For his crimes, Prometheus was chained to a rock and forced to write npm packages. <oriansj>odd guix has greetd but no greetd front-ends