On Sunday I'll test if the CDN helps with the bandwidth laziness

@kyrios123 Sounds good. Now that Brisk Menu has been updated are there any further blockers for MATE? Or can we get Brisk Menu updated to git and land MATE 1.22.x next week?

@JoshStrobl Yes we can. No more blockers. I made a last round of updates yesterday for MATE so it's all fine.

Perhaps it would be good to check D5688 against i3 (I have never used it)

PS: why updating brisk to git instead of tagging a release?

PS: why updating brisk to git instead of tagging a release?

I can tag a release, I got no problem doing that, Wimpy had just mentioned some other PRs in that mate-menus API update PR that he wanted to get added and figured we'd get some validation in unstable first before I tag a release (in the event say, there is a major issue that isn't discovered until we land it in unstable and get it more thoroughly tested by Solus users). Similar to what I did for Budgie 10.5.

Re. compton, I can test that on my laptop when it gets landed alongside the MATE stack. Most i3 users are going to be using sway or i3wm anyways, so the scope of potential impact should it break for i3 is limited. I saw no issue with the diff itself.

Fork Plata-Theme into our own repo, re-introduce MATE Desktop support and merge in our metacity patch.

Will this be a separate package in eopkg, or are you replacing the current plata-theme package with the fork? I'm just concerned about how up-to-date the fork will be compared to upstream.

In T7805#147837, @serebit wrote:

Fork Plata-Theme into our own repo, re-introduce MATE Desktop support and merge in our metacity patch.

Will this be a separate package in eopkg, or are you replacing the current plata-theme package with the fork? I'm just concerned about how up-to-date the fork will be compared to upstream.

Your concern is unwarranted. @JoshStrobl keeps very close attention to Plata development. If we are ever behind, it's because of things like this holding us back. Forking provides us an easier way of maintaining this sizable patchset.

Monday update on my end:

1. I have a local fork of Plata-Theme now. Dropkicked Cinnamon, Telegram, Tweetdeck, and XFCE/Thunar/PCManFM support so far. Re-introduced MATE Support and applied our Budgie IconPopover styling patch. I didn't mark this resolved in meta task since it's still WIP, involves some further branding changes, etc. Considering that specific item as a "living" one that'll probably last next few days.
2. ferryd set up on home server, gnome-upgrade repository created.
3. Currently cloning shannon and unstable repos onto home server. This is gonna take quite a while and is gonna push back the AppStream update for obvious reasons. Fortunately @DataDrake did a massive cleanup of repos and old eopkgs, so considerably less to clone than when I originally created the task.

Total amount of time to clone the entire repo was 9 hours. Total size of both repos, with hardlinks, amounts to 401GB. Not bad. I'll work on sorting out the AppStream Data when I wake up.

Had to make ferryd semi-competent with mass import, so waiting as Bryan would say a "small eternity" on my repos to be added. 25000+ packages (this is all the sub-packages too) on unstable, as an example.

Follow-up: Was working on sorting out appstream data today except ran into a snag. Our appstream-builder is patched to support the eopkg format. Since all the repo contents are on my home server, which runs Fedora and for obvious reasons doesn't have a patch for eopkg format, it means that building it on the server directly has proven to be problematic. Building on that, our appstream-glib is insanely out-of-date, presumably because nobody has wanted to touch the patches and rebase them.

So I guess I get to do the honors. Should hopefully get it rebased tomorrow. In the meantime I'm going to go through and check our various software for references to packages.getsol.us so I know what sort of fall-out, if any, to expect once I start the work on Fastly.

Initial analysis of potential fallout:

1. Would affect AppStream screenshot assets which are pointed to https://packages.getsol.us/screenshots. See rAPST solus-appstream-data do_stream.sh.
2. solbuild points to https://packages.getsol.us/solbuild for its ImageBaseURI.

In my opinion, packages. isn't the appropriate subdomain for solbuild images and screenshots anyways. I'd rather see us move to sc. for Software Center assets and tooling. (or similar) for solbuild images. Thoughts @DataDrake?

FYI - I'm planning to have a look at gstreamer 1.16.0 next week