Re: 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
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.
Re: 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
Re: Mechanism for helping in multi-channels configuration
Hi Simon, The wishlist is: provide a machine-readable description on guix-science channel side in order to help in finding the good overlap between commits of different channels. It could be nice if instead of an hard error, “guix pull” could say: « the channel ’guix’ needs to be at least at commit 1234abc ». I was just thinking about these kinds of errors. It would also happen between channels when packages are split from a single file (eg. golang.scm to golang-xyz.scm). Then channels immediately go out of sync as we're doing continual releases. So, it wouldn't just be for time-machine. It's all a bit too fragile for my liking. I assume we won't be to frequent versioned releases any time soon.. A sketch of a solution might be: 1. Have a script that scrapes all the define-public symbols in every file in every package. 2. Have a script that determines the symbols needed by each file. (Macros make this more difficult, but.) 3. Have both scripts have an incremental version that runs on diffs (for performance). 4. Run this for every commit on every branch on every channel caching the result. 5. Have a CI script keep this updated for new commits. 6. Have a server track incompatibilities. For example, a 'definition-reference' could look like, (definition-reference (commit-range start-hash end-hash) file-path identifier) (definition-reference (commit-range "44b340d..." "06dba3b...") "gnu/packages/golang" 'go-github-com-rs-xid) Commit ranges makes the size of entries tractable (since package probably aren't getting moved / deleted / added very much). Then use a hash table, (or trie or B+ Tree, or distributed hash table, etc) to go from identifier to definition-reference. You would probably would also want to know commit date so you could index on it. That would let you find versions that supplied the identifier that are as close as possible chronologically to a particular version of a different channel Now this isn't perfect (in case anyone was getting that impression ;): - It won't have any idea about version incompatibilities. - It couldn't trace renamed variables. - And probably more. Might be useful to additionally track package versions, but that might run into resource issues. I'm thinking a Guile daemon backed by SQLite.. What do you think? Full disclosure: I've got nothing lined up for the summer yet, so I'm on the prowl for GSoC projects :) Kind regards, - Christina
[post Guix Days] Guix Common Document (was: Request-For-Comment process)
Hi all, I hope that the discussion we had yesterday (Friday 2nd) in Guix Days has clarified the idea behind this proposal. I am waiting Ludo’s notes in order to refine this proposal, integrate many comments and/or ideas, and polish. Thanks all participants. The aim of the proposal is to have a process to document our processes with the least bureaucracy as possible. Well, Debian project is often cited as an example (social contract, voting system, etc.). Indeed, however there is more bureaucracy in Debian than in French State. ;-) Instead, let just formalize what we are already doing. Currently, we are just adding more and more sections to the manual and for other parts the structure for making decisions is not clear. For sure, it works… until now but I think it does not scale and we are touching the limits about what can be done with this informal structure. Let me clarify my attempt behind this “RFC proposal”. First, pukkamustard proposed the name “Guix Common Document” echoing “greatest common divisor“ (gcd): the greatest common divisor of two or more integers is the largest positive integer that divides each of the integers – other said, that’s the larger integer in common with all. I like it because it captures well the idea; although such different name could be confusing from the outside. Anyway. That’s an implementation detail. ;-) Second, from my point of view, the core components of the proposal are: + consensus; + co-supporter. Consensus, because it is how we already collaborate. Somehow, it changes almost nothing for our daily operations but having an explicit formalization will help outsiders. The definition of “consensus” is twofold: 1. can live with; 2. concerns are actively resolved. Other said, the definition wording of “consensus” specifies how to avoid being blocked by disagreements: when one wish to block a proposal then one bears a special responsibility for finding alternatives, proposing ideas/code or explaining the rationale for the status quo. And to make it clear, the first idea for making decision is “voting” but then we need to define “who” votes. Well, this appears to me a counter-measure against something that would be rare and this solution does not trust in the values of our community (being welcoming, inclusive, taking care of each other, etc. well as least, trying as much as possible :-)). For me, the counter-measure against an hostile takeover is somehow captured the point #2 above. Co-supporter, because similarly as the manual section « (guix) Reviewing the Work of Others » [1], the aim is to cross the final line, make progress by incremental focused improvements. Therefore, a proposal needs the help of someone committed to the project (long-standing contributor, committer, etc.). I agree that “contributor sufficiently familiar” is maybe too vague and needs more specific examples as “contributor sufficiently familiar (committers or people with X commits)”. Well, that’s part refining the proposal. :-) Last, I think that the time-frame for discussing needs to be bounded. Somehow this bound will help in the incremental improvement and will avoid the trap of the perfect-as-the-first-try. Well, let recover from these awesome Guix Days and from FOSDEM and then resume this proposal. Cheers, simon 1: https://guix.gnu.org/manual/devel/en/guix.html#Reviewing-the-Work-of-Others
Mechanism for helping in multi-channels configuration
Hi, Well, using Guix bdab356 from a little bit more than one month old, then associating the channel guix-science 0b3d4a2f last week, I get the failure: --8<---cut here---start->8--- $ guix build /gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv The following derivation will be built: /gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv building /gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv... (repl-version 0 1 1) WARNING: (guix-science build bazel-build-system): imported module (guix build utils) overrides core binding `delete' (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (python-nr-stream)) (value #f)) builder for `/gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv' failed to produce output path `/gnu/store/qzgj4vig3vklbznz1i0pgy11nr3z4rv9-guix-science' build of /gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv failed View build log at '/var/log/guix/drvs/g3/aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv.gz'. guix build: error: build of `/gnu/store/g3aa5rh7bs5pyxd3q1gvhwz1s9z1vh3z-guix-science.drv' failed --8<---cut here---end--->8--- Well, that’s expected! Guix bdab356 does not contain python-nr-stream introduced by commit 7dfe41aa71a4a4a9d6065a44e9c6271717215b3e. The wishlist is: provide a machine-readable description on guix-science channel side in order to help in finding the good overlap between commits of different channels. It could be nice if instead of an hard error, “guix pull” could say: « the channel ’guix’ needs to be at least at commit 1234abc ». WDYT? Cheers, simon
Re: Request-For-Comment process: concrete implementation
Hi Ricardo, On mer., 20 déc. 2023 at 12:49, Ricardo Wurmus wrote: > I just got back from travels and finally caught up with important email. > I read the proposal and it looks good to me. Thank you for working on > this! > > This would be the first project I contribute to that has an RFC process, > so I don’t know what to look out for. My concerns may thus be > completely out of touch with reality, so beware as you read on. Thank you for the feedback. Much appreciated! :-) I will address your question in another broad message. Cheers, simon
