The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped automatically by the mailing list software.
--- Begin Message ---I now recall why I bailed out on the upstream indexes: they contain ABI versioned names that are eliminated by the ASU server's file parsers. A couple of examples: libatomic1 - https://downloads.openwrt.org/snapshots/targets/x86/64/packages/index.json libatomic - https://sysupgrade.openwrt.org/json/v1/snapshots/targets/x86/64/index.json libasm1 - https://downloads.openwrt.org/snapshots/packages/x86_64/base/index.json libasm - https://sysupgrade.openwrt.org/json/v1/snapshots/packages/x86_64-index.json How should we proceed here? - Remove the ABI versions in upstream index.json by changing the build? (Possibly breaking non-ASU users of this file.) - Introduce another file "index-sans-abi.json" with the ABIs removed? - Introduce another file "abi-mappings.json" with ABI to non-ABI mappings? - Add another section "abi_mappings: { "libatomic1": "libatomic", ... }" to the existing indexes? I don't think it's feasible to change the ASU clients, as they also rely on the `ubus call rpc-sys packagelist` that also strips ABI names. On Sunday, November 10th, 2024 at 07:05, Eric <evil.funct...@proton.me> wrote: > Paul, > > Aha! I had forgotten that I already played with the upstream index.json files > in owut several months ago and just forgot about them. I still have that > code, so as soon as my morning coffee kicks in, I'll start adapting it into > the ASU server so we have backward compatibility for auc, luci app and FS... > > I'll see if I can get it working today and submit a PR as soon as I feel it's > ready. > > Eric > > On Sunday, November 10th, 2024 at 04:18, Paul Spooren m...@aparcar.org wrote: > > > Hi Eric, > > > > Right now there exists index.json1 and we might want to create something > > like manifest.json, too. This way I’d be package manger format independent > > and would allow downstream tools to digest our existing packages. > > > > Best, > > Paul > > > > > On 9. Nov 2024, at 17:28, Eric evil.funct...@proton.me wrote: > > > > > > On Saturday, November 9th, 2024 at 07:50, Paul Spooren m...@aparcar.org > > > wrote: > > > > > > > My self hosted infrastructure is obsolete and we moved instead to the > > > > official staging environment1. > > > > > > Hi Paul, > > > > > > I'm looking at the binary database "packages.adb"1 on the staging server, > > > where on the production server we have the ascii "Packages"[2] file, > > > which lists all of the package info. Since the ASU server does its own > > > parsing of [2] in the `parse_packages_file` function, are we going to > > > have the build do a translation step to make an equivalent "Packages" or > > > should we add code to the ASU server to use the new "packages.adb" for > > > that? > > > > > > Eric > > > > > > 1 > > > https://downloads.staging.openwrt.org/snapshots/targets/x86/64/packages/packages.adb > > > [2] > > > https://downloads.openwrt.org/snapshots/targets/x86/64/packages/Packages
--- End Message ---
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
