Re: [LEDE-DEV] [wiki]Wiki structure proposals and some questions

2016-09-29 Thread Thomas Endt 
> Also, it would be cool to get email notifications about any page
> modification to pages I subscribed or have chosen somehow too, I didn't
> find anything to set that.

You now find an additional button on top of the page "manage subscriptions".

Good for now, but needs some attention regarding the downsides mentioned
here:
https://www.dokuwiki.org/subscription#enabling_subscriptions


Regards,
Thomas


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

Re: [LEDE-DEV] [OpenWrt] [OpenWrt-Users] OpenWrt Summit Nearing Capacity; please register soon!

2016-09-29 Thread Eric Schultz 
Ben,

Yes, there will be live streaming of the event! We'll have the links to
the streams posted on http://openwrtsummit.org
 prior to the event. The streams will also be
saved on Youtube for those who can't watch them live.

Thanks,

Eric

On 09/29/2016 07:43 AM, Benjamin Henrion wrote:
> On Wed, Sep 21, 2016 at 8:53 PM, Eric Schultz
>  wrote:
>> I'm excited to let folks know that the response to OpenWrt Summit has
>> been very strong; we currently have over 170 registrations. If you've
>> already registered, thank you so much! If you're interested in attending
>> but haven't registered yet, please do so as soon as possible. Depending
>> on demand this week, we may be forced to close registrations very soon.
>>
>> To register or find out more about OpenWrt Summit, please visit
>> http://openwrtsummit.org
> Is there any streaming foreseen?
>
> Best,
>
> --
> Benjamin Henrion 
> FFII Brussels - +32-484-566109 - +32-2-3500762
> "In July 2005, after several failed attempts to legalise software
> patents in Europe, the patent establishment changed its strategy.
> Instead of explicitly seeking to sanction the patentability of
> software, they are now seeking to create a central European patent
> court, which would establish and enforce patentability rules in their
> favor, without any possibility of correction by competing courts or
> democratically elected legislators."
> ___
> OpenWrt mailing list
> open...@lists.prplfoundation.org
> http://lists.prplfoundation.org/cgi-bin/mailman/listinfo/openwrt


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

Re: [LEDE-DEV] [wiki]Wiki structure proposals and some questions

2016-09-29 Thread Alberto Bursi 
Good, thanks. :)

I'll make a mockup of the pages I want to make in the playground with 
images, and re-arrange other pages outside as I proposed.

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

Re: [LEDE-DEV] [wiki]Wiki structure proposals and some questions

2016-09-29 Thread Thomas Endt 
> > Structure:
> > I was thinking about dividing the wiki in five main pages 
[...]

> Looks good to time, maybe Thomas has also comments on that?

Just go ahead and show something.
Playground for temporary presentations: 
https://wiki.lede-project.org/playground:playground

> > Also I'd like to have the “hardware support” page to have the devices
> divided by most likely usecase

Like "show me all modems"?
https://wiki.openwrt.org/toh/views/toh_minimal_all?dataflt%5B0%5D=device%20type_%3DModem

Regards,
Thomas


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

[LEDE-DEV] [PATCH] base-files: remove non-working filter option for wifi detect

2016-09-29 Thread Christian Lamparter 
This patch removes the non-working wifi driver filter for
the wifi detection script.

I figured that rather than replacing ${2:-$DRIVERS} with
${1:-$DRIVERS}, it would be better to remove it. Nobody
needed it in the previous years.

Signed-off-by: Christian Lamparter 
---
 package/base-files/files/sbin/wifi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/base-files/files/sbin/wifi 
b/package/base-files/files/sbin/wifi
index 2476414..6bd3544 100755
--- a/package/base-files/files/sbin/wifi
+++ b/package/base-files/files/sbin/wifi
@@ -146,7 +146,7 @@ wifi_reload() {
 }
 
 wifi_detect() {
-   for driver in ${2:-$DRIVERS}; do (
+   for driver in $DRIVERS; do (
if eval "type detect_$driver" 2>/dev/null >/dev/null; then
eval "detect_$driver" || echo "$driver: Detect failed" 
>&2
else
@@ -227,7 +227,7 @@ scan_wifi
 
 case "$1" in
down) wifi_updown "disable" "$2";;
-   detect) wifi_detect "$2";;
+   detect) wifi_detect ;;
status) ubus_wifi_cmd "status" "$2";;
reload) wifi_reload "$2";;
reload_legacy) wifi_reload_legacy "$2";;
-- 
2.9.3


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

Re: [LEDE-DEV] [wiki]Wiki structure proposals and some questions

2016-09-29 Thread Thomas Endt 
> I recently posted in the discussion page of the todo page of the wiki.
> https://wiki.lede-project.org/talk:to_do_list

> Now, apart from that I'd like to note that while I can get a nice
> forum-like interface where I cal also select if I want to get emails to
> notify answers when it's my first post in a discussion page

I implemented a more comfortable way for discussions.
See the above link.


> Also, it would be cool to get email notifications about any page
> modification to pages I subscribed or have chosen somehow too, I didn't
> find anything to set that.

dokuwiki is RSS capable, however, I havn't done anything yet with RSS.
I'll check this out.

Regards, Thomas


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

[LEDE-DEV] ubus rpcd plugins

2016-09-29 Thread 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

Re: [LEDE-DEV] [wiki]Wiki structure proposals and some questions

2016-09-29 Thread Alberto Bursi 

On 09/29/2016 01:49 PM, Martin Tippmann wrote:
> Not sure if that's a good idea and better than a list because it's
> effort to maintain, would be cool if these pages could be a "fallout"
> of a category in the table of hardware and be generated and updated
> from a single source.

The main point is that it improves awareness, while using the wiki to 
get at their device page, people will see that LEDE supports A, B and C 
category of devices.

It also helps convey that LEDE isn't just for routers, and in a 
(hopeful) future you might have people that don't come on the wiki for a 
router (or even not for a nas), so splitting the bigger categories is 
good imho.

While there will also be a "search the ToH" page for those that want to 
search stuff.

Adding the category to the ToH would also be a good idea as people 
coming to look for a NAS (or anything that isn't a router) currently 
don't have much choice than reading through a table filtered by giga eth 
and whatever.

And as you said all this is easy to auto-generate/update if you add 
device category field in the ToH.
>> The general idea is making something like NasCentral wiki (they do it with 
>> brands and make sub-wikis with a different hostname, I'm not asking to make 
>> subwikis here) http://www.nas-central.org/wiki/Main_Page
> I personally don't think that this approach would work well for LEDE -
> the default setup is the same for all models and hardware details are
> mostly abstracted away and not model specific. Maybe it's useful to
> group documentation for NAS like hardware into the same namespace or
> something like that but the overall idea is IMHO that you can do what
> you want with the router, or maybe I'm did not fully understand you
> here.

I was talking of layout/esthetics.
I wanted to make a general "LEDE supported hardware" page with images of 
all categories of devices (a generic router, a NAS, a wifi audio box 
thingy, a devboard and so on), and when people click on that they land 
in a page with a list of all the devices in that category.

No brands as we don't deal with brands, just dividing by device type.
I used NAScentral wiki as an example of layout, as you see their main 
page is like that (but with brand symbols).

We could have the LEDE logo in the middle and all images of supported 
device categories around it, like them.

> But there are already a lot of wonderful and great router icons here:
> https://github.com/Moorviper/Freifunk-Router-Anleitungen/wiki  maybe
> these could be used and build upon.

wow. :) They are sure nice, but I'd say "having a proper standardized 
image for all supported hardware" is not crucial for now.

>
> I'm a little late (sorry) but I hope we soon have a staging wiki were
> we can experiment and setup different ideas without breaking stuff.

Well, good for the future.

But currently the wiki is little more than an empty stub, I can always 
try to put down a skeleton of what I'm proposing and if you don't like 
it I'll roll back to current stub state.

>>> Now, apart from that I'd like to note that while I can get a nice
>>> forum-like interface where I cal also select if I want to get emails
>>> to notify answers when it's my first post in a discussion page, on
>>> that page I seem to get only the generic wiki editing interface.
> I guess if there is a DokuWiki plugin for that it's possible. I'll look into 
> it.
>
>>> Also, it would be cool to get email notifications about any page
>>> modification to pages I subscribed or have chosen somehow too, I
>>> didn't find anything to set that.
> Again, I guess we have to resort to a plugin here - and it should
> probably not be the default to receive mails.
>
Thanks, these are crucial features for a modern wiki, most would-be 
contributors will expect them to be there and working.

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

[LEDE-DEV] [PATCH 2/2] uci/lua: add explicit close() method

2016-09-29 Thread Dirk Feytons 
This allows a caller to explicitly free the cursor as soon as it is
no longer needed instead of having to wait for the garbage collector.

Signed-off-by: Dirk Feytons 
---
 lua/uci.c |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/lua/uci.c b/lua/uci.c
index ddb9c5c..22055cb 100644
--- a/lua/uci.c
+++ b/lua/uci.c
@@ -933,8 +933,19 @@ uci_lua_list_configs(lua_State *L)
 static int
 uci_lua_gc(lua_State *L)
 {
-   struct uci_context *ctx = find_context(L, NULL);
-   uci_free_context(ctx);
+   struct uci_context **ctx;
+
+   if (!lua_isuserdata(L, 1)) {
+   if (!global_ctx)
+   return 0;
+   ctx = _ctx;
+   } else {
+   ctx = luaL_checkudata(L, 1, METANAME);
+   if (!*ctx)
+   return 0;
+   }
+   uci_free_context(*ctx);
+   *ctx = NULL;
return 0;
 }
 
@@ -970,6 +981,7 @@ uci_lua_cursor(lua_State *L)
 
 static const luaL_Reg uci[] = {
{ "__gc", uci_lua_gc },
+   { "close", uci_lua_gc },
{ "cursor", uci_lua_cursor },
{ "load", uci_lua_load },
{ "unload", uci_lua_unload },
-- 
1.7.9.5


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

[LEDE-DEV] [PATCH 1/2] uci/lua: add list_configs() function

2016-09-29 Thread Dirk Feytons 
Returns an array with all the available configs.

Signed-off-by: Dirk Feytons 
---
 lua/uci.c |   21 +
 1 file changed, 21 insertions(+)

diff --git a/lua/uci.c b/lua/uci.c
index 47d59c8..ddb9c5c 100644
--- a/lua/uci.c
+++ b/lua/uci.c
@@ -911,6 +911,26 @@ uci_lua_set_savedir(lua_State *L)
 }
 
 static int
+uci_lua_list_configs(lua_State *L)
+{
+   struct uci_context *ctx;
+   char **configs = NULL;
+   char **ptr;
+   int i = 1;
+
+   ctx = find_context(L, NULL);
+   if ((uci_list_configs(ctx, ) != UCI_OK) || !configs)
+   return uci_push_status(L, ctx, false);
+   lua_newtable(L);
+   for (ptr = configs; *ptr; ptr++) {
+   lua_pushstring(L, *ptr);
+   lua_rawseti(L, -2, i++);
+   }
+   free(configs);
+   return 1;
+}
+
+static int
 uci_lua_gc(lua_State *L)
 {
struct uci_context *ctx = find_context(L, NULL);
@@ -971,6 +991,7 @@ static const luaL_Reg uci[] = {
{ "set_confdir", uci_lua_set_confdir },
{ "get_savedir", uci_lua_get_savedir },
{ "set_savedir", uci_lua_set_savedir },
+   { "list_configs", uci_lua_list_configs },
{ NULL, NULL },
 };
 
-- 
1.7.9.5


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

Re: [LEDE-DEV] [OpenWrt-Users] OpenWrt Summit Nearing Capacity; please register soon!

2016-09-29 Thread Benjamin Henrion 
On Wed, Sep 21, 2016 at 8:53 PM, Eric Schultz
 wrote:
> I'm excited to let folks know that the response to OpenWrt Summit has
> been very strong; we currently have over 170 registrations. If you've
> already registered, thank you so much! If you're interested in attending
> but haven't registered yet, please do so as soon as possible. Depending
> on demand this week, we may be forced to close registrations very soon.
>
> To register or find out more about OpenWrt Summit, please visit
> http://openwrtsummit.org

Is there any streaming foreseen?

Best,

--
Benjamin Henrion 
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

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

Re: [LEDE-DEV] [wiki]Wiki structure proposals and some questions

2016-09-29 Thread Martin Tippmann 
Hi,

> On 09/28/2016 05:51 PM, Alberto Bursi wrote:
>> I recently posted in the discussion page of the todo page of the wiki.
>> https://wiki.lede-project.org/talk:to_do_list

I quote that here and add my personal thoughts/opinion:

> Structure:
> I was thinking about dividing the wiki in five main pages (names not final): 
> “LEDE info” (links to forums, mailing list, contacts, copies of their 
> meeting's transcripts, and any LEDE-related information that does not relate 
> directly to the firmware and the hardware) “this wiki” (where we have the 
> wiki rules, the TODO and other wiki-related information) 
> “installation/configuration” (of LEDE and of packages), “developer 
> documentation” (where info about how things are supposed to work currently, 
> and how to make your own firmware), and last but not least “supported 
> hardware” (with ToH and all that). Then all other things are children of 
> these pages, for example in the “installation/configuration” you will find 
> “downloading” “installation” “basic configuration” “advanced configuration”. 
> Under “first time configuration” you can find all topics that matter to get 
> the router up and running in a simple home network, under “advanced 
> configuration” you find all topics for configuring everything else. And so on 
> and so forth.

Looks good to time, maybe Thomas has also comments on that?

> Also I'd like to have the “hardware support” page to have the devices divided 
> by most likely usecase, for example the obvious biggest category is the one 
> about “routers”, but also one about NAS devices (most Kirkwood-based devices 
> are NAS, not routers for example and LEDE supports only a fraction of those 
> out in the wild), a page about wifi music streamers (there are a few 
> supported), a page about dev boards, and so on. I'd like to have only very 
> odd stuff in the “miscellaneous” category.

Not sure if that's a good idea and better than a list because it's
effort to maintain, would be cool if these pages could be a "fallout"
of a category in the table of hardware and be generated and updated
from a single source.

> The general idea is making something like NasCentral wiki (they do it with 
> brands and make sub-wikis with a different hostname, I'm not asking to make 
> subwikis here) http://www.nas-central.org/wiki/Main_Page

I personally don't think that this approach would work well for LEDE -
the default setup is the same for all models and hardware details are
mostly abstracted away and not model specific. Maybe it's useful to
group documentation for NAS like hardware into the same namespace or
something like that but the overall idea is IMHO that you can do what
you want with the router, or maybe I'm did not fully understand you
here.

But there are already a lot of wonderful and great router icons here:
https://github.com/Moorviper/Freifunk-Router-Anleitungen/wiki  maybe
these could be used and build upon.

I'm a little late (sorry) but I hope we soon have a staging wiki were
we can experiment and setup different ideas without breaking stuff.

>> Now, apart from that I'd like to note that while I can get a nice
>> forum-like interface where I cal also select if I want to get emails
>> to notify answers when it's my first post in a discussion page, on
>> that page I seem to get only the generic wiki editing interface.

I guess if there is a DokuWiki plugin for that it's possible. I'll look into it.

>> Also, it would be cool to get email notifications about any page
>> modification to pages I subscribed or have chosen somehow too, I
>> didn't find anything to set that.

Again, I guess we have to resort to a plugin here - and it should
probably not be the default to receive mails.

regards
Martin

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

[LEDE-DEV] Wiki structure proposals and some questions

2016-09-29 Thread Alberto Bursi 
I recently posted in the discussion page of the todo page of the wiki.

https://wiki.lede-project.org/talk:to_do_list

Now, apart from that I'd like to note that while I can get a nice
forum-like interface where I cal also select if I want to get emails to
notify answers when it's my first post in a discussion page, on that
page I seem to get only the generic wiki editing interface.

Also, it would be cool to get email notifications about any page
modification to pages I subscribed or have chosen somehow too, I didn't
find anything to set that.

-Alberto


p.s. why if I add the [wiki] tag in the subject I get a message that my mail
  looks suspicious and that it is awaiting moderation?


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

Re: [LEDE-DEV] [wiki]Wiki structure proposals and some questions

2016-09-29 Thread Jo-Philipp Wich 
Hi Alberto,

your mail was rejected because it contained headers indicating a reply
to another mail without having a "Re:" in the header.

This usually happens if you randomly reply to a mail in the list and
then delete subject & body to write a new message.

I manually accepted those mails for now.

~ Jo

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

Re: [LEDE-DEV] [wiki]Wiki structure proposals and some questions

2016-09-29 Thread Alberto Bursi 
Hmm, I'm on OpenSUSE and I'm using Thunderbird so if it's Microsoft 
that's happening server-side.

If it keeps happening I'll switch to my gmail account, but seriously, I 
am disappointed.

-Alberto


On 09/29/2016 09:56 AM, John Crispin wrote:
> it seems to have been rejected with "Message has a suspicious header" i
> am assuming that microsoft is adding weird headers to your mails.
>
>   John
>
> On 29/09/2016 09:47, Alberto Bursi wrote:
>> I sent this yesterday and it is still waiting "moderator approval".
>>
>>
>> On 09/28/2016 05:51 PM, Alberto Bursi wrote:
>>> I recently posted in the discussion page of the todo page of the wiki.
>>> https://wiki.lede-project.org/talk:to_do_list
>>>
>>> Now, apart from that I'd like to note that while I can get a nice
>>> forum-like interface where I cal also select if I want to get emails
>>> to notify answers when it's my first post in a discussion page, on
>>> that page I seem to get only the generic wiki editing interface.
>>>
>>> Also, it would be cool to get email notifications about any page
>>> modification to pages I subscribed or have chosen somehow too, I
>>> didn't find anything to set that.
>>>
>>> -Alberto
>>
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


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

[LEDE-DEV] Discussion of FHS and /srv vs /usr/var for packages feed

2016-09-29 Thread Daniel Dickinson 
Hi all,

Most of you are probably unaware of the following discussion
https://github.com/openwrt/packages/pull/3059 in which, in the context
of postfix specifically, but touching on what should be the policy for
the packages feed in general, it is discussed what is considered a
reasonable way to handle packages that normally use persistent data
in /var for FHS reasons, but which cannot on OpenWrt/LEDE due to /var
being a symlink to /tmp in the default arrangemnt.

One suggestion that I think makes the most sense is to use the normal
package /var location and make sure the user is made aware of the lack
of persistence, unless they take measure to change it.

Making it persistent by default is less to preferred, IMO, because the
reason for the /var symlink is flash wear and that doesn't change
because of a packages requirements, and users should be made aware that
they need either change their plan, or at least consider the impact of
what they are doing.

What think ye?

Regards,

Daniel

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

Re: [LEDE-DEV] Patches to web

2016-09-29 Thread Syrone Wong 
You can add prefix when doing "git format-patch" and send it to the
list. Check the output before sending is a good idea if you don't want
to make mistakes.


Best Regards,
Syrone Wong


On Thu, Sep 29, 2016 at 10:26 AM, Marvin Arnold  wrote:
> I'd like to make a small pull-request to the `web` repo. But I don't
> quite understand the instructions online.
>
> From what I can tell, I should send something with a subject like 'web:
> Instructions for architecture discovery' and a body generated by
> something like https://git-scm.com/docs/diff-generate-patch to this list.
>
> https://github.com/marvinmarnold/web/commit/d44fe3bc6f020e4b585d01bf40346b24e8536403
>
>
> Thanks,
>
> marvin
>
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

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

Re: [LEDE-DEV] The procd daemon does not handle correctly the instances

2016-09-29 Thread John Crispin 
yep, saw that while looking at the procd code this morning.

On 29/09/2016 10:36, Lebleu Pierre wrote:
> In fact, the code already exists for the method "add".
> 
> When we call the method "set", it does a vlist_update(), instance_add() and 
> then vlist_flush().
> 
> For the method "add", it only update the PID as you said so.
> 
> I just purpose to call the method "add" rather than "set" when we specify the 
> instance.
> 
> 
> Pierre
> 
> -Original Message-
> From: John Crispin [mailto:j...@phrozen.org] 
> Sent: donderdag 29 september 2016 7:43
> To: Lebleu Pierre ; 
> lede-dev@lists.infradead.org
> Subject: Re: [LEDE-DEV] The procd daemon does not handle correctly the 
> instances
> 
> this might actually be solvable int he scripts, will need to take a closer 
> look today
> 
>   John
> 
> On 29/09/2016 07:20, John Crispin wrote:
>> procd uses a vlist to store instances in. if oe changes all are 
>> restarted. we need to change this as per my last mail to only restart 
>> those that actually changed.
>>
>>  John
>>
>> On 28/09/2016 15:44, Lebleu Pierre wrote:
>>> Hi,
>>>
>>> Thank you for your answer.
>>>
>>> First, I am going to clarify a little bit what I am trying to do.
>>>
>>> I would like to have more than one instance for a given daemon (here, 
>>> dnsmasq).
>>> I would like to stop one instance when I need.
>>> I would like to start one instance without stopping the other one.
>>>
>>> root@LEDE:~# ps w | grep dnsmasq
>>> 11633 dnsmasq   1560 S/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.main 
>>> -k -x /var/run/dnsmasq/dnsmasq.main.pid
>>> 11634 dnsmasq   1556 S/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.second 
>>> -k -x /var/run/dnsmasq/dnsmasq.second.pid
>>> 11636 root  1556 S/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.main 
>>> -k -x /var/run/dnsmasq/dnsmasq.main.pid
>>> 11660 root  1712 Rgrep dnsmasq
>>> root@LEDE:~# /etc/init.d/dnsmasq start main root@LEDE:~# ps w | grep 
>>> dnsmasq
>>> 11633 dnsmasq   1560 S/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.main 
>>> -k -x /var/run/dnsmasq/dnsmasq.main.pid
>>> 11636 root  1556 S/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.main 
>>> -k -x /var/run/dnsmasq/dnsmasq.main.pid
>>> 11715 root  1712 Rgrep dnsmasq
>>> root@LEDE:~# /etc/init.d/dnsmasq start second root@LEDE:~# ps w | 
>>> grep dnsmasq
>>> 11753 dnsmasq   1556 S/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.second 
>>> -k -x /var/run/dnsmasq/dnsmasq.second.pid
>>> 11757 root  1712 Rgrep dnsmasq
>>>
>>> As you can see, when I want to start the second instance : it starts it but 
>>> it also kills the first instance...
>>>
>>> I had a look at the procd code and it seems it does not flush the other 
>>> instance if we call the method "add". Am I right ?
>>>
>>> Regarding the procd.sh file, it seems there is a lack of something. Indeed, 
>>> we can call "stop myinstance" but we can't call "start myinstance".
>>>
>>> Here, please find my modification :
>>>
>>> diff --git a/package/base-files/files/etc/rc.common 
>>> b/package/base-files/files/etc/rc.common
>>> index e0de073..8cc6e69 100755
>>> --- a/package/base-files/files/etc/rc.common
>>> +++ b/package/base-files/files/etc/rc.common
>>> @@ -102,9 +102,11 @@ ${INIT_TRACE:+set -x}
>>> . $IPKG_INSTROOT/lib/functions/procd.sh
>>> basescript=$(readlink "$initscript")
>>> rc_procd() {
>>> +   local method="set"
>>> +   [ -n "$2" ] && method="add"
>>> procd_open_service "$(basename ${basescript:-$initscript})" 
>>> "$initscript"
>>> "$@"
>>> -   procd_close_service
>>> +   procd_close_service $method
>>> }
>>>  
>>> start() {
>>> diff --git a/package/system/procd/files/procd.sh 
>>> b/package/system/procd/files/procd.sh
>>> index fa6f8a9..1af9c7b 100644
>>> --- a/package/system/procd/files/procd.sh
>>> +++ b/package/system/procd/files/procd.sh
>>> @@ -72,11 +72,15 @@ _procd_open_service() {  }
>>>  
>>>  _procd_close_service() {
>>> +   local method="set"
>>> +   [ -n "$1" ] && method="$1"
>>> +
>>> json_close_object
>>> _procd_open_trigger
>>> service_triggers
>>> _procd_close_trigger
>>> -   _procd_ubus_call set
>>> +
>>> +   _procd_ubus_call $method
>>>  }
>>>  
>>>  _procd_add_array_data() {
>>>
>>>
>>> With this patch, it seems to work.
>>>
>>> Pierre
>>> -Original Message-
>>> From: John Crispin [mailto:j...@phrozen.org]
>>> Sent: dinsdag 27 september 2016 17:48
>>> To: Lebleu Pierre ; 
>>> lede-dev@lists.infradead.org
>>> Subject: Re: [LEDE-DEV] The procd daemon does not handle correctly 
>>> the instances
>>>
>>>
>>>
>>> On 27/09/2016 17:34, Lebleu Pierre wrote:
 Hi all,

 I found a bug in the daemon process management. Indeed, when we have 
 several instances of one daemon such as "dnsmasq" and we want to restart 
 only one

Re: [LEDE-DEV] The procd daemon does not handle correctly the instances

2016-09-29 Thread Lebleu Pierre 
In fact, the code already exists for the method "add".

When we call the method "set", it does a vlist_update(), instance_add() and 
then vlist_flush().

For the method "add", it only update the PID as you said so.

I just purpose to call the method "add" rather than "set" when we specify the 
instance.


Pierre

-Original Message-
From: John Crispin [mailto:j...@phrozen.org] 
Sent: donderdag 29 september 2016 7:43
To: Lebleu Pierre ; lede-dev@lists.infradead.org
Subject: Re: [LEDE-DEV] The procd daemon does not handle correctly the instances

this might actually be solvable int he scripts, will need to take a closer look 
today

John

On 29/09/2016 07:20, John Crispin wrote:
> procd uses a vlist to store instances in. if oe changes all are 
> restarted. we need to change this as per my last mail to only restart 
> those that actually changed.
> 
>   John
> 
> On 28/09/2016 15:44, Lebleu Pierre wrote:
>> Hi,
>>
>> Thank you for your answer.
>>
>> First, I am going to clarify a little bit what I am trying to do.
>>
>> I would like to have more than one instance for a given daemon (here, 
>> dnsmasq).
>> I would like to stop one instance when I need.
>> I would like to start one instance without stopping the other one.
>>
>> root@LEDE:~# ps w | grep dnsmasq
>> 11633 dnsmasq   1560 S/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.main -k 
>> -x /var/run/dnsmasq/dnsmasq.main.pid
>> 11634 dnsmasq   1556 S/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.second 
>> -k -x /var/run/dnsmasq/dnsmasq.second.pid
>> 11636 root  1556 S/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.main -k 
>> -x /var/run/dnsmasq/dnsmasq.main.pid
>> 11660 root  1712 Rgrep dnsmasq
>> root@LEDE:~# /etc/init.d/dnsmasq start main root@LEDE:~# ps w | grep 
>> dnsmasq
>> 11633 dnsmasq   1560 S/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.main -k 
>> -x /var/run/dnsmasq/dnsmasq.main.pid
>> 11636 root  1556 S/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.main -k 
>> -x /var/run/dnsmasq/dnsmasq.main.pid
>> 11715 root  1712 Rgrep dnsmasq
>> root@LEDE:~# /etc/init.d/dnsmasq start second root@LEDE:~# ps w | 
>> grep dnsmasq
>> 11753 dnsmasq   1556 S/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.second 
>> -k -x /var/run/dnsmasq/dnsmasq.second.pid
>> 11757 root  1712 Rgrep dnsmasq
>>
>> As you can see, when I want to start the second instance : it starts it but 
>> it also kills the first instance...
>>
>> I had a look at the procd code and it seems it does not flush the other 
>> instance if we call the method "add". Am I right ?
>>
>> Regarding the procd.sh file, it seems there is a lack of something. Indeed, 
>> we can call "stop myinstance" but we can't call "start myinstance".
>>
>> Here, please find my modification :
>>
>> diff --git a/package/base-files/files/etc/rc.common 
>> b/package/base-files/files/etc/rc.common
>> index e0de073..8cc6e69 100755
>> --- a/package/base-files/files/etc/rc.common
>> +++ b/package/base-files/files/etc/rc.common
>> @@ -102,9 +102,11 @@ ${INIT_TRACE:+set -x}
>> . $IPKG_INSTROOT/lib/functions/procd.sh
>> basescript=$(readlink "$initscript")
>> rc_procd() {
>> +   local method="set"
>> +   [ -n "$2" ] && method="add"
>> procd_open_service "$(basename ${basescript:-$initscript})" 
>> "$initscript"
>> "$@"
>> -   procd_close_service
>> +   procd_close_service $method
>> }
>>  
>> start() {
>> diff --git a/package/system/procd/files/procd.sh 
>> b/package/system/procd/files/procd.sh
>> index fa6f8a9..1af9c7b 100644
>> --- a/package/system/procd/files/procd.sh
>> +++ b/package/system/procd/files/procd.sh
>> @@ -72,11 +72,15 @@ _procd_open_service() {  }
>>  
>>  _procd_close_service() {
>> +   local method="set"
>> +   [ -n "$1" ] && method="$1"
>> +
>> json_close_object
>> _procd_open_trigger
>> service_triggers
>> _procd_close_trigger
>> -   _procd_ubus_call set
>> +
>> +   _procd_ubus_call $method
>>  }
>>  
>>  _procd_add_array_data() {
>>
>>
>> With this patch, it seems to work.
>>
>> Pierre
>> -Original Message-
>> From: John Crispin [mailto:j...@phrozen.org]
>> Sent: dinsdag 27 september 2016 17:48
>> To: Lebleu Pierre ; 
>> lede-dev@lists.infradead.org
>> Subject: Re: [LEDE-DEV] The procd daemon does not handle correctly 
>> the instances
>>
>>
>>
>> On 27/09/2016 17:34, Lebleu Pierre wrote:
>>> Hi all,
>>>
>>> I found a bug in the daemon process management. Indeed, when we have 
>>> several instances of one daemon such as "dnsmasq" and we want to restart 
>>> only one instance, the other instance is killed by procd. It seems procd 
>>> updates the second instance and then, kill it.
>>>
>>> Please find the patch :
>>> diff --git a/service/service.c b/service/service.c index 
>>> 0796adb..9ed07da 100644
>>> ---

Re: [LEDE-DEV] [wiki]Wiki structure proposals and some questions

2016-09-29 Thread John Crispin 
it seems to have been rejected with "Message has a suspicious header" i
am assuming that microsoft is adding weird headers to your mails.

John

On 29/09/2016 09:47, Alberto Bursi wrote:
> I sent this yesterday and it is still waiting "moderator approval".
> 
> 
> On 09/28/2016 05:51 PM, Alberto Bursi wrote:
>> I recently posted in the discussion page of the todo page of the wiki. 
>> https://wiki.lede-project.org/talk:to_do_list
>>
>> Now, apart from that I'd like to note that while I can get a nice 
>> forum-like interface where I cal also select if I want to get emails 
>> to notify answers when it's my first post in a discussion page, on 
>> that page I seem to get only the generic wiki editing interface.
>>
>> Also, it would be cool to get email notifications about any page 
>> modification to pages I subscribed or have chosen somehow too, I 
>> didn't find anything to set that.
>>
>> -Alberto
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

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

Re: [LEDE-DEV] [wiki]Wiki structure proposals and some questions

2016-09-29 Thread Alberto Bursi 
I sent this yesterday and it is still waiting "moderator approval".


On 09/28/2016 05:51 PM, Alberto Bursi wrote:
> I recently posted in the discussion page of the todo page of the wiki. 
> https://wiki.lede-project.org/talk:to_do_list
>
> Now, apart from that I'd like to note that while I can get a nice 
> forum-like interface where I cal also select if I want to get emails 
> to notify answers when it's my first post in a discussion page, on 
> that page I seem to get only the generic wiki editing interface.
>
> Also, it would be cool to get email notifications about any page 
> modification to pages I subscribed or have chosen somehow too, I 
> didn't find anything to set that.
>
> -Alberto


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

[LEDE-DEV] Luci + Luci2 compat

2016-09-29 Thread Daniel Dickinson 
Hi all,

In the interests of making LuCI2 development feasible without
losing all of LuCI in the process, I'm planning on looking to a
luci-luci2 compat mechanism that would allow LuCI2 apps to be
used from within the current LuCI framework, while preventing
using of old LuCI mechanism in LuCI2 apps (so that new apps
don't end up with LuCI dependencies, since the long term goal
is to ditch LuCI in favour of LuCI2).

Has anyone got anything like this yet, and any pointers on the
LuCI2 stuff in particular, since I'm not all that familiar with
it.

Regards,

Daniel

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

[LEDE-DEV] Back from hospital; getting reintegrated

2016-09-29 Thread Daniel Dickinson 
Hi all,

I was in the hop for a while and while I've been out for about
a month there has been a lot to take care of.  I've also gotten
a couple boughts of already this school season (from those in
the family who are in school or work at school), so that hasn't
helped. (For those interested in such things the best way to
understand why I was in hospital is to watch "A Beautiful
Mind"; which except for the end where in real life John Nash
was on a newer medication that didn't have the horrible effects
of the older generation medications AND a brilliant mind to
make sense of what he was experience (in the movie it was made
to appear he just out-thought the illness).

In any event I'm back and have a number of patches I plan on
submitting, and want to get reintegrated into the community
here (as well as rl of course), and would like to help with
things like the wiki and bugs, in addition to submitting
patches.

Speaking of patches, even if I don't commit without review, I'd
like commit access or at least a vote and a voice in governance
of the project.  I believe I have a lot to contribute, and want
to be more than just a patch submitter.

Regards,

Daniel

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