<apteryx>lle-bout: for long url I typically break them with a \ escape, continuing on the first column of the next line.
<aaauser>on my computer, i want to update a library package and recompile all installed programs depending on it. is there any way to do this? I can make a package variant in my local channel with the update, but other packages still depend on the old version from guix.
<jackhill>(I don't have a good example at hand, unfortunately, so I think you'll have to be at the mercy of the manual ☺)
<aaauser>Those work, but you have to use those options manually to build with the modified version. I was hoping there was a way to automatically rebuild them all as if the original library definition changed. Thanks anyway though.
<aaauser>I think I'm probably going to try to clone and automatically patch a local copy of the guix repo.
<jackhill>aaauser: yep, that's definitely one way, and may make the most sense depending on what you're really trying to do. There's also a way to do it with scheme code that you could use with a manifest. The documentation for which is evading me right now…
<jackhill>ah: here's what I was thinking about. see the options->transformation procedure. You could then map the tranformation over a list of packages.
<ryuslash>Hello :) I don't suppose anyone who's knowledgeable about the go-build-system is online right now?
<jackhill>ryuslash: I once added the env var to it to set GO111MODULE=no to preserve the old behaviour when working on a go update, but I don't know if that's the sort of knowledge you seek. What are you trying to do?
<ryuslash>I'm guessing it would be too simple to think that changing the variable you added to on and changing the union we make to tmpdir/pkg/mod/ would be enough to make things work? I'm guessing the problem with the go modules was that Go would try to download them during build?
<jackhill>ryuslash: yay, improvement of the go build system would be most welcome! My feelings alight with Leo's last comment that it might be easiest to start with at new build system (of course looking at the current one). I think the problem is not even that finding the expertiese in the current build system, but expertiese in how go wants to do things post moduels.
<ryuslash>post-modules? Are they planning to move to something else already?
<jackhill>It would be intereresting to know if the minimal change you proposed would work, so that could be a good place to start. Otherwise, if you could document what needs to happen to do module-aware go building and share that on guix-devel@ you might find the needed help.
<ryuslash>To be honest though, I don't know much about Go, I haven't tried anything with it I think since it was still in Beta or something
<jackhill>ryuslash: no, I ment post-modules as in after the change to modules (where before modules existed, I would call it pre-modules)
<ryuslash>I just really want to update Syncthing :) (and learn more about Guix)
<jackhill>ryuslash: cool. IRC is more active daytime European time as well
<ryuslash>Yeah, I try to be online, but during work hours I'm frequently just too busy to even log on
<jackhill>Amusingly, I worked on that one go upgrade becasue I was thinking about getting more into go, and wanted to start with a module-aware version, so I could learn the new thing, but I got distracted by other projects before really learning go…
<ryuslash>yeah, I've been getting distracted a lot by other things and it's making me feel bad. I really do want to try and do this if I can.
<ryuslash>I just have too many things I want to do :)
<jackhill>haha I know the feeling. Hopefully it will at least be enjoyable to work on.
<ryuslash>It's in guile at least, how bad can it really be :D I need more Lisp in my life
<jackhill>lfam: we were just talking about https://issues.guix.gnu.org/45476 Vaguely, well, what a module-aware go build system would be like :) Although, I guess you said you were burt out on go for now, which is fine.
<jackhill>I don't want to punish your other good deeds with more go thinking :)
<lfam>Oh cool! I'll read the logs, but might have much to contribute on this topic
<ryuslash>lfam: that would be cool, I'm still trying to figure out how things fit together and what needs to be done. so far I'm hoping that I can turn on modules and change the unioned directory to put everything under tmpdir/pkg/mod, assuming that the issue was that Go tries to download things during build and not something else. But other than that there doesn't seem to be anything that I can see so far that gives us a whole lot of control
<tissevert>still lost with this custom init system, herd: I tried to replace network-manager by connman in my config.scm, now I don't see any of them in herd and I still got nm-applet in my systray somehow ^^
<tissevert>I read gnu/services/networking, so the definition of connman but that doesn't really understand what is (not) going on
<leoprikler>I wouldn't be surprised if nm-applet was somehow propagated by GNOME.
<i1l>why maintain init at all? either upstream did supplied a unit file, or someone asked them to do so, or maked a package "service-this-thong". then make a 'union-services for oprenrc, runit, systemd, and shepherd.
<i1l>after all, if someone uses non default init, that is not a maintainers, or Guix, but community (the exact users) issue.
<i1l>who need them, those will make. no maintenance..
<i1l>used on Alpine. openrf upstream initscript was not designed to deal with subvolumes of btrfs.
<lle-bout[m]>I don't feel like messing with the init stuff of GNU Guix is at my fingertips now, it's not as easy as you make it sound
<i1l>.. so my mount options were not applied if i used a subvolume as /.
<kisaja[m]>Ill probably try my best because of freedom and security
<lle-bout[m]><kisaja[m] "We all know we dont want systemd"> I don't get behind the arguments against systemd FWIW, it's a good init system to me, just there's so much more to do with GNU Guile and the Shepherd vision I feel
<i1l>last man tried to support systemd here seems disappeared. blackbeard?
<raghavgururajan>sneek, later tell lle-bout: I think we could merge (after test-build) the gst patches to master instead of c-u, because, it indirectly enables A/V support in XMPP clients like Gajim. WDYT?
<raghavgururajan>lle-bout[m]: Cool! Btw, I think we can divide and conquer in this way: I can take care of updating/patching packages from the chart. You can take care of updating stuff to make sure that the branch as whole builds. Sounds good?
<efraim>If I want to use GUIX_DAEMON_SOCKET on Guix System I suppose I should just remove the guix-configuration service and add an environment variable
<efraim>if guix by default has a daemon socket at /var/guix/daemon-socket/socket and I export /var/guix over nfs then I suppose I could point GUIX_DAEMON_SOCKET at "unix:/var/guix/daemon-socket/socket"
<cdegroot_>efraim: the reason to use unix domain sockets is speed/overhead, nothing else. If you only need localhost, it's the quickest portable way and you don't need to deal with IP or even TCP overhead.
<davidl>I sent a patch earlier today, should I just wait for someone to review it, or ask someone here with commit access? (I sent one in the past that never got a reply)
<i1l>davidl: link? commiter usually dare to review, if that is not a cat in the bag deal.
<i1l>post a link here as a bait for a commiter.. sometimes people catch fat ones
<i1l>mine catch has 4 letters long nick. but they escaped.
<Noisytoot>What's the difference between guix.info and guix.gnu.org?
<ennoausberlin>Hello. I wonder if there was a mongodb package. I can not find it anymore
<nckx>ennoausberlin: It was removed because the last free version no longer received upstream security attention.
<nckx>i1l: I'm going to try to rewrite it by parsing vsftpd.spec ourselves, instead of relying on a brittle hard-coded list of ‘all patches’. And hope to get rid of the git stuff too, although davidl probably had their reasons?
<davidl>nckx: I know the package def is quite ugly. I am a guile noob, so this was a quick way to go about this. I was not aware of the patch procedure. The patches need to be applied in order written (there are multiple 0001-....patch files) - maybe the patch procedure can handle that if you also manage to read the patch-list in order from vsftpd.spec.
<davidl>nckx: I was perhaps too eager to submit a patch, and should have worked on it longer. OTOH, getting the reviews is very helpful to learn more.
<davidl>nckx: I don't know myself what el8 signifies
<davidl>nckx: I wish I didn't have to put a let clause inside the replace 'unpack lambda procedure for the version variables, but didn't know how to make the more top level let provide variables for inside that lambda procedure.
<nckx>davidl: That's all right! I noticed that Scheme was not your native language after asking those questions. The good news is that this means you can delete a lot of stuff 😉 No need to (let ((version ...))) again, for example, just use ‘,version’.
<nckx>My psychic powers would have been more impressive had I hit Send sooner.
***Noisytoot is now known as noisytoot[x]
***noisytoot[x] is now known as Noisytoot
<clacke>civodul: no mean guix.info is the short one that redirects to guix.gnu.org saving me two keypresses
<davidl>nckx: By the way, if this rpm package gets accepted: it may instead be better to extend or modify the 'unpack phase in gnu-build-system which looks at the suffixes, and do unpacking there. If there is a pattern in how the unpacked rpm package provides patches and the source-code tarball inside, we could perhaps make a more general solution for rpm-packages.
<nckx>Meaning to impugn my own lazy use of SYSTEM; not your original, davidl.
<davidl>nckx: for example; inside the rpm package there is vsftpd-<version>.tar.gz, which is perhaps standard place for the package source for rpm (I haven't checked), and the vsftpd.spec is probably standardized too like <package>.spec.
<apteryx>raghavgururajan: i've found out that it works if I add a sip: URI and specify which proxy to use (e.g., sip:XXXXXXXXXX@my-proxy-url); there's a discrepancy between the UI (does that for me) and the CLI (doesn't).
<apteryx>leoprikler: do you still see value in https://issues.guix.gnu.org/45316 ? I'm not sure I do. The affected packages were very rare IIRC; our original idea to fix them up on a case by case basis still sounds like a better idea than introducing extra complexity. There'd be many packages to adapt for the reintroduction of a subdirectory too.
<apteryx>It's nice to have this clever option ready to test should the problem become serious though!
<apteryx>civodul: just sent a rebased version of the append-separator? patches; it's for core-updates, haven't retried it there but the resolved conflicts were simple to resolve, so I'd expect it to work as it used to.
***to-hu1 is now known as to-hu
<rekado>civodul: let’s do that and pay 2800 EUR ;)
<efraim>Actually it'd be a better deal to front them 280 years of Guix Europe membership
<rekado>this is convenient because you can use Guix on the installation of Guix itself
<link2xt>yes, there is my updated guix which I pulled with guix pull
<rekado>e.g. to roll back to a previous version etc
<rekado>the ~/.guix-profile location is where *you* install packages with Guix.
<rekado>so you need two things: ~/.config/guix/current/bin should be first on PATH (so that you can use the freshest “guix” command), and the variables defined in ~/.guix-profile/etc/profile need to be set
<rekado>so in ~/.bash_profile you should also have “GUIX_PROFILE=$HOME/.guix-profile” and then “source $GUIX_PROFILE/etc/profile”
<rekado>don’t worry about GUIX_PROFILE being used a second time; the variable is not exported, but it is checked when sourcing the etc/profile file.
<lfam>For a distro that is assembled in such an ad-hoc way, I hope they would be flexible about this kind of thing
<lfam>Although I understand the value of deadlines and process, too
<leoprikler>apteryx: w.r.t. 45316 the fix I'm trying to push (not in git terms, at least not yet) is mostly backwards compatible – i.e. it shouldn't matter if a package doesn't use a subdirectory at all
<leoprikler>what does change are hardcoded paths for packages, that now install to subdirectory, which is to be expected
<leoprikler>in particular, we still use EMACSLOADPATH to detect site-lisp, but none of its subdirectories
<leoprikler>Adding direct store paths should also improve UX in the 47458 sense.
<malik>im trying to define a new guix package, and if i dont have the sha256 line i get an error missing field initializers (hash) and if i include it it extraneous field initializers (sha256) ? I'm sure its something obvious, but I'm building off the seeminlgy offical hello package example