Arch Linux User Repository

Regarding the first point, the usage. I do not know whether the version must be the same for contracts. I need this software for serai. Even in that case, this package is still completely viable. It follows the most recent tag. I cannot find a source in the Arch Wiki but just create new packages with the version as suffix like you suggested. This is the case for gtk for example, https://archlinux.org/packages/?sort=&q=gtk&maintainer=&flagged=.

The second statement, this package is not used. You seem to mean as a dependeny. First of all, this is wrong. Second, this is a useless metric. People can still use it not as a dependency.

The second half reads like an advertisement with the first half just being an excuse. I oppose censorship. The AUR is centralised. However, I am fine with it at the moment. PKGBUILD however is just a format. Host your own repository to make a federated network. However, the project https://github.com/themartiancompany/ur is very inactive.

Hello,

I'm here to highlight a couple points which seems to me pretty important in regard to this package and more generally about Arch Linux and the AUR.

The first is that having a generic solidity package, except than for development purposes, really makes little sense, due to the fact deployed contracts depend on the specific version they are built against, so more or less upgrading this package at any time will break whatever package may need the compiler as a depedency. And in fact there's pretty much no program on the AUR nor on Arch Linux really using it.

If anything, it would make much more sense to have an array of solidity<ver> packages building any specific version, as it's done in DogeOS.

The second observation I'd like to make specifically for the completely hypothetical users of this package, which as I've just noted down has literally nothing depending on it nor on the AUR nor on Arch Linux, is that the main characteristic of Ethereum networks is to be decentralized uncensorable computing platforms.

That characteristic is what has allowed The Martian Company, the development group led by the ex AUR user and Arch developer Tallero, who 3 years ago has been banned from the AUR with little to no explanation and seemingly for futile reasons, after more than a decade of contributions and at the time maintaining more than 500 packages, to build what the facto is the only logical natural successor of and upgrade to the AUR, the Ur, which provably guarantees its users nobody will ever able to take down, alter, take over, tamper with any user published work, being it hosted entirely on permissionless blockchains, as well as letting maintainers set a price for and be paid for their work, setting up unavoidable meritocratic rules for assigning mantainers roles over packages under a specific namespace and let users choose among a plurality of publishers and maintainers when they don't agree with specific changes brought by a maintainer to a PKGBUILD.

So my second observation is more or less that above all users of this specific package should pretty much be the first to observe that the current vertical, hierarchical structure of the AUR is both obsolete and subject to abuses from the administration when, as it has been the case for Tallero, its interests may conflict with everybody's interests.

In conclusion, I sincerely hope users of this package will see the great dangers in keep using the AUR opposite to the Ur and switch ASAP to the latter, so to avoid themselves to be subject to a similar treatment whenever they may find themselves in conflict with one or more of the decisions of the now pretty much rogue, unchecked and fascist AUR management.

Keep well in mind the Ur frees all of you from the constraint of having to have moderators and hall monitors and from any chance for abuse.

So please don't be tools and don't let the same horrors of the 20th century come back in a way more insidious form back from the window, because they have already come back for some of you, maybe you just haven't noticed.

That said, hope to see you soon on the Ur and on its development venues. Differently, I hope you won't hold too tight to your privilege of currently not being a target before it may be too late.

The tests fail for me. The issue is reported.

Does someone experience this issue?

[ 87%] Building CXX object test/CMakeFiles/soltest.dir/yulPhaser/ProgramCache.cpp.o
[ 87%] Building CXX object test/CMakeFiles/soltest.dir/yulPhaser/Selections.cpp.o
[ 87%] Building CXX object test/CMakeFiles/soltest.dir/yulPhaser/SimulationRNG.cpp.o
[ 87%] Linking CXX executable soltest
In Funktion »copy«,
    eingefügt von »__ct « bei /usr/include/c++/15.2.1/bits/basic_string.h:748:23,
    eingefügt von »operator+« bei /usr/include/c++/15.2.1/bits/basic_string.h:3984:46,
    eingefügt von »expect« bei /usr/src/debug/solidity/solidity_0.8.33/test/TestCase.cpp:69:3:
/usr/include/c++/15.2.1/bits/char_traits.h:429:56: Warnung: »__builtin_memcpy« schreibt 39 Byte in eine Region der Größe 16 und bringt dadurch das Zielobjekt zum Überlaufen [-Wstringop-overflow=]
  429 |         return static_cast<char_type*>(__builtin_memcpy(__s1, __s2, __n));
      |                                                        ^
/usr/src/debug/solidity/solidity_0.8.33/test/TestCase.cpp: In Funktion »expect«:
/usr/src/debug/solidity/solidity_0.8.33/test/TestCase.cpp:69:3: Anmerkung: an Offset 16 des Zielobjekts »<anonym>« der Größe 32
{standard input}: Assembler messages:
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
c++: schwerwiegender Fehler: Signal Getötet hat Programm lto1 beendet
Kompilierung beendet.
make[3]: *** [/tmp/ccALL7uc.mk:254: /tmp/ccMChG2k.ltrans126.ltrans.o] Fehler 1
lto-wrapper: schwerwiegender Fehler: make gab Ende-Status 2 zurück
Kompilierung beendet.
/usr/bin/ld: error: lto-wrapper failed
collect2: Fehler: ld gab 1 als Ende-Status zurück
make[2]: *** [test/CMakeFiles/soltest.dir/build.make:1993: test/soltest] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:888: test/CMakeFiles/soltest.dir/all] Fehler 2
make: *** [Makefile:136: all] Fehler 2
==> FEHLER: Ein Fehler geschah in check().
    Breche ab...
Fehler: ‚solidity-0.8.33-1‘ konnte nicht erstellt werden:
Fehler: kann serai-0.0.0-1 nicht erstellen, Abhängigkeiten nicht erfüllt: solidity
Fehler: Pakete konnten nicht erstellt werden: solidity-0.8.33-1  serai-0.0.0-1
[WARN] - (starship::context): Scanning current directory timed out.
[WARN] - (starship::context): You can set scan_timeout in your config to a higher value to allow longer-running scans to keep executing.

I investigated the issue. The error happens when running the tests. Strangely, I can only reproduce when installing this package with makepkg which is used by the AUR helpers. When cloning the repository and compiling by manually calling the build commands, the tests are executed normally and pass.

I even tried executing the tests with and without "z3". In both setups, the tests fail.

That issue was introduced with either v0.8.27 or v0.8.28.

I reported the issue here.

For now, I simply disabled the tests.

I'm getting a bunch of compile errors like:

/solidity/test/soltest.cpp(120): error: in "optimizedIRCaching/bytecode_dependency_creation": Exception during extracted test: /solidity/libsolidity/interface/CompilerStack.cpp(119): Throw in function solidity::frontend::CompilerStack::CompilerStack(solidity::frontend::ReadCallback::Callback)
Dynamic exception type: boost::wrapexcept<solidity::langutil::InternalCompilerError>
std::exception::what: You shall not have another CompilerStack aside me.
[solidity::util::tag_comment*] = You shall not have another CompilerStack aside me.

@Xeonacid If I understand you correctly you want (-> means conflicts with):

solidity -> {}
solidity-bin -> {solidity}
solidity-git -> {solidity}

Considering https://wiki.archlinux.org/title/PKGBUILD#conflicts , I thinks that the current approach is correct.

solidity-bin was ok

The package should not conflict with solidity-bin solidity-git. They should conflict with us instead.

Take a look at a similar issue. Try installing without z3 and cvc4. However, for me the bar was stuck somewhat over 80% so I do not know whether we experienced the same issue as I would assume that the order of test execution is the same which normally it should be from my understanding.

If that still does not solve the issue, you can skip the tests with paru --mflags --nocheck -S <package-name>.