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 ---On 28/03/17 17:37, Daniel Golle wrote: > Hi Pau, > > On Tue, Mar 28, 2017 at 09:28:22PM +0200, Pau wrote: >> Hi. >> >> I am using the SDK and IB from LEDE 17.01.0 release (mips_24kc). I've >> been using it successfully the last days until now. I did not change >> anything but I get the error: >> >> * opkg_install_pkg: Package luci-lib-nixio sha256sum mismatch. Either >> the opkg or the package index are corrupt. Try 'opkg update'. >> >> Then I went to downloads.lede-project.org [1] and I see that there are >> new compiled packages with date "Tue Mar 28 18:35:15 2017". >> Luci-lib-nixio is one of them [2] (which now is published on the >> repository with a new version). > > Packages from the feeds and even base-packages (think: openssl) can > change after a release, just like for other distributions. i agree packages can and should be maintained, but in progressive releases. i.e. if i install ubuntu 12.04 today, i expect to have exactly the same system than what i got if i installed ubuntu 12.04 at the time of its release if i want to get the fixes that happened after the time of original 12.04 release, i'd install 12.04.1 or, install 12.04 and run "apt-get update && apt-get upgrade" the equivalent in lede would be ..."opkg update && opkg upgrade *"? but it doesn't even really make sense, given squashfs and so on. so i'm thinking out loud: wouldn't it make sense to leave the packages tree "frozen" at the time of release? and any updated packages compiled and dumped to a different feed, like 17.01-updates ? https://downloads.lede-project.org/releases/17.01-updates/packages/ i thought debian did something like this, but i just checked and the "jessie" dist *does* change over time (5 minutes ago i thought only "jessie-updates" changed) i must admit that after some thinking, i'm utterly confused, so will probably accept whatever reasoning anyone provides, all we want to do is create a firmware based on a specific LEDE release, and not fear that if we want to rebuild the exact same firmware in two months (or days!), we will get a different (broken) result :) > The error message you see more looks like being caused by inconsistent > Package index not matching the actual binaries. Maybe regenerating > the index can fix that...? > >> >> In the other hand the feeds.conf.default file included in the release >> SDK points to the specific commit >> a100738163585ae1edc24d832ca9bef1f34beef0 from Sat Jan 28 01:38:06 2017. >> The SDK published then is not consistent with the current package binary >> repositories. > > The SDK doesn't need to be consistent with all packages, but the fixed > commit (instead of a branch) is indeed misleading (and most likely got > rather political reasons, like not poluting a repo called > github.com/openwrt/packages with a branch called for-lede-17.01...) > >> >> So my question here is: what's the point for publishing a Release if the >> packages included are changing? Is this the expected behavior? > > Definitely not the expected behaviour, but packages may and should > change, eg. for bug or security fixes. > > > Cheers > > > Daniel > >> >> Thanks. >> >> [1] >> https://downloads.lede-project.org/releases/17.01.0/packages/mipsel_24kc/ >> [2] >> https://downloads.lede-project.org/releases/17.01.0/packages/mips_24kc/luci/luci-lib-nixio_git-17.073.42825-b47a21f-1_mips_24kc.ipk >> >> -- >> ./p4u >> > > > > >> _______________________________________________ >> Lede-dev mailing list >> Lede-dev@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/lede-dev > > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev >
--- End Message ---
_______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
