[OpenWrt-Devel] flock clash with msmtpq-ng-mta

2019-01-03 Thread Marcel Telka 

Hi,

After upgrade from LEDE 17.01.4 to OpenWrt 18.06.1 I noticed that mailq from
the msmtpq-ng-mta package no longer works:

# mailq
flock: unrecognized option: w
BusyBox v1.28.4 () multi-call binary.

Usage: flock [-sxun] FD|{FILE [-c] PROG ARGS}

[Un]lock file descriptor, or lock FILE, run PROG

-s  Shared lock
-x  Exclusive lock (default)
-u  Unlock FD
-n  Fail rather than wait
logger: unrecognized option: i
BusyBox v1.28.4 () multi-call binary.

Usage: logger [OPTIONS] [MESSAGE]

Write MESSAGE (or stdin) to syslog

-s  Log to stderr as well as the system log
-t TAG  Log using the specified tag (defaults to user name)
-p PRIO Priority (numeric or facility.level pair)
#


The problem is that busybox 1.28.4-2 ships /usr/bin/flock (and it lacks support
for the -w option) which was not the case for busybox 1.25.1-4 (in 17.01.4).
The /usr/bin/flock was just not there.  Apparently, logger is a problem too.

So either mailq should be changed to do not expect the -w option for flock, or
flock should be enhanced to support -w, or the busybox package should stop to
deliver flock.

To workaround this issue on an already running device just simply remove the
/usr/bin/flock symlink.


Thanks.

--
+---+
| Marcel Telka   e-mail:   mar...@telka.sk  |
|homepage: http://telka.sk/ |
|jabber:   mar...@jabber.sk |
+---+


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Pending ath79 issues on ar9342 and 4.14/4.19 kernels

2019-01-03 Thread Weedy 
On Tue, 1 Jan 2019 at 19:26, Petr Štetiar  wrote:
>
> Hi,
Happy new year!

> this is more like my todo list shared with 蝈蝈 (Guo), but I hope, that I
> could get some inputs from others as well.
I'm tagging along with the subject not specifically the points you made.
I hope this isn't a problem. And I'm not trying to imply you have to fix these.
I'm just a end user.

5. A general performance loss going from ar71xx/4.9 to ath79/4.14
I used to be able to rsync stuff 7-10MiB/s over WiFi and now I'm at
4-6MiB/s (5ghz, 2.4ghz has always been crowded and shit)
And I swear sysupgrade/rebooting takes longer now. That said the
network fastpath stuff does seem to work so that's a win for wired.
This does give me an excuse to update to all PoE AC equipment, but I'm
still sad to see perf get worse over time.

6. Uptime is terrible. This is arguably my biggest problem with ath79.
I am the families tech support so I need WiFi to always "Just Work
(TM)" and it doesn't do that any more.
This might be your #4, I haven't been really able to catch it in the act.
But I'll come home and notice my box(es) have rebooted, or I'll be in
another corner of the house and WiFi completely stalls for minutes.
I have some self healing magic on my boxes so they are either panicing
or my script sees they aren't passing traffic and ifdown/ifup
something or forces a reboot.
I had some crap in notepad that I forgot to send to the list last
month but "NETDEV WATCHDOG" sounds familiar.



As an aside because of the new year, I'd like to thank all OpenWRT
devs for their continued service.
I've been using it since before the WR 0.9 release. And I hope I'm
able to keep using it until the heat death of the universe.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] treewide: dts: Unify naming of gpio-keys nodes

2019-01-03 Thread Petr Štetiar 
Christian Lamparter  [2019-01-03 18:27:40]:

> I would try to split up the patch into multiple patches so that
> each maintainer has the chance to act on just his own turf. 

I don't want to waste more of my time on such noop stuff, I've tried it so
let's see how it pans out :-)

> Keep in mind that linux-kernel is heavily compartmentalized. The device-tree
> maintainers mainly just ack/review patches for the subsystem maintainers.

Yea, just give me some feedback and I'm more then happy to do what is
necessary to finish this crusade, but until then I'll just put it on ice.

> However it's much easier to comment on the daily patches/PRs
> and make sure that new boards/dts are up to spec with the latest craze and
> also, you get the chance to interact with the commiters a bit.

Yea, almost every submission has some copy&pasted stuff (I'm guilty as well),
so just trying to make it easier for everyone. Provide good examples for
copy&pasting, saving some time of submitters, reviewers and commiters.

> While looking at the checklist, I noticed that one of the "SPDX license tag"
> check is already automated in the upstream scripts/checkpatch.pl... And now,
> I wish that the script could also act on default-state = "off", the
> "gpio-keys-polled" and "gpio-leds" node names, etc.

Indeed, it would be nice to automate this and other checks and integrate it
into GitHub's PR pipeline via some CI system. Well, one day :-)

-- ynezz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] treewide: dts: Unify naming of gpio-keys nodes

2019-01-03 Thread Christian Lamparter 
On Tuesday, January 1, 2019 6:07:40 PM CET Petr Štetiar wrote:
> Christian Lamparter  [2018-12-31 17:41:34]:
> 
> > I hope you know what you are up against because unless you also do the 
> > changes
> > upstream this will happen again and again. :\ / :)
> 
> My plan is to first wait for comments here, see if it gets merged eventualy
> and then start poking upstream. I still didn't received any feedback yet(good
> sign?) on my last `treewide: dts: Remove default-state=off property...`[1]
> upstream attempt so I don't know if it's worth the effort.
Hm, interesting. I usually get replies within a few days. Granted, I have never
sent anything that big in a single mail to multiple mailinglists and 
maintainers. I would try to split up the patch into multiple patches so that
each maintainer has the chance to act on just his own turf. 
Keep in mind that linux-kernel is heavily compartmentalized. The device-tree
maintainers mainly just ack/review patches for the subsystem maintainers.
This is done in order to prevent the conflicts between the various trees when
they get staged into -next and ultimately wander into the kernel during the
"merge window". 

I guess if you still want to follow through you could start to update the
binding documents. But, I do understand that you don't want to waste 
anymore time with it.

> Anyway, I guess, that in most of the cases, people are just copy&pasting from
> the DTS files from the OpenWrt repository and some of them even wonder[2] why
> they need to use generic `leds` node names if it's not the case in the rest of
> the DTS files in OpenWrt tree:
> 
>  @mkresin: would you please rename the node to the generic "leds".
>  @arapov: @mkresin, by the way, the rest of *.dts in ramips/ using gpio-leds.
>   Do you still think it is good to deviate from the rest here?
> 
> 1. https://patchwork.kernel.org/patch/10732465/
> 2. https://github.com/openwrt/openwrt/pull/1686#discussion_r244512451
True, I think you noticed that it's a surprisingly long and weird difficult
process to push these sort of changes upstream unless you are directly
involved there. However it's much easier to comment on the daily patches/PRs
and make sure that new boards/dts are up to spec with the latest craze and
also, you get the chance to interact with the commiters a bit.

> 3. https://openwrt.org/submitting-patches#dts_checklist
^^ I know that one only too well.
"The name of a node should reflect the function of the device and not its 
model. "
I c&p that from the device-tree spec and linked to it so devs know from where
these seemingly arbitrary rules come from. While looking at the checklist, I 
noticed that one of the "SPDX license tag" check is already automated in the
upstream scripts/checkpatch.pl... And now, I wish that the script could also
act on default-state = "off", the "gpio-keys-polled" and "gpio-leds" 
node names, etc.

Oh well.

Regards,
Christian



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] GSoC 2019 application

2019-01-03 Thread Andreas Bräu 
Hi there,

I wish you all a happy new year. I hope you had a good time over Christmas and 
New Year.

A new year also means there will be a new Google Summer of Code. It will be the 
15th edition!

The application period will start in a few days on January 15.

If we want to apply again and to be successful, we need to add some fresh ideas 
to our projects page before our application: https://projects.freifunk,net 


You can add, edit or delete your ideas via GitHub: 
https://github.com/freifunk/projects.freifunk.net-contents/tree/master/collections/_projects
 


We should also delete ideas that are obsolete now.

If you have any questions, please tell me!

Best regards,

Andi


signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] uboot-imx6: Bump to 2018.11

2019-01-03 Thread Petr Štetiar 
Build tested: apalis, mx6sabresd, nitrogen6dl, nitrogen6dl2g, nitrogen6q,
  nitrogen6q2g, nitrogen6s, nitrogen6s1g, wandboard

Run tested: apalis (pending PR #1595)

Cc: Felix Fietkau 
Cc: Vladimir Vid 
Cc: Koen Vandeputte 
Signed-off-by: Petr Štetiar 
---
 package/boot/uboot-imx6/Makefile   |  4 ++--
 package/boot/uboot-imx6/patches/100-wandboard-enable-fit.patch |  6 +++---
 .../boot/uboot-imx6/patches/110-mx6cuboxi-mmc-fallback.patch   | 10 +-
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/package/boot/uboot-imx6/Makefile b/package/boot/uboot-imx6/Makefile
index 3eba249..8bd1ff6 100644
--- a/package/boot/uboot-imx6/Makefile
+++ b/package/boot/uboot-imx6/Makefile
@@ -7,10 +7,10 @@
 
 include $(TOPDIR)/rules.mk
 
-PKG_VERSION:=2018.03
+PKG_VERSION:=2018.11
 PKG_RELEASE:=1
 
-PKG_HASH:=7e7477534409d5368eb1371ffde6820f0f79780a1a1f676161c48442cb303dfd
+PKG_HASH:=737c93f2ea03fec669e840dbee32bcf6238e6924ff5f20e4f1c472ee24e5d37e
 
 include $(INCLUDE_DIR)/u-boot.mk
 include $(INCLUDE_DIR)/package.mk
diff --git a/package/boot/uboot-imx6/patches/100-wandboard-enable-fit.patch 
b/package/boot/uboot-imx6/patches/100-wandboard-enable-fit.patch
index 6bfcc1f..d51b62b 100644
--- a/package/boot/uboot-imx6/patches/100-wandboard-enable-fit.patch
+++ b/package/boot/uboot-imx6/patches/100-wandboard-enable-fit.patch
@@ -1,6 +1,6 @@
 --- a/configs/wandboard_defconfig
 +++ b/configs/wandboard_defconfig
-@@ -27,7 +27,7 @@ CONFIG_CMD_I2C=y
+@@ -29,7 +29,7 @@ CONFIG_CMD_I2C=y
  CONFIG_CMD_MMC=y
  CONFIG_CMD_SATA=y
  CONFIG_CMD_USB=y
@@ -8,8 +8,8 @@
 +# CONFIG_CMD_CACHE is not set
  CONFIG_CMD_EXT4_WRITE=y
  CONFIG_ENV_IS_IN_MMC=y
- CONFIG_DM=y
-@@ -39,3 +39,5 @@ CONFIG_USB_STORAGE=y
+ CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+@@ -44,3 +44,5 @@ CONFIG_USB_STORAGE=y
  CONFIG_VIDEO=y
  # CONFIG_VIDEO_SW_CURSOR is not set
  CONFIG_OF_LIBFDT=y
diff --git a/package/boot/uboot-imx6/patches/110-mx6cuboxi-mmc-fallback.patch 
b/package/boot/uboot-imx6/patches/110-mx6cuboxi-mmc-fallback.patch
index 0883eb7..ed13b92 100644
--- a/package/boot/uboot-imx6/patches/110-mx6cuboxi-mmc-fallback.patch
+++ b/package/boot/uboot-imx6/patches/110-mx6cuboxi-mmc-fallback.patch
@@ -1,7 +1,7 @@
 --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
 +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
-@@ -334,6 +334,12 @@ int board_init(void)
-   return ret;
+@@ -290,6 +290,12 @@ static void setup_iomux_enet(void)
+   udelay(100);
  }
  
 +void board_boot_order(u32 *spl_boot_list)
@@ -10,12 +10,12 @@
 +  spl_boot_list[1] = BOOT_DEVICE_MMC1;
 +}
 +
- static bool is_hummingboard(void)
+ int board_phy_config(struct phy_device *phydev)
  {
-   int val1, val2;
+   if (phydev->drv->config)
 --- a/arch/arm/mach-imx/spl.c
 +++ b/arch/arm/mach-imx/spl.c
-@@ -136,7 +136,7 @@ int g_dnl_bind_fixup(struct usb_device_d
+@@ -158,7 +158,7 @@ int g_dnl_bind_fixup(struct usb_device_d
  /* called from spl_mmc to see type of boot mode for storage (RAW or FAT) */
  u32 spl_boot_mode(const u32 boot_device)
  {
-- 
1.9.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel