IRC channel logs

<apteryx>I think Software Heritage has limited support for some kind of archives?

<apteryx>not sure if crates are, but worth checking

<aarcov>I think crates are distributed as tarballs if I recall correctly, although they might have a separate tracker for the site

<aarcov>Does anyone know if I have some updated crates to add, if I should submit them to the normal master or the separate rust-team branch?

<ryan77627>For anyone that has the same service issue as me: Turns out I just need to set the kill-user-processes? boolean to true for the elogind service type and that should handle everything shepherd leaves behind

<aarcov>Is there a way to declare a package as deprecated in its definition? I've seen some examples were a package has been sort of 're-cast' as deprecated (like this: `(deprecated-package "python-google-brotli" python-brotli))`), but not where it was declared so in its definition (I'd like to do something like `(define-public (deprecated-package <stuff>))`)

<aarcov>Although, I don't think I have tried to do something like: `(define-public (deprecated-package (package <stuff>)))`

<aarcov>I'd like to be able to use this as some packages have had bugs identified in newer releases, and the newer releases were yanked with the intent that people continue to use the older versions (till an even newer release is added) and I'd like to be able to indicate this

<lilyp>aarcov: We have ways to define variables as deprecated, but the deprecated-package mechanism is about pointing to other replacement packages

<lilyp>I don't think 'tis a great way to indicate yanked releases. Perhaps we ought to have a property for ignored releases if the refresher otherwise produces garbage

<hapst3r>nckx: ah well I dont have a checkout (guix repo code on hard disk), only have guix installed as a package manager on a foreign distro. There, I needed sudo grep to find stuff in ~/.config/guix/current, without grep it wouldn't return anything.

<hapst3r>However this touches another subject I'm interested in: I always had Guix as Code and Guix as Package Manager/Distro, a duality I find irritating in the face of Schemes Code as Data Paradigma. Is there a way to "link" a checkout to the distro and/or package manager so that changes I make to the code become available to the distro at large? Or is this where channels and/or sent patches come in?

<aarcov>that's true, as it isn't exactly a deprecation

<aarcov>I was thinking of providing a way to allow the package to continue to exist (sometimes they're pulled for an unintentional semvar breaking change) so that items that specifically depend on it (and were made to work with it) can continue to reference it, but it is also prevented from being part of automatic updates

<aarcov>For example rust-chrono had a semvar breaking change at around version 0.4.30 that was intentionally made (annoyingly) because it is/was predicted to negatively impact only a few public packages that used the removed/changed interface

<aarcov>basically, some way to handle things when a package is considered to not be recommended for general use, but might still have some stuff that depends on it (another things is when some packages seem to be stuck in a perpetual 'release-candidate' phase and keep having breaking changes, but insist that they are still part of the same version...)

<ennoausberlin>I wonder why the search function in irc logs only delivers results up to 31.01.2023. Everything newer is not shown

<ennoausberlin>Or at least most of the time. There is something broken

<jpoiret>hapst3r: if you *need* sudo to searh in ~/.config/guix/current, it's maybe because you've `sudo guix pull`d before, and so the permissions on the symlink are borked

<futurile>Morning guix people

<civodul>Hello Guix!

<futurile>morning civodul - 45 people at the patch-review session - it was a disorganised - but just the first one - so a great turn-out!

<civodul>futurile: woow, well done!

<civodul>impressive

<civodul>really grateful you folks are taking care of this

<jpoiret>futurile: what, that's mind-boggling

<jpoiret>sorry i couldn't make it, I realized the session was 1 hour later than I had written down so couldn't

<futurile>I hope it was OK - it was a lot more than I expected - we didn't actually manage to review patches - next time arun / fnat suggested we got to break out rooms much faster

<futurile>so you probably didn't miss too much jpoiret - but come along next time - it was fun to see so many people ;-)

<hapst3r>futurile: I had a good time and was happy to take part in a "community event". If I can make time I'll be sure to attend in the future :)

<hapst3r>But yes, I think earlier and/or more breakout rooms is a good idea. Currently a lot of people (me included) yearn for more input, and I am unsure how to cope with this information asymmetry that currently prevails in the project (which is not by design but by way of some people knowing a lot more than others)

<hapst3r>I think

<futurile>hapst3r: thanks - that's great feedback - it's good to know how everyone experienced it.

<futurile>hapst3r: I was thinking of breaking into three groups for next time: (1) new people that want to get dev set-up and/or watch a basic patch review process (2) people that want to do some patch reviews from the list together (3) hackers that want to hack together (like irc but by video)

<futurile>hapst3r: if we can get more experienced people to give feedback on specific patches that would be cool - maybe a list on the wiki asking for feedback on patch xxx

<hapst3r>futurile: yes, this tripartition seems like a very good idea!

<jpoiret>futurile: do you create a new worktree for each patchset?

<jpoiret>seems like a lot of effort

<jpoiret>i usually create worktrees just for other branches

<yelninei>hi, im trying to build something and the configure script fails with: "ld: cannot find -lcurl-gnutls: No such file or directory". I already have curl as an input and curl seems to be compiled with --with-gnutls. Any ideas?

<futurile>jpoiret: I have been - but I think I'm "doing it wrong" because then I have to bootstrap/compile guix each time - yesterday a few people who use worktree have them as 'long running' - that's going to be more efficient - so I'm goign to change

<futurile>jpoiret: I like keeping things separate though - it makes it simpler for my tiny brain to keep things organised :-))

<erikeah>Good morning to everyone! Anyone knows if something like nix-ld or nix-ld-rs is plan to be part of guix? I think it could be a decent solution for those binaries living outside of the guix ecosystem.

<jpoiret>yelninei: libcurl-gnutls is just libcurl

<jpoiret>it's an alias used by distros when they want to ensure it has been built with gnutls support

<yelninei>so i just should be able to replace 'curl-gnutls' with 'curl' in the configure script?

<yelninei>that seemed to have worked. thanks jpoiret.

<futurile>erikeah: haven't heard of that - you could look in issues.guix.gnu.org and/or ask on the mailing list

<jpoiret>hi from core-updates

<jpoiret>civodul: how does the locpath work on guix system? Is GUIX_LOCPATH supposed to be set?

<jpoiret>mine isn't on c-u and I get locale warnings

<jpoiret>once it's set to /run/current-system/locale it does

<jpoiret>oh no. is the hack in glibc's definition not working?

<erikeah>futurile: I will do, I will open a issue to request feature. I think it could be a good solution.

<civodul>jpoiret: GUIX_LOCPATH is the right one: it’s a versioned variant of LOCPATH

<civodul>but then, see the ‘locale-glibcs’ field of ‘operating-system’

<civodul>usually we had the previous glibc in there so that we get locales for both the new and the previous glibc

<jpoiret>right, but I'm on a generation with 100% glibc 2.39

<jpoiret>all programs (including my login manager) just spit out a locale warning

<jpoiret>if I do set GUIX_LOCPATH to /run/current-system/locale, they stop doing so

<janneke>jpoiret: curious if guix copy works for you

<podiki>erikeah: not sure what those nix things are, guessing a way to use a different ld loader? we do have guix shell --container --emulate-fhs which can help in running other things, though need to include dependencies and set up the container (sharing things from host)

<jpoiret>janneke: i'll try that once i figure out this locale thing

<janneke>jpoiret: in fact, they might be related, not so many other changes in guix

<jpoiret>oh no :(

<jpoiret>it looks like there's a != instead of a ==

<jpoiret>is GUIX_LOCPATH or LOCPATH set for anyone on guix system?

<jpoiret>janneke: can you help me debug those pesky locale issues?

<jpoiret>from my reading of the versioned locpath patches, both the original one (dating from 2015!) and the glibc 2.37 one are wrong

<jpoiret>but then I don't understand how the one used on master doesn't end up with the same issue

<jpoiret>basically, if neither GUIX_LOCPATH or LOCPATH are set, the default compiled-in locpath of /run/current-system/locale is *not* added to the internal searched locale_path

<apteryx>jpoiret: on my system it's set to $HOME/.guix-profile/lib/locale

<apteryx>I guess caused by a search-path on glibc or glibc-locales (I have glibc-locales installed)

<jpoiret>apteryx: right

<jpoiret>if you unset GUIX_LOCPATH and start a locale-using application (eg. Guile), do you get a locale warning?

<jpoiret>but I didn't have glibc-locales in any of my profiles iirc, so that shouldn't have applied to me

<apteryx>'GUIX_LOCPATH= guile' suggests no

<jpoiret>does that unset or just set to ""?

<jpoiret>AH, no I know why it was working before

<jpoiret>the patch was ~wrong but some later code in glibc managed to handle it properly

<jpoiret>basically in some other function (the one that actually finds the locale to use) if the internal locale_path was NULL the default one was used

<janneke>jpoiret: where is that faulty != / ==?

<janneke>faulty/suspect

<jpoiret>but now, with glibc 2.39 we always add an internal path to the location of the C.UTF-8 locale, so it's not empty, and the bit that added the default locpath isn't triggered anymore

<jpoiret>oh no, that's a world rebuild

<jpoiret>janneke: basically the line "+ if (*locale_path != NULL)"

<jpoiret>the (NULL, 0) argz list is a valid value, but here we somehow don't add the default path if it is one

<jpoiret>s/if it is one/if local_path is the zero argz list/

<jpoiret>I'll just rewrite the patch with the proper argz calls

<janneke>hmm, i'd need more context for that code

<janneke>if locale_path is unset, it could make sense you cannot add to it

<jpoiret>right. I think I've got it though, so all good :)

<janneke>good luck :)

<jpoiret>thanks

<old>is there a way to tell shepherd to way for network to be operational before starting a service?

<old>I have a service and it fails to start after reboot because DNS failed to resolve. I suspect that this is because my network device is not yet ready somehow

<ieure>old, There's a networking service which you can add to the requirements of yours. I forget the exact name, grepping the Guix code ought to turn it up.

<ieure>I'm on my work machine, which is primitive & incapable of running Guix (it's an M1 MacBook Pro (not my choice, I don't like it)).

<^chewie>Looking for some advice on a bootloader issue. https://dpaste.org/C15M1#L1 This is a new problem that started yesterday, but I had made no changes to the bootloader section since the beginning of this process, and as you can tell by the grub.cfg, there were many iterations prior to this issue.

<peanuts>"dpaste/C15M1 (Plain Code)" https://dpaste.org/C15M1#L1

<^chewie>tl;dr "grub-install: error: efibootmgr failed to register the boot entry: Block device required."

<^chewie>Looking for advice on where to dig into next.

<yelninei>it it possible to reset the numbering of the generations? i.e. i am at system generation 142 and would like the number to be smaller.

<old>ieure: inetd?

<old>hmm that's not a service I have

<ieure>old, No. It's something abstract, networking-service-type or similar.

<ieure>old, inetd is a daemon that launches other network daemons. It's uncommon to find on modern Linuxen.

<old>NetworkManager loopback wpa-supplicant host-name

<old>are pretty much everything network related I have with sudo herd status

<old>I guess I could check the ssh service at what it does

<ieure>old, https://guix.gnu.org/en/manual/devel/en/html_node/Networking-Setup.html#index-static_002dnetworking

<peanuts>"Networking Setup (GNU Guix Reference Manual)" https://guix.gnu.org/en/manual/devel/en/html_node/Networking-Setup.html#index-static_002dnetworking

<ieure>> provision (default: '(networking))

<ieure>That's what you want.

<ieure>It's a symbol provided by the service, there's not a concrete networking service type, since networking can be set up in multiple ways.

<ieure>You want 'networking in your service's requirements.

<ieure>Or, yes, look at how basically any network-dependent service in Guix does it.

<old>yes I just swa that

<old>greak thank you!

<old>is there a subset of it? For example I have a local wiki server

<old>I do not need the internet to be available, just local IP I guess

<ieure>I think internet connectivity of the network you're connected to is out of scope.

<old>okay

<ieure>Doubt anything provides that, but I could be wrong.

<old>hmm I forgot to mentionned that these are home services

<old>and networking does not seem to work with them

<old>will check the home-syncthing-service-type

<ieure>Yeah, was just going to suggest that.

<old>eeeh empty for home

<old>looks like home services does not have access to system services as requirements

<ieure>Why does your service depend on DNS to start?

<old>the wiki I suppose check for update (DokuWiki). I could probably turn this off in the admin pannel

<old>my other service is a dynamic DNS that ping porkbun to get my address IP and change my DNS record to match it

<old>I could just move this to OS service instead

<jpoiret>yelninei: you'd need to delete all generations to be able to restart the numbering. However, that evidently isn't possible :)

<yelninei>jpoiret: :(, i guess i have to live with big numbers sadly

<yelninei>jpoiret: it seems if you create a new link in /var/guix/profiles with the correct name (system-1-link, pointing to the same path as one other profile) you can then switch to generation 1 and then restart the numbering :)

<yelninei>(also works for user profile numbers)

<vagrantc>does "guix weather" use the same substitute servers as the configured guix-daemon ... or is it contacting the substitute servers directly?

<civodul>vagrantc: hi! starting from recently, it can use the same servers as the daemon and emits a warning if it could not determine what the daemon uses

<civodul>(because the daemon is too old)

<civodul>but i think we haven’t updated the ‘guix’ package since that change was made

<civodul>so you always get the warning currently

<vagrantc>thanks!

<vagrantc>i was just looking for a simple way to figure out which substitute servers are configured

<vagrantc>i think the current guix package in debian stable does not default to using bordeaux

<vagrantc>ACTION has some 1.8Ah cells waiting in a mailbox somewhere anyways

<civodul>vagrantc: i guess you could “pgrep -fa guix-daemon” in case --substitute-urls appears on the command line

<civodul>and otherwise check the package’s configure flags

<civodul>in case you know the package maintainer

<vagrantc>heh.

<vagrantc>i fixed it in a newer upload ... although it was long enough ago that i have to actually look :)

<vagrantc>but yeah, it wasn't showing up in the commandline argujments ... but i recalled that it had changed the default behavior at some point (e.g. without arguments)

<vagrantc>hrm. looks like i added to /etc/guix/acl ... hrm.

<vagrantc>hrm. maybe it is enabled by default ... strings on guix-daemon shows both substitute-servers on the same line

<vagrantc>i don't go out of my way to change that particular default with configure arguments ...

<vagrantc>hrm. i think they were enabled ... but it is harder to know for sure if o don't see it querying the other server

<vagrantc>matters more for arm64, where bordeaux seems to have a much higher hit rate than ci

<cbaines>vagrantc, best way to test is to guix build --substitute-urls=SPECIFIC_SERVER /gnu/store/...

<vagrantc>oh, yeah... i even tried that and it failed

<vagrantc>but maybe i spelled it wrong or something

<cbaines>given that the store path is something that you haven't got but is available to substitute

<cbaines>if guix doesn't start substituting, then that would suggest that the ACL is missing the bordeaux key

<vagrantc>should definitely have the key

<cbaines>could you post the full command you tried?

<vagrantc>hah. my attempt neglected the https:// part

<vagrantc>all is well... more-or-less. :)

<jackhill>Hi Guix, would it be appropriate to submit release candidates to guix-patches? Not to get them included in Guix, but to test the candidates using the QA infrastructure to report possible portability bugs to upstream potentially before the release?

IRC channel logs

2024-03-08.log