Sorry for that. I updated on my machine when RC-1 was released and didn't realise that the package had been bumped since then.

At some point down the line integration tests have started failing in the chroot (passing otherwise). Given that I haven't bumped shards since initial commit, has something changed in solbuild's backend that might cause them to fail? Otherwise I'll just disable them.

Updated to 24.2 and re-enabled some tests that are now passing. PATH-related test still doesn't pass in solbuild.

The latest release is now 0.8.0. https://github.com/kovidgoyal/kitty/archive/v0.8.0.tar.gz

pgadmin3 works, but its tabs aren't themed properly: image.

Updated to 2.0.0 and corrected license to BSD-3-Clause.

Updated to version 24.1, supporting LLVM 5.0. Additional release notes for the v0.24.0 and v0.24.1 releases are on Github.

Removed commented lines that were left from drafting

The link that you've provided for the package should be the source tarball rather than a compiled binary.

I have most everything building properly. Just need to figure out what will happen with old versions listed above.

I packaged this locally for the same reason as the OP, so if given the green light, I can upload that pretty quickly.

Nope, all good. I've been using Hackage to check dependencies for the most part, so that's fine.

I've found more time to work on this. Judging by other Haskell programs, we prefer to package libraries rather than use cabal to install them, correct?

I did a fresh reinstall of Solus from the latest ISO (was using one from February or so...) and the issue seems to be resolved.

Moving/resizing windows with super/alt + click and drag. More often it's that my palm triggers it in breaks in typing. It also seems to occur occasionally when I've just moved from the trackpad to the keyboard.

Awaiting an update of crystal to confirm my current package file will build with it.

I have a package that will build, but as in the primary post, is blocked by glew being updated.

The next release including the LLVM 5.0 patch was released a few weeks ago as version 0.24.0, but is tagged as a pre-release. Is this a valid release candidate for inclusion, or do we wait for a stable release?

In D884#19906, @joebonrichie wrote:

Steam still ships glew1.10 so I don't know if this can be updated

The compiler currently doesn't build on LLVM 5.0, which was pushed to unstable and stable in the GNOME stack upgrade this past weekend.

Obviously not part of the triage team, but it's worth noting that Rambox requires a non-free tool to build. Not sure how well that integrates, given that all third-party tools are to be moved to snaps, and I'm not sure how well snap runs in the build environment.

Fair enough. I just copied and pasted the changelog and forgot that they have a Windows version too. Removed the two entries that mention it.

Fixed errors: redundant declaration for libssl, unnecessary specification for non-doc package, enable networking tests, leverage variables for cleaning, don't include LICENSE

My bad; my fault for looking through older commits and not finding any done with Arcanist. Call it nerves.

I think I can get most of the files to install to the right place, but permissions are wrong for most of them.

@kyrios123 Thanks. Are these advanced sort of specifications properly documented anywhere?

Had a go at packaging this. Part of the make install script for the HIDS adds a new user and installs files owned by this user. What's the usual method of doing this for Solus?

Given the frequency of version bumps in their commit history (1.1 in 2001, 1.1.1 in 2003, 1.2 in 2008, 1.3 in 2013), version 1.4 might not be out for another year at least. Would it not be easier to port back the autotools files (given that about only a dozen lines have changed since 1.3 and the current git HEAD, aside from the new files) for a sooner release?

The problem with packaging Crystal is that it doesn't have a bootstrap; Crystal requires Crystal to compile. The solution to this, I guess, is to fetch the distributed binary for use in building, but I don't know if we encourage that in situations like this. Do we have a precedence?

Is this possible to include as one package? Afaik the current package.yml spec doesn't allow for file renaming before the setup phase, so it tries to download all five as whatever the current version is, but it will only fetch the first because of naming conflicts.

Removed code block around changelog.

In D630#11015, @JoshStrobl wrote:

The code tags around the items can be removed, the Software Center can parse them.

Added changelog from Github.

Added test plan.