uscan errors on the URL as it is no longer available.
Also switched the download URL to HTTPS.
Signed-off-by: Rosen Penev
---
package/boot/apex/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/package/boot/apex/Makefile b/package/boot/apex/Makefile
index d90df8e..6
uscan errors on the URL as it is no longer available.
Signed-off-by: Rosen Penev
---
package/boot/yamonenv/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/package/boot/yamonenv/Makefile b/package/boot/yamonenv/Makefile
index 011d39a..ef1f36d 100644
--- a/package/bo
uscan errors on the URL as it is no longer available.
Signed-off-by: Rosen Penev
---
package/boot/fconfig/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/package/boot/fconfig/Makefile b/package/boot/fconfig/Makefile
index 3c33d73..d82fa8d 100644
--- a/package/boot/
Allows discovery without having to use NetBIOS. Useful for mobile devices.
Could eventually throw nbmd away. But that requires Windows 10...
Tested on Fedora 28 with avahi-discover.
Signed-off-by: Rosen Penev
---
package/network/services/samba36/Makefile | 2 +-
package/network/service
The intention of 967b6be118e3 ("ar8327: Add workarounds for AR8337
switch") was to remove the register fixups for AR8337. But instead they
were removed for AR8327.
The RGMII RX delay is forced even if the port is used as phy instead of
mac, which results in no package flow at least for one board.
Hi,
some time ago Jacek Trzcinski sent a patch[1] for supporting the
MR3420v3, which unfortunately wasn't developed further to be included.
I'm using a MR3420v3 and would like to have official support for this
router; I think I could modify the patch for the master branch, but I
have no knowledge
I was informed that gpio-hogs might be the thing we are looking for, i
will look into that. So this patch should be hold back for now.
On 8/16/18 2:15 AM, David Bauer wrote:
> This commit adds support for the AVM Fritz!Box 4020 WiFi-router.
>
> SoC: Qualcomm Atheros QCA9561 (Dragonfly) 750MHz
>
Hello Karl,
On 8/16/18 3:12 AM, Karl Palsson wrote:
> 1) how bad are the portability issues that you felt
> reimplementing in _C_ was the best path? 2) if it's that bad, why
> keep it? How will future people knwo what to use. Either get rid
> of it, or fix it.
Regarding 1)
The portability issue s
