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 ---Hi Paul, On Mon, Jan 13, 2020 at 9:13 AM Paul Spooren <m...@aparcar.org> wrote: > > Hi, > > On 1/12/20 1:05 PM, Martin Blumenstingl wrote: > > Hi Paul, > > > > On Sun, Jan 12, 2020 at 10:47 PM Paul Spooren <m...@aparcar.org> wrote: > >> Hi all, > >> > >> some time ago I created a (now outdated) device overview[0] based on > >> YAML meta data. This approach could simplify maintaining an device > >> overview and device specific pages[1]. > >> > >> All commits adding new devices already include most relevant information > >> for creating the overview. However it would be convenient if developers > >> would format their commit messages in a generic format, therefore I'd > >> propose the following: > >> > >> Every commit message for newly added devices must contain a number of > >> hardware information and steps for an initial installation. > >> The hardware information should contain at least the following > >> information, maybe more: > >> > >> SoC, flash, ram, wifi, LEDs, buttons, USB, serial, vendor, model, device > >> tree ID, Ethernet ports > > can we automate this somehow? > > the device tree files already contain most of that information. > > If you have a tool to extract such data or ideas on how to create such, > that'd be great. I don't have such a tool my idea was that most of the data is already available in the .dts files (or .dtb files, I haven't really thought about the up-/downsides): - SoC - flash size - RAM size - (wifi can be detected on some devices where wifi is either part of the SoC or the PCI(e) wifi chip is described in the .dts) - buttons - serial console (existence of such) - model - Ethernet ports - USB controller(s) this data can be parsed periodically to ensure that the TOH is up-to-date, for example if a missing LED is added after the initial submission of the device. there are probably downsides when going this route, but I have not thought these through yet (because I don't have time to implement a tool which would do the parsing) > As an alternative I could also create a shell script that extracts data > on a running machine, but that might miss some details. that would be another solution the downside I see compared to .dts/.dtb parsing is that you need access to the device to update the TOH. but I don't know whether this is relevant for the use-case that we're discussing Martin
--- End Message ---
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
