Re: [LEDE-DEV] [PATCH] libjson-c: Update to 0.13

[Karl Palsson]

Alexandru Ardelean  wrote:
> On Sat, Mar 31, 2018 at 9:45 AM, Hans Dedecker
>  wrote:
> > On Sat, Mar 31, 2018 at 12:25 AM, Rosen Penev  wrote:
> >> From: Daniel Engberg 
> >>
> >> Update (lib)json-c to 0.13
> > What are the changes?
> > Is there any size increase ?
> > Please be a bit more verbose in the git commit description
> >
> 
> From me, this is a NAK.
> See https://github.com/lede-project/source/pull/1575
> 
> The size increase is reasonably big [percentage-wise +30%, even
> though the lib is small]. 0.13 adds a few new features, but
> nothing that is of interest to OpenWrt. The set of features in
> 0.12 is sufficient for now.

And fixes a pile of bugs, and improves performance :)

Please remember that this library is heavily used by packages
too, not just the ones in core. Yes, it's bigger, but hey, linux
4.14 is bigger than linux 4.9 too.

> What would be interesting in 0.13 or later, is to have disable
> flags, to keep it slim. And maybe switch to cmake, since it's
> better supported, and preferred [by various users of
> libjson-c]. Maybe once we have the disable flags, then it would
> be fine to upgrade.

cmake better supported what? Upstream's "how to build"
documentation doesn't even _mention_ cmake. The extended docs say
that cmake is there for win32.

Cheers,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] kernel version status

[Karl Palsson]

Hauke Mehrtens  wrote:
> The following targets are on kernel 4.4 and will probably not
> be included in the next release:
> * gemini

This is a platform that upstream seems to be actually working on,
would it not be at least polite to keep it alive while it's
landing in mainline? I don't have any hardware or care myself, it
just seems odd to kill the one that's being worked on.

Cheers,
Karl P


signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Karl Palsson]

Philip Prindeville <phil...@redfish-solutions.com> wrote:
> 
> 
> In a perfect world, no one should ever have to build with
> patches, anything in files/, cherry-picked commits, etc.
> Everything would be expressed in the .config (or
> kernel-config).

I think this is probably the root of all the discussion. I agree
with you that most people shouldn't want patches, but I think
it's rather silly to say that it should all be via .config.
Putting things in files/ is vastly easier and more flexible than
trying to create something for everyone in makefile and kconfig
syntax!

I'd generally rather see a lot _less_ of things created via an
ever expanding .config and _more_ local customizations applied as
local customizations :)

Cheers,
Karl Palsson



signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/2] libubox: Don't warn about sign comparisons.

[Karl Palsson]

Rosen Penev <ros...@gmail.com> wrote:
> On Fri, Feb 2, 2018 at 4:54 AM, Karl Palsson
> <ka...@tweak.net.au> wrote:
> >
> > Rosen Penev <ros...@gmail.com> wrote:
> >> -Wsign-compare was breaking my builds when i disabled MIPS16 on
> >> ramips (mt7621). Since this will probably not get fixed,
> >> disable it.
> >
> > Given the fine tuned nature of all your prior commits, why are
> > you now all of a sudden avoiding actually fixing the bad sign
> > comparisons?
> 
> It breaks my build. Previous efforts at fixing have been
> unsuccessful.

link to rejected patches that fix it? Sounds like it would be
easier to push on a "this doesn't compile" than just "let's turn
off warnings"

Cheers,
Karl Palsson

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/2] libubox: Don't warn about sign comparisons.

[Karl Palsson]

Rosen Penev  wrote:
> -Wsign-compare was breaking my builds when i disabled MIPS16 on
> ramips (mt7621). Since this will probably not get fixed,
> disable it.

Given the fine tuned nature of all your prior commits, why are
you now all of a sudden avoiding actually fixing the bad sign
comparisons? Turning them off wholesale sounds like a terrible
idea!

Cheers,
Karl P


> 
> Signed-off-by: Rosen Penev 
> ---
>  CMakeLists.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 57804cf..0449a59 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -3,7 +3,7 @@ INCLUDE(CheckLibraryExists)
>  INCLUDE(CheckFunctionExists)
>  
>  PROJECT(ubox C)
> -ADD_DEFINITIONS(-Os -Wall -Werror --std=gnu99 -g3
> -Wmissing-declarations) +ADD_DEFINITIONS(-Os -Wall -Werror
> --std=gnu99 -g3 -Wmissing-declarations -Wno-sign-compare)
>  
>  OPTION(BUILD_LUA "build Lua plugin" ON)
>  OPTION(BUILD_EXAMPLES "build examples" ON)
> -- 
> 2.7.4
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] curl: Switch all TLS libraries to use ca-bundle.

[Karl Palsson]

How will this play with people with ca-certificates installed
rather than ca-bundle?



Rosen Penev  wrote:
> At least one application (transmission) depends on
> CURL_CA_BUNDLE being set in order to operate properly (Could
> not connect to tracker errors). As far as I can tell, there's
> no real drawback to doing this for all TLS libraries supported
> by curl.
> 
> Signed-off-by: Rosen Penev 
> ---
>  package/network/utils/curl/Makefile | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/package/network/utils/curl/Makefile
> b/package/network/utils/curl/Makefile index 17fcf70..930bd10
> 100644
> --- a/package/network/utils/curl/Makefile
> +++ b/package/network/utils/curl/Makefile
> @@ -111,13 +111,15 @@ CONFIGURE_ARGS += \
>   --without-nss \
>   --without-libmetalink \
>   --without-librtmp \
> + --without-ca-path \
> + --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt \
>   \
>   $(call autoconf_bool,CONFIG_IPV6,ipv6) \
>   \
> - $(if $(CONFIG_LIBCURL_WOLFSSL),--with-cyassl="$(STAGING_DIR)/usr" 
> --without-ca-path 
> --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt,--without-cyassl) \
> - $(if $(CONFIG_LIBCURL_GNUTLS),--with-gnutls="$(STAGING_DIR)/usr" 
> --without-ca-bundle --with-ca-path=/etc/ssl/certs,--without-gnutls) \
> - $(if $(CONFIG_LIBCURL_OPENSSL),--with-ssl="$(STAGING_DIR)/usr" 
> --without-ca-bundle --with-ca-path=/etc/ssl/certs,--without-ssl) \
> - $(if $(CONFIG_LIBCURL_MBEDTLS),--with-mbedtls="$(STAGING_DIR)/usr" 
> --without-ca-path 
> --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt,--without-mbedtls) \
> + $(if 
> $(CONFIG_LIBCURL_WOLFSSL),--with-cyassl="$(STAGING_DIR)/usr",--without-cyassl)
>  \
> + $(if 
> $(CONFIG_LIBCURL_GNUTLS),--with-gnutls="$(STAGING_DIR)/usr",--without-gnutls) 
> \
> + $(if 
> $(CONFIG_LIBCURL_OPENSSL),--with-ssl="$(STAGING_DIR)/usr",--without-ssl) \
> + $(if 
> $(CONFIG_LIBCURL_MBEDTLS),--with-mbedtls="$(STAGING_DIR)/usr",--without-mbedtls)
>  \
>   \
>   $(if 
> $(CONFIG_LIBCURL_LIBIDN),--with-libidn="$(STAGING_DIR)/usr",--without-libidn) 
> \
>   $(if 
> $(CONFIG_LIBCURL_SSH2),--with-libssh2="$(STAGING_DIR)/usr",--without-libssh2) 
> \
> -- 
> 2.7.4
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1] dnsmasq: use SIGUSR2 for dnssec time valid

[Karl Palsson]

Kevin Darbyshire-Bryant  wrote:
> 
> I don’t have a magic patch for this problem. It seems to me
> that ideally busybox ntpd shouldn’t serve time until it has
> sync’d. A horrible hack idea: firewall rule to drop incoming
> ntp requests from clients… have an ntpd hotplug script that
> captures the stratum change event and removes the firewall
> rules. And/or ntpd has a new command line switch implemented
> that does the same thing ie. ignore ntp requests until sync’d.
> 
> Failing that, maybe you really can’t have DNS and time at the
> same time ;-) Now where did I put that chicken…...

The freshly released busybox 1.28 has a number of DNS related
fixes for NTP btw.

  ntpd: do run the script at least once in 11 minutes
  ntpd: improve treatment of DNS resolution failures
  ntpd: mention in help text that -d can be repeated
  ntpd: perform DNS resolution out of send/receive loop. Closes 10466
  ntpd: skip over setting next DNS resolution attempt if it is not needed


Cheers,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] base-files: rc.common: fix enable() return code and logic

[Karl Palsson]

Roman Yeryomin  wrote:
> On 2017-12-21 21:35, Roman Yeryomin wrote:
> > In current state, if there is STOP but no START, enbale()
> > will return 0 (success), which is wrong.
> > Moreover there is no need to check for START/STOP twice.
> > Instead, add err variable to save success state and
> > and return it's value.
> > Also eliminate the need to disable() by using 'ln -sf',
> > which will first delete the old symlink if one exists.
> > 
> 
> Ah, mistake in description, if there is no STOP it returns 1,
> which is wrong. Will resend with corrected description.

What do you mean? Are you saying that "enable" doesn't work if
STOP isn't defined? because that's clearly not the case...


> 
> Regards,
> Roman
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] luci: treewide: Replace strerror(errno) with %m.

[Karl Palsson]

Rosen Penev  wrote:
> Saves a few bytes. No functional difference.

Except that it now requires gnu extensions to compile. That seems
like a pretty poor tradeoff.

Sincerely,
Karl P


> 
> Signed-off-by: Rosen Penev 
> ---
>  contrib/package/freifunk-watchdog/src/watchdog.c |  6 ++---
>  contrib/package/freifunk-watchdog/src/watchdog.h |  6 ++---
>  modules/luci-mod-admin-full/src/luci-bwc.c   | 31 
> 
>  3 files changed, 19 insertions(+), 24 deletions(-)
> 
> diff --git a/contrib/package/freifunk-watchdog/src/watchdog.c
> b/contrib/package/freifunk-watchdog/src/watchdog.c index
> f546985..3e46668 100644
> --- a/contrib/package/freifunk-watchdog/src/watchdog.c
> +++ b/contrib/package/freifunk-watchdog/src/watchdog.c
> @@ -153,8 +153,7 @@ static int find_process(const char *name)
>   return pid;
>   }
>  
> - syslog(LOG_CRIT, "Unable to open /proc: %s",
> - strerror(errno));
> + syslog(LOG_CRIT, "Unable to open /proc: %m");
>  
>   return -1;
>  }
> @@ -381,8 +380,7 @@ static int do_daemon(void)
>  
>   if( (iwfd = socket(AF_INET, SOCK_DGRAM, 0)) == -1 )
>   {
> - syslog(LOG_ERR, "Can not open wireless control socket: %s",
> - strerror(errno));
> + syslog(LOG_ERR, "Can not open wireless control socket: %m");
>  
>   return 1;
>   }
> diff --git a/contrib/package/freifunk-watchdog/src/watchdog.h
> b/contrib/package/freifunk-watchdog/src/watchdog.h index
> 6f2382d..d13bbd9 100644
> --- a/contrib/package/freifunk-watchdog/src/watchdog.h
> +++ b/contrib/package/freifunk-watchdog/src/watchdog.h
> @@ -128,14 +128,12 @@ iw_ioctl(int  skfd,   /* Socket 
> to the kernel */
>   switch(fork())  
> \
>   {   
> \
>   case -1:
> \
> - syslog(LOG_CRIT, "Unable to fork child: %s",
> \
> - strerror(errno));   
> \
> + syslog(LOG_CRIT, "Unable to fork child: %m");   
> \
>   break;  
> \
>   
> \
>   case 0: 
> \
>   execl(x, NULL); 
> \
> - syslog(LOG_CRIT, "Unable to execute action: 
> %s",\
> - strerror(errno));   
> \
> + syslog(LOG_CRIT, "Unable to execute action: 
> %m");   \
>   return 1;   
> \
>   }   
> \
>   } while(0)
> diff --git a/modules/luci-mod-admin-full/src/luci-bwc.c
> b/modules/luci-mod-admin-full/src/luci-bwc.c index
> 8ddd917..2d1cc6d 100644
> --- a/modules/luci-mod-admin-full/src/luci-bwc.c
> +++ b/modules/luci-mod-admin-full/src/luci-bwc.c
> @@ -309,8 +309,8 @@ static int update_ifstat(
>   {
>   if (init_file(path, sizeof(struct traffic_entry)))
>   {
> - fprintf(stderr, "Failed to init %s: %s\n",
> - path, strerror(errno));
> + fprintf(stderr, "Failed to init %s: %m\n",
> + path);
>  
>   return -1;
>   }
> @@ -339,8 +339,8 @@ static int update_radiostat(
>   {
>   if (init_file(path, sizeof(struct radio_entry)))
>   {
> - fprintf(stderr, "Failed to init %s: %s\n",
> - path, strerror(errno));
> + fprintf(stderr, "Failed to init %s: %m\n",
> + path);
>  
>   return -1;
>   }
> @@ -367,8 +367,8 @@ static int update_cnstat(uint32_t udp, uint32_t tcp, 
> uint32_t other)
>   {
>   if (init_file(path, sizeof(struct conn_entry)))
>   {
> - fprintf(stderr, "Failed 

Re: [LEDE-DEV] Lua script as a ubus service using rpcd

[Karl Palsson]

Carlito Nueno  wrote:
> Hi all,
> 
> I am trying to make a ubus service in lua.
> 
> I placed a lua script (myluaservice) in /usr/libexec/rpcd but I
> didn't see it in ubus -v list.
> 
> So I placed a shell script (myshellservice) in
> /usr/libexec/rpcd and moved the lua script (myluaservice) to
> /usr/bin/ and made both scripts executables.
> 
> Now I can see the shell script in ubus -v list but lua script
> is not called.
> 
> Both scripts:
> https://gist.github.com/ironpillow/4e116a7aa897bf05b3bb39c38f9b23b4.
> 


How is rpcd meant to know that it needs to require your lua
module and call specific named functions?

You need to have the same arguments and invocation method as your
shell script, then it will work just fine.

Cheers,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/7] ag71xx: Reorder some more structs based on warmth.

[Karl Palsson]

Rosen Penev <ros...@gmail.com> wrote:
> Should help slightly.

That's not really very encouraging. Surely you have a test setup
if you're actually looking at making performance related changes?
You should have actual numbers on changes, otherwise this is just
poking in chicken entrails.

Sincerely,
Karl Palsson


> 
> Signed-off-by: Rosen Penev <ros...@gmail.com>
> ---
>  .../ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h  | 10 
> +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git
> a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
> b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
> index 5ead6b3..f9ef17d 100644
> --- a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
> +++ b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
> @@ -106,13 +106,16 @@ struct ag71xx_buf {
>  };
>  
>  struct ag71xx_ring {
> + /* "Hot" fields in the data path. */
> + unsigned intcurr;
> + unsigned intdirty;
> +
> + /* "Cold" fields - not used in the data path. */
>   struct ag71xx_buf   *buf;
>   u8  *descs_cpu;
>   dma_addr_t  descs_dma;
>   u16 desc_split;
>   u16 order;
> - unsigned intcurr;
> - unsigned intdirty;
>  };
>  
>  struct ag71xx_mdio {
> @@ -166,14 +169,15 @@ struct ag71xx {
>  
>   struct net_device   *dev;
>   struct platform_device  *pdev;
> + /* Serialises access to regs */
>   spinlock_t  lock;
>   struct napi_struct  napi;
> - u32 msg_enable;
>  
>   /*
>* From this point onwards we're not looking at per-packet fields.
>*/
>   void __iomem*mac_base;
> + u32 msg_enable;
>  
>   struct ag71xx_desc  *stop_desc;
>   dma_addr_t  stop_desc_dma;
> -- 
> 2.7.4
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 4/4] toolchain: musl: update to current HEAD

[Karl Palsson]

Christian Lamparter  wrote:
> Hello,
> 
> On Monday, November 20, 2017 8:17:05 AM CET Syrone Wong wrote:
> > Hi,
> > 
> > Any specific reason to introduce these changes?
> Actually yes. The LEDE Website prides itself with
> "LEDE is actively updated [...]"
> 

Actively updated is one, "we're going to be standing on the
bleeding edge at all times, you're gonna get cut" is another.
Musl is also making releases quite regularly, it's not even 20
days since 17, and only 30 since 16. Surely musl would be
considering a release too for these issues?

Cheers,
Karl P

> 
> a71b46cf fix malloc state corruption when ldso rejects loading
> a second libc The Thread on the MUSL ML is "[musl] diffutils
> crash in malloc". Judging from the descussion, it can cause
> programs to misbehave starting with 1.1.17 and 1.1.18.
> 
> And there's more:
> 72656157 fix fgetwc when decoding a character that crosses
> buffer boundary c21051e9 prevent fork's errno from being
> clobbered by atfork handlers
> ...
> 
> + some UAPI updates, which will be nice to have for 4.14 development.
> 
> And Also, Rich made big changes to iconv and it broke the
> 900-iconv_size_hack.patch.
> 
> Regards,
> Christian
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Fwd: [FSFE PR][EN] FSFE makes copyrights computer readable

[Karl Palsson]

David Lang  wrote:
> that's mostly a question to direct at the upstream software
> sources. only a small portion of things are written by the LEDE
> team
> 
> SPDX is mostly useful for people wanting to fork or extract
> code from opensource projects, not for the project writing the
> code

Well, packages are already using SPDX license tags, but something
that autogenerated say, a luci page with "here's all the software
in use on this build" or even just a manifest from buildroot of
all the packages and all their licenses would be nice.

It's also for people _using_ projects that are trying to be
compliant, not just forking or extracting, I think that's a
little bit negative.

Cheers,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] umdns: Replace unnecessary memset calls with {}.

[Karl Palsson]

Rosen Penev <ros...@gmail.com> wrote:
> Less verbose.
> 
> Signed-off-by: Rosen Penev <ros...@gmail.com>
> 
> v2: some of those memset calls are needed. Also replace { 0 }
> with {}.

cmon, that's just unnecessary. It's one thing to prefer using gnu
{} instead of ISO C {0} but replacing ISO standard C form with a
gnu form, just because? What on earth for?

Sincerely,
Karl Palsson

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] busybox ntpd not syncing if any server is bad (update, if _first_ server is bad)

[Karl Palsson]

Final note here, busybox has fixed this upstream, and ntpd now
syncs faster and _vastly_ more reliably with bad servers in the
list. Depending on their release schedule some people may like
the patches backported, but I'm just carrying them myself for the
time being.

Cheers,
Karl P


Karl Palsson <ka...@tweak.net.au> wrote:
> 
> For a followup, on master, with busybox 1.27.2, busybox ntpd
> will sync with bad servers in the list, but only if they're not
> _first_ Further, "bad.example.org" won't count as "bad" for the
> purpose of these tests. Someone (presumably dnsmasq?) is
> responding instantly with failures there.
> 
> Try something like 
> /usr/sbin/ntpd -n -N -d -l -S /usr/sbin/ntpd-hotplug -p bad1.n
> otexample.notorg -p bad2.notexample.notorg -p
> good.working.server.here.com
> 
> It appears that the dns resolution times out, and is ordered in
> such a way that busybox sends a request, and even though it
> gets a reply "instantly" it doesn't actually process it for
> several seconds. At that point, it .. fails? to process
> properly, and so just continues sending requests, getting
> replies, and never stepping or setting the stratum. (And hence,
> my tests with ntpdate -q never succeeded)
> 
> I've filed https://bugs.busybox.net/show_bug.cgi?id=10466 with
> busybox for this. It's actually only a bother for me in my
> development environment, where the *.pool.ntp.org addresses
> aren't resolveable
> 
> Sincerely,
> Karl Palsson

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] busybox ntpd not syncing if any server is bad (update, if _first_ server is bad)

[Karl Palsson]

Magnus Kroken <mkro...@gmail.com> wrote:
> On 21.08.2017 16:34, Karl Palsson wrote:
> > on master, even with the ntpd patch for busybox applied.
> > # ntpdate -q localhost
> > server ::1, stratum 0, offset 0.00, delay 0.0
> > server 127.0.0.1, stratum 0, offset 0.00, delay 0.0 21
> > Aug 14:26:24 ntpdate[1392]: no server suitable for
> > synchronization found
> > # echo $?
> > 1
> > # ntpd -w -d -p localhost
> > ntpd: sending query to 127.0.0.1
> > ntpd: reply from 127.0.0.1: peer is unsynced
> > ntpd: sending query to 127.0.0.1
> 
> Thanks for the clarification. Running ntpd like before (-p
> bad.example.org -p ntp.uio.no), LEDE master with Busybox 1.27.2
> does seem to work:
> 
> root@LEDE:~# ntpdate -q ::1
> server ::1, stratum 3, offset 0.28, delay 0.02777
> 23 Aug 19:12:55 ntpdate[5416]: adjust time server ::1 offset
> 0.28 sec root@LEDE:~# echo $? 0
> 
> I also tested against my OpenWrt 15.05 VM and the current LEDE
> x86_64 snapshot (r4723), and they both give the expected output
> as you describe (OpenWrt similar to above, LEDE fails).
> 
> Note that my patch in Patchwork only updates to Busybox 1.27.1,
> I will send the 1.27.2 patch shortly, after rebasing and
> testing it.
> 

For a followup, on master, with busybox 1.27.2, busybox ntpd will
sync with bad servers in the list, but only if they're not
_first_ Further, "bad.example.org" won't count as "bad" for the
purpose of these tests. Someone (presumably dnsmasq?) is
responding instantly with failures there.

Try something like 
/usr/sbin/ntpd -n -N -d -l -S /usr/sbin/ntpd-hotplug -p bad1.n
otexample.notorg -p bad2.notexample.notorg -p
good.working.server.here.com

It appears that the dns resolution times out, and is ordered in
such a way that busybox sends a request, and even though it gets
a reply "instantly" it doesn't actually process it for several
seconds. At that point, it .. fails? to process properly, and so
just continues sending requests, getting replies, and never
stepping or setting the stratum. (And hence, my tests with
ntpdate -q never succeeded)

I've filed https://bugs.busybox.net/show_bug.cgi?id=10466 with
busybox for this. It's actually only a bother for me in my
development environment, where the *.pool.ntp.org addresses
aren't resolveable

Sincerely,
Karl Palsson

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] merge: add OpenWrt branding

[Karl Palsson]

Hannu Nyman  wrote:
> Zoltan HERPAI kirjoitti 26.10.2017 klo 18:41:
> > + -
> > +  * 2 oz. Orange Juice Combine all juices in a
> > +  * 2 oz. Pineapple Juice  tall glass filled with
> > +  * 2 oz. Grapefruit Juice ice, stir well.
> > +  * 2 oz. Cranberry Juice
> > + -
> 
> 
> Still promoting the drink recipe although the voting is clearly
> going against release names and also all given feedback about
> drinks has been negative?

Not all.  I quite like the drinks, I was just strongly against going back to 
the old name. right now.  

When DD was chosen it was far from 100% one way or the other too.

Cheers,
Karl P



signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] download.mk: introduce a new variable SKIPHASH

[Karl Palsson]

Baptiste Jonglez  wrote:
> When calling a download target, hash verification is now
> completely skipped if the SKIPHASH variable is set.
> 
> This allows to easily bump package version:
> 
> # Update PKG_VERSION in the package Makefile
> $ make package//download SKIPHASH=1 V=s
> $ make package//check FIXUP=1 V=s
> 
> This will download the new version of the package, and then
> automatically update PKG_HASH with the hash of the new version.
> Of course, it is still the responsibility of the packager to
> ensure that the new tarball is legitimate, because it is
> downloaded from a possibly untrusted source.
> 
> Fixes: b30ba14e ("scripts/download.pl: fail loudly if provided
> hash is unsupported") Signed-off-by: Baptiste Jonglez
> 


Until/if your new documentation project takes off, please
consider adding this to the "how to package" doc pages. none of
these extra magical parameters are discoverable in any way right
now.

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] merge: add OpenWrt branding

[Karl Palsson]

Zoltan HERPAI  wrote:
> Given that we've decided to sail under the same flag for the
> benefit of the whole community, and acknowledge the
> achievements of the LEDE project, let's start the final steps
> of the merge.
> 
> The git and other sources are untouched until the infra merge.
> 


I'd like to leave Designated Driver as the period of time for
OpenWrt's trunk branch before LEDE, and have "something
different" for the new path going forward. The YY.MM naming is
boring, but functional. Alphabetical names are fine too, but I
don't think it should go back to the old name.

Sincerely,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] procd: Restore respawn on SIGTERM timeout

[Karl Palsson]

Kristian Evensen  wrote:
> When SIGTERM times out, procd sends SIGKILL and then restarts
> the process once SIGCHLD has been received. This all works
> fine, with one exception - respawn is not restored when
> instance_start() is called from instance_exit(). The reason is
> that respawn is always set to false in instance_stop(), and the
> same service_instance struct is used for the
> instance_start()-call.
> 
> The consequence is that if the process is killed/crashes again,
> it will not respawn. Solve this issue by adding a variable used
> to store the original value of respawn in instance_stop(), and
> then restore the original respawn-value in instance_exit().

It smells like this likely applies to many other fields. Is there
a path here that's not using the copy/compare routines for a
service/instance? Should they be? Does your path even restore all
the parameters of respawn?

Cheers,
Karl P


> 
> Signed-off-by: Kristian Evensen 
> ---
>  service/instance.c | 6 --
>  service/instance.h | 1 +
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/service/instance.c b/service/instance.c
> index b7cb523..76c74ed 100644
> --- a/service/instance.c
> +++ b/service/instance.c
> @@ -532,9 +532,10 @@ instance_exit(struct uloop_process *p, int ret)
>  
>   if (in->halt) {
>   instance_removepid(in);
> - if (in->restart)
> + if (in->restart) {
> + in->respawn = in->respawn_org;
>   instance_start(in);
> - else {
> + } else {
>   struct service *s = in->srv;
>  
>   avl_delete(>instances.avl, >node.avl);
> @@ -567,6 +568,7 @@ instance_stop(struct service_instance *in, bool halt)
>   if (!in->proc.pending)
>   return;
>   in->halt = halt;
> + in->respawn_org = in->respawn;
>   in->restart = in->respawn = false;
>   kill(in->proc.pid, SIGTERM);
>   uloop_timeout_set(>timeout, in->term_timeout * 1000);
> diff --git a/service/instance.h b/service/instance.h
> index bdd14de..a0ac302 100644
> --- a/service/instance.h
> +++ b/service/instance.h
> @@ -48,6 +48,7 @@ struct service_instance {
>   bool halt;
>   bool restart;
>   bool respawn;
> + bool respawn_org;
>   int respawn_count;
>   int reload_signal;
>   struct timespec start;
> -- 
> 2.11.0
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] instance: properly compare and reload respawn config

[Karl Palsson]

respawn configuration variables were not checked for changes, and were
not copied to new instances.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---
 service/instance.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/service/instance.c b/service/instance.c
index a968a0b..d12c580 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -629,6 +629,13 @@ instance_config_changed(struct service_instance *in, 
struct service_instance *in
if (!in->pidfile && in_new->pidfile)
return true;
 
+   if (in->respawn_retry != in_new->respawn_retry)
+   return true;
+   if (in->respawn_threshold != in_new->respawn_threshold)
+   return true;
+   if (in->respawn_timeout != in_new->respawn_timeout)
+   return true;
+
if (!blobmsg_list_equal(>limits, _new->limits))
return true;
 
@@ -949,6 +956,9 @@ instance_config_move(struct service_instance *in, struct 
service_instance *in_sr
in->trigger = in_src->trigger;
in->command = in_src->command;
in->pidfile = in_src->pidfile;
+   in->respawn_retry = in_src->respawn_retry;
+   in->respawn_threshold = in_src->respawn_threshold;
+   in->respawn_timeout = in_src->respawn_timeout;
in->name = in_src->name;
in->node.avl.key = in_src->node.avl.key;
 
-- 
2.4.11


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/2] target/toolchain: Switch to xz compression instead of bz2

[Karl Palsson]

Koen Vandeputte  wrote:
> 
> On 2017-09-05 19:29, L. D. Pinney wrote:
> > i7 4770K <--- Yes we all have these plus 64 GB of RAM don't we ?
> This is not relevant as the benchmark was provided to show
> relative differences .. (percentage)
> 
> 
> I really understand your concern and I don't mind if the
> patches get rejected (really :) )
> 
> But in this case, please be straightforward and:
> - Ask for rejecting of this one: [1]
> - Submit a new patch requesting to revert this patch too :)  [2]

Sure, but [1] (turn on multithreading for xz) hasn't been
accepted, and effectively appears to be dead. _if_ that goes in,
I absolutely agree that the toolchain should be the same as the
SDK. If it _doesn't_ go in, I'd say really that the SDK should be
put back to bz2 to be consistent with the toolchain :)

> 
> 
> Why is xz valid for SDK but not for toolchain? (see commit msg
> from [2] for size differences)
> 
> [1] https://patchwork.ozlabs.org/patch/802620/
> [2] 
> https://git.lede-project.org/?p=source.git;a=commit;h=9f61ccd9e34fab1a1b90b846c1144e885401e70a
> 
> 
> > I've done some benchmarks on a machine here (i7 4770K):
> >
> >
> > tar bz2:0m19.271s(now)
> > tar cfJ:  1m3.384s
> > xz:1m19.958s(patch)
> > xz - T 0:0m38.587s(Future with -T 0 ?)
> >
> >
> > [1] http://patchwork.ozlabs.org/patch/802620/
> >
> >
> > Koen
> >
> > ___
> > Lede-dev mailing list
> > Lede-dev@lists.infradead.org 
> > http://lists.infradead.org/mailman/listinfo/lede-dev
> 

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/2] target/toolchain: Switch to xz compression instead of bz2

[Karl Palsson]

This is going to make builds _much_ slower :( 


Koen Vandeputte  wrote:
> Switch to xz compression instead of bz2
> This reduces the output size here from 41M to 29M
> 
> Signed-off-by: Koen Vandeputte 
> ---
>  target/toolchain/Makefile | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/target/toolchain/Makefile
> b/target/toolchain/Makefile index ef2dc68..da1a6d2 100644
> --- a/target/toolchain/Makefile
> +++ b/target/toolchain/Makefile
> @@ -26,7 +26,7 @@ all: compile
>  
>  
> TOOLCHAIN_PREFIX:=$(TOOLCHAIN_BUILD_DIR)/toolchain-$(ARCH)$(ARCH_SUFFIX)_gcc-$(GCCV)$(DIR_SUFFIX)
>  
> -$(BIN_DIR)/$(TOOLCHAIN_NAME).tar.bz2: clean
> +$(BIN_DIR)/$(TOOLCHAIN_NAME).tar.xz: clean
>   mkdir -p $(TOOLCHAIN_BUILD_DIR)
>   $(TAR) -cf - -C $(TOPDIR)/staging_dir/  \
>  $(foreach exclude,$(EXCLUDE_DIRS),--exclude="$(exclude)") \
> @@ -59,13 +59,13 @@ $(BIN_DIR)/$(TOOLCHAIN_NAME).tar.bz2: clean
>   find $(TOOLCHAIN_BUILD_DIR) -name CVS | $(XARGS) rm -rf
>   mkdir -p $(BIN_DIR)
>   (cd $(BUILD_DIR); \
> - tar cfj $@ $(TOOLCHAIN_NAME); \
> + tar cfJ $@ $(TOOLCHAIN_NAME); \
>   )
>  
>  download:
>  prepare:
> -compile: $(BIN_DIR)/$(TOOLCHAIN_NAME).tar.bz2
> +compile: $(BIN_DIR)/$(TOOLCHAIN_NAME).tar.xz
>  install: compile
>  
>  clean:
> - rm -rf $(TOOLCHAIN_BUILD_DIR) $(BIN_DIR)/$(TOOLCHAIN_NAME).tar.bz2
> + rm -rf $(TOOLCHAIN_BUILD_DIR) $(BIN_DIR)/$(TOOLCHAIN_NAME).tar.xz
> -- 
> 2.7.4
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] RFC [PATCH] odhcpd: don't enable server mode on dhcp lan

[Karl Palsson]

Instead of blindly enabling the odhcpd v6 server and RA server on the
lan port, only do that if the lan port isn't set to DHCP.

This prevents the unhelpful case of a device being a dhcpv4 client and
v6 server on the same ethernet port.

Signed-off-by: Karl Palsson <ka...@etactica.com>
-- 

Should other protocols be excluded?  The list on 
https://lede-project.org/docs/user-guide/network_configuration
is rather long.  Are there other modes worth considering?

---
 package/network/services/odhcpd/files/odhcpd.defaults | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/package/network/services/odhcpd/files/odhcpd.defaults 
b/package/network/services/odhcpd/files/odhcpd.defaults
index e184da90acbb..152e63dd18b6 100644
--- a/package/network/services/odhcpd/files/odhcpd.defaults
+++ b/package/network/services/odhcpd/files/odhcpd.defaults
@@ -2,13 +2,23 @@
 uci -q get dhcp.odhcpd && exit 0
 touch /etc/config/dhcp
 
+LANPROTO=$(uci -q get network.lan.proto)
+MODE=server
+
+case "$LANPROTO" in
+"dhcp")
+   echo "odhcpd: Not enabling server mode on a dhcp lan!" > /dev/kmsg
+   MODE=disabled
+   ;;
+esac
+
 uci batch <http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] procd: mdns: Support txt values with spaces

[Karl Palsson]

Properly quote the arguments so that you can register a service with TXT
entries that contains spaces.

Example:
   procd_add_mdns myservice tcp  "key=descriptive text field 1" \
 "another=something equally verbose"

Output before:
$ avahi-browse -r -v _myservice._tcp
_myservice._tcp  local
   hostname = [blah.local]
   address = [192.168.255.74]
   port = []
   txt = ["verbose" "equally" "another=something" "1" "field" "text" 
"key=descriptive"]

Output now:
$ avahi-browse -r -v _myservice._tcp
_myservice._tcp  local
   hostname = [blah.local]
   address = [192.168.255.74]
   port = []
   txt = ["another=something equally verbose" "key=descriptive text field 1"]

Signed-off-by: Karl Palsson <ka...@etactica.com>
---
 package/system/procd/files/procd.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/system/procd/files/procd.sh 
b/package/system/procd/files/procd.sh
index 00d754d16ff0..c23c37b83f00 100644
--- a/package/system/procd/files/procd.sh
+++ b/package/system/procd/files/procd.sh
@@ -423,7 +423,7 @@ procd_add_mdns_service() {
json_add_int port "$port"
[ -n "$1" ] && {
json_add_array txt
-   for txt in $@; do json_add_string "" $txt; done
+   for txt in "$@"; do json_add_string "" "$txt"; done
json_select ..
}
json_select ..
@@ -432,7 +432,7 @@ procd_add_mdns_service() {
 procd_add_mdns() {
procd_open_data
json_add_object "mdns"
-   procd_add_mdns_service $@
+   procd_add_mdns_service "$@"
json_close_object
procd_close_data
 }
-- 
2.4.11


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] busybox ntpd not syncing if any server is bad

[Karl Palsson]

Magnus Kroken <mkro...@gmail.com> wrote:
> Hi Karl
> 
> On 17.08.2017 15:13, Karl Palsson wrote:
> > It certainly _looks_ better, but isn't actually syncing...
> > 
> > Sincerely,
> > Karl Palsson
> > 
> > 
> > # /usr/sbin/ntpd -d -n -N -l -S /usr/sbin/ntpd-hotplug -p 
> > 0.lede.pool.ntp.org  -p working.good.org
> > ntpd: bad address '0.lede.pool.ntp.org'
> > ntpd: sending query to 192.168.255.124
> > ntpd: bad address '0.lede.pool.ntp.org'
> > ntpd: reply from 192.168.255.124: offset:-2.453565 delay:5.006456
> > status:0x24 strat:3 refid:0xc1043a2c rootdelay:0.001495
> > reach:0x01
> [...]
> 
> Could you elaborate on what to look for to verify a well
> behaved ntpd? How do you tell if it's synced? I can't tell what
> is different about the above log (which you state never
> actually syncs) and your "good" log from OpenWrt 15.05
> mentioned in your first message about the issue.

I use ntpdate or similar to ask it...

on master, even with the ntpd patch for busybox applied.
# ntpdate -q localhost
server ::1, stratum 0, offset 0.00, delay 0.0
server 127.0.0.1, stratum 0, offset 0.00, delay 0.0 21
Aug 14:26:24 ntpdate[1392]: no server suitable for
synchronization found
# echo $?
1
# ntpd -w -d -p localhost
ntpd: sending query to 127.0.0.1
ntpd: reply from 127.0.0.1: peer is unsynced
ntpd: sending query to 127.0.0.1

On OpenWrt 15.05 you would get this sort of output.

# ntpdate -q localhost
server 127.0.0.1, stratum 3, offset 0.42, delay 0.02815 21
Aug 14:31:15 ntpdate[12902]: adjust time server 127.0.0.1 offset
0.42 sec root@eg-03B77B:~# echo $? 0
# ntpd -w -d -p localhost
ntpd: resolved peer localhost to 127.0.0.1
ntpd: sending query to 127.0.0.1
ntpd: reply from 127.0.0.1: offset:+0.80 delay:0.002000
status:0x24 strat:3 refid:0xec76ef1f rootdelay:0.002258
reach:0x01 ntpd: sending query to 127.0.0.1 ntpd: reply from
127.0.0.1: offset:-0.000258 delay:0.002000 status:0x24 strat:3
refid:0xec76ef1f rootdelay:0.002258 reach:0x03 ntpd: sending
query to 127.0.0.1 ntpd: reply from 127.0.0.1: offset:-0.000146
delay:0.002000 status:0x24 strat:3 refid:0xec76ef1f
rootdelay:0.002258 reach:0x07 ^C


> 
> To test this I'm running OpenWrt 15.05.1 in a VM, and LEDE
> master with Busybox 1.27.2 on my router, see logs below. To my
> untrained eye they appear to behave the same as your supposedly
> bad ntpd with backported patch.

I'll try and build again with your 1.27 bump. I've currently only
been trying with the ntpd patch backported only:
https://git.busybox.net/busybox/commit/networking/ntpd.c?h=1_27_stable=b62ea34afed7d3bf60a6c8ef5a030fea52f55b10
Maybe there's something else needed.

Sincerely,
Karl Palsson


> 
> Regards
> /Magnus
> 
> * LEDE master
> /usr/sbin/ntpd -d -n -N -l -S /usr/sbin/ntpd-hotplug -p
> bad.example.org -p ntp.uio.no ntpd: bad address
> 'bad.example.org' ntpd: 'ntp.uio.no' is 129.240.2.6 ntpd:
> sending query to 129.240.2.6 ntpd: reply from 129.240.2.6:
> offset:+0.004915 delay:0.012800 status:0x24 strat:2
> refid:0xc23aca94 rootdelay:0.006836 reach:0x01 ntpd: sending
> query to 129.240.2.6 ntpd: reply from 129.240.2.6:
> offset:+0.004270 delay:0.011344 status:0x24 strat:2
> refid:0xc23aca94 rootdelay:0.006836 reach:0x03 ntpd: sending
> query to 129.240.2.6 ntpd: reply from 129.240.2.6:
> offset:+0.004963 delay:0.012624 status:0x24 strat:2
> refid:0xc23aca94 rootdelay:0.006836 reach:0x07 ntpd: executing
> '/usr/sbin/ntpd-hotplug stratum' ntpd: sending query to
> 129.240.2.6 ntpd: reply from 129.240.2.6: offset:+0.005244
> delay:0.013224 status:0x24 strat:2 refid:0xc23aca94
> rootdelay:0.006836 reach:0x0f ntpd: sending query to
> 129.240.2.6 ntpd: bad address 'bad.example.org' ntpd: reply
> from 129.240.2.6: offset:+0.004792 delay:0.012428 status:0x24
> strat:2 refid:0xc23aca94 rootdelay:0.006836 reach:0x1f ntpd:
> sending query to 129.240.2.6 ntpd: reply from 129.240.2.6:
> offset:+0.004734 delay:0.012564 status:0x24 strat:2
> refid:0xc23aca94 rootdelay:0.006836 reach:0x3f ntpd: sending
> query to 129.240.2.6 ntpd: reply from 129.240.2.6:
> offset:+0.004723 delay:0.012973 status:0x24 strat:2
> refid:0xc23aca94 rootdelay:0.006836 reach:0x7f ntpd: bad
> address 'bad.example.org' ntpd: sending query to 129.240.2.6
> ntpd: reply from 129.240.2.6: offset:+0.004097 delay:0.011920
> status:0x24 strat:2 refid:0xc23aca94 rootdelay:0.006836
> reach:0xff ntpd: bad address 'bad.example.org' ntpd: bad
> address 'bad.example.org' ntpd: bad address 'bad.example.org'
> 
> 
> * OpenWrt 15.05.1
> /usr/sbin/ntpd -d -n -N -l -S /usr/sbin/ntpd-hotplug -p
> bad.example.org -p ntp.uio.no ntpd: resolved peer ntp.uio.no to
> 129.240.2.6 ntpd: sending query to 129.240.2.6 ntpd: bad
> address 'bad.example.org' ntpd: coul

Re: [LEDE-DEV] About /etc/board.json

[Karl Palsson]

Jo-Philipp Wich <j...@mein.io> wrote:
> 
> > - There is already a JSON parsing/generation Lua library of choice
> > in LEDE? (I suppose there is at least in Luci)
> 
> Package "luci-lib-jsonc" - despite its name it is mostly
> standalone, only depending on liblua and libjson-c.
> 
> API docs at
> http://htmlpreview.github.io/?http://raw.githubusercontent.com/openwrt/luci/master/documentation/api/modules/luci.jsonc.html
> 

Given that it is completely standalone, would you mind if I spent
some time making a luarocks module for it? It would make it
easier to use this on host systems, so we can use "one" lua json
library everywhere. I've been using dkjson/lua-cjson in the past,
but with json-c (the library) already installed, and
luci-lib-json-c already installed, and with C apps also using
json-c, it would be nice to drop the extra dependencies, but
installing luci on development hosts is a pain.

Alternatively of course, simply splitting this completely out of
luci altogether, as it has nothing in common with it apart from
the namespace and the source repository. Simply adding a luarocks
file is probably less intrusive though :)

Cheers,
Karl Palsson


signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/3] base-files: allocate uid/gid starting from 65536

[Karl Palsson]

Do you mean to have it count down now as well, instead of up from
100?

Yousong Zhou  wrote:
> There already exist static assignment of uid/gid 65533 in
> packages feed and we have nobody/nogroup taking 65534 as their
> ids. Let's change the pid of dynamic assignment to start from
> 65536 so that the two assignment scheme will not collide with
> each other
> 
> While at, fix the scan command checking existence of uid/gid
> 
> Signed-off-by: Yousong Zhou 
> ---
>  package/base-files/Makefile   | 2 +-
>  package/base-files/files/lib/functions.sh | 8 
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/package/base-files/Makefile
> b/package/base-files/Makefile index 54c157611f..2cea494c3f
> 100644
> --- a/package/base-files/Makefile
> +++ b/package/base-files/Makefile
> @@ -11,7 +11,7 @@ include $(INCLUDE_DIR)/kernel.mk
>  include $(INCLUDE_DIR)/version.mk
>  
>  PKG_NAME:=base-files
> -PKG_RELEASE:=174
> +PKG_RELEASE:=175
>  PKG_FLAGS:=nonshared
>  
>  PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
> diff --git a/package/base-files/files/lib/functions.sh
> b/package/base-files/files/lib/functions.sh index
> ae7f4dc9ee..dd69a4f1f3 100755
> --- a/package/base-files/files/lib/functions.sh
> +++ b/package/base-files/files/lib/functions.sh
> @@ -306,8 +306,8 @@ group_add_next() {
>   gid=$(grep -s "^${1}:" ${IPKG_INSTROOT}/etc/group | cut -d: -f3)
>   [ -n "$gid" ] && return $gid
>   gids=$(cat ${IPKG_INSTROOT}/etc/group | cut -d: -f3)
> - gid=100
> - while [ -n "$(echo $gids | grep $gid)" ] ; do
> + gid=65536
> + while [ -n "$(echo "$gids" | grep "^$gid$")" ] ; do
>   gid=$((gid + 1))
>   done
>   group_add $1 $gid
> @@ -334,8 +334,8 @@ user_add() {
>   local rc
>   [ -z "$uid" ] && {
>   uids=$(cat ${IPKG_INSTROOT}/etc/passwd | cut -d: -f3)
> - uid=100
> - while [ -n "$(echo $uids | grep $uid)" ] ; do
> + uid=65536
> + while [ -n "$(echo "$uids" | grep "^$uid$")" ] ; do
>   uid=$((uid + 1))
>   done
>   }
> -- 
> 2.12.2
> 

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] github oauth for webpage editing requests too many permission

[Karl Palsson]

Hi,

I was trying to fix something on the documentation pages of
lede-project today, and tried to login with github.

However, the docuwiki/oauth thing is demanding full read/write
access to my account, which seems excessive...

```
LEDE Project (lede-project.org) by lede-project
wants to access your karlp account
Personal user data
Full access
This application will be able to read and write all user data.
This includes the following:

Private email addresses
Private profile information
Followers
Learn more
```

Can someone perhaps reconfigure that to request only what's
necessary to do an oauth login for editing, not granting access
to the account?

Sincerely,
Karl P

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Fwd: Re: convention on uid/gid for packages

[Karl Palsson]

Yousong Zhou <yszhou4t...@gmail.com> wrote:
> On 19 May 2017 at 18:44, Karl Palsson <ka...@tweak.net.au>
> wrote:
> > Resending to the list properly as planned...
> >
> >
> > I've modified one of my packages (mosquitto) to use the
> > autoassignment style, as it never cared about the actual uid/gid.
> >
> > However, is this really the expected behaviour?
> >
> > # cat /etc/passwd
> > root:x:0:0:root:/root:/bin/ash
> > daemon:*:1:1:daemon:/var:/bin/false
> > ftp:*:55:55:ftp:/home/ftp:/bin/false
> > network:*:101:101:network:/var:/bin/false
> > nobody:*:65534:65534:nobody:/var:/bin/false
> > avahi:x:105:105:avahi:/var/run/avahi:/bin/false
> > dnsmasq:x:453:453:dnsmasq:/var/run/dnsmasq:/bin/false
> > mosquitto:x:100:102:mosquitto:/var/run/mosquitto:/bin/false <<<
> > 100:102??
> >
> >
> > I know I don't care, but getting 100 for uid and 102 for gid
> > seems somewhat unexpected? Is it issuing ids from the same
> > sequence or something?
> >
> 
> no, this is not how group_add_next works. please check the
> content of /etc/group and see if there might already exist a
> group of name "network" with id 101.
> 

Correct, "network" was a group too.  But they why did it pick userid 100 for my 
service?  

Anyway, as I don't _really_ need them to have the same numbers
for uid/gid, it's just traditional, is it now ok to go and make
my package use the autoassignment? Or is this something that
should get tidied up further in the autoassignment code?

Sincerely,
Karl Palsson

# cat /etc/passwd 
root:x:0:0:root:/root:/bin/ash
daemon:*:1:1:daemon:/var:/bin/false
ftp:*:55:55:ftp:/home/ftp:/bin/false
network:*:101:101:network:/var:/bin/false
nobody:*:65534:65534:nobody:/var:/bin/false
avahi:x:105:105:avahi:/var/run/avahi:/bin/false
dnsmasq:x:453:453:dnsmasq:/var/run/dnsmasq:/bin/false
mosquitto:x:100:102:mosquitto:/var/run/mosquitto:/bin/false

# cat /etc/group 
root:x:0:
daemon:x:1:
adm:x:4:
mail:x:8:
audio:x:29:
www-data:x:33:
ftp:x:55:
users:x:100:
network:x:101:
nogroup:x:65534:
avahi:x:105:avahi
dnsmasq:x:453:dnsmasq
mosquitto:x:102:mosquitto
root@eg-037BCC:/#


signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Fwd: Re: convention on uid/gid for packages

[Karl Palsson]

Resending to the list properly as planned...


I've modified one of my packages (mosquitto) to use the
autoassignment style, as it never cared about the actual uid/gid.

However, is this really the expected behaviour?

# cat /etc/passwd 
root:x:0:0:root:/root:/bin/ash
daemon:*:1:1:daemon:/var:/bin/false
ftp:*:55:55:ftp:/home/ftp:/bin/false
network:*:101:101:network:/var:/bin/false
nobody:*:65534:65534:nobody:/var:/bin/false
avahi:x:105:105:avahi:/var/run/avahi:/bin/false
dnsmasq:x:453:453:dnsmasq:/var/run/dnsmasq:/bin/false
mosquitto:x:100:102:mosquitto:/var/run/mosquitto:/bin/false <<<
100:102??


I know I don't care, but getting 100 for uid and 102 for gid
seems somewhat unexpected? Is it issuing ids from the same
sequence or something?

Sincerely,
Karl Palsson


Yousong Zhou <yszhou4t...@gmail.com> wrote:
> On 16 May 2017 at 00:02, Val Kulkov <val.kul...@gmail.com>
> wrote:
> > I agree that not depending on the manual cooperation across groups of
> > people would be ideal. However, updating 35+ packages to use the
> > auto-allocation mechanism is not an easy undertaking.
> 
> Updating 35+ packages is easy with a few lines of shell
> scripting.
> 
> > Besides, some of
> > the packages might actually rely on particular numeric uid/gid's - we
> > don't know until we run tests with these packages.
> 
> Thanks for the reminder. It feels secure that you know someone
> is watching your back. If the changes are to be made for good,
> we should of course fix those beforehand those we already know
> will break. As for the unknown, how bad and in what scale and
> how high the possibilities they will break?
> 
> >
> > Here is another suggestion. make menuconfig might collect all USERID:=
> > strings from all packages and produce a list of uids and gids that
> > have been taken so that the auto-allocation mechanism will stay away
> > from these uids/gids. Such lists will likely be fairly compact, taking
> > perhaps less than 500 bytes. This will (1) avoid conflicts between
> > packages, (2) avoid the need to re-do the uid/gid allocation for 35+
> > packages, and (3) not require manual cooperation between groups of
> > people in the future.
> >
> 
> Future posts may refer to this one as "these are legacies of a
> previous decision for historical reasons".
> 
> Thinking that we have talked too much and given enough
> proposals in this thread, I prepared a doc trying to do a quick
> sum up. Please give further comments there. Hopefully we can
> come to a conclusion and take actions thereafter.
> 
> https://docs.google.com/document/d/15kD_-9wCW5mjI8aJaCT03Uoxde3rrtCdZWcaz-5mEtA/edit?usp=sharing
> 
> Regards,
> yousong
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] sdk: Fix src-git URL for the base feed when on a detached commit (FS#501)

[Karl Palsson]

Baptiste Jonglez  wrote:
> From: Baptiste Jonglez 
> 
> When the source repository is on a detached commit (such as
> when building a release tag), the git URL for the "base" feed
> is incorrect in the SDK.
> 
> Before this commit:
> 
>   On branch "master":  src-git base git://git.lede-project.org/source
>   On branch "lede-17.01":  src-git base 
> git://git.lede-project.org/source;lede-17.01
>   On tag "v17.01.0-rc2":   src-git base 
> git://git.lede-project.org/source;HEAD  <-- incorrect
> 
> After this commit:
> 
>   On branch "master":  src-git base 
> git://git.lede-project.org/source;master
>   On branch "lede-17.01":  src-git base 
> git://git.lede-project.org/source;lede-17.01
>   On tag "v17.01.0-rc2":   src-git base 
> git://git.lede-project.org/source^28b7d7f1dac725157c19236b8899e1c97f19cee9

I'd prefer if you could make it...

On tag "v17.01.0-rc2": src-git base
git://git.lede-project.org/source;v17.01.0-rc2

rather than the hash. Tags work just fine there, I've been using
that locally for my own tags, and it's much "nicer" than just the
hash.

Cheers,
Karl P


> 
> Notice that the "master" branch is now explicitly expanded:
> this is just to simplify the new code.
> 
> Signed-off-by: Baptiste Jonglez 
> ---
>  target/sdk/Makefile | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/target/sdk/Makefile b/target/sdk/Makefile index
> 719b659d25..34755b2096 100644
> --- a/target/sdk/Makefile
> +++ b/target/sdk/Makefile
> @@ -38,9 +38,10 @@ SDK_DIRS = \
>   $(STAGING_SUBDIR_TOOLCHAIN)
>  
>  GIT_URL:=$(filter git://% http://% https://%,$(shell git config --get 
> remote.origin.url 2>/dev/null))
> -GIT_BRANCH:=$(filter-out master,$(shell git rev-parse
> --abbrev-ref HEAD 2>/dev/null)) +GIT_BRANCH:=$(filter-out
> HEAD,$(shell git rev-parse --abbrev-ref HEAD 2>/dev/null))
> +GIT_DETACHED_COMMIT:=$(shell git rev-parse HEAD 2>/dev/null)
>  
> -BASE_FEED:=$(if $(GIT_URL),src-git base $(GIT_URL)$(if
> $(GIT_BRANCH),;$(GIT_BRANCH))) +BASE_FEED:=$(if
> $(GIT_URL),src-git base $(GIT_URL)$(if
> $(GIT_BRANCH),;$(GIT_BRANCH),^$(GIT_DETACHED_COMMIT)))
>  BASE_FEED:=$(if $(BASE_FEED),$(BASE_FEED),$(shell cd $(TOPDIR); LC_ALL=C git 
> svn info 2>/dev/null | sed -ne 's/^URL: /src-gitsvn base /p'))
>  BASE_FEED:=$(if $(BASE_FEED),$(BASE_FEED),$(shell cd $(TOPDIR); LC_ALL=C svn 
> info 2>/dev/null | sed -ne 's/^URL: /src-svn base /p'))
>  BASE_FEED:=$(if $(BASE_FEED),$(BASE_FEED),src-git base 
> https://git.lede-project.org/source.git$(if $(GIT_BRANCH),;$(GIT_BRANCH)))
> -- 
> 2.11.1
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] massive speed-loss using 'make defconfig'

[Karl Palsson]

> 
> (apply some symbols)
> make defconfig
> 
> [...]
> 
> (apply some symbols)
> make defconfig
> 
> This is called up to 30 times till our '.config' is ready.
> 
> Question: is it *safe* to call 'defconfig' only at there very
> end?

That's all I've ever done. I have a little snippet of maybe 20-30
lines of config keys, and just call "make defconfig" once. It
never even entered my mind to try doing it in multiple runs.

signature.html
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC PATCH odhcpd] config: respect ignore uci option

[Karl Palsson]

Jo-Philipp Wich <j...@mein.io> wrote:
> The odhcpd documentation currently implies that "option ignore
> 1" in a section of type "dhcp" will disable any services on the
> referenced interface while the code actually ignores the
> setting when initializing referenced interfaces.
> 
> This commonly leads to situations where users think that
> "option disabled" will prevent any server activity on a given
> interface while in reality odhcpd effectively acts as rogue
> DHCPv6 server in its default configuration.
> 
> To fully inhibit any activity, one has to specify both "option
> ignore 1" as well as "option ra disabled", "option ndp
> disabled" and "option dhcpv6 disabled" which is highly counter
> intuitive at best.
> 
> A previous commit (5f425ed Respect interface "ignore" settings
> as documented.) attempted to address the problem by observing
> the value of i->ignore instead of unconditionally enabling all
> protocols but broke the ability to use DHCPv6 relay mode while
> having DHCPv4 disabled.
> 
> This patch changes ...
> 
>  - the enabling of services on an interface to use the value of the ignore
>option as default choice instead of hardcoding "true"
> 
>  - the options "ra", "ndp", "dhcpv4" and "dhcpv6" to take precedence over the
>default "ignore" state to allow selectively enabling services on ignored
>interfaces
> 
>  - the README to clarify the fact that "ra", "ndp", "dhcpv4" and "dhcpv6" can
>now override "option ignore"
> 
> Signed-off-by: Jo-Philipp Wich <j...@mein.io>
> ---

Acked-by: Karl Palsson <ka...@etactica.com>

Not tested, but I support a future where "ignore" ignores :)

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/1] add support for overlaying rootfs content

[Karl Palsson]

Rafał Miłecki  <zaj...@gmail.com> wrote:
> On 7 December 2016 at 16:44, Karl Palsson <ka...@tweak.net.au>
> wrote:
> > How is this different from just reverting the commit that stopped
> > this from working? I'm all for this, don't get me wrong, but if a
> > package can just explicitly define a file as "this overwrites
> > whatever" how is that any different from before?
> 
> This new solution doesn't depend on the order of
> adding/installing packages and we have actually some control
> which package overwrites files.
> 
re order: how? You've still got to collect all the packages with
this special define and run them right? You're still going to get
conflicts one way or the other.

re control: how?  How is this:

```Your new way
package/blah/overlay
$(CP) wop /etc/somewhere
endef

any different from this

```The old way that was removed
package/blah/install
$(CP) wop /etc/somewhere
endef
```

Cheers,
Karl P

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/1] add support for overlaying rootfs content

[Karl Palsson]

How is this different from just reverting the commit that stopped
this from working? I'm all for this, don't get me wrong, but if a
package can just explicitly define a file as "this overwrites
whatever" how is that any different from before?

If I remember correctly it was this one:

commit 021b96d7c5c668fbcb5375c65cee90832bb2854f
Author: Matthias Schiffer <mschif...@universe-factory.net> Date:
Mon Sep 26 15:25:38 2016 +0200

rootfs: remove unnecessary and potentially harmful force flags from opkg 
call

Especially --force-overwrite and --force-depends will often lead to broken
images; it's better to fail the build in such cases than to silently ignore
the errors.

Instead, ignore errors in the per-device rootfs opkg remove command, so
the build doesn't break when packages can't be removed because of
dependencies.

Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net>



Perhaps putting --force-overwrite back on?

Cheers,
Karl Palsson


Rafał Miłecki  <zaj...@gmail.com> wrote:
> From: Rafał Miłecki <ra...@milecki.pl>
> 
> This adds support for install-overlay define. When used in
> package it allows installing files to a special directory that
> gets copied to the root when installing it. It allows
> overwriting files provided by other packages.
> 
> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>
> ---
>  include/package-ipkg.mk   | 9 +
>  package/base-files/files/lib/functions.sh | 5 +
>  2 files changed, 14 insertions(+)
> 
> diff --git a/include/package-ipkg.mk b/include/package-ipkg.mk
> index afd2d4e..e168eb3 100644
> --- a/include/package-ipkg.mk
> +++ b/include/package-ipkg.mk
> @@ -96,7 +96,14 @@ ifeq ($(DUMP),)
>  KEEP_$(1):=$(strip $(call Package/$(1)/conffiles))
>  
>  ifeq ($(BUILD_VARIANT),$$(if $$(VARIANT),$$(VARIANT),$(BUILD_VARIANT)))
> +do_install=
>  ifdef Package/$(1)/install
> +  do_install=yes
> +endif
> +ifdef Package/$(1)/install-overlay
> +  do_install=yes
> +endif
> +ifdef do_install
>ifneq ($(CONFIG_PACKAGE_$(1))$(DEVELOPER),)
>  IPKGS += $(1)
>  compile: $$(IPKG_$(1)) $(PKG_INFO_DIR)/$(1).provides 
> $(STAGING_DIR_ROOT)/stamp/.$(1)_installed
> @@ -178,6 +185,8 @@ $(_endef)
>   @rm -rf $$(IDIR_$(1)) $$(call opkg_package_files,$(1))
>   mkdir -p $(PACKAGE_DIR) $$(IDIR_$(1))/CONTROL $(PKG_INFO_DIR)
>   $(call Package/$(1)/install,$$(IDIR_$(1)))
> + $(if $(Package/$(1)/install-overlay),mkdir -p $(PACKAGE_DIR) 
> $$(IDIR_$(1))/rootfs-overlay)
> + $(call Package/$(1)/install-overlay,$$(IDIR_$(1))/rootfs-overlay)
>   -find $$(IDIR_$(1)) -name 'CVS' -o -name '.svn' -o -name '.#*' -o -name 
> '*~'| $(XARGS) rm -rf
>   @( \
>   find $$(IDIR_$(1)) -name lib\*.so\* -or -name \*.ko | awk -F/ 
> '{ print NF }'; \
> diff --git a/package/base-files/files/lib/functions.sh
> b/package/base-files/files/lib/functions.sh index
> b3bf221..b68db6b 100755
> --- a/package/base-files/files/lib/functions.sh
> +++ b/package/base-files/files/lib/functions.sh
> @@ -230,6 +230,11 @@ default_postinst() {
>   ret=$?
>   fi
>  
> + if [ -d "$root/rootfs-overlay" ]; then
> + cp -R $root/rootfs-overlay/. $root/
> + rm -fR $root/rootfs-overlay/
> + fi
> +
>   if [ -z "$root" ] && grep -q -s "^/etc/uci-defaults/" 
> "/usr/lib/opkg/info/${pkgname}.list"; then
>   . /lib/functions/system.sh
>   [ -d /tmp/.uci ] || mkdir -p /tmp/.uci
> -- 
> 2.10.1
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] odhcpd: Update to 2016-12-01 snapshot

[Karl Palsson]

John Crispin <j...@phrozen.org> wrote:
> Hi Karl,
> 
> this comment is completely devoid any usefulness. let me help
> by rephrasing it to make it useful.
> 
> "Hi community,
> 
> i have noticed that it is common practice to not annotate the
> upstream changes properly in commit bumping the git hash of
> packages. i feel that it would be much better if we used some
> common pattern, such as the "git log --online" output to make
> the changes more explicit. this would make the changelog of
> trunk more readable.
> 
> b/R"
> 
> let me know if this is what you actually wanted to say. because
> it think it would be a good idea and i would support such a new
> way of bumping packages.

Sounds lovely, I appreciate your rewording, it's much clearer and
to the point than my earlier complaints. Let's hope the community
agrees!

Cheers,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] odhcpd: Update to 2016-12-01 snapshot

[Karl Palsson]

Florian Fainelli <f.faine...@gmail.com> wrote:
> On 12/04/2016 02:53 PM, Karl Palsson wrote:
> > Care to explain what you're updating? This patch is completely
> > devoid of useful information without resorting to external
> > sources. Surely, you have motivation for updating?
> 
> Having this commit below, and the other two make on top which
> are bugfixes as well:
> 
> https://git.lede-project.org/?p=project/odhcpd.git;a=commitdiff;h=374dc3f13623df58275d9da51637976c34be125d

Great, still need to leave to see what you're actually doing. A
summary is useful for being a summary.

> Mind complaining to whoever does similar updates in the future:

Absolutely, I'll complain on these commits whenever I see them,
but I can't be everywhere at once. Also, the bad behaviour of
others is no excuse for bad behaviour of your own, and it's lame
to try and use it as an excuse.

Sincerely,
Karl Palsson


signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] odhcpd: Update to 2016-12-01 snapshot

[Karl Palsson]

Care to explain what you're updating? This patch is completely
devoid of useful information without resorting to external
sources. Surely, you have motivation for updating?

Sincerely,
Karl Palsson


Florian Fainelli <f.faine...@gmail.com> wrote:
> Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
> ---
>  package/network/services/odhcpd/Makefile | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/package/network/services/odhcpd/Makefile
> b/package/network/services/odhcpd/Makefile index
> f6ce26c150ef..f8a74b93c911 100644
> --- a/package/network/services/odhcpd/Makefile
> +++ b/package/network/services/odhcpd/Makefile
> @@ -8,15 +8,15 @@
>  include $(TOPDIR)/rules.mk
>  
>  PKG_NAME:=odhcpd
> -PKG_VERSION:=2016-11-21
> +PKG_VERSION:=2016-12-01
>  PKG_RELEASE=$(PKG_SOURCE_VERSION)
>  
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
>  PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
>  PKG_SOURCE_URL:=git://git.lede-project.org/project/odhcpd.git
>  PKG_SOURCE_PROTO:=git
> -PKG_SOURCE_VERSION:=5f425ed1e5f92397e27ec4f44820b6ef677b8134
> -PKG_MIRROR_MD5SUM:=64ef09adbb88e1a419a689985dbc784c94003b247216d6e188e81b7f2807b032
> +PKG_SOURCE_VERSION:=41b52688403016017eca812315a7206b6d27c097
> +PKG_MIRROR_MD5SUM:=14b2ddb5a48d5af81e36594e7c526c2e2019c2d4b112af41f9004660bb84a230
>  
>  PKG_MAINTAINER:=Steven Barth <ste...@midlink.org>
>  PKG_LICENSE:=GPL-2.0
> -- 
> 2.9.3
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] can I have some feedback about a wrapper to call initscripts

[Karl Palsson]

Jo-Philipp Wich <j...@mein.io> wrote:
> Hi Alberto,
> 
> personally I like the service wrapper since it alligns the
> service handling with Debian and older CentOS / Redhat distros.

If it looks like debian and out of date unsupported
centos/redhat, but is actually completely different, is it really
helpful to make it look like something it's not?

The life of the "service  start|stop|status" really wasn't
very long. It didn't offer command completion without shell
programming, and was simply a rewording of /etc/init.d/
start|stop|status. Redhat based distros moved to systemd, ubuntu
went to upstart, and that changed things _again_ Why should
openwrt _add_ a duplicate path that needs to be documented and
adds little to no value?

Sincerley,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH odhcpd 3/5] ubus: Fix displayed valid paramater for both DHCPv4 and DHCPv6 lease

[Karl Palsson]

Hans Dedecker <dedec...@gmail.com> wrote:
> Fix ubus valid parameter being displayed as a negative number;
> also display infinite lifetime as INT32_MAX

Really? Why not 0 or -1? You dont' specify an infinite lease as
INT32_MAX, why would I want to receive an infinite lease as some
magic number that only programmer nerds would even recognize?

Sincerely,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH odhcpd 1/5] config: Support infinite as DHCP pool leasetime value

[Karl Palsson]

Hans Dedecker <dedec...@gmail.com> wrote:
> Add support for infinite leasetime value; this can be done by
> specifying "infinite" as leasetime value which is similar to
> dnsmasq infinite leasetime support. Specifying "infinite" as
> leasetime is valid for both the host and dhcp uci sections. A
> DHCPv4/DHCPv6 assignment is now considered infinite if
> valid_unil holds the value 0.

Can you specify "0" in uci too? that's a really common way of
saying never, I've not ever seen a config file that needed the
word "infinite" before

Sincerely,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] LED uci policy for not actively used LEDs

[Karl Palsson]

Mathias Kresin  wrote:
> 2016-11-10 16:41 GMT+01:00 Jo-Philipp Wich :
> > Hi Karl,
> >
> > I think there is not much speaking against making the led init script
> > run earlier. I think it would make sense to have it START=11, right
> > after /etc/init.d/boot.
> 
> I've a TDW-8980 here, where the ath9k driver acts as GPIO
> controller for the wireless LED [0]. The wireless led is
> populated to sysfs only after the ath9k driver is loaded. This
> might take some time, since the ath9k EEPROM needs to be loaded
> from flash first to fixup an invalid PCI vendor and device id.
> 
> Long story short, changing the START param might lead to a
> start of the led init script before all referenced leds are
> available in sysfs. At the moment I see this issue already on
> the TDW-8980 on first boot. And yes, I know that a propper fix
> would be some kind of hotplug script.
> 

hehe, it's almost like a pile of shell scripts is a problematic
way of ordering startup, and we should build something that can
handle dependencies of interrelated items or something

hang on...

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Package updates in the for-15.05 branch (libuv)

[Karl Palsson]

libuv was recently udpated too:
https://github.com/openwrt/packages/commit/d8d457e52c2560bab4cf49182762bb4a8fe6019c

from 1.4.2 to 1.9.1, though fortunately that at least seems to be
ABI compatible:
https://abi-laboratory.pro/tracker/timeline/libuv/

I'm concerned that given the lack of release from both LEDE and
OpenWrt, people are starting to treat the for-15.05 branch like a
free for all "mainline" branch again.

Karl Palsson <ka...@tweak.net.au> wrote:
> 
> Again, we're getting major version package updates in the
> stable for-15.05 branch. haproxy has just been updated from
> 1.5.x to 1.6.x, with no pull request, no mailing list
> discussion and by a committer without a proper name.
> 
> Again, if packages in the stable release aren't enough for you,
> _use your own feed_ and stop dumping major changes on people
> using a stable branch. The commit updating haproxy had to be
> immediately followed with fixup commits _already_
> 
> https://github.com/openwrt/packages/commit/bec6d8fc8d3f0a18ab965933e4b9187c30aab743
> 
> What's going on?!
> 
> Sincerely,
> Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] dnsmasq: support log-dhcp option

[Karl Palsson]

Helpful when trying to resolve issues with quirky dhcp client devices.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---
 package/network/services/dnsmasq/files/dnsmasq.init | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 6f5ccfeae429..76128301037c 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -567,6 +567,7 @@ dnsmasq_start()
append_bool "$cfg" fqdn "--dhcp-fqdn"
append_bool "$cfg" proxydnssec "--proxy-dnssec"
append_bool "$cfg" localservice "--local-service"
+   append_bool "$cfg" logdhcp "--log-dhcp"
append_bool "$cfg" quietdhcp "--quiet-dhcp"
append_bool "$cfg" sequential_ip "--dhcp-sequential-ip"
append_bool "$cfg" allservers "--all-servers"
-- 
2.4.11


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] base-files: ensure reset only works if an overlay exists

[Karl Palsson]

It used to only do the sync+reboot for button presses less than 1
second. jffs2reset and reboot for button presses longer than 5
seconds, and _nothing_ for presses between 1 and 5 seconds.
(Potentially leaving room for someone else to add some other
hook, but realistically just useless)

I noticed it, but thought it was probably simpler this way, but
Rafal's right, if you're changing that behaviour as well, it
should at least be documented as deliberate in the commit note.

Sincerely,
Karl Palsson

Chris Blake <chrisrblak...@gmail.com> wrote:
> Rafal,
> 
> I am not sure I see the issue you are mentioning. The patch's
> goal is to disable the "reset" feature for devices that do not
> have an overlay, and instead just reboot the device. This patch
> does that, and was tested on an ar71xx and x86_64 ext4
> platform.
> 
> Regards,
> Chris Blake
> 
> On Wed, Oct 19, 2016 at 4:33 PM, Rafał Miłecki
> <zaj...@gmail.com> wrote:
> > On 19 October 2016 at 16:54, Chris Blake <chrisrblak...@gmail.com> wrote:
> >> Currently the reset script will try to run jffs2reset on boards that are
> >> running a rw ext4 or other rootfs, which will then cause jffs2reset to
> >> fail and the board to never reboot. This change ensures that jffs2reset
> >> is only ran if an overlay is mounted.
> >>
> >> Signed-off-by: Chris Blake <chrisrblak...@gmail.com>
> >> ---
> >>  package/base-files/files/etc/rc.button/reset | 11 ++-
> >>  1 file changed, 6 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/package/base-files/files/etc/rc.button/reset 
> >> b/package/base-files/files/etc/rc.button/reset
> >> index c6dc7cf..fab9a6c 100755
> >> --- a/package/base-files/files/etc/rc.button/reset
> >> +++ b/package/base-files/files/etc/rc.button/reset
> >> @@ -11,15 +11,16 @@ timeout)
> >> set_state failsafe
> >>  ;;
> >>  released)
> >> -   if [ "$SEEN" -lt 1 ]
> >> +   OVERLAY="$(cat /proc/mounts | grep ' /overlay ' 2>/dev/null)"
> >> +   if [ "$SEEN" -gt 5 -a -n "$OVERLAY" ]
> >> +   then
> >> +   echo "FACTORY RESET" > /dev/console
> >> +   jffs2reset -y && reboot &
> >> +   elif [ "$SEEN" ]
> >> then
> >> echo "REBOOT" > /dev/console
> >> sync
> >> reboot
> >> -   elif [ "$SEEN" -gt 5 ]
> >> -   then
> >> -   echo "FACTORY RESET" > /dev/console
> >> -   jffs2reset -y && reboot &
> >> fi
> >>  ;;
> >>  esac
> >
> > It seems to me you just changed behavior for pressing button for time
> > between 1 and 5 seconds. Your commit message doesn't state you wanted
> > to do that and I don't think we should.
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] package contribution guidelines

[Karl Palsson]

Rafał Miłecki  <zaj...@gmail.com> wrote:
> On 19 October 2016 at 16:59, Chris Blake
> <chrisrblak...@gmail.com> wrote:
> > diff --git a/package/utils/beep/Makefile b/package/utils/beep/Makefile
> > new file mode 100644
> > index 000..b9bb4d80
> > --- /dev/null
> > +++ b/package/utils/beep/Makefile
> > @@ -0,0 +1,50 @@
> > +#
> > +# Copyright (C) 2016 OpenWrt.org
> > +#
> > +# This is free software, licensed under the GNU General Public License v2.
> > +# See /LICENSE for more information.
> > +#
> 
> We really need to do some final research on this and add some
> documentation probably.
> 
> I don't think you can assign copyrights to OpenWrt without
> having a contract specifying that clearly.

jow drafted some nice updates to the
https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md
file on piratepad when we spoke about this recently. Addresses a
few other things that had come up recently too, wrt git vs
http(s) sources and so on.

Did anyone else ever comment on that jow? Should we submit it as
a change to that file now?

Sincerely,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Out of tree builds

[Karl Palsson]

The scripts/env script is intended to help with this. See
https://wiki.openwrt.org/doc/devel/env

./scripts/env new my-target-a
make menuconfig/whatever
make
./scripts/env new my-target-b
make menuconfig/whatever
make
./scripts/env switch my-target-a
-- back to target a configs now

(There might be other, less well documented paths)

Sincerely,
Karl P


David Woodhouse  wrote:
> Is there a simple trick I'm missing, to build for multiple
> targets from the same build tree?
> 
> I'm mostly just manually copying my .config file out of the way
> and swapping it for a different one each time — but there's got
> to be a better way, surely?
> 
> mv .config .config.wndr3800
> mv .config.tdw8970 .config
> make -j32 oldconfig world
> 
> -- 
> dwmw2
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] replacing files in base system from a package?

[Karl Palsson]

David Lang <da...@lang.hm> wrote:
> 
> I think this is a bad idea, your priority for packages may not
> match someone else's priority, and what happens if someone
> wants something from one package and something else from
> another.
> 
> I could see the ability to say "This package is explicitly
> designed to override files in others" for customization, but
> unless the /files approach has been eliminated, that's a far
> better approach for local customizations.


Using files is a poor choice: 

* It requires forking
* It can't make decisions based on make variables

Both of these are things that in the past were easily met by
packages providing files themselves.

Sincerely,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] per device rootfs vs multiple devices

[Karl Palsson]

Matthias Schiffer <mschif...@universe-factory.net> wrote:
> Hi,
> {*} means that the package can't be disabled completely, but it can be set
> to M. This should give you the desired behaviour.

Right, ok. This is one of those things that's not in the Kconfig
legend. (Not in kernel upstream either, just magic knowledge) I
presume it comes from reusing modules as targets or something.

> 
> Creating a new config and setting
> CONFIG_TARGET_PER_DEVICE_ROOTFS from the beginning also works
> and sets all used DEVICE_PACKAGES to M. As your workflow
> created a config with these packages set to * first, you ended
> up with these packages still being selected after switching to
> CONFIG_TARGET_PER_DEVICE_ROOTFS.

Right, yes. After manually making some config stubs and applying
"make defconfig" I get the expected behaviour of device packages
only in the device. Pretty high surprise factor for the way
menuconfig works, but ok, that's what I'm adding the
documentation for :)

It would be _nice_ if the help in kconfig could say where it had
been pulled in from too, but I live with that. currently it just
says...

"Selected by: MODULE_DEFAULT_avrdude [=y] &&
TARGET_PER_DEVICE_ROOTFS [=y] && m && MODULES [=y]"

but not what "module" it was that pulled it in.
 
> The additional rootfs aren't ever copied to the bin directory,
> so finding only a single lede-ar71xx-generic-root.squashfs is
> expected.

The other things I can document, but this seems just wrong. If
you have a per device rootfs, what would even be _in_ the
"generic" one? Surely if you have chosen per device rootfs, you
expect to get per device rootfs?

In any case, this per device rootfs setting makes a complete mess
of scripts/diffconfig.sh. I get duplicate lines for each target,
and now _al_ of the base core packages that were untouched
are now marked as explicitly selected.
CONFIG_TARGET_DEVICE_PACKAGES_ar71xx_generic_DEVICE_dragino2=""
<< duplicated

Sincerely,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] scripts: case insensitive sort device names

[Karl Palsson]

When selecting devices from the Target Devices menu, the brand choices
of naming makes it confusing to find particular devices by name, as the
sorting is case sensitve.  AirTight came after ALFA, and devolo and
jjPlus both came after Zyxel.

This does _not_ apply to the Target Profile list, as that includes
"Default - all profiles" inside the profile list.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---
 scripts/target-metadata.pl | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/scripts/target-metadata.pl b/scripts/target-metadata.pl
index 3422572d1639..7f7dc6d4ee77 100755
--- a/scripts/target-metadata.pl
+++ b/scripts/target-metadata.pl
@@ -276,8 +276,12 @@ menu "Target Devices"
 
 EOF
foreach my $target (@target) {
-   my $profiles = $target->{profiles};
-   foreach my $profile (@{$target->{profiles}}) {
+   my @profiles = sort {
+   my $x = $a->{name};
+   my $y = $b->{name};
+   "\L$x" cmp "\L$y";
+   } @{$target->{profiles}};
+   foreach my $profile (@profiles) {
next unless $profile->{id} =~ /^DEVICE_/;
print <<EOF;
 menuconfig TARGET_DEVICE_$target->{conf}_$profile->{id}
-- 
2.4.11


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Support for KEY_BRIGHTNESS_ZERO

[Karl Palsson]

Rafał Miłecki  <zaj...@gmail.com> wrote:
> There are some (rare) devices with a button for disabling LEDs
> (e.g. ASUS RT-AC68U). I'm looking for a way to support such a
> feature. Maybe at some point we could also support it as an
> extra feature triggerable from UI.
> 
> So basically I probably need to add some smart /etc/rc.button/
> handler. Unfortunately I don't have a good idea for that.
> 
> I can't relay on /etc/config/system and LEDs there as not all
> of them are specified there. Many LEDs don't require changing
> and they are set to default state based on platform/DT data.
> 
> So I guess I should somehow store state of all LEDs from
> /sys/class/leds/ and set their triggers to "none". When
> receiving KEY_BRIGHTNESS_ZERO I should restore the state.
> 
> Any tips for implementing this? There are various triggers with
> various extra settings in /sys/class/leds/*/
> 

Related, even with leds set in /etc/config/system, their triggers
aren't setup until S96. How can they get setup earlier? I've got
a daemon that wants a led trigger file to be passed in for it to
write to on activity, but the triggers aren't set. Is
/etc/config/system ever actually useful for leds?

Sincerely,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] ar71xx: move dragino2 from legacy to generic

[Karl Palsson]

Tested on real hardware with r1804.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---
 target/linux/ar71xx/image/generic.mk| 10 ++
 target/linux/ar71xx/image/legacy-devices.mk |  6 --
 target/linux/ar71xx/image/legacy.mk |  2 --
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/target/linux/ar71xx/image/generic.mk 
b/target/linux/ar71xx/image/generic.mk
index 0307b263704e..53fee878eb98 100644
--- a/target/linux/ar71xx/image/generic.mk
+++ b/target/linux/ar71xx/image/generic.mk
@@ -27,6 +27,16 @@ define Device/cf-e316n-v2
 endef
 TARGET_DEVICES += cf-e316n-v2
 
+define Device/dragino2
+  BOARDNAME := DRAGINO2
+  CONSOLE := ttyATH0,115200
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-ledtrig-usbdev
+  DEVICE_TITLE := Dragino 2 (MS14)
+  IMAGE_SIZE := 16000k
+  MTDPARTS := spi0.0:256k(u-boot)ro,16000k(firmware),64k(config)ro,64k(art)ro
+endef
+TARGET_DEVICES += dragino2
+
 define Device/weio
   DEVICE_TITLE := WeIO
   DEVICE_PACKAGES := kmod-usb-core kmod-usb2
diff --git a/target/linux/ar71xx/image/legacy-devices.mk 
b/target/linux/ar71xx/image/legacy-devices.mk
index d6935e7db263..245a4112fadd 100644
--- a/target/linux/ar71xx/image/legacy-devices.mk
+++ b/target/linux/ar71xx/image/legacy-devices.mk
@@ -161,12 +161,6 @@ define LegacyDevice/DB120
 endef
 LEGACY_DEVICES += DB120
 
-define LegacyDevice/DRAGINO2
-  DEVICE_TITLE := DRAGINO2
-  DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-ledtrig-usbdev
-endef
-LEGACY_DEVICES += DRAGINO2
-
 define LegacyDevice/EWDORINAP
   DEVICE_TITLE := Embedded Wireless Dorin Platform (4MB flash)
   DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-ledtrig-usbdev 
kmod-usb-storage
diff --git a/target/linux/ar71xx/image/legacy.mk 
b/target/linux/ar71xx/image/legacy.mk
index 92f3469b7328..58a65d4dbca8 100644
--- a/target/linux/ar71xx/image/legacy.mk
+++ b/target/linux/ar71xx/image/legacy.mk
@@ -271,7 +271,6 @@ 
ew-dorin_mtdlayout_16M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),16000k(fir
 
f9k1115v2_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),14464k(rootfs),1408k(kernel),64k(nvram)ro,64k(envram)ro,64k(art)ro,15872k@0x5(firmware)
 
dlrtdev_mtdlayout=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,6208k(firmware),64k(caldata)ro,640k(certs),960k(unknown)ro,64k@0x7f(caldata_copy)
 
dlrtdev_mtdlayout_fat=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,7168k(firmware),640k(certs),64k(caldata)ro,64k@0x66(caldata_orig),6208k@0x5(firmware_orig)
-dragino2_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,16000k(firmware),64k(config)ro,64k(art)ro
 
mr12_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,256k(u-boot-env)ro,13440k(rootfs),2304k(kernel),128k(art)ro,15744k@0x8(firmware)
 
mr16_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,256k(u-boot-env)ro,13440k(rootfs),2304k(kernel),128k(art)ro,15744k@0x8(firmware)
 
pb92_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,2752k(rootfs),896k(kernel),64k(nvram),64k(art)ro,3648k@0x5(firmware)
@@ -946,7 +945,6 @@ $(eval $(call 
SingleProfile,AthLzma,64k,AP152_16M,ap152-16M,AP152,ttyS0,115200,$
 $(eval $(call 
SingleProfile,AthLzma,64k,BXU2000N2,bxu2000n-2-a1,BXU2000n-2-A1,ttyS0,115200,$$(bxu2000n2_mtdlayout),RKuImage))
 $(eval $(call 
SingleProfile,AthLzma,64k,CAP4200AG,cap4200ag,CAP4200AG,ttyS0,115200,$$(cap4200ag_mtdlayout),KRuImage))
 $(eval $(call 
SingleProfile,AthLzma,64k,DB120,db120,DB120,ttyS0,115200,$$(db120_mtdlayout),RKuImage))
-$(eval $(call 
SingleProfile,AthLzma,64k,DRAGINO2,dragino2,DRAGINO2,ttyATH0,115200,$$(dragino2_mtdlayout),KRuImage,65536))
 $(eval $(call 
SingleProfile,AthLzma,64k,EWDORINAP,ew-dorin,EW-DORIN,ttyATH0,115200,$$(ew-dorin_mtdlayout_4M),KRuImage,65536))
 $(eval $(call 
SingleProfile,AthLzma,64k,EWDORINRT,ew-dorin-router,EW-DORIN-ROUTER,ttyATH0,115200,$$(ew-dorin_mtdlayout_4M),KRuImage,65536))
 $(eval $(call 
SingleProfile,AthLzma,64k,EWDORIN16M,ew-dorin-16M,EW-DORIN,ttyATH0,115200,$$(ew-dorin_mtdlayout_16M),KRuImage,65536))
-- 
2.4.11


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] PROVIDES dependency issue

[Karl Palsson]

I recently started maintaining a "future" version of a package,
as a way of having a preview version available. [1] I added
"PROVIDES:= libmosquitto" to the library version of
libmosquitto-next, and I have a application package that then
simply DEPENDS: = libmosquitto.

This works for most applications, but one always fails with
```
Package blah is missing dependencies for the following libraries:
libmosquitto.so.1
```

If I manually run ```make package/mosquitto-next/{clean,compile}``` I can then 
rerun the build and it will finish just fine.  It seems like the package that 
fails is alphabetically before "m"?  

Is this a known current limitation of PROVIDES? or is it a bug
that should be working?

Sincerely,
Karl Palsson

[1] mosquitto-next and mosquitto
https://github.com/remakeelectric/owrt_pub_feeds/tree/master/net/mosquitto{,-next}

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] replacing files in base system from a package?

[Karl Palsson]

Alberto Bursi <alberto.bu...@outlook.it> wrote:
> 
> 
> On 10/03/2016 03:26 PM, Karl Palsson wrote:
> > What's the "new" way of doing this? In the past, in OpenWrt CC
> > and before, a package could install files like /etc/banner and
> > /etc/inittab that were provided by the base-files package. It was
> > always listed as "unreliable" as apparently you couldn't rely on
> > the order. In practice it actually worked just fine.
> >
> > What's the currently accepted mechanism for including replacement
> > files in a custom build?
> >
> > Sincerely,
> > Karl Palsson
> >
> 
> What I've found so far for my own project is that a script in
> /files/etc/uci-defaults folder in source folder should work.
> Anyway scripts in /etc/uci-defaults (from any source) are
> called on first boot and apply configuration changes on device,
> just look at the ones you have already there in the rootfs.
> 

You're absolutely correct, that way _works_ but it's pointlessly
redundant to ship files just so that I can make the bootup
process take longer while it "finishes" replacing files that I
knew from the outset I never wanted. It also means that until
_my_ uci-defaults file runs, (depends on everyone else) I still
have the old original files in place. uci-defaults is a great
mechanism for many things, but i really don't feel it's
appropriate for everything.

Sincerely,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] replacing files in base system from a package?

[Karl Palsson]

What's the "new" way of doing this? In the past, in OpenWrt CC
and before, a package could install files like /etc/banner and
/etc/inittab that were provided by the base-files package. It was
always listed as "unreliable" as apparently you couldn't rely on
the order. In practice it actually worked just fine.

Presently, LEDE actively prevents this, with the build scripts
failing the build with


 * check_data_file_clashes: Package blah wants to install file 
/home/karlp/src/lede-source/build_dir/target-mips_24kc_musl-1.1.15/root-ar71xx/etc/banner
But that file is already provided by package  * base-files
 * check_data_file_clashes: Package blah wants to install file 
/home/karlp/src/lede-source/build_dir/target-mips_24kc_musl-1.1.15/root-ar71xx/etc/inittab
But that file is already provided by package  * base-files
 * opkg_install_cmd: Cannot install package blah.
package/Makefile:56: recipe for target 'package/install' failed

Now, clearly I could just edit the base-files package in a forked
repository. However, the motivation of using a package was to
avoid forking LEDE. I've seen talks and presentations on this,
"use a package!"

What's the currently accepted mechanism for including replacement
files in a custom build?

Sincerely,
Karl Palsson


signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Call defines for minifying scripting languages

[Karl Palsson]

Jan-Tarek Butt <ta...@ring0.de> wrote:
> Hi,
> 
> My Idea ist to create calldefs to minify all scriptes there are
> interpreted by run time.
> 
> As example see the mail "[PATCH] LuaSrcDiet call define for lua
> code Minifying".
> 
> I plan to write also calldefs for shellscripts, python and
> perl.
> 
> They brings vareous of features.
> 
> 1. Reducing memory size on firmware images.

But will it? They're in the squashfs image, it's already been
demonstrated before that compressing things before can actually
have negative impacts.

> 2. Strip out all comments (which makes us able to do better
> code commenting) 3. and so on.
> 
> One negative point will be there:
> 
> the minified code an not realy human readable but if some one
> want to read this script or work on it on routers, they can
> easily copy the unminified script via scp.

This is a _massive_ downside IMO, and absolutely not something
that should be enabled by default. There's already far too much
undocumented/underdocumented internal behaviours of scripts and
processes in LEDE/OpenWrt, and minifying scripts and stripping
comments actively works to preserve that situation.

Sincerely,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] ubus rpcd plugins

[Karl Palsson]

Hi, I've been trying to implement a firmware update via a ubus
rpcd plugin, and have run into a problem regarding how ubus calls
the plugins. As best I can tell, if a ubus rpcd plugin does
_anything_ in the background, ubus call hangs and then timesout.
I can see that rpcd already has some attempts at sysupgrade
support, where it forks, explicitly to avoid this [1] but even
with a lua ubus rcpd plugin forking, I see the same behaviour
with fork, or with shell &.

Example output below..

```
# ubus list -v demo-hang
'demo-hang' @e96d29a7
"gofork":{"fname":"String"}
"simple":{"fname":"String"}
# ubus call demo-hang simple
{
"simple": "went fine"
}
# ubus call demo-hang gofork
Command failed: Request timed out
```

Sample rpcd plugin handler:
```
#!/bin/sh
case "$1" in
list)
echo '{ "gofork": { "fname": "somestring" }, "simple": { 
"fname": "somestring" } }'
;;
call)
case "$2" in
simple)
read input;
printf "simple called with input <%s>\n" 
"$input" >> /tmp/demo-hang.log
echo '{ "simple": "went fine" }'
;;
gofork)
read input;
printf "gofork called with input <%s>\n" 
"$input" >> /tmp/demo-hang.log
# fork and let the child do some long running 
task
(sleep 3; echo "after sleeping, child wrote 
this" >> /tmp/demo-hang.log)&
echo '{ "gofork": "went fine" }'
;;
esac
;;
esac
```

The log file written has the child output included, so it's
clearly running. Is there any method of starting a task from a
rpcd plugin like this? Even in my own case, I can't use the
"existing" rpcd sysupgrade support, because it's not available on
the CC branch, and there's been no releases of anything later.

Sincerely,
Karl Palsson


[1] RPCD forking to do background task:
https://git.lede-project.org/?p=project/rpcd.git;a=blob;f=sys.c;h=b90aa6b894aba29e8be4884c160a7c34ee0ca646;hb=HEAD#l189

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] odhcpd [PATCHv2 2/3] remove superfluous log output.

[Karl Palsson]

From: Karl Palsson <ka...@etactica.com>

Drop pointless syslog.  The single line just doubles the amount of lines
logged to syslog without adding any value.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---
Change since v1:
 Nothing

 src/odhcpd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/odhcpd.c b/src/odhcpd.c
index 4341369..e83a700 100644
--- a/src/odhcpd.c
+++ b/src/odhcpd.c
@@ -465,7 +465,6 @@ static void odhcpd_receive_packets(struct uloop_fd *u, 
_unused unsigned int even
else if (addr.in.sin_family == AF_INET)
inet_ntop(AF_INET, _addr, ipbuf, 
sizeof(ipbuf));
 
-   syslog(LOG_DEBUG, "--");
syslog(LOG_DEBUG, "Received %li Bytes from %s%%%s", (long)len,
ipbuf, (iface) ? iface->ifname : "netlink");
 
-- 
2.4.11


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] odhcpd [PATCHv2 3/3] Respect interface "ignore" settings as documented.

[Karl Palsson]

From: Karl Palsson <ka...@etactica.com>

The "ignore" option is correctly loaded.  Actually observe it as
documented.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---
Changes since v1:
 * nothing, no feedback received on this item

 src/config.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/config.c b/src/config.c
index ef51112..a1b6ab7 100644
--- a/src/config.c
+++ b/src/config.c
@@ -695,10 +695,10 @@ void odhcpd_reload(void)
i->ndp = (master && master->ndp == 
RELAYD_RELAY) ?
RELAYD_RELAY : RELAYD_DISABLED;
 
-   setup_router_interface(i, true);
-   setup_dhcpv6_interface(i, true);
-   setup_ndp_interface(i, true);
-   setup_dhcpv4_interface(i, true);
+   setup_router_interface(i, !i->ignore);
+   setup_dhcpv6_interface(i, !i->ignore);
+   setup_ndp_interface(i, !i->ignore);
+   setup_dhcpv4_interface(i, !i->ignore);
} else {
close_interface(i);
}
-- 
2.4.11


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] odhcpd: [PATCHv2 1/3] enable loglevel setting via command line

[Karl Palsson]

From: Karl Palsson <ka...@etactica.com>

Currently the loglevel is hardcoded to LOG_WARNING, even though there is
debug log messages.  Allow setting the loglevel via cli option.
Include basic help text because we're adding command line options.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---

Changes since v1:
 Use command line arg instead of env var.

 src/odhcpd.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/src/odhcpd.c b/src/odhcpd.c
index 74830ac..4341369 100644
--- a/src/odhcpd.c
+++ b/src/odhcpd.c
@@ -54,11 +54,33 @@ static void sighandler(_unused int signal)
uloop_end();
 }
 
+static void print_usage(const char *app)
+{
+   printf(
+   "== %s Usage ==\n\n"
+"  -h, --help   Print this help\n"
+"  -l level Specify log level 0..7 (default %d)\n",
+   app, LOG_WARNING
+   );
+}
 
-int main()
+int main(int argc, char **argv)
 {
openlog("odhcpd", LOG_PERROR | LOG_PID, LOG_DAEMON);
-   setlogmask(LOG_UPTO(LOG_WARNING));
+   int opt;
+   int log_level = LOG_WARNING;
+   while ((opt = getopt(argc, argv, "hl:")) != -1) {
+   switch (opt) {
+   case 'h':
+   print_usage(argv[0]);
+   return 0;
+   case 'l':
+   log_level = atoi(optarg);
+   fprintf(stderr, "Log level set to %d\n", log_level);
+   break;
+   }
+   }
+   setlogmask(LOG_UPTO(log_level));
uloop_init();
 
if (getuid() != 0) {
-- 
2.4.11


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] odhcpd: [PATCH 1/3] enable loglevel setting via envvar ODHCPD_LOG_LEVEL

[Karl Palsson]

John Crispin <j...@phrozen.org> wrote:
> 
> 
> On 22/09/2016 19:32, Karl Palsson wrote:
> > From: Karl Palsson <ka...@etactica.com>
> > 
> > Currently the loglevel is hardcoded to LOG_WARNING, even though there is
> > debug log messages.  Allow an env var to control the log threshold.
> > 
> > Signed-off-by: Karl Palsson <ka...@etactica.com>
> > ---
> >  src/odhcpd.c | 16 +++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/odhcpd.c b/src/odhcpd.c
> > index 74830ac..c51cfa1 100644
> > --- a/src/odhcpd.c
> > +++ b/src/odhcpd.c
> > @@ -58,7 +58,21 @@ static void sighandler(_unused int signal)
> >  int main()
> >  {
> > openlog("odhcpd", LOG_PERROR | LOG_PID, LOG_DAEMON);
> > -   setlogmask(LOG_UPTO(LOG_WARNING));
> > +   char *env_log_level = getenv("ODHCPD_LOG_LEVEL");
> > +   int log_level = LOG_WARNING;
> > +   if (env_log_level) {
> > +   char *end;
> > +   errno = 0;
> > +   long temp = strtol(env_log_level, , 0);
> > +   if (end == env_log_level || *end != '\0'
> > +   || ((temp == LONG_MIN || temp == LONG_MAX) && errno == 
> > ERANGE)
> > +   || (log_level > LOG_DEBUG) || log_level < LOG_EMERG) {
> > +   syslog(LOG_ERR, "ODHCPD_LOG_LEVEL envvar was invalid");
> > +   } else {
> > +   log_level = temp;
> > +   }
> > +   }
> > +   setlogmask(LOG_UPTO(log_level));
> > uloop_init();
> 
> this is pretty bloaty. i am also not sure if using an env var
> is the right way to solve this.

sure, strol sucks. But that's "the" way of checking. I could use
atoi, and just convert nulls to some sort of default maybe. As
for an env var, sure, they suck too, I just copied procd, was
trying to be consistent. I'm open to other suggestions. I don't
_need_ the logging anymore, after adding more for the fixing the
"ignore" problem, and with logging feasible, there's probably
more debug that would be relevant, so this patch could be dropped
entirely if it's too much of a headache.

Cheers,
Karl P

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] odhcpd: [PATCH 2/3] remove superfluous log output.

[Karl Palsson]

From: Karl Palsson <ka...@etactica.com>

Drop pointless syslog.  The single line just doubles the amount of lines
logged to syslog without adding any value.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---
 src/odhcpd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/odhcpd.c b/src/odhcpd.c
index c51cfa1..50f3c9f 100644
--- a/src/odhcpd.c
+++ b/src/odhcpd.c
@@ -457,7 +457,6 @@ static void odhcpd_receive_packets(struct uloop_fd *u, 
_unused unsigned int even
else if (addr.in.sin_family == AF_INET)
inet_ntop(AF_INET, _addr, ipbuf, 
sizeof(ipbuf));
 
-   syslog(LOG_DEBUG, "--");
syslog(LOG_DEBUG, "Received %li Bytes from %s%%%s", (long)len,
ipbuf, (iface) ? iface->ifname : "netlink");
 
-- 
2.4.11


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] odhcpd: [PATCH 1/3] enable loglevel setting via envvar ODHCPD_LOG_LEVEL

[Karl Palsson]

From: Karl Palsson <ka...@etactica.com>

Currently the loglevel is hardcoded to LOG_WARNING, even though there is
debug log messages.  Allow an env var to control the log threshold.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---
 src/odhcpd.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/src/odhcpd.c b/src/odhcpd.c
index 74830ac..c51cfa1 100644
--- a/src/odhcpd.c
+++ b/src/odhcpd.c
@@ -58,7 +58,21 @@ static void sighandler(_unused int signal)
 int main()
 {
openlog("odhcpd", LOG_PERROR | LOG_PID, LOG_DAEMON);
-   setlogmask(LOG_UPTO(LOG_WARNING));
+   char *env_log_level = getenv("ODHCPD_LOG_LEVEL");
+   int log_level = LOG_WARNING;
+   if (env_log_level) {
+   char *end;
+   errno = 0;
+   long temp = strtol(env_log_level, , 0);
+   if (end == env_log_level || *end != '\0'
+   || ((temp == LONG_MIN || temp == LONG_MAX) && errno == 
ERANGE)
+   || (log_level > LOG_DEBUG) || log_level < LOG_EMERG) {
+   syslog(LOG_ERR, "ODHCPD_LOG_LEVEL envvar was invalid");
+   } else {
+   log_level = temp;
+   }
+   }
+   setlogmask(LOG_UPTO(log_level));
uloop_init();
 
if (getuid() != 0) {
-- 
2.4.11


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] odhcpd: [PATCH 3/3] Respect interface "ignore" settings as documented.

[Karl Palsson]

From: Karl Palsson <ka...@etactica.com>

The "ignore" option is correctly loaded.  Actually observe it as
documented.

Signed-off-by: Karl Palsson <ka...@etactica.com>
---

 src/config.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/config.c b/src/config.c
index ef51112..a1b6ab7 100644
--- a/src/config.c
+++ b/src/config.c
@@ -695,10 +695,10 @@ void odhcpd_reload(void)
i->ndp = (master && master->ndp == 
RELAYD_RELAY) ?
RELAYD_RELAY : RELAYD_DISABLED;
 
-   setup_router_interface(i, true);
-   setup_dhcpv6_interface(i, true);
-   setup_ndp_interface(i, true);
-   setup_dhcpv4_interface(i, true);
+   setup_router_interface(i, !i->ignore);
+   setup_dhcpv6_interface(i, !i->ignore);
+   setup_ndp_interface(i, !i->ignore);
+   setup_dhcpv4_interface(i, !i->ignore);
} else {
close_interface(i);
}
-- 
2.4.11


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Documentation for router support means the famous Table of Hardware

[Karl Palsson]

Russell Senior <russ...@personaltelco.net> wrote:
>> [on making documentation changes only via pull requests]
>> 
> I want to push back on this a little bit. Jimmy Wales had
> similar ideas, once upon a time (see
> https://en.wikipedia.org/wiki/Nupedia), and he was proven
> wrong, empirically. The beauty of wikis is that people are
> empowered to contribute what they know. Without that
> empowerment, the vehicles for sharing what they know is much
> more scattered and diffused. Yes, wikis are a shit storm of
> inconsistency. If people want more consistency what is really
> needed is people to garden the manure into neat rows. I can't
> begin to count the vast utility I have derived from the
> steaming heaps of barely coherent crap that has been dumped
> into OpenWrt wiki. If you close that vehicle off, what you will
> end up with is a whole lot of nothing, which I argue is vastly
> worse.
> 
> If you want something that's pretty, hire someone to watch
> RecentChanges and clean stuff up. If the experts had the time
> and raw information to do it, we wouldn't be talking about
> this. The reality is that they don't. I argue for letting the
> rabble continue to contribute as they can. If you don't like
> what it looks like, that discomfort is trying to tell you what
> to do next: click the edit button and make it better.

I strongly support this. Doing documentation changes via git
pulls only is a _major_ obstacle. Vanishingly few people will
ever do minor corrections, and so few people already write major
new articles. And that's _before_ you find these magical
"reviewer" people to review documentation pulls!

I fully recognise that not all the information in the openwrt
wiki is correct or up to date, but that's why it has history
annotations saying when it was written, and with your reading
glasses on, you can get real useful information there, even if
it's often incomplete, or sometimes slightly wrong, or outdated.
People should be encouraged to edit more freely, not putting up
more steps in the way.

Sincerely,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/2] apm821xx: detect sd-card media changes for the WNDR4700

[Karl Palsson]

Christian Lamparter  wrote:
> The insertion or removal of the sd-card cannot be detected by
> the hardware itself. This is by design. To workaround this, for
> the WNDR4700 unload/load the dwc2 module in case the the
> special SD CARD GPIO line is low/high.

You want to bounce _all_ usb devices when the SD card is
inserted/removed? That sounds brutally intrusive! I've posted
before on the openwrt-devel list about the hard times I've had
with sd card detection before, also using a platform with a USB
card reader attached. Unless you can figure out how to get the in
kernel block detection working, (I could see it running scsi
probes, and getting responses changing when I inserted/removed
the SD card via usbmon, but couldn't it to reliably and stably
generate useful events [1]) or you run a userspace daemon, much
like udisks2 on gnome desktops, or something like
https://github.com/arduino/linino/tree/master/trunk/package/linino/uSDaemon

Even just the following works for detecting cards
inserted/removed. (It's rather more intrusive cpu wise than it
looks unfortunately, but at least it isn't bouncing the entire
USB system!) while true; do
block info > /dev/null
sleep 1; done

[1] I was working on 3.18, it's quite possible that the in kernel
block detection now works properly. see
/sys/block/sdXX/events_poll_msecs and try and hook events to
that.

Sincerely,
Karl P

> 
> Signed-off-by: Christian Lamparter 
> ---
>  target/linux/apm821xx/base-files/etc/rc.button/BTN_1 | 19 +++
>  target/linux/apm821xx/dts/wndr4700.dts   |  2 +-
>  2 files changed, 20 insertions(+), 1 deletion(-)
>  create mode 100755 target/linux/apm821xx/base-files/etc/rc.button/BTN_1
> 
> diff --git
> a/target/linux/apm821xx/base-files/etc/rc.button/BTN_1
> b/target/linux/apm821xx/base-files/etc/rc.button/BTN_1 new file
> mode 100755 index 000..9956412
> --- /dev/null
> +++ b/target/linux/apm821xx/base-files/etc/rc.button/BTN_1
> @@ -0,0 +1,19 @@
> +#!/bin/sh
> +
> +. /lib/functions.sh
> +. /lib/apm821xx.sh
> +
> +BOARD=$(apm821xx_board_name)
> +
> +if [ $BOARD == "wndr4700" ]; then
> + case "$ACTION" in
> + released)
> + rmmod dwc2
> + ;;
> + pressed)
> + modprobe dwc2
> + ;;
> + esac
> +fi
> +
> +return 0
> diff --git a/target/linux/apm821xx/dts/wndr4700.dts
> b/target/linux/apm821xx/dts/wndr4700.dts index 9a2ceb9..caaf05b
> 100644
> --- a/target/linux/apm821xx/dts/wndr4700.dts
> +++ b/target/linux/apm821xx/dts/wndr4700.dts
> @@ -432,7 +432,7 @@
>  
>   sdcard {
>   label = "SDCard inserted";
> - gpios = < 7 0>;
> + gpios = < 7 1>;
>   linux,code = <0x101>; /* BTN_1 */
>   };
>   };
> -- 
> 2.9.3
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] Use printf instead of echo.

[Karl Palsson]

Felix Fietkau  wrote:
> On 2016-08-23 12:10, A. Benz wrote:
> > Hi Bastian,
> > 
> > I will update them, however to do that while adhering to Felix's request 
> > on using perfect syntax means going over them one by one.
> > 
> > Perhaps a seasoned sed user can do a trick to automate it?
> > 
> > For now, the change I submitted is whats needed to fix breakage on my 
> > system. For others, I will send patches if no one takes it up in a few days.
> Actually, you might be able to simplify the change even more by
> forcing the hostapd build shell to bash (some other packages do
> this as well).

really?  Surely printf is better than requiring bash?

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] RFC: patches on cyassl/wolfssl openssl compatibility

[Karl Palsson]

While attempting to update libwebsockets to version 2.x, I ran into
the curious case of openssl compatiblity in wolfssl (nee cyassl)

Apparently "--with-stunnel" enables "the rest" of the openssl
compatibitility, bringing the compatibility up to v1.0.1.

As openssl is already at 1.0.1, it seems reasonable that the wolfssl
compatiblity should also be at a useful level.  Unfortunately, you
still need to explicitly check the wolfssl options at compile time to
_enable_ the compatibility.  Patches for ustream-ssl follow, patches for
libwebsockets are not pushed yet, as there's no point until this is resolved.
They're available in https://github.com/karlp/packages/commits/drafts/lws-v2.x
if anyone wants to look at them.

Note: I'm not actually a wolfssl/cyassl user, this just came about while
trying to bring forward cyassl support in libwebsockets, so if someone
understands the true intentions of wolfssl here, I'm all ears.

Sincerely,
Karl P


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

[Karl Palsson]

> Maybe some of it, but for more generic platforms, I am not sure
> sub-targets make sense, and in general, it is more difficult to
> edit those than to change a diffconfig as far as I can tell.

For who?  I'm pretty sure I can use "make menuconfig" _far_ more reliably than 
I can edit a diffconfig file to use a "buildme" script.  If I don't know 
anything, and _need_ to build a custom image that can't be built with image 
builder, or post install config, then menuconfig at least makes sure that 
dependencies get pulled in properly.  Adding line items to file that you then 
"defoncfig" and hope you got perfectt seems fraught with danger, and for what? 
To avoid showing someone how to use menuconfig?  Which they'll need to use 
anyway?  Because I don't believe for a _second_ that somehow you're going to 
have "buildme" magic that automatically solves all the configs someone needs.  

Sincerely,
Karl Palsson


signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.

[Karl Palsson]

Conor O'Gorman  wrote:
> 
> 
> On 03/06/16 13:27, Ben Greear wrote:
> >
> >
> > On 06/03/2016 02:17 AM, John Crispin wrote:
> >>
> >>
> >> On 01/06/2016 20:21, Ben Greear wrote:
> >>> On 06/01/2016 11:07 AM, John Crispin wrote:
>  Hi Ben,
> 
>  also inclined to reject this one. it will open up the pandoras box and
>  we will end up maintaining piles of diffconfig files. it would make
>  morse sense to document what the script does inside web.git as a 
>  "how to
>  build" or "getting started" page
> >>>
> >>> I do not have much history with LEDE/WRT, but is the diffconfig output
> >>> really that fragile?
> >>>
> >>> I will be willing to maintain the x86-64 and probably Ventana
> >>> diffconfigs, and even if it totally fails, you have not lost
> >>> any functionality since the main infrastructure is unchanged.
> >>
> >> for how long and will all the other people submitting these files also
> >> provide LTS ? normally activism fades after a few months. we can see
> >> this will board support and package maintenance. i think this will be a
> >> burden.
> >
> > Anything that makes it more easy for others to build images
> > should help bring in more newbies faster, which might keep the
> > activism going, especially for common platforms that will
> > constantly be getting new hardware (like x86-64).
> >
> > Currently, a newbie with an x86-64 board is going to have a slow
> > and frustrating time trying to get any sort of useful 'AP' built
> > from LEDE.  I think I can help to fix that problem if you will
> > let me.
> >
> > So, how about you accept a small number of diffconfig recipes, and the 
> > buildme
> > script, and then see how that works for a while.  I can update
> > buildme.sh to grab a diffconfig from a URL (using curl, or something)
> > and then folks wanting to provide out-of-tree diffconfigs need only
> > put their config in a public place and tell users how to use it:
> >
> > ./buildme.sh -T http://my.funkyplatform.com/board1
> >
> > Thanks,
> > Ben
> >
> This seems to duplicate the functionality of the sub-targets
> and profiles mechanism?


Also, image builder.


signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] _GNU_SOURCE should be defined for building vs uClibc

[Karl Palsson]

Waldemar Brodkorb  wrote:
> > 
> > This still doesn't work on the uclibc in openwrt-CC branch. The
> > O_PATH definitions are in asm-generic/fcntl.h, which can be
> > included via linux/fcntl.h, _GNU_SOURCE doesn't get this pulled
> > in though.
> > 
> > I attempted to add includes for linux/fcntl, but it just gives me
> > redeclaration errors for struct flock.
> 
> The definition where added to uClibc-ng after 1.0.9 release.
> LEDE included 1.0.14 recently. You need to update.
> 

I'm well aware that it would work if I was on living on the
bleeding edge of latest LEDE. [1] I'm just reporting that, up
until this O_PATH landed, procd fixes were still backportable to
the last _released_ version of openwrt/lede. (uclibc 0.9.33.2)
That is no longer the case.

Sincerely,
Karl P


[1] Everything always works, you just haven't pulled the latest!

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC v3 2/2] x86: use sysfs DMI information to populate sysinfo

[Karl Palsson]

Dirk Neukirchen  wrote:
> On 01.06.2016 17:14, Jo-Philipp Wich wrote:
> > Use the DMI data available in sysfs to extract manufacturer and model info
> > and write it to /tmp/sysinfo/.
> > 
> > The data will be picked up by board_detect and can be used by e.g. LuCI to
> > display a more appropriate model description.
> > 
> > On an APU board the files will contain the following values:
> > 
> > # cat /tmp/sysinfo/model
> > PC Engines APU
> > 
> > # cat /tmp/sysinfo/board_name
> > pc-engines-apu
> > 
> > Signed-off-by: Jo-Philipp Wich 
> > ---
> >  target/linux/x86/base-files/lib/preinit/20_sysinfo | 16 
> >  1 file changed, 16 insertions(+)
> >  create mode 100644 target/linux/x86/base-files/lib/preinit/20_sysinfo
> > 
> > diff --git a/target/linux/x86/base-files/lib/preinit/20_sysinfo 
> > b/target/linux/x86/base-files/lib/preinit/20_sysinfo
> > new file mode 100644
> > index 000..0b836ce
> > --- /dev/null
> > +++ b/target/linux/x86/base-files/lib/preinit/20_sysinfo
> > @@ -0,0 +1,16 @@
> > +do_sysinfo_x86() {
> > +   local vendor product boardname
> > +
> > +   vendor="$(cat /sys/devices/virtual/dmi/id/sys_vendor 2>/dev/null)"
> > +   product="$(cat /sys/devices/virtual/dmi/id/product_name 2>/dev/null)"
> > +
> > +   [ -n "$vendor" -a -n "$product" ] || return
> > +
> > +   boardname="$(printf "%s %s" "$vendor" "$product" | tr 'A-Z' 'a-z' | tr 
> > -cs 'a-z0-9_-' '-')"
> > +
> > +   mkdir -p /tmp/sysinfo
> > +   echo "$boardname" > /tmp/sysinfo/board_name
> > +   echo "$vendor $product" > /tmp/sysinfo/model
> 
> Issue 1:
> Maybe change up variable naming to keep more in line with
> sysfs/DMI standards ? as future reference: [1]
> 
> on my normal(?) Intel ATX motherboard both sysfs entries are
> empty but board_name & board_vendor exist: I might expect to
> get /tmp/sysinfo/board_name from board_* and not from the sys_*
> or product* domain
> 
> cat /sys/devices/virtual/dmi/id/board_vendor 
> Intel Corporation
> cat /sys/devices/virtual/dmi/id/board_name 
> DZ77RE-75K
> 

fwiw, my hp laptop (and a colleagues other, newer HP) has both
sys_vendor and product_name (and they're sane...)
sys_vendor:Hewlett-Packard (board_vendor also exists, and is the
same as sys_vendor) product_name:HP EliteBook 8470p

It also has board_name, but it's "useless" 
board_name:179B

I generally like the patch though, it seems like a clear
improvement, even if there turn out to be edge cases.

Cheers,
Karl P


signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] _GNU_SOURCE should be defined for building vs uClibc

[Karl Palsson]

John Crispin  wrote:
> 
> 
> On 23/05/2016 20:12, Waldemar Brodkorb wrote:
> > Hi John,
> > John Crispin wrote,
> > 
> >> Hi,
> >> is it really a gnu extension or is uclibc b0rked for these symbols ?
> > 
> > I think it isn't b0rked.
> > It was added for ARM GNU libc here under #ifdef __USE_GNU:
> > https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=sysdeps/unix/sysv/linux/arm/bits/fcntl.h;h=aa2d36ca80f0ca4c5793b28b3852ce60b5fe57ef;hp=6a5f89ad1f8bdf8a825fc1e55a84679a86349a6c;hb=adb252daea96e7e160553703d477b76ff6a7781e;hpb=01b5049d107460f5eca797eda983958d1a410ffd
> > 
> > And later moved to generic fcntl.h file. So we are correct here or
> > at least compatible to GNU libc.
> > 
> > best regards
> >  Waldemar
> >  
> 
> ok, i'll merge it later today or in the morning
> 

This still doesn't work on the uclibc in openwrt-CC branch. The
O_PATH definitions are in asm-generic/fcntl.h, which can be
included via linux/fcntl.h, _GNU_SOURCE doesn't get this pulled
in though.

I attempted to add includes for linux/fcntl, but it just gives me
redeclaration errors for struct flock.

Cheers,
Karl P

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC 03/12] ath25: register button actions through board.d

[Karl Palsson]

Given that the existing default button handler didn't actually do
anything, I think it furthers the argument that they can just be
dropped entirely.

Jo-Philipp Wich  wrote:
> Register button actions through board.d and drop corresponding
> config sections from the /etc/config/system template.
> 
> Also rename `01_leds` to `01_system` now that it is doing more
> than just adding an led entry.
> 
> Signed-off-by: Jo-Philipp Wich 
> 
>  delete mode 100755 target/linux/ath25/base-files/etc/board.d/01_leds
>  create mode 100755 target/linux/ath25/base-files/etc/board.d/01_system
> 
> diff --git a/target/linux/ath25/base-files/etc/board.d/01_leds
> b/target/linux/ath25/base-files/etc/board.d/01_leds deleted
> file mode 100755 index e6ab4a7..000
> --- a/target/linux/ath25/base-files/etc/board.d/01_leds
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -#!/bin/sh
> -# Copyright 2012-2015 OpenWrt.org
> -#
> -
> -. /lib/functions/uci-defaults.sh
> -
> -board_config_update
> -
> -ucidef_set_led_netdev "wlan" "wlan" "wlan" "wlan0"
> -
> -board_config_flush
> -
> -exit 0
> diff --git
> a/target/linux/ath25/base-files/etc/board.d/01_system
> b/target/linux/ath25/base-files/etc/board.d/01_system new file
> mode 100755 index 000..eac16b5
> --- /dev/null
> +++ b/target/linux/ath25/base-files/etc/board.d/01_system
> @@ -0,0 +1,16 @@
> +#!/bin/sh
> +# Copyright 2012-2015 OpenWrt.org
> +#
> +
> +. /lib/functions/uci-defaults.sh
> +
> +board_config_update
> +
> +ucidef_set_led_netdev "wlan" "wlan" "wlan" "wlan0"
> +
> +ucidef_add_button "shortreset" "reset" "released" "logger
> reboot" "0" "4" +ucidef_add_button "longreset" "reset"
> "released" "logger factory default" "5" "30"
> +
> +board_config_flush
> +
> +exit 0
> diff --git a/target/linux/ath25/base-files/etc/config/system
> b/target/linux/ath25/base-files/etc/config/system index
> 1d29ad8..0834b52 100644
> --- a/target/linux/ath25/base-files/etc/config/system
> +++ b/target/linux/ath25/base-files/etc/config/system
> @@ -7,17 +7,3 @@ config timeserver ntp
>   list server 1.openwrt.pool.ntp.org
>   list server 2.openwrt.pool.ntp.org
>   list server 3.openwrt.pool.ntp.org
> -
> -config button
> - option button   reset
> - option action   released
> - option handler  "logger reboot"
> - option min  0
> - option max  4
> -
> -config button
> - option button   reset
> - option action   released
> - option handler  "logger factory default"
> - option min  5
> - option max  30
> -- 
> 2.1.4
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] TR-069 for OpenWrt

[Karl Palsson]

David Lang  wrote:
> On Thu, 26 May 2016, Delbar Jos wrote:
> 
> > We are conscious of the fact that together with the proposals made by 
> > Felix, 
> > Luka and Wojtek we are now looking at many "competing" proposals. As a next 
> > step, we recommend to organize a workshop, at a practical location and 
> > time, 
> > where we put everything on the table and define the most appropriate path 
> > forward to the benefit of OpenWrt as a whole.
> 
> nothing wrong with supporting many different remote management
> daemons.
> 
> > TR-069 is a complicated remote management system and in order to make this 
> > initiative a success, we must ensure that the complexity is handled in an 
> > elegant way and with respect for OpenWrt's core architecture. More than on 
> > the 
> > protocol itself, we believe that we should focus on the architectural 
> > enhancements required to support remote management in general.
> 
> What is it that you think is needed to "support remote
> management in general"?
> 
> It's worth pointing out that many people are remotely managing
> OpenWRT devices, Ansible/Salt/Puppet/Chef/etc are all common
> tools for the job.

Really?  python, python, ruby, ruby.  None of those are really fun enjoyable 
tasks on _my_ openwrt/leded devices.  

> now, those are all tools aimed at managing Linux Servers, not
> networking gear, but OpenWRT is a server.
> 
> So I'd suggest starting off by creating a daemon that talks
>  and just stores the stuff it's sent in some
> simple files so that it can return the info when queried.

Did you read the intro to Delbar's mail, describing that they
already have a complete tr069 project, for managing openwrt
devices, that they want to open source, and want to collaborate
on making it more useful for all, and perhaps see if there are
common pain points that can be resolved by handling things
differently on the lede/openwrt side, rather than working around
on the tr069 side?

I think it's exciting and I'd love to hear more about it.
ansible/salt/puppet/chef have been far too heavy to run, and
openvpn servers granting remote shell access is far too tedious
for daily use.

Cheers,
Karl P

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] uci-lua: error checking problems

[Karl Palsson]

When using the lua binding for UCI, there's cases where failures
aren't properly propagating to the lua caller environment.

eg: (Starting from an empty file)

root@blah:/# lua
Lua 5.1.5 Copyright (C) 1994-2012 Lua.org, PUC-Rio (double int32)
> uci = require("uci")
> x = uci.cursor()
> =x:set("unknown", "unused", "someoption", "somevalue")
true   << lies!
> =x:save("unknown")
true  << more lies!
> =x:commit("unknown")
true  << redundant lies!
> 
root@blah:/# uci show unknown
root@blah:/# ^^ hah! 

In this particular case, the problem is that "err =
UCI_ERR_INVAL" should be "ctx->err = UCI_ERR_INVAL" however this
turns out to be a prevalent problem across the lua binding.

http://git.openwrt.org/?p=project/uci.git;a=blob;f=lua/uci.c;h=47d59c883ab9320b39304fdd46297576c3550fa1;hb=HEAD#l613

Options are some global replacing, or overhauling how the general
utility functions handle codes like this.

"Filed" as an email, as this is too big to fix in a few minutes
on IRC

Cheers,
Karl P

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] [ubox] logd: add ubus reload method

[Karl Palsson]

Alexandru Ardelean <ardeleana...@gmail.com> wrote:
> On Thu, May 12, 2016 at 5:30 PM, Karl Palsson
> <ka...@tweak.net.au> wrote:
> 
> >
> > Dan Bugnar <danut...@gmail.com> wrote:
> > > From: Dan Bugnar <danut...@gmail.com>
> > >
> > > Add logd link to uci library, to read the system config file
> > > and get the buffer size. Remove the -S option support and use
> > > just the option from the config file.
> >
> >
> > Why do you need this exactly? It's already being parsed from the
> > config file by the init script, and that is much less code than
> > adding all of uci parsing into logd?
> >
> >
> Doing a reload on logd (to increase the buffer size), should
> not clear out the previous log info. By default logd's reload,
> is a logd restart. The end game is to do a proper reload, and
> keep whatever info was logged, before the reload (if doing a
> log buffer increase).

And that's something that you want to do, at run time, often
enough that you want to add config file parsing to it? I mean,
ok, I understand what you're saying, but is that really a useful
usecase? changing log size dynamically?

Cheers,
Karl P


signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] [ubox] logd: add ubus reload method

[Karl Palsson]

Dan Bugnar  wrote:
> From: Dan Bugnar 
> 
> Add logd link to uci library, to read the system config file
> and get the buffer size. Remove the -S option support and use
> just the option from the config file.


Why do you need this exactly? It's already being parsed from the
config file by the init script, and that is much less code than
adding all of uci parsing into logd?

Cheers,
Karl P

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev