Conversation
ADKaster
left a comment
There was a problem hiding this comment.
This is pretty cool! There's already a large collection of patches in the Ports/ directory of serenity, with xexxa's cool https://ports.serenityos.net/ that organizes the AvailablePorts by category.
Your question about SDL2 in the description makes me wonder how Nix would want to pick up or reproduce our existing patches.
|
Packaged serenity libraries, lagom, and added support for x86_64-serenity. Will squash and organiser properly before merging :) |
|
Not sure why ofborg eval is failing? 😕 |
|
@ofborg eval |
eb35b21 to
5f698c1
Compare
alyssais
left a comment
There was a problem hiding this comment.
I've only reviewed the first 1½ commits so far, because it didn't build for me when I tried, either on the second commit, or the head of the PR:
checking for references to /build/ in /nix/store/rh54vhdmfpablzzfjmgnhypbfcs8jq50-serenity-bootstrap-toolchain-unstable-2022-08-07...
RPATH of binary /nix/store/rh54vhdmfpablzzfjmgnhypbfcs8jq50-serenity-bootstrap-toolchain-unstable-2022-08-07/x86_64-pc-linux-gnu/i686-pc-serenity/lib/libopcodes-2.38.so contains a forbidden reference to /build/
find: 'standard output': Broken pipe
find: write error
pkgs/development/compilers/gcc/12/serenity-libtool-enable-shared-library-support.patch
Outdated
Show resolved
Hide resolved
|
Hello friends! I revisited SerenityOS support again and rewrote it from scratch, with changes from all the review comments (thank you!) and upstream support improvements. In my opinion the new patch set is smaller, simpler, and better integrated with nixpkgs compiler tooling. Please let me know your thoughts! @NixOS/exotic-platform-maintainers |
|
Glad to hear this project has helped motivate the upstreaming effort! In the mean time I will work on getting the LLVM toolchain to work as well. To focus on the compiler toolchain I've dropped the patches for OpenSSL. |
Last revision before major LLVM bump SerenityOS/serenity#18522
|
We should consider keeping enough patches for Serenity in-tree to make stdenv work but not patches and conditionals outside of that scope. I think there is less work overall if Serenity testers don't have to build their own toolchains and if we don't have to work around their conditionals in the leaf packages here. Accumulating patches for toolchains isn't such a terrible thing. It would be a resource for people looking to port toolchains elsewhere and if there are problems at least its not something that we deal with on the master branch. |
Agreed, which is why I'm happy to accept them if they're rejected upstream. But it's definitely not better than the patches being upstreamed, which is why we should only do it if they can't be upstreamed. |
|
Yes, upstreaming is ideal, but complicated. It's easy enough to patch an LLVM release but patching their master branch and waiting for the next release can take a while. Maybe the platform only wants to support building with GCC and not LLVM. These are the sorts of thing that blocked Genode support. |
This is not the case. |
There's a major LLVM release every six months. That's not a long time in the context of adding a whole new platform. And it would be fine to backport patches to get support available early — backports are very different to patches we might never get rid of.
In that case, it would be fine not to support LLVM for that platform. |
|
A release every six months means waiting three months on average, plus the time to get patches merged. This PR has been open for ten months already and I would not be surprised if it was open in ten months from now. |
|
It is immensely easier to say "no more patches" than it is to upstream work or write patches in the first place. Can we please have an example where we've been burned in the past by this? |
Exactly, so if it takes three months for patches to get in, that's unlikely to make a difference at all to the length of time it takes for the new platform to be reviewed (which can start before the patches are upstream). |
Example one: I maintain QEMU. For a long time updating QEMU was a total nightmare, because of Darwin patches that were applied in Nixpkgs, and those were just the bare minimum to deal with QEMU depending on a newer SDK than we are able to provide. Updates would be delayed weeks because of the need to update patches, and because they were for Darwin, I couldn't even test them. Later there was a proposal to add eleven more patches to implement 9p support on Darwin. I put my foot down, because at that point there's no way I'd be able to handle updates without them getting blocked on Darwin. As a result, the patches were submitted and accepted upstream, and now every QEMU user on Darwin, not just Nixpkgs users, benefits from that support, and I don't have to try to rebase a dozen patches for a platform I don't use every time I update QEMU. Example two: we patch systemd to work on musl, because upstream is hostlie to musl. As a result of a compromise with the systemd maintainers, these patches are only applied during musl builds, so they don't have to wait for updated musl patches to update systemd. (This is the same setup originally proposed for the Serenity toolchain.) This works, but it means that as musl enthusiasts, we have to be very on the ball so that new systemd releases don't completely break the ability to run NixOS on musl. (Basically, the patches have to be updated before systemd gets out of staging.) A lot of work would have been saved if upstream had been willing to accept those patches once, so they didn't have to be redone every time. Sadly, in this case that didn't happen, so we're stuck with extra boring, repetitive work forever keeping those patches up to date. It was absolutely worth the attempt to upstream the patches to try to save all that future work, especially because, if upstream is entirely unwilling to support a platform, it's probably not going to take very long to find that out. |
Nobody is saying "no more patches". I'm saying "no patches where there hasn't even been the bare minimum of an attempt to upstream them, where they would make sense to upstream, and where upstream is not known to be unreasonable (e.g. hostile to new platforms, bad CLA requirements, etc.)". |
|
@emilytrau are you still planning on merging this? This would be a cool addition to the cross infra! |
Description of changes
A graphical Unix-like operating system for desktop computers! SerenityOS is a love letter to '90s user interfaces with a custom Unix-like core. It flatters with sincerity by stealing beautiful ideas from various other systems.
I've spent about a week working on porting nixpkgs to SerenityOS. I wanted to play around with both lower-level nixpkgs infra and SerenityOS for the first time and this was a super fun project to do both! There's still plenty of work to be done but I wanted to get it out for play/testing/feedback from both the nix and serenity side.
Bootstrapping stdenv got very complicated but I'm proud that this builds entirely from source with no bootstrapping binaries required.
This is able to build against the SerenityOS main branch without any patches. I am planning a PR to make the nix profile work out-of-the-box, and start an overlay for Serenity specific package fixes.
:^)
How to test
Serenity patch to load the nix profile automatically https://gist.github.com/emilytrau/2c4f8346ca71405527521fbbe0113989
Todo
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)nixos/doc/manual/md-to-db.shto update generated release notes@NixOS/exotic-platform-maintainers