On Sat, Jan 23, 2021 at 06:57:53PM -0500, Etienne Champetier wrote:
> Le sam. 23 janv. 2021 à 18:09, Sam Kuper a écrit :
>> I suggest that if a vote is held, it should be a three-way vote
>> between the following outcomes (which should probably be mutually
>> exclusive):
>>
>> - OpenWRT Jobs wiki p
Hi All,
Le sam. 23 janv. 2021 à 18:09, Sam Kuper a écrit :
>
> On Sat, Jan 23, 2021 at 02:55:05PM +, Ted Hess wrote:
> > [T]here must be some sort of criteria (contributions, legitimate
> > business site or references) to get your name/outfit listed. And, as
> > Daniel said, we don't want to
On Sat, Jan 23, 2021 at 02:55:05PM +, Ted Hess wrote:
> [T]here must be some sort of criteria (contributions, legitimate
> business site or references) to get your name/outfit listed. And, as
> Daniel said, we don't want to be in the business of certifying
> contractors.
Those two sentences se
Pstore (persistent store) can be used to stash debug information (kernel
console, panics, ftrace) across reboots or crashes. If the filesystem is
present, mount it.
Signed-off-by: Brian Norris
---
package/base-files/files/etc/init.d/boot | 1 +
1 file changed, 1 insertion(+)
diff --git a/packag
On 1/23/2021 11:06:53 AM, "Petr Štetiar" wrote:
Ted Hess [2021-01-23 14:55:05]:
Hi,
we don't want to be in the business of certifying contractors.
exactly.
If we get complaints
Do we want new source for a potential bad press?
their reference gets reviewed and most likely remove
Hi,
I do not think this is a good idea. The project should remain
commercially and politically independent in order to guarantee its
sovereignty. Hauke gave some good pointers on how to contact individuals
devs.
John
___
openwrt-devel mailing
On 1/23/21 6:07 PM, Ibrahim Tachijian wrote:
What do the NACK people say is the best way to find people that is
willing to do OpenWRT work ?
Surely, emailing this mailing list is not enough, or?
Hi,
I would suggest to look into the git history of the part which interests
you and write a mai
On 1/23/21 2:24 PM, Jo-Philipp Wich wrote:
Hi,
I don't think this is a good idea due to legal obligations,
administrative hassle, quality of work issues and so on.
NACK from me.
I agree with Jo.
NACK from me too.
Such a page will also be seen as some sort of endorsement and people
could bl
Ted Hess [2021-01-23 14:55:05]:
Hi,
> we don't want to be in the business of certifying contractors.
exactly.
> If we get complaints
Do we want new source for a potential bad press?
> their reference gets reviewed and most likely removed.
You can't review business cases as patches, this is
On 23/01/21 09:49, Paul Spooren wrote:
On Sa, Jan 23, 2021 at 07:25, Alberto Bursi
wrote:
On 22/01/21 20:03, Daniel Golle wrote:
Hi Philip,
On Fri, Jan 22, 2021 at 11:23:42AM -0700, Philip Prindeville wrote:
Hi,
Is anyone interested in adding a page to the openwrt.org site about
de
On 1/23/2021 1:25:31 AM, "Alberto Bursi"
wrote:
On 22/01/21 20:03, Daniel Golle wrote:
Hi Philip,
On Fri, Jan 22, 2021 at 11:23:42AM -0700, Philip Prindeville wrote:
Hi,
Is anyone interested in adding a page to the openwrt.org site about developers
willing to do commercial work?
It
Hi,
I don't think this is a good idea due to legal obligations,
administrative hassle, quality of work issues and so on.
NACK from me.
~ Jo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openw
On 1/23/21 1:58 AM, David Bauer wrote:
Enable support for the Ubiquiti UniFi Outdoor+ RF filter via
device-tree. The old way of using platform data is not required anymore,
as it was only used on the now removed ar71xx target.
Signed-off-by: David Bauer
---
.../ath/551-ath9k_ubnt_uap_plus_hsr
This sorts the Build recipes alphabetically, wraps some long lines
and moves the DEVICE_VARS to the top like common on several other
targets.
Cc: Rafał Miłecki
Signed-off-by: Adrian Schmutzler
---
Changes in v2:
- new patch
---
target/linux/bcm4908/image/Makefile | 28 -
This sets the DTS paths automatically based on their device definition
name. Devices where this is not possible may still be served by simply
overwriting DEVICE_DTS in their respective definition.
Cc: Rafał Miłecki
Signed-off-by: Adrian Schmutzler
---
Changes in v2:
- rebase
---
target/linux/
Hi,
two comments below.
> + leds {
> + compatible = "gpio-leds";
> +
> + led_white: white {
> + label = "blue";
> + gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
> + };
> +
> + blue {
> + label =
On Sa, Jan 23, 2021 at 07:25, Alberto Bursi
wrote:
On 22/01/21 20:03, Daniel Golle wrote:
Hi Philip,
On Fri, Jan 22, 2021 at 11:23:42AM -0700, Philip Prindeville wrote:
Hi,
Is anyone interested in adding a page to the openwrt.org site about
developers willing to do commercial work?
Append a device specific version trailer used by the stock
firmware upgrade application to validate firmwares.
The trailer contains a list of ZyXEL firmware version
numbers, which includes a four letter hardware identifier.
The stock web UI requires that the current hardware matches
one of the lis
Only two minor changes is required to make our initramfs image
flashable from stock web UI. This allows upgrades to OpenWrt
without using console access.
In theory, the u-image magic could be different for the
initramfs and the squashfs image, since it is not validated by
u-boot and the stock web
The stock firmware of the ZyXEL GS1900 series use a non-standard
u-image magic. This is not enforced by the stock u-boot, which is
why we could boot images with the default magic. The flash
management application of the stock firmware will however verify
the magic, and refuse any image with anoth
20 matches
Mail list logo