I don't know if it's just due to my small tablet screen or something that happens to everyone but

I can't try to select the contents because it disappears if I move the mouse off the status field, or scroll because the page scrollbar is already at the top.

I want to see all packages that are outdated and are transitive dependencies of package "foo" and "bar" for example.

It's hard to care about all outdated packages, but it's easier to care about a small set imo

We currently throw out missing packages due to dep cycles which makes autobuild alter fail. Ideally autobuild wouldn't even start them and write out in the queue status that some dep is missing.

The current API response is (it grew over time..):

{
    "repo_url": "https://github.com/msys2/MINGW-packages",
    "repo_path": "mingw-w64-mono",
    "version": "6.4.0.198-1",
    "name": "mingw-w64-mono",
    "source": false,
    "packages": {
        "ucrt64": [
            "mingw-w64-ucrt-x86_64-mono"
        ],
        "clang64": [
            "mingw-w64-clang-x86_64-mono"
        ]
    },
    "new": [
        "ucrt64",
        "clang64"
    ],
    "depends": {
        "msys": [
            "libedit",
            "perl-libwww"
        ]
    }
}

and we hardcode in autobuild that ucrt64 depends on msys etc.

Ideally the response would be this, so all the info is neatly separated by build type:

{
    "repo_url": "https://github.com/msys2/MINGW-packages",
    "repo_path": "mingw-w64-mono",
    "version": "6.4.0.198-1",
    "name": "mingw-w64-mono",
    "source": false,
    "builds": {
        "ucrt64": {
            "packages": [
                "mingw-w64-ucrt-x86_64-mono"
            ],
            "new": true,
            "depends": {
                "msys": [
                    "libedit",
                    "perl-libwww"
                ]
            }
        },
        "clang64": {
            "packages": [
                "mingw-w64-clang-x86_64-mono"
            ],
            "new": true,
            "depends": {
                "msys": [
                    "libedit",
                    "perl-libwww"
                ]
            }
        }
    }
}

With all the ucrt64 package updates lately, updates for any other repo are kind of buried. It would be nice to be able to be able to see the latest updates for a given repo.

The "pending package updates" page has a similar issue, but it doesn't have a 'repo' column, so I don't know if something like that would work there.

Assume we have "foo" in the repo and try to build "foo-git" and "bar" depending on "foo". We shouldn't replace "foo" with "foo-git" in the deps because -git variants will likely fail and will not be used for building.

Not sure how pacman resolves this, but we should only replace a provides if there is not a real package with that name in the repo or in the queue.

In case the server gets restarted it will just return empty everything until it fetches everything. Since we now depend on the API for building this leads to the CI job removing all already built packages.

The API should return 50x in case the data hasn't been fetched yet.

• Fetch http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.ini
• Extract the source name from the "source:" tarball name and the matching version
• Link to https://cygwin.com/packages/summary/<src-name>-src.html

It would be nice if we could receive github webhooks and trigger an appveyor build so we can get rid of the appveyor cron job.

• https://github.com/bloomberg/python-github-webhook or https://github.com/nickfrostatx/flask-hookserver
• https://www.appveyor.com/docs/api/projects-builds/#start-build-of-branch-most-recent-commit

This requires two secrets on the deployment side of things: github webhook secret and appveyor api token.

This is conceptionally similar to a pkgbase, but for groups. Something like this doesn't really exist on the PKGBUILD level, but end users can't really work with pkgbase with pacman either, so for them that doesn't matter.

It still gives the end user the same structure as with packages, there is a base thing that has multiple instances for each environment, and searching might be a bit easier.

The UX could be improved, but the basics are there at least.

Fixes https://github.com/msys2/msys2-web/issues/47

Do some very basic parsing of spdx expressions and add links to the respective license pages.

Multiple licenses in a package are combined with "OR".

Running on Windows 10.

pacman -S mingw-w64-clang-x86_64-toolchain

Results in : ---> Packages (47) mingw-w64-clang-x86_64-bzip2-1.0.8-2 mingw-w64-clang-x86_64-ca-certificates-20210119-1 mingw-w64-clang-x86_64-expat-2.4.8-1 mingw-w64-clang-x86_64-gettext-0.21-3 mingw-w64-clang-x86_64-libffi-3.3-4 mingw-w64-clang-x86_64-libiconv-1.16-2 mingw-w64-clang-x86_64-libsystre-1.0.1-4 mingw-w64-clang-x86_64-libtasn1-4.18.0-1 mingw-w64-clang-x86_64-libtre-git-r128.6fb7206-2 mingw-w64-clang-x86_64-libxml2-2.9.13-2 mingw-w64-clang-x86_64-lua-5.4.3-2 mingw-w64-clang-x86_64-mpdecimal-2.5.1-1 mingw-w64-clang-x86_64-ncurses-6.3-5 mingw-w64-clang-x86_64-openssl-1.1.1.n-1 mingw-w64-clang-x86_64-p11-kit-0.24.1-2 mingw-w64-clang-x86_64-python-3.9.12-1 mingw-w64-clang-x86_64-python-six-1.16.0-2 mingw-w64-clang-x86_64-readline-8.1.001-1 mingw-w64-clang-x86_64-sqlite3-3.38.2-1 mingw-w64-clang-x86_64-tcl-8.6.11-5 mingw-w64-clang-x86_64-termcap-1.3.1-6 mingw-w64-clang-x86_64-tk-8.6.11.1-2 mingw-w64-clang-x86_64-tzdata-2022a-1 mingw-w64-clang-x86_64-xz-5.2.5-3 mingw-w64-clang-x86_64-zlib-1.2.12-1 mingw-w64-clang-x86_64-clang-14.0.0-1 mingw-w64-clang-x86_64-clang-analyzer-14.0.0-1 mingw-w64-clang-x86_64-clang-tools-extra-14.0.0-1 mingw-w64-clang-x86_64-compiler-rt-14.0.0-1 mingw-w64-clang-x86_64-crt-git-10.0.0.r14.ga08c638f8-1 mingw-w64-clang-x86_64-gcc-compat-14.0.0-1 mingw-w64-clang-x86_64-headers-git-10.0.0.r14.ga08c638f8-1 mingw-w64-clang-x86_64-libc++-14.0.0-1 mingw-w64-clang-x86_64-libc++abi-14.0.0-1 mingw-w64-clang-x86_64-libmangle-git-10.0.0.r14.ga08c638f8-1 mingw-w64-clang-x86_64-libunwind-14.0.0-1 mingw-w64-clang-x86_64-libwinpthread-git-10.0.0.r14.ga08c638f8-1 mingw-w64-clang-x86_64-lld-14.0.0-1 mingw-w64-clang-x86_64-lldb-14.0.0-1 mingw-w64-clang-x86_64-llvm-14.0.0-1 mingw-w64-clang-x86_64-make-4.3-1 mingw-w64-clang-x86_64-openmp-14.0.0-2 mingw-w64-clang-x86_64-pkgconf-1.8.0-2 mingw-w64-clang-x86_64-polly-14.0.0-1 mingw-w64-clang-x86_64-tools-git-10.0.0.r14.ga08c638f8-1 mingw-w64-clang-x86_64-winpthreads-git-10.0.0.r14.ga08c638f8-1 mingw-w64-clang-x86_64-winstorecompat-git-10.0.0.r14.ga08c638f8-1

Total Download Size: 162.89 MiB Total Installed Size: 1196.46 MiB

But then --->

error: failed retrieving file 'mingw-w64-clang-x86_64-lldb-14.0.0-1-any.pkg.tar.zst' from mirror.msys2.org : SSL connection timeout error: failed retrieving file 'mingw-w64-clang-x86_64-openssl-1.1.1.n-1-any.pkg.tar.zst' from mirror.msys2.org : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds error: failed retrieving file 'mingw-w64-clang-x86_64-openssl-1.1.1.n-1-any.pkg.tar.zst' from repo.msys2.org : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds error: failed retrieving file 'mingw-w64-clang-x86_64-openmp-14.0.0-2-any.pkg.tar.zst' from mirror.msys2.org : Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds warning: too many errors from mirror.msys2.org, skipping for the remainder of this transaction

The current search bar only searches by package name in either Base Packages or Packages meaning if I were to want to look up a Fourth compiler, I would need to go to https://packages.msys2.org/package or https://packages.msys2.org/base and use my browser's find function to search for Fourth to bring up one of the 4th packages

On the queue page, there is no real indication there is another list after the giant pending package updates list. On discord, @elieux suggested adding ids to the lists, but I suggest going one step further and also adding some sort of "TOC" type thing with a link to that id, and also indicating that there is in fact another section down there.

A package can only be removed if nothing in the repo depends on it anymore.

This also includes if it provides something and there is no real package with that name, and that provides is used somewhere.

In the future we might want to start some build if anything in our responses changes, maybe with some debounce to avoid triggering it too much.

• We currently already detect changes for etag handling
• We currently always "detect" a change when the appveyor job runs because it always uploads a new release and the mtime changes. We should avoid updating the parsing release if nothing has changed.