compilation failure against latest lix release-2.91 #12

Closed
opened 2024-10-17 00:00:17 +00:00 by benaryorg · 9 comments

Compiling against the latest lix release-2.91 branch currently fails, reproducible using:

nix build --log-format multiline --no-link --print-out-paths --print-build-logs -v --refresh --override-input lix 'git+https://git.lix.systems/lix-project/lix?ref=release-2.91' .#hydra

Where:

• Updated input 'lix':
    'git+https://git.lix.systems/lix-project/lix?ref=refs/heads/main&rev=ed9b7f4f84fd60ad8618645cc1bae2d686ff0db6' (2024-10-05)
  → 'git+https://git.lix.systems/lix-project/lix?ref=release-2.91&rev=4422a649e69a7bb6fa3a94a38a18420c0ecc11f2' (2024-09-26)

Full build logs here (IPv6 only): https://hydra.shell.bsocat.net/build/22463/nixlog/2

relevant parts
[2/11] Compiling C++ object src/hydra-queue-runner/hydra-queue-runner.p/nar-extractor.cc.o
FAILED: src/hydra-queue-runner/hydra-queue-runner.p/nar-extractor.cc.o 
g++ -Isrc/hydra-queue-runner/hydra-queue-runner.p -Isrc/hydra-queue-runner -I../src/hydra-queue-runner -Isrc/libhydra -I../src/libhydra -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libexpr -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libfetchers -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libstore -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libutil -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix -I/nix/store/sc8bz0mka4fnv19gzy86wr3w9y7ym3g9-boehm-gc-8.2.6-dev/include -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libmain -I/nix/store/knjg1dsi6abrqb4hh3aid715i9jbfzp2-libpqxx-7.7.5/include -I/nix/store/gk0ykc87k0il9d7ihm7p40wfip831bcg-prometheus-cpp-1.1.0-dev/include -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++20 -O3 -include lix/config.h -MD -MQ src/hydra-queue-runner/hydra-queue-runner.p/nar-extractor.cc.o -MF src/hydra-queue-runner/hydra-queue-runner.p/nar-extractor.cc.o.d -o src/hydra-queue-runner/hydra-queue-runner.p/nar-extractor.cc.o -c ../src/hydra-queue-runner/nar-extractor.cc
../src/hydra-queue-runner/nar-extractor.cc:11:1: error: expected class-name before '{' token
   11 | {
      | ^
../src/hydra-queue-runner/nar-extractor.cc:13:5: error: expected class-name before '{' token
   13 |     {
      |     ^
../src/hydra-queue-runner/nar-extractor.cc:24:18: error: 'void Extractor::MyFileHandle::receiveContents(std::string_view)' marked 'override', but does not override
   24 |             void receiveContents(std::string_view data) override
      |                  ^~~~~~~~~~~~~~~
../src/hydra-queue-runner/nar-extractor.cc:59:21: error: 'FileHandle' was not declared in this scope; did you mean 'MyFileHandle'?
   59 |     std::unique_ptr<FileHandle> createRegularFile(const Path & path, uint64_t size, bool executable) override
      |                     ^~~~~~~~~~
      |                     MyFileHandle
../src/hydra-queue-runner/nar-extractor.cc:59:31: error: template argument 1 is invalid
   59 |     std::unique_ptr<FileHandle> createRegularFile(const Path & path, uint64_t size, bool executable) override
      |                               ^
../src/hydra-queue-runner/nar-extractor.cc:59:31: error: template argument 2 is invalid
../src/hydra-queue-runner/nar-extractor.cc:59:10: error: '<expression error>' in namespace 'std' does not name a type
   59 |     std::unique_ptr<FileHandle> createRegularFile(const Path & path, uint64_t size, bool executable) override
      |          ^~~~~~~~~~~~~~~~~~~~~~
../src/hydra-queue-runner/nar-extractor.cc:54:10: error: 'void Extractor::createDirectory(const nix::Path&)' marked 'override', but does not override
   54 |     void createDirectory(const Path & path) override
      |          ^~~~~~~~~~~~~~~
../src/hydra-queue-runner/nar-extractor.cc:70:10: error: 'void Extractor::createSymlink(const nix::Path&, const std::string&)' marked 'override', but does not override
   70 |     void createSymlink(const Path & path, const std::string & target) override
      |          ^~~~~~~~~~~~~
../src/hydra-queue-runner/nar-extractor.cc: In lambda function:
../src/hydra-queue-runner/nar-extractor.cc:95:35: error: invalid initialization of reference of type 'nix::ParseSink&' from expression of type 'Extractor'
   95 |         co_yield parseAndCopyDump(extractor, source);
      |                                   ^~~~~~~~~
In file included from ../src/hydra-queue-runner/nar-extractor.cc:3:
/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libutil/archive.hh:163:50: note: in passing argument 1 of 'nix::WireFormatGenerator nix::parseAndCopyDump(ParseSink&, Source&)'
  163 | WireFormatGenerator parseAndCopyDump(ParseSink & sink, Source & source);
      |                                      ~~~~~~~~~~~~^~~~
../src/hydra-queue-runner/nar-extractor.cc:96:5: warning: no return statement in function returning non-void [-Wreturn-type]
   96 |     }(source, prefix, members);
      |     ^
[3/11] Compiling C++ object src/hydra-queue-runner/hydra-queue-runner.p/builder.cc.o
FAILED: src/hydra-queue-runner/hydra-queue-runner.p/builder.cc.o 
g++ -Isrc/hydra-queue-runner/hydra-queue-runner.p -Isrc/hydra-queue-runner -I../src/hydra-queue-runner -Isrc/libhydra -I../src/libhydra -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libexpr -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libfetchers -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libstore -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libutil -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix -I/nix/store/sc8bz0mka4fnv19gzy86wr3w9y7ym3g9-boehm-gc-8.2.6-dev/include -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libmain -I/nix/store/knjg1dsi6abrqb4hh3aid715i9jbfzp2-libpqxx-7.7.5/include -I/nix/store/gk0ykc87k0il9d7ihm7p40wfip831bcg-prometheus-cpp-1.1.0-dev/include -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++20 -O3 -include lix/config.h -MD -MQ src/hydra-queue-runner/hydra-queue-runner.p/builder.cc.o -MF src/hydra-queue-runner/hydra-queue-runner.p/builder.cc.o.d -o src/hydra-queue-runner/hydra-queue-runner.p/builder.cc.o -c ../src/hydra-queue-runner/builder.cc
../src/hydra-queue-runner/builder.cc: In lambda function:
../src/hydra-queue-runner/builder.cc:189:17: error: 'ignoreExceptionInDestructor' was not declared in this scope
  189 |                 ignoreExceptionInDestructor();
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~
[4/11] Compiling C++ object src/hydra-evaluator/hydra-evaluator.p/hydra-evaluator.cc.o
[5/11] Compiling C++ object src/hydra-queue-runner/hydra-queue-runner.p/dispatcher.cc.o
[6/11] Compiling C++ object src/hydra-queue-runner/hydra-queue-runner.p/build-result.cc.o
[7/11] Compiling C++ object src/hydra-queue-runner/hydra-queue-runner.p/queue-monitor.cc.o
../src/hydra-queue-runner/queue-monitor.cc: In member function 'Jobset::ptr State::createJobset(pqxx::work&, const std::string&, const std::string&, JobsetID)':
../src/hydra-queue-runner/queue-monitor.cc:651:18: warning: 'bool pqxx::row::empty() const' is deprecated: Row slicing is going away. [-Wdeprecated-declarations]
  651 |     if (res.empty()) throw Error("missing jobset - can't happen");
      |         ~~~~~~~~~^~
In file included from /nix/store/knjg1dsi6abrqb4hh3aid715i9jbfzp2-libpqxx-7.7.5/include/pqxx/transaction_base.hxx:37,
                 from /nix/store/knjg1dsi6abrqb4hh3aid715i9jbfzp2-libpqxx-7.7.5/include/pqxx/dbtransaction.hxx:20,
                 from /nix/store/knjg1dsi6abrqb4hh3aid715i9jbfzp2-libpqxx-7.7.5/include/pqxx/blob.hxx:34,
                 from /nix/store/knjg1dsi6abrqb4hh3aid715i9jbfzp2-libpqxx-7.7.5/include/pqxx/pqxx:6,
                 from ../src/libhydra/db.hh:3,
                 from ../src/hydra-queue-runner/state.hh:17,
                 from ../src/hydra-queue-runner/queue-monitor.cc:1:
/nix/store/knjg1dsi6abrqb4hh3aid715i9jbfzp2-libpqxx-7.7.5/include/pqxx/row.hxx:184:3: note: declared here
  184 |   empty() const noexcept;
      |   ^~~~~
[8/11] Compiling C++ object src/hydra-queue-runner/hydra-queue-runner.p/build-remote.cc.o
[9/11] Compiling C++ object src/hydra-queue-runner/hydra-queue-runner.p/hydra-queue-runner.cc.o

I'm not sure if this is a Lix thing or a hydra thing (and I'm not a C++ person), but I'll see what I can figure out as soon as I find some spoons.
With the 24.11 release being around the corner I understand if this isn't the highest prio, but since this might be an (unintentional) BC breaking change on the Lix side I figured I could at least open an issue.

Compiling against the latest lix release-2.91 branch currently fails, reproducible using: ```bash nix build --log-format multiline --no-link --print-out-paths --print-build-logs -v --refresh --override-input lix 'git+https://git.lix.systems/lix-project/lix?ref=release-2.91' .#hydra ``` Where: ```text • Updated input 'lix': 'git+https://git.lix.systems/lix-project/lix?ref=refs/heads/main&rev=ed9b7f4f84fd60ad8618645cc1bae2d686ff0db6' (2024-10-05) → 'git+https://git.lix.systems/lix-project/lix?ref=release-2.91&rev=4422a649e69a7bb6fa3a94a38a18420c0ecc11f2' (2024-09-26) ``` Full build logs here (IPv6 only): https://hydra.shell.bsocat.net/build/22463/nixlog/2 <details> <summary>relevant parts</summary> ```text [2/11] Compiling C++ object src/hydra-queue-runner/hydra-queue-runner.p/nar-extractor.cc.o FAILED: src/hydra-queue-runner/hydra-queue-runner.p/nar-extractor.cc.o g++ -Isrc/hydra-queue-runner/hydra-queue-runner.p -Isrc/hydra-queue-runner -I../src/hydra-queue-runner -Isrc/libhydra -I../src/libhydra -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libexpr -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libfetchers -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libstore -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libutil -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix -I/nix/store/sc8bz0mka4fnv19gzy86wr3w9y7ym3g9-boehm-gc-8.2.6-dev/include -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libmain -I/nix/store/knjg1dsi6abrqb4hh3aid715i9jbfzp2-libpqxx-7.7.5/include -I/nix/store/gk0ykc87k0il9d7ihm7p40wfip831bcg-prometheus-cpp-1.1.0-dev/include -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++20 -O3 -include lix/config.h -MD -MQ src/hydra-queue-runner/hydra-queue-runner.p/nar-extractor.cc.o -MF src/hydra-queue-runner/hydra-queue-runner.p/nar-extractor.cc.o.d -o src/hydra-queue-runner/hydra-queue-runner.p/nar-extractor.cc.o -c ../src/hydra-queue-runner/nar-extractor.cc ../src/hydra-queue-runner/nar-extractor.cc:11:1: error: expected class-name before '{' token 11 | { | ^ ../src/hydra-queue-runner/nar-extractor.cc:13:5: error: expected class-name before '{' token 13 | { | ^ ../src/hydra-queue-runner/nar-extractor.cc:24:18: error: 'void Extractor::MyFileHandle::receiveContents(std::string_view)' marked 'override', but does not override 24 | void receiveContents(std::string_view data) override | ^~~~~~~~~~~~~~~ ../src/hydra-queue-runner/nar-extractor.cc:59:21: error: 'FileHandle' was not declared in this scope; did you mean 'MyFileHandle'? 59 | std::unique_ptr<FileHandle> createRegularFile(const Path & path, uint64_t size, bool executable) override | ^~~~~~~~~~ | MyFileHandle ../src/hydra-queue-runner/nar-extractor.cc:59:31: error: template argument 1 is invalid 59 | std::unique_ptr<FileHandle> createRegularFile(const Path & path, uint64_t size, bool executable) override | ^ ../src/hydra-queue-runner/nar-extractor.cc:59:31: error: template argument 2 is invalid ../src/hydra-queue-runner/nar-extractor.cc:59:10: error: '<expression error>' in namespace 'std' does not name a type 59 | std::unique_ptr<FileHandle> createRegularFile(const Path & path, uint64_t size, bool executable) override | ^~~~~~~~~~~~~~~~~~~~~~ ../src/hydra-queue-runner/nar-extractor.cc:54:10: error: 'void Extractor::createDirectory(const nix::Path&)' marked 'override', but does not override 54 | void createDirectory(const Path & path) override | ^~~~~~~~~~~~~~~ ../src/hydra-queue-runner/nar-extractor.cc:70:10: error: 'void Extractor::createSymlink(const nix::Path&, const std::string&)' marked 'override', but does not override 70 | void createSymlink(const Path & path, const std::string & target) override | ^~~~~~~~~~~~~ ../src/hydra-queue-runner/nar-extractor.cc: In lambda function: ../src/hydra-queue-runner/nar-extractor.cc:95:35: error: invalid initialization of reference of type 'nix::ParseSink&' from expression of type 'Extractor' 95 | co_yield parseAndCopyDump(extractor, source); | ^~~~~~~~~ In file included from ../src/hydra-queue-runner/nar-extractor.cc:3: /nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libutil/archive.hh:163:50: note: in passing argument 1 of 'nix::WireFormatGenerator nix::parseAndCopyDump(ParseSink&, Source&)' 163 | WireFormatGenerator parseAndCopyDump(ParseSink & sink, Source & source); | ~~~~~~~~~~~~^~~~ ../src/hydra-queue-runner/nar-extractor.cc:96:5: warning: no return statement in function returning non-void [-Wreturn-type] 96 | }(source, prefix, members); | ^ [3/11] Compiling C++ object src/hydra-queue-runner/hydra-queue-runner.p/builder.cc.o FAILED: src/hydra-queue-runner/hydra-queue-runner.p/builder.cc.o g++ -Isrc/hydra-queue-runner/hydra-queue-runner.p -Isrc/hydra-queue-runner -I../src/hydra-queue-runner -Isrc/libhydra -I../src/libhydra -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libexpr -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libfetchers -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libstore -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libutil -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix -I/nix/store/sc8bz0mka4fnv19gzy86wr3w9y7ym3g9-boehm-gc-8.2.6-dev/include -I/nix/store/1ha4j0vmxq4knn4jf8lawnm5dxdxhpjb-lix-2.91.1-pre20240926-4422a64-dev/include/lix/libmain -I/nix/store/knjg1dsi6abrqb4hh3aid715i9jbfzp2-libpqxx-7.7.5/include -I/nix/store/gk0ykc87k0il9d7ihm7p40wfip831bcg-prometheus-cpp-1.1.0-dev/include -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++20 -O3 -include lix/config.h -MD -MQ src/hydra-queue-runner/hydra-queue-runner.p/builder.cc.o -MF src/hydra-queue-runner/hydra-queue-runner.p/builder.cc.o.d -o src/hydra-queue-runner/hydra-queue-runner.p/builder.cc.o -c ../src/hydra-queue-runner/builder.cc ../src/hydra-queue-runner/builder.cc: In lambda function: ../src/hydra-queue-runner/builder.cc:189:17: error: 'ignoreExceptionInDestructor' was not declared in this scope 189 | ignoreExceptionInDestructor(); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ [4/11] Compiling C++ object src/hydra-evaluator/hydra-evaluator.p/hydra-evaluator.cc.o [5/11] Compiling C++ object src/hydra-queue-runner/hydra-queue-runner.p/dispatcher.cc.o [6/11] Compiling C++ object src/hydra-queue-runner/hydra-queue-runner.p/build-result.cc.o [7/11] Compiling C++ object src/hydra-queue-runner/hydra-queue-runner.p/queue-monitor.cc.o ../src/hydra-queue-runner/queue-monitor.cc: In member function 'Jobset::ptr State::createJobset(pqxx::work&, const std::string&, const std::string&, JobsetID)': ../src/hydra-queue-runner/queue-monitor.cc:651:18: warning: 'bool pqxx::row::empty() const' is deprecated: Row slicing is going away. [-Wdeprecated-declarations] 651 | if (res.empty()) throw Error("missing jobset - can't happen"); | ~~~~~~~~~^~ In file included from /nix/store/knjg1dsi6abrqb4hh3aid715i9jbfzp2-libpqxx-7.7.5/include/pqxx/transaction_base.hxx:37, from /nix/store/knjg1dsi6abrqb4hh3aid715i9jbfzp2-libpqxx-7.7.5/include/pqxx/dbtransaction.hxx:20, from /nix/store/knjg1dsi6abrqb4hh3aid715i9jbfzp2-libpqxx-7.7.5/include/pqxx/blob.hxx:34, from /nix/store/knjg1dsi6abrqb4hh3aid715i9jbfzp2-libpqxx-7.7.5/include/pqxx/pqxx:6, from ../src/libhydra/db.hh:3, from ../src/hydra-queue-runner/state.hh:17, from ../src/hydra-queue-runner/queue-monitor.cc:1: /nix/store/knjg1dsi6abrqb4hh3aid715i9jbfzp2-libpqxx-7.7.5/include/pqxx/row.hxx:184:3: note: declared here 184 | empty() const noexcept; | ^~~~~ [8/11] Compiling C++ object src/hydra-queue-runner/hydra-queue-runner.p/build-remote.cc.o [9/11] Compiling C++ object src/hydra-queue-runner/hydra-queue-runner.p/hydra-queue-runner.cc.o ``` </details> --- I'm not sure if this is a Lix thing or a hydra thing (and I'm not a C++ person), but I'll see what I can figure out as soon as I find some spoons. With the 24.11 release being around the corner I understand if this isn't the highest prio, but since this might be an (unintentional) BC breaking change on the Lix side I figured I could at least open an issue.
Author

Ah, it looks like 7c7078cccf, while making hydra build against lix' main branch, caused build failures against the current stable.

I somehow assumed this repo would follow the upstream release model of always building/testing against an already released version of Nix (or in this case Lix).
If keeping the hydra main in sync with the Lix main (which sounds like a good idea since it'd make for a ready-to-use release as soon as Lix releases) is the future, could we have a stable or even release-x.y branches too?
I get that it's more maintenance overhead, but being able to run nix flake update without having to manually exclude or pin the hydra repo would be nice as a user.

Ah, it looks like 7c7078cccf8a112aecada9e0c590300f43c3fdbb, while making hydra build against lix' main branch, caused build failures against the current stable. I somehow assumed this repo would follow the upstream release model of always building/testing against an already released version of Nix (or in this case Lix). If keeping the hydra *main* in sync with the Lix *main* (which sounds like a good idea since it'd make for a ready-to-use release as soon as Lix releases) is the future, could we have a *stable* or even *release-x.y* branches too? I get that it's more maintenance overhead, but being able to run `nix flake update` without having to manually exclude or pin the hydra repo would be nice as a user.
Member

What we'll probably want to do is to branch off for each Lix version as upstream does it. Perhaps even tags?

Thoughts @delroth @raito @yu-re-ka?

What we'll probably want to do is to branch off for each Lix version as upstream does it. Perhaps even tags? Thoughts @delroth @raito @yu-re-ka?
Owner

Ideally, this should be included in the release engineering of Lix, but there's too much pressure over there in the Lix team, so any help is welcome on what is the cheapest thing we can do that makes end users happy.

@ma27 you have full authority to decide on something reasonable here that doesn't suck up your soul, IMHO. :)

Ideally, this should be included in the release engineering of Lix, but there's too much pressure over there in the Lix team, so any help is welcome on what is the cheapest thing we can do that makes end users happy. @ma27 you have full authority to decide on something reasonable here that doesn't suck up your soul, IMHO. :)
Member

First of all apologies that I didn't respond earlier, there was too much other stuff ongoing. That said, I'd like to assure your that if it'll end up with me taking responsibility here, this will obviously get a higher priority in my personal schedule!

but there's too much pressure over there in the Lix team

I'm well-aware of that and it was not my intention to push the work onto them.

My suggestion is relatively simple: since Hydra doesn't have a release process and I don't think it's wise to establish one now, we should

  • Branch off release-X.Y where X.Y is the Lix minor this Hydra compiles with.
  • While I don't want to give explicit stability guarantees for these branches, I'd like to only backport bugfixes and security fixes[1]. Another reason for that is backporting more stuff is probably hard given that we'll regularly need C++ fixes to keep up with Lix changes.

I'd offer to take care of that, two notes:

  • It would certainly help to get write access to this repo if the Lix team is OK with that. Otherwise, I'm also fine with proxying all my work through other folks (mostly creating branches and having people merge backports).
    I intend to only use my write access for maintenance tasks and to push things that are discussed with other stake-holders[2]. I.e. I don't intend to push for e.g. #11 if people are not OK with that. If you ever get the impression that this isn't the case, reach out to me, please!
  • I have a potential conflict of interest that I need to disclose and I'll accept any decision from your end here: my employer makes heavy use of Hydra internally and since ~October, it's part of my job to implement improvements there. The internal decision is to stick to CppNix for now which means that I'm working against the codebase of NixOS/hydra and upstreaming my changes.
    I am interested in switching to Lix+this Hydra because I'm convinced of Lix being the better option, but I'm not in the position to make that call (and I must say it's kinda hard to tell what we'll end up with in a few months), so it's unclear if that'll happen. I do intend to upstream my changes here as well, however that'll be an effort in my free time.

[1] @raito what's the current lifetime policy of Lix? I.e. is 2.90 dead because 24.05 already has 2.91? If so, I wouldn't bother supporting 2.90 at all and start with 2.91 right away.
[2] I guess @raito, @delroth and @leo60228 can be considered stake-holders. Anyone else?

First of all apologies that I didn't respond earlier, there was too much other stuff ongoing. That said, I'd like to assure your that if it'll end up with me taking responsibility here, this will obviously get a higher priority in my personal schedule! > but there's too much pressure over there in the Lix team I'm well-aware of that and it was not my intention to push the work onto them. My suggestion is relatively simple: since Hydra doesn't have a release process and I don't think it's wise to establish one _now_, we should * Branch off `release-X.Y` where `X.Y` is the Lix minor this Hydra compiles with. * While I don't want to give explicit stability guarantees for these branches, I'd like to only backport bugfixes and security fixes[1]. Another reason for that is backporting more stuff is probably hard given that we'll regularly need C++ fixes to keep up with Lix changes. I'd offer to take care of that, two notes: * It would certainly help to get write access to this repo if the Lix team is OK with that. Otherwise, I'm also fine with proxying all my work through other folks (mostly creating branches and having people merge backports). I intend to only use my write access for maintenance tasks and to push things that are discussed with other stake-holders[2]. I.e. I don't intend to push for e.g. #11 if people are not OK with that. If you ever get the impression that this isn't the case, reach out to me, please! * I have a potential conflict of interest that I need to disclose and I'll accept any decision from your end here: my employer makes heavy use of Hydra internally and since ~October, it's part of my job to implement improvements there. The internal decision is to stick to CppNix for now which means that I'm working against the codebase of NixOS/hydra and upstreaming my changes. I am interested in switching to Lix+this Hydra because I'm convinced of Lix being the better option, but I'm not in the position to make that call (and I must say it's kinda hard to tell what we'll end up with in a few months), so it's unclear if that'll happen. I do intend to upstream my changes here as well, however that'll be an effort in my free time. [1] @raito what's the current lifetime policy of Lix? I.e. is 2.90 dead because 24.05 already has 2.91? If so, I wouldn't bother supporting 2.90 at all and start with 2.91 right away. [2] I guess @raito, @delroth and @leo60228 can be considered stake-holders. Anyone else?
Owner

Oh! Wait you didn't have access to that? I think I am allowed to simply unilaterally give you write access to the secondary Lix projects, so I am going to do so (Raito and co please also do this if you notice similarly responsible people who should simply be given commit access under trusted-contributors/secondary-committers in keycloak).

Oh! Wait you didn't have access to that? I think I am allowed to simply unilaterally give you write access to the secondary Lix projects, so I am going to do so (Raito and co please also do this if you notice similarly responsible people who should simply be given commit access under `trusted-contributors/secondary-committers` in keycloak).
Owner

AFAIK Lix 2.90 is dead realistically. We do not generally backport very hard unless it is a bug that affects a lot of users or a security bug; though I think 2.90 didn't even get the last trivial security backport. There is not currently a formal release maintenance policy; my current stance is that even old NixOS versions can just have their Lix upgraded to the latest release because they don't break stuff.

AFAIK Lix 2.90 is dead realistically. We do not generally backport very hard unless it is a bug that affects a lot of users or a security bug; though I think 2.90 didn't even get the last trivial security backport. There is not currently a formal release maintenance policy; my current stance is that even old NixOS versions can just have their Lix upgraded to the latest release because they don't break stuff.
Member

Wait you didn't have access to that? I think I am allowed to simply unilaterally give you write access to the secondary Lix projects, so I am going to do so

Thanks a lot for your trust, that's greatly appreciated!
I prepared a branch locally that I'll push tomorrow (CET) and document it on main in the readme. That should sufficiently cover this issue's scope.

my current stance is that even old NixOS versions can just have their Lix upgraded to the latest release because they don't break stuff.

Yes indeed. I guess I'll keep an eye on the latest Lix release only for now then.

> Wait you didn't have access to that? I think I am allowed to simply unilaterally give you write access to the secondary Lix projects, so I am going to do so Thanks a lot for your trust, that's greatly appreciated! I prepared a branch locally that I'll push tomorrow (CET) and document it on main in the readme. That should sufficiently cover this issue's scope. > my current stance is that even old NixOS versions can just have their Lix upgraded to the latest release because they don't break stuff. Yes indeed. I guess I'll keep an eye on the latest Lix release only for now then.
Member

EDIT: I forgot to logout and login again, sorry for the ping.

@jade am I holding it wrong?
I wanted to push a branch lix-2.91 now to this repo and I get

Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 919 bytes | 919.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0), pack-reused 0 (from 0)
remote: 
remote: Forgejo: User permission denied for writing.
To git.lix.systems:lix-project/hydra
 ! [remote rejected]   lix-2.91 -> lix-2.91 (pre-receive hook declined)
error: failed to push some refs to 'git.lix.systems:lix-project/hydra'
EDIT: I forgot to logout and login again, sorry for the ping. <del>@jade am I holding it wrong? I wanted to push a branch `lix-2.91` now to this repo and I get</del> ``` Enumerating objects: 7, done. Counting objects: 100% (7/7), done. Delta compression using up to 8 threads Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 919 bytes | 919.00 KiB/s, done. Total 4 (delta 3), reused 0 (delta 0), pack-reused 0 (from 0) remote: remote: Forgejo: User permission denied for writing. To git.lix.systems:lix-project/hydra ! [remote rejected] lix-2.91 -> lix-2.91 (pre-receive hook declined) error: failed to push some refs to 'git.lix.systems:lix-project/hydra' ```
Owner

@ma27 try logging out of forgejo and back in again, that's how to resync your groups from keycloak

@ma27 try logging out of forgejo and back in again, that's how to resync your groups from keycloak
ma27 closed this issue 2024-12-06 16:34:59 +00:00
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/hydra#12
No description provided.