Re: Repology and outdated packages
Maxime Devos schreef op di 07-06-2022 om 23:32 [+0200]:
> In my experience with antioxidant, not-up-to-date Rust toolchains do
> not prevent upgrading packages -- in the process of resolving build
> failures, I updated some crates. This never resulted in a ‘you need
> an
> new toolchain error’. At worst, I had to disable the "unstable",
> "nightly" or "generic-simd" features of the crate.
Correction (adding the rust-git-path crate to update another crate to
avoid non-building crate due to updated crates with a different API):
Saving crate informtion in
/gnu/store/fr292pqsfas2i9nwc3bijx5skb8g3ayg-rust-git-path-0.1.3/lib/guixcrate/git-path.crate-info
error[E0658]: use of unstable library feature 'is_symlink'
--> src/realpath.rs:50:34
|
50 | if real_path.is_symlink() {
| ^^
|
= note: see issue #85748
for more information
Looks like it is possible to work-around avoid though:
https://github.com/rust-lang/cargo/commit/c6745a3d7fcea3a949c3e13e682b8ddcbd213add
Alternatively, I could set RUSTC_BOOTSTRAP=1. From
The build system sets RUSTC_BOOTSTRAP=1. This special variable means
to break the stability guarantees of rust: Allow using #![feature(...)]
with a compiler that's not nightly. This should never be used except
when bootstrapping the compiler.
Greetings,
Maxime.
signature.asc
Description: This is a digitally signed message part
Re: proposal: guix-ment...@gnu.org list/alias
On 03/06/2022 12:53, jbra...@dismail.de wrote: I always use this website to remind myself how to use git send-email: https://git-send-email.io/ We could out that information in the guix manual or link to it. :) This is great - many thanks for sharing. I think a link in the manual would be very useful.
Re: aarch64 workers appear to have stalled on ci.guix.gnu.org
On Wed, Jun 8, 2022 at 4:59 PM Ludovic Courtès wrote: > It looks like ‘cuirass-remote-worker’ needed a kick on these boxes, > which Mathieu and I did earlier today (‘herd restart …’). Most of them > are busy right now. I only count 7 successful builds for aarch64, and several more under spec:guix. Every other build looks to have failed with a timeout. https://ci.guix.gnu.org/search?query=status:success%20system:aarch64-linux
Re: Merging ‘staging’?
On Mon, Jun 06, 2022 at 11:17:47PM +0200, Ludovic Courtès wrote: > We have to check for AArch64 & co. Any takers? > > Overall it seems to me we should be able to merge ‘staging’ within a > couple of days. Thoughts? > > Ludo’. > I mostly succeeded in updating my rock64 aarch64 machine guix time-machine --branch=staging -- package -m ~/keep/guixsd/rock64-manifest.scm but building llvm@11 fails (needed for mesa, I think). The log ends with: [...] make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' [ 97%] Built target verify-uselistorder make -f tools/yaml2obj/CMakeFiles/yaml2obj.dir/build.make tools/yaml2obj/CMakeFiles/yaml2obj.dir/depend make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' cd /tmp/guix-build-llvm-11.0.0.drv-0/build && /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/tools/yaml2obj /tmp/guix-build-llvm-11.0.0.drv-0/build /tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj /tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj/CMakeFiles/yaml2obj.dir/DependInfo.cmake --color= Consolidate compiler generated dependencies of target yaml2obj make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' make -f tools/yaml2obj/CMakeFiles/yaml2obj.dir/build.make tools/yaml2obj/CMakeFiles/yaml2obj.dir/build make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' [ 98%] Linking CXX executable ../../bin/yaml2obj cd /tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj && /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E cmake_link_script CMakeFiles/yaml2obj.dir/link.txt --verbose=1 /gnu/store/dbcbcaxq20kbkhh2mr8k98qfnymq22kp-gcc-10.3.0/bin/c++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -ffunction-sections -fdata-sections -O3 -DNDEBUG -Wl,-allow-shlib-undefined -Wl,-O3 -Wl,--gc-sections CMakeFiles/yaml2obj.dir/yaml2obj.cpp.o -o ../../bin/yaml2obj -Wl,-rpath,/tmp/guix-build-llvm-11.0.0.drv-0/build/lib ../../lib/libLLVMObjectYAML.so.11 -lpthread ../../lib/libLLVMSupport.so.11 -Wl,-rpath-link,/tmp/guix-build-llvm-11.0.0.drv-0/build/lib make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' [ 98%] Built target yaml2obj make -f examples/Bye/CMakeFiles/Bye.dir/build.make examples/Bye/CMakeFiles/Bye.dir/depend make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' cd /tmp/guix-build-llvm-11.0.0.drv-0/build && /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/examples/Bye /tmp/guix-build-llvm-11.0.0.drv-0/build /tmp/guix-build-llvm-11.0.0.drv-0/build/examples/Bye /tmp/guix-build-llvm-11.0.0.drv-0/build/examples/Bye/CMakeFiles/Bye.dir/DependInfo.cmake --color= Consolidate compiler generated dependencies of target Bye make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' make -f examples/Bye/CMakeFiles/Bye.dir/build.make examples/Bye/CMakeFiles/Bye.dir/build make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' make[2]: Nothing to be done for 'examples/Bye/CMakeFiles/Bye.dir/build'. make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' [ 98%] Built target Bye make -f unittests/Passes/CMakeFiles/TestPlugin.dir/build.make unittests/Passes/CMakeFiles/TestPlugin.dir/depend make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' cd /tmp/guix-build-llvm-11.0.0.drv-0/build && /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/unittests/Passes /tmp/guix-build-llvm-11.0.0.drv-0/build /tmp/guix-build-llvm-11.0.0.drv-0/build/unittests/Passes /tmp/guix-build-llvm-11.0.0.drv-0/build/unittests/Passes/CMakeFiles/TestPlugin.dir/DependInfo.cmake --color= Consolidate compiler generated dependencies of target TestPlugin make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' make -f unittests/Passes/CMakeFiles/TestPlugin.dir/build.make unittests/Passes/CMakeFiles/TestPlugin.dir/build make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' make[2]: Nothing to be done for 'unittests/Passes/CMakeFiles/TestPlugin.dir/build'. make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' [ 98%] Built target TestPlugin make -f unittests/Support/DynamicLibrary/CMakeFiles/SecondLib.dir/build.make unittests/Support/
Re: Merging ‘staging’?
On Thu, Jun 09, 2022 at 07:19:30PM +0200, pelzflorian (Florian Pelz) wrote: > On Mon, Jun 06, 2022 at 11:17:47PM +0200, Ludovic Courtès wrote: > > We have to check for AArch64 & co. Any takers? > > > > Overall it seems to me we should be able to merge ‘staging’ within a > > couple of days. Thoughts? > > > > Ludo’. > > > > I mostly succeeded in updating my rock64 aarch64 machine > > guix time-machine --branch=staging -- package -m > ~/keep/guixsd/rock64-manifest.scm > > but building llvm@11 fails (needed for mesa, I think). The log ends with: > > [...] > make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' > [ 97%] Built target verify-uselistorder > make -f tools/yaml2obj/CMakeFiles/yaml2obj.dir/build.make > tools/yaml2obj/CMakeFiles/yaml2obj.dir/depend > make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' > cd /tmp/guix-build-llvm-11.0.0.drv-0/build && > /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E > cmake_depends "Unix Makefiles" > /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src > /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/tools/yaml2obj > /tmp/guix-build-llvm-11.0.0.drv-0/build > /tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj > /tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj/CMakeFiles/yaml2obj.dir/DependInfo.cmake > --color= > Consolidate compiler generated dependencies of target yaml2obj > make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' > make -f tools/yaml2obj/CMakeFiles/yaml2obj.dir/build.make > tools/yaml2obj/CMakeFiles/yaml2obj.dir/build > make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' > [ 98%] Linking CXX executable ../../bin/yaml2obj > cd /tmp/guix-build-llvm-11.0.0.drv-0/build/tools/yaml2obj && > /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E > cmake_link_script CMakeFiles/yaml2obj.dir/link.txt --verbose=1 > /gnu/store/dbcbcaxq20kbkhh2mr8k98qfnymq22kp-gcc-10.3.0/bin/c++ -fPIC > -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra > -Wno-unused-parameter -Wwrite-strings -Wcast-qual > -Wno-missing-field-initializers -pedantic -Wno-long-long > -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess > -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment > -ffunction-sections -fdata-sections -O3 -DNDEBUG -Wl,-allow-shlib-undefined > -Wl,-O3 -Wl,--gc-sections CMakeFiles/yaml2obj.dir/yaml2obj.cpp.o -o > ../../bin/yaml2obj > -Wl,-rpath,/tmp/guix-build-llvm-11.0.0.drv-0/build/lib > ../../lib/libLLVMObjectYAML.so.11 -lpthread ../../lib/libLLVMSupport.so.11 > -Wl,-rpath-link,/tmp/guix-build-llvm-11.0.0.drv-0/build/lib > make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' > [ 98%] Built target yaml2obj > make -f examples/Bye/CMakeFiles/Bye.dir/build.make > examples/Bye/CMakeFiles/Bye.dir/depend > make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' > cd /tmp/guix-build-llvm-11.0.0.drv-0/build && > /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E > cmake_depends "Unix Makefiles" > /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src > /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/examples/Bye > /tmp/guix-build-llvm-11.0.0.drv-0/build > /tmp/guix-build-llvm-11.0.0.drv-0/build/examples/Bye > /tmp/guix-build-llvm-11.0.0.drv-0/build/examples/Bye/CMakeFiles/Bye.dir/DependInfo.cmake > --color= > Consolidate compiler generated dependencies of target Bye > make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' > make -f examples/Bye/CMakeFiles/Bye.dir/build.make > examples/Bye/CMakeFiles/Bye.dir/build > make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' > make[2]: Nothing to be done for 'examples/Bye/CMakeFiles/Bye.dir/build'. > make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' > [ 98%] Built target Bye > make -f unittests/Passes/CMakeFiles/TestPlugin.dir/build.make > unittests/Passes/CMakeFiles/TestPlugin.dir/depend > make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' > cd /tmp/guix-build-llvm-11.0.0.drv-0/build && > /gnu/store/6lfyb68pdy0b1vggzbvw8grkv2ws6vhl-cmake-minimal-3.21.4/bin/cmake -E > cmake_depends "Unix Makefiles" > /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src > /tmp/guix-build-llvm-11.0.0.drv-0/llvm-11.0.0.src/unittests/Passes > /tmp/guix-build-llvm-11.0.0.drv-0/build > /tmp/guix-build-llvm-11.0.0.drv-0/build/unittests/Passes > /tmp/guix-build-llvm-11.0.0.drv-0/build/unittests/Passes/CMakeFiles/TestPlugin.dir/DependInfo.cmake > --color= > Consolidate compiler generated dependencies of target TestPlugin > make[2]: Leaving directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' > make -f unittests/Passes/CMakeFiles/TestPlugin.dir/build.make > unittests/Passes/CMakeFiles/TestPlugin.dir/build > make[2]: Entering directory '/tmp/guix-build-llvm-11.0.0.drv-0/build' > make[2]: Nothing to b
Re: On commit access, patch review, and remaining healthy
Hi Giovanni, >> Guix has very high coding standards > > Do you think other software distribution do have less high coding > standards? I meant that Guix has very high coding/packaging standards in the following senses: - We prefer to not bundle dependencies. Tracking out bundled dependencies, git submodules, etc. and figuring out how to rewire everything so it works with unbundled dependencies can be really tricky for some packages. - We build strictly from source. - We aim to package tests for all packages. - We have strict conventions for commit messages. Our commit message Changelog is a strange dated practice from the time before good version control systems. I can live with it, but not everyone likes it. Let's just say I've heard complaints about it offlist. - We don't just list the main license of a package. We trace out the license of each and every file, if they are different from the main license. - Our synopses and descriptions are not casually copy-pasted from the project website. We try to rewrite and improve on them if necessary. - We have to be careful about pushing changes that will cause too many rebuilds. We have a core-updates process for that. I could go on forever, but you get the idea. I do agree with most of these coding standards, and have no problem with following them. But, it does add some pressure to the process. I don't have much experience with other distributions except for Arch Linux and that too only with the AUR (Arch User Repository). The AUR was more of a wiki than a centrally curated repository. Anyone can contribute packages, and there is no review. Most packages don't run tests, and the standards are generally low. >> but that means that there is a high cost of failure > > please can you expand on this? What is that cost of failure? The cost of failure is mostly in the mind. A commit is something that has your name on it and lives on in the repo history *forever*. So, it better be good. That's the pressure. I do have one or two commits in the guix repo with badly borked commit messages. >> and a pressure to live up to that high standard. This means that even >> if I'm 99% sure of a commit, I tend to leave it to others because of >> that nagging 1% doubt I have about some trivial aspect of the >> patch. The 1% doubt could even be about really trivial things like >> indentation or the name of a variable. In other words, perfectionism >> causes paralysis. > > generally speaking I really understand your feeling (the "impostor > syndrome" as Ludo' say) but please do not be paralyzed by this feeling, > do /not/ have fear to make a mistake, we (pluralis majestatis :-D ) are > not here to judge you I know. ;-) > specifically speaking, IMHO in cases like this you should send an > email-reply to that bug (patch) explaining the 1% you are unsure of Yeah, I would. But, often that 1% is too nitpicky to be worth reporting. Sometimes, I fix the 1% myself and push. But often, I confess that I just leave it to other committers. >> This excessive self-doubt is created by feeling like one doesn't >> "belong" in the elite community of Guix hackers > > I undestand there are many meanings of "elite" [1], but if it's an > elite I meant "elite" in the sense that Guix hackers are among the most skilled programmers I've known. > it is /for sure/ a very open group of persons Definitely, I love the community! That's why I'm still here after all these years! Cheers! :-) Arun
Re: On commit access, patch review, and remaining healthy
Hi Ludo, > I can think of two ways to reassure committers: > > 1. By having clear reviewer check lists (you’d do that if you tick all > the boxes, you’re fine); > > 2. By improving automation—nothing new here: if there was a tick that > says “applies without merge conflicts” and another one that read > “builds fine”, anyone could lightheartedly hit the “merge” button. > > #2 is going to take time I’m afraid, but at least #1 is actionable > (‘guix lint’ should help, too). > > WDYT? Are there other possibilities that come to mind? Nothing very specific comes to mind immediately. When I do have specific ideas, I'll be sure to write to guix-devel about them. I'm largely happy with the direction the Guix community is headed with teams, mentors and better tooling. So, at this point, it will be good to progressively experiment with these ideas and see where it leads. Regards, Arun
Re: Merging ‘staging’?
On Thu, Jun 09, 2022 at 08:41:21PM +0300, Efraim Flashner wrote: > I know I've built llvm@11 and mesa on aarch64 hardware for staging. Oh I see I'm missing the last merge; I'm still at commit b422687cbd. I will try again with staging at 091eb323ba27. But it will take a long time; feel free to proceed regardless. Regards, Florian
Re: Teams
Hi Guix, I like the idea of teams. And, it's nice to see so many volunteers raise their hands! > * Rust team > Efraim Flashner > Aleksandr Vityazev > Arun Isaac > John Soo > Maxim Cournoyer > Nicolas Goaziou > Tobias Geerinckx-Rice However, I know very little about Rust, and I'm not a good fit for this team. I could easily be a part of the python, emacs lisp, common lisp, scheme teams, etc if necessary. But, what I'd really like is to be part of a mumi+tooling team. Maybe we should have such a team? Also, since we have so many ideas for teams, can we have some structured way to suggest teams, and add or remove them as needs change? Regards, Arun
python-libcst upgrade and python-flake8
Hi Guixers,
What do suggest as a recommended fix for this error?
```
= 482 passed in 3.80s ==
phase `check' succeeded after 5.0 seconds
starting phase `sanity-check'
validating 'flake8'
/gnu/store/zaw5z708sldm6v3qxjczcia7gl65dw5x-python-flake8-3.9.2/lib/python3.9/site-packages
...checking requirements: ERROR: flake8==3.9.2
ContextualVersionConflict(pyflakes 2.4.0
(/gnu/store/mxkp1zl64cd3i247shp7njkxad8v13x9-python-pyflakes-2.4.0/lib/python3.9/site-packages),
Requirement.parse('pyflakes<2.4.0,>=2.3.0'), {'flake8'})
error: in phase 'sanity-check': uncaught exception:
%exception #<&invoke-error program: "python" arguments:
("/gnu/store/35ix1m6m8a5s21j02ajhdyqxb2xkshfb-sanity-check.py"
"/gnu/store/zaw5z708sldm6v3qxjczcia7gl65dw5x-python-flake8-3.9.2/lib/python3.9/site-packages")
exit-status: 1 term-signal: #f stop-signal: #f>
phase `sanity-check' failed after 0.2 seconds
command "python" "/gnu/store/35ix1m6m8a5s21j02ajhdyqxb2xkshfb-sanity-check.py"
"/gnu/store/zaw5z708sldm6v3qxjczcia7gl65dw5x-python-flake8-3.9.2/lib/python3.9/site-packages"
failed with status 1
builder for
`/gnu/store/khh67agxwf3rvbrrph2m4x0ki7b0my2c-python-flake8-3.9.2.drv' failed
with exit code 1
build of /gnu/store/khh67agxwf3rvbrrph2m4x0ki7b0my2c-python-flake8-3.9.2.drv
failed
Could not find build log for
'/gnu/store/khh67agxwf3rvbrrph2m4x0ki7b0my2c-python-flake8-3.9.2.drv'.
building
/gnu/store/grfg324ljk5hpkwqq45pw99klxjib4bm-python-libcst-minimal-0.4.3.drv...
cannot build derivation
`/gnu/store/5amv1366vcs79l3z0jfpd1c6s5w0315b-python-pylama-7.7.1.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/k6nw3cj8ckd3ss9v7a73km47wz27mkfw-python-isort-5.10.1.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/dd8qjvk6cd3xxfl6vspax6vbp3yyiix2-python-libcst-0.4.3.drv': 1
dependencies couldn't be built
guix build: error: build of
`/gnu/store/dd8qjvk6cd3xxfl6vspax6vbp3yyiix2-python-libcst-0.4.3.drv' failed
```
I was trying to upgrade python-libcst:
http://dpaste.com/AQDS5XW42
Should I package a new version of flake8 that doesn't have a version conflict
or patch out libcst?
all best,
jgart
Re: Merging ‘staging’?
On Thu, Jun 09, 2022 at 09:02:14PM +0200, pelzflorian (Florian Pelz) wrote: > I will try again with staging at 091eb323ba27. llvm@11 was built successfully. Sorry for the noise. Regards, Florian
Re: python-libcst upgrade and python-flake8
Hi jgart,
> validating 'flake8'
> /gnu/store/zaw5z708sldm6v3qxjczcia7gl65dw5x-python-flake8-3.9.2/lib/python3.9/site-packages
> ...checking requirements: ERROR: flake8==3.9.2
> ContextualVersionConflict(pyflakes 2.4.0
> (/gnu/store/mxkp1zl64cd3i247shp7njkxad8v13x9-python-pyflakes-2.4.0/lib/python3.9/site-packages),
> Requirement.parse('pyflakes<2.4.0,>=2.3.0'), {'flake8'})
I believe this was fixed in Guix proper already by upgrading to 4.0.1
and loosening the version checks. In any case it’s not a problem with
the library you are trying to package.
Cheers,
Lars
