bug#68894: Prosody guix service required fixes.
On Sat, Feb 03 2024, em...@msavoritias.me wrote: > We could simplify it by a lot i think either way. Some ways could be: > > 1. Remove the opaque-configuration since it never worked for raw > content which does already. > > 2. Remove the ssl config section here > https://guix.gnu.org/en/manual/devel/en/guix.html#index-ssl > > nobody should be touching these settings either way. > > Personally I would prefer to have a scheme config but could go either > way. I use xmpp as my only-full time messaging and own the xmpp guix > room. > > This prosody service is going to be used for joinjabber which you can > see here btw https://codeberg.org/joinjabber/Infra > > I also have talked about a guix self hosted xmpp server for a guix > room so prosody would be used for that. > > My thinking is that yeah the xmpp support in guix is not great and > should be better. To that end in the short term I would be interested > in updating/maintaining/adding xmpp software/services to guix. > > Longer term as i wrote maybe also putting all xmpp stuff in a single > file. but that can come later 😄 An xmpp team would also be something > that could be done at some point. This all sounds good. I'm glad the service is used and I'll help you or review if you need! Cheers Clément
bug#68874: executing `/gnu/store/...-guile-3.0.9/bin/guile': Exec format error
Hi, On Thu, 01 Feb 2024 at 22:16, Josselin Poiret wrote: >> --8<---cut here---start->8--- >> $ /tmp/new/bin/guix describe >> /gnu/store/vqkjfl6ds3vdvig2x5pkvvzkc3wivrp0-guile-wrapper/bin/guile: error >> while loading shared libraries: >> /gnu/store/1gd9nsy4cps8fnrd1avkc9l01l7ywiai-guile-3.0.9/lib/libguile-3.0.so.1: >> file too short >> --8<---cut here---end--->8--- > > File too short sounds like store corruption, can you check whether that > file is empty? Maybe try gc'ing it and retrying? Indeed, empty: --8<---cut here---start->8--- $ file $(readlink -f /gnu/store/1gd9nsy4cps8fnrd1avkc9l01l7ywiai-guile-3.0.9/lib/libguile-3.0.so.1) /gnu/store/1gd9nsy4cps8fnrd1avkc9l01l7ywiai-guile-3.0.9/lib/libguile-3.0.so.1.6.0: empty --8<---cut here---end--->8--- However, I am not able to remove the item. I mean: I have tried many operations as “guix gc”, “guix gc --verify” with ’repair’ and ’contents’, remove some part of ~/.cache/guix and then “guix gc”, remove the complete ~/.cache/guix and then “guix gc”, rebuild the derivation with --check, etc. And the file is still empty. Arf, I spent some time to find which was retained it. Well, I did nothing special for that corruption. And once I had it, the process for recovering is not straightforward. Somehow, it misses helpers that maps item to profile. For instance, in order to find the culprit retaining the item, I did --8<---cut here---start->8--- $ guix gc --referrers /gnu/store/1gd9nsy4cps8fnrd1avkc9l01l7ywiai-guile-3.0.9 /gnu/store/1gd9nsy4cps8fnrd1avkc9l01l7ywiai-guile-3.0.9 /gnu/store/50vkm2fkk3aij8jc92phb3ahapn776m8-guix-command /gnu/store/fd744pmbhzq1avpjjsmfiasp7yqdmiwy-guix-daemon /gnu/store/vqkjfl6ds3vdvig2x5pkvvzkc3wivrp0-guile-wrapper $ guix gc --referrers /gnu/store/50vkm2fkk3aij8jc92phb3ahapn776m8-guix-command /gnu/store/fd744pmbhzq1avpjjsmfiasp7yqdmiwy-guix-daemon /gnu/store/icp4z3cxp0fibsm4j887nz8k56jc1jgi-guix-7bf8b7c33 --8<---cut here---end--->8--- then ’grep’ the term ’7bf8b7c33’ inside /var/guix/profiles/per-user. Well, it was retained because I did switch-generation. Anyway. Hum, it could be nice if instead: guix gc: error: cannot delete path `/gnu/store/…' since it is still alive it would also point the “profile“ (or profiles) that makes it alive. Cheers, simon
bug#68912: Guix-home search paths shadow .config/guix/current
Hi, On my machine the order of search paths are: $ echo $PATH | tr : '\n' /home/cdo/.guix-home/profile/bin /home/cdo/.guix-home/profile/sbin /run/setuid-programs /home/cdo/.config/guix/current/bin /home/cdo/.guix-profile/bin /run/current-system/profile/bin /run/current-system/profile/sbin /gnu/store/gjsxzcc0gqpz4lpbsrbidlnn5ij1lfm1-gzip-1.12/bin /gnu/store/z81jl0pb4ppkci4im6n856dkhi2ki2d3-coreutils-9.1/bin This leads to unexpected results if you have Guix inside your home package list. (Which you might desire if you wanted to use Guix in a home container.) The Guix you interact with stays stuck on the version that you had when you first `guix home reconfigured` a configuration with guix as a package. Then `guix pull` appears to succeed but `guix describe` is still stuck at the original version. And even a `guix home reconfigure` doesn't update the version because it's using the `guix` from the original `guix home reconfigure`. The way out of this situation is to use `~/.config/guix/current/bin/guix` directly, setting $PATH manually, or simply removing `guix` from your home package list. However, the situation is preventable and undesirable and there's several possible solutions: 1. Reorder the paths by default, keeping ~/.config/guix in front of ~/.guix-home 2. Have `guix home` warn when 'guix' is included as a package 3. Have `guix pull` warn when Guix is shadowed and unable to be updated My preference would be at least 1 and 3. (Incidentally, how did gzip and coreutils get in there? I didn't put it there.) I'm happy to contribute a patch if others agree that it's worth fixing. Excited to contribute more! - Christina Supplementary output: $ guix describe guix aeb4943 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: aeb494322ca9dec4a4d66a7d063239c8536bd538 $ guix pull Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Updating channel 'nonguix' from Git repository at 'https://gitlab.com/nonguix/nonguix'... Building from these channels: guix https://git.savannah.gnu.org/git/guix.git 9389070 nonguix https://gitlab.com/nonguix/nonguix fe2fcf1 Computing Guix derivation for 'x86_64-linux'... \ nothing to be done hint: After setting `PATH', run `hash guix' to make sure your shell refers to `/home/cdo/.config/guix/current/bin/guix'. $ hash guix $ which guix /home/cdo/.guix-home/profile/bin/guix $ guix describe guix aeb4943 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: aeb494322ca9dec4a4d66a7d063239c8536bd538
bug#63775: git describe on current master says: v1.3.0-38775-g6192acf8b7
Hi Jonathan, I'm CC'ing guix-devel because I suspect many users who cloned/updated the Guix repo are having the same results... and concerns. This is a git bug, not an issue with our repo, and for this reason (I hope) I'm closing this bug; please see below. Jonathan Brielmaier via Bug reports for GNU Guix writes: > Hm, I'm hitting this bug while trying to work on the openSUSE package. > They offer a way to build RPM packages from the most recent master > commit, but it's get the wrong version (1.3.0 instead of 1.4.0) due to > this `git describe` result. As pointed out by Simon last June the result of "git describe" is not what users should get given the "Search strategy" documented in the command manual: https://git-scm.com/docs/git-describe#_search_strategy: --8<---cut here---start->8--- If multiple tags were found during the walk then the tag which has the fewest commits different from the input commit-ish will be selected and output. Here fewest commits different is defined as the number of commits which would be shown by git log tag..input will be the smallest number of commits possible. --8<---cut here---end--->8--- The upstream bug report (and a reproducer) is this one: «Subject: [BUG] `git describe` doesn't traverse the graph in topological order» https://lore.kernel.org/git/ZNffWAgldUZdpQcr@farprobe/ Another user also reported the issue and a reproducer: https://public-inbox.org/git/ph0pr08mb773203ce3206b8defb172b2f94...@ph0pr08mb7732.namprd08.prod.outlook.com/ The "executive summary" is that "git describe" gets the count of "fewest commits different from the input commit-ish" wrong (see anso previous messages in this thread for details). Anyway, even if this bug was solved, I'd warmly suggest NOT to base the check for the latest stable Guix commit (usually tagged as v[0-9]*) on the result of "git describe". Today, if "guix describe" had no bugs, the correct result would be: "base-for-issue-62196"... AFAIU :-) This is a reproducer: --8<---cut here---start->8--- $ git describe $(git rev-list --tags --max-count=1) base-for-issue-62196 --8<---cut here---end--->8--- To get the value corresponding to the latest tagged version, we should testrict the list of tags to the ones matching the "v[0-9]*" regexp: --8<---cut here---start->8--- $ git describe $(git rev-list --tags="v[0-9]*" --max-count=1) v1.4.0 --8<---cut here---end--->8--- To browse all the tags there is the "git tag" command, for example to have the list and description of every Guix released version: --8<---cut here---start->8--- $ git tag -l "v[0-9]*" --sort=-creatordate -n v1.4.0 GNU Guix 1.4.0. v1.4.0rc2 GNU Guix 1.4.0rc2. v1.4.0rc1 GNU Guix 1.4.0rc1. v1.3.0 GNU Guix 1.3.0. v1.3.0rc2 GNU Guix 1.3.0rc2. v1.3.0rc1 GNU Guix 1.3.0rc1. v1.2.0 GNU Guix 1.2.0. v1.2.0rc2 GNU Guix 1.2.0rc2. v1.2.0rc1 GNU Guix 1.2.0rc1. v1.1.0 GNU Guix 1.1.0. v1.1.0rc2 GNU Guix 1.1.0rc2. v1.1.0rc1 GNU Guix 1.1.0rc1. v1.0.1 GNU Guix 1.0.1. v1.0.0 GNU Guix 1.0.0. v0.16.0 GNU Guix 0.16.0. v0.15.0 GNU Guix 0.15.0. v0.14.0 GNU Guix 0.14.0. v0.13.0 GNU Guix 0.13.0. v0.12.0 GNU Guix 0.12.0 v0.11.0 GNU Guix 0.11.0. v0.10.0 GNU Guix 0.10.0. v0.9.0 GNU Guix 0.9.0. v0.8.3 GNU Guix 0.8.3. v0.8.2 GNU Guix 0.8.2. v0.8.1 GNU Guix 0.8.1. v0.8GNU Guix 0.8. v0.7GNU Guix 0.7. v0.6GNU Guix 0.6. v0.5GNU Guix 0.5. v0.4GNU Guix 0.4. v0.3GNU Guix 0.3. v0.2GNU Guix 0.2. v0.1GNU Guix 0.1. v0.0Guix 0.0, initial announcement. --8<---cut here---end--->8--- HTH! Happy hacking, Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
bug#68920: Issues with issues.guix.gnu.org (502 Bad Gateway)
Hi Guix, From my machine[1] connecting to https://issues.guix.gnu.org/ results in, after 130 seconds[2], a 502 bad gateway. It's been having issues for over a week, but I only just found a need to test it. I couldn't see an issue about it on debbugs so I thought it prudent to raise an issue. Reproduced with curl, firefox, and ungoogled-chromium on the main page and on specific issues. It appears to be under a lot of load. Kind regards, - Christina [1] based in Cambridge, UK, and via my VPS in Dusseldorf, Germany on 2024-02-03 19:30 UTC+0 [2] Rather consistently 130-140 seconds from both UK and Dusseldorf. Apparently the server is in Berlin.
bug#68920: Issues with issues.guix.gnu.org (502 Bad Gateway)
Hi Christina, On Sat, Feb 03 2024, Christina O'Donnell wrote: > connecting to https://issues.guix.gnu.org/ results in ... a 502 bad > gateway. You are welcome to use my Mumi clone at mumi.juix.org. Kind regards Felix
