Re: [LEDE-DEV] convention on uid/gid for packages
On Sun, May 14, 2017 at 3:59 AM, Daniel Golle wrote: > Hi Val, > > On Sat, May 13, 2017 at 06:23:29PM -0400, Val Kulkov wrote: >> Is there any convention on the use of uid and gid when creating new >> users or groups? Can someone point me to it, if it exists? >> >> I noticed that two packages, icecast and postfix, compete for the same >> uid=87: >> >> icecast's Makefile: >> USERID:=icecast=87:icecast=87 >> >> postfix's postfix.init: >> user_exists postfix || user_add postfix 87 > > This looks wrong to me (user_add in the init script)... > >> >> There may be more packages competing for the same uid/gid's, I have >> not fully researched it. >> >> I am preparing a new package, opendkim, which should be run as a >> non-privileged user. For this, >> USERID:=opendkim=:opendkim= seems appropriate, >> but what numbers should I assign? > > I run into this issue before and believe that we should have a wiki > page which allows registering static UIDs/GIDs at least for the > packages which actually need that (ie. if a specific UID or GID is > referenced in other packages, or scripts like firewall rules, ...). > Grep'ing for USERID allows to automatically generate that list based > on the currently available packages very easily. > > Examples from elsewhere for inspiration: > > FreeBSD got those lists > https://svnweb.freebsd.org/ports/head/UIDs?view=markup > https://svnweb.freebsd.org/ports/head/GIDs?view=markup > > linuxfromscratch got a much smaller list for essential/system UIDs/GIDs > http://linuxfromscratch.org/blfs/view/svn/postlfs/users.html > > > Cheers > Just woke up from the weekend. I recommend trying this out [based on lldpd] : https://github.com/lede-project/source/blob/master/package/network/services/lldpd/Makefile#L35 We use lldpd and this seems to work ; lldpd does some priv separation. Alex > > Daniel > > ___ > 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] [RFC 1/1] Revert "build: fix regression on running make kernel_menuconfig"
On Mon, May 15, 2017 at 2:53 AM, Stijn Tintel wrote: > On 15-05-17 00:20, Sergey Ryazanov wrote: >> This reverts commit 86c966a8ae9c4e74b912a16a760aaed17c68eb32. >> >> This patch caused the segmentation fault in mconf during >> "make kernel_menuconfig" due to a mess with ncurses/ncursesw libraries >> (forced linking with ncurses, while binary compiled with headers of >> ncursesw). >> >> Fixes: FS#366 (make kernel_menuconfig: Segmentation fault) >> > This fixes FS #366 for me. Thanks a lot! > > Tested-by: Stijn Tintel > Thank you for so fast testing! -- Sergey ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)
Martin,
in my flow-up mail I found this wrong numbering also. I attched a
copy of the relavant section from this mail.
I defined a new "label" gpio_pca and reference gpio0 of the pca ...
On Sonntag, 14. Mai 2017 23:50:25 CEST Mathias Kresin wrote:
> > poe_passthrough {
> >
> > gpio-export,name = "poe_power_port0";
> > gpio-export,output = <1>;
> > gpios = <&gpio0 496 0>;
>
> Your GPIO number is wrong.
>
When using the following dts-file it improves, a bit:
/ {
model = "UBNT-ERX-SFP";
i2c-gpio {
compatible = "i2c-gpio";
gpios = <&gpio0 3 GPIO_ACTIVE_HIGH /* sda */
&gpio0 4 GPIO_ACTIVE_HIGH /* scl */
>;
#address-cells = <1>;
#size-cells = <0>;
gpio_pca: pca9555@25 {
compatible = "pca9555";
reg = <0x25>;
};
};
gpio_export {
compatible = "gpio-export";
#size-cells = <0>;
poe_passthrough {
gpio-export,name = "poe_power_port0";
gpio-export,output = <1>;
gpios = <&gpio_pca 0 0>;
};
};
};
I think I got the trick to define a name for the PCA-gpio-chip and
reference it in the gpio-export section.
But it fails now with
[1.64] /gpio_export/poe_passthrough: could not get #gpio-cells for
/i2c-gpio/pca9555@25
[1.66] [ cut here ]
[1.67] WARNING: CPU: 3 PID: 1 at drivers/gpio/gpiolib.c:85 0x801dc2fc()
[1.68] invalid GPIO -22
[1.69] Modules linked in:
[1.69] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.4.61 #0
seems not to find the i2c-pca and it's gpios, as these modules are not
compile into the kernel.
[ 10.46] kmodloader: loading kernel modules from /etc/modules.d/*
[ 10.47] i2c /dev entries driver
[ 10.48] pca953x 0-0025: interrupt support not compiled in
[ 10.50] i2c-gpio i2c-gpio: using pi
Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)
On Sonntag, 14. Mai 2017 23:00:38 CEST Martin Blumenstingl wrote:
> > / {
> >
> > model = "UBNT-ERX-SFP";
> >
> > i2c-gpio {
> >
> > compatible = "i2c-gpio";
> > gpios = <&gpio0 3 GPIO_ACTIVE_HIGH /* sda */
> >
> > &gpio0 4 GPIO_ACTIVE_HIGH /* scl */
> >
> > >;
> >
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > gpio_pca: pca9555@25 {
> >
> > compatible = "pca9555";
> > reg = <0x25>;
>
> you seem to be missing two properties here which indicate that this is
> actually a GPIO controller:
> #gpio-cells = <2>;
> gpio-controller;
>
> value 2 in #gpio-cells means that whenever you reference a GPIO (just
> like you do in your poe_passthrough node) that the first parameter is
> the pin number and the second parameter is the polarity (active
> high/low)
> gpio-controller should be self-explanatory
>
Martin, having dts like:
gpio_pca: pca9555@25 {
compatible = "pca9555";
#gpio-cells = <2>;
gpio-controller;
reg = <0x25>;
};
end up in a similar thing as before
[1.65] [ cut here ]
[1.66] WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:85 0x801dc2fc()
[1.68] invalid GPIO -517
[1.68] Modules linked in:
[1.69] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.61 #0
Not sure if this is better then the
"/gpio_export/poe_passthrough: could not get #gpio-cells for
/i2c-gpio/pca9555@25" fault.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC 1/1] Revert "build: fix regression on running make kernel_menuconfig"
On 15-05-17 00:20, Sergey Ryazanov wrote: > This reverts commit 86c966a8ae9c4e74b912a16a760aaed17c68eb32. > > This patch caused the segmentation fault in mconf during > "make kernel_menuconfig" due to a mess with ncurses/ncursesw libraries > (forced linking with ncurses, while binary compiled with headers of > ncursesw). > > Fixes: FS#366 (make kernel_menuconfig: Segmentation fault) > > Signed-off-by: Sergey Ryazanov > --- > include/kernel-build.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/kernel-build.mk b/include/kernel-build.mk > index 7d1e23c..a4d12ec 100644 > --- a/include/kernel-build.mk > +++ b/include/kernel-build.mk > @@ -159,7 +159,7 @@ define BuildKernel > rm -f $(LINUX_DIR)/.config.prev > rm -f $(STAMP_CONFIGURED) > $(LINUX_RECONF_CMD) > $(LINUX_DIR)/.config > - $(_SINGLE)$(MAKE) -C $(LINUX_DIR) $(KERNEL_MAKEOPTS) > HOST_LOADLIBES="-L$(STAGING_DIR_HOST)/lib -lncurses" $$@ > + $(_SINGLE)$(MAKE) -C $(LINUX_DIR) $(KERNEL_MAKEOPTS) $$@ > $(LINUX_RECONF_DIFF) $(LINUX_DIR)/.config > $(LINUX_RECONFIG_TARGET) > >install: $(LINUX_DIR)/.image This fixes FS #366 for me. Thanks a lot! Tested-by: Stijn Tintel ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC 0/1] fix segfault in make kernel_menuconfig
Hello,
the folling patch fixes segfault in mconf when run "make
kernel_menuconfig" on my system (Gentoo with fresh portages).
This issue already was reported in FS#366 [1].
I tracked down this segfault to stranger linked mconf binary. It linked
with both ncurses and ncursesw libraries:
linux-4.4.61 $ ldd scripts/kconfig/mconf
linux-gate.so.1
libncurses.so.6 => /lib/libncurses.so.6
libncursesw.so.6 => /lib/libncursesw.so.6
libc.so.6 => /lib/libc.so.6
/lib/ld-linux.so.2
When analyzing a core file with gdb, it looks like that mconf was
compiled with the headers of ncursesw, but it calls functions from
ncurses:
linux-4.4.61 $ gdb scripts/kconfig/mconf core
Core was generated by `scripts/kconfig/mconf Kconfig'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0xb770d2fd in waddch_literal (ch=, win=0x96a1f20)
385 line->text[x++] = ch;
(gdb) bt
#0 waddch_literal (ch, win)
#1 waddch_nosync (ch, win)
#2 waddch (win, ch)
#3 draw_box (win, y, x, height, width, box, border)
#4 dialog_menu (title, prompt, selected, s_scroll)
#5 conf (menu, active_menu)
#6 main (ac, av)
(gdb) print sizeof(*draw_box::win)
$1 = 108
(gdb) print sizeof(*waddch_literal::win)
$2 = 76
mconf itself was linked with the following command:
linux-4.4.61 $ grep -n '[-]lncurses' scripts/kconfig/.mconf.cmd
1:cmd_scripts/kconfig/mconf := gcc -o scripts/kconfig/mconf
scripts/kconfig/mconf.o scripts/kconfig/zconf.tab.o
scripts/kconfig/lxdialog/checklist.o scripts/kconfig/lxdialog/util.o
scripts/kconfig/lxdialog/inputbox.o scripts/kconfig/lxdialog/textbox.o
scripts/kconfig/lxdialog/yesno.o scripts/kconfig/lxdialog/menubox.o
-L/tmp/lede/staging_dir/host/lib -lncurses -lncursesw
First linking instruction ('-lncurses') is comes from the
include/kernel-build.mk script in the HOST_LOADLIBES parameter, while
the second one ('-lncursesw') generated by the kernel itself and stored
in the HOSTLOADLIBES_mconf variable. Then both variables are joined to
get the final linking command.
Kernel uses script/kconfig/lxdialog/check-lxdialog.sh script to detect
compilation and linking options for ncurses[w]. And this script do the
everything possible to detects ncurses[w] header files and library on
the host system. This script have one more feature: it prefers the
ncursesw library (and widechars) to regular ncurses library.
Each kernel version in use (e.g 3.18, 4.4 and 4.9) uses this script and
behaves in a similar way.
So when we force to link with ncurses on the host system, which also
contains installed ncursesw library, we create prerequisites for
segfaults and other issues.
This forced linking was added in the commit 86c966a8ae9c4e (build: fix
regression on running make kernel_menuconfig). After I reverted this
commit the make kernel_menuconfig command became fully functional
without any issues.
Since mentioned commit should fix some issue (according to its subject)
and since I tested this reverting patch only on the few systems I could
miss something and segfault issue should have a more complex solution.
So I send this reverting patch as RFC.
1. https://bugs.lede-project.org/index.php?do=details&task_id=366
Sergey Ryazanov (1):
Revert "build: fix regression on running make kernel_menuconfig"
include/kernel-build.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.10.2
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC 1/1] Revert "build: fix regression on running make kernel_menuconfig"
This reverts commit 86c966a8ae9c4e74b912a16a760aaed17c68eb32. This patch caused the segmentation fault in mconf during "make kernel_menuconfig" due to a mess with ncurses/ncursesw libraries (forced linking with ncurses, while binary compiled with headers of ncursesw). Fixes: FS#366 (make kernel_menuconfig: Segmentation fault) Signed-off-by: Sergey Ryazanov --- include/kernel-build.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/kernel-build.mk b/include/kernel-build.mk index 7d1e23c..a4d12ec 100644 --- a/include/kernel-build.mk +++ b/include/kernel-build.mk @@ -159,7 +159,7 @@ define BuildKernel rm -f $(LINUX_DIR)/.config.prev rm -f $(STAMP_CONFIGURED) $(LINUX_RECONF_CMD) > $(LINUX_DIR)/.config - $(_SINGLE)$(MAKE) -C $(LINUX_DIR) $(KERNEL_MAKEOPTS) HOST_LOADLIBES="-L$(STAGING_DIR_HOST)/lib -lncurses" $$@ + $(_SINGLE)$(MAKE) -C $(LINUX_DIR) $(KERNEL_MAKEOPTS) $$@ $(LINUX_RECONF_DIFF) $(LINUX_DIR)/.config > $(LINUX_RECONFIG_TARGET) install: $(LINUX_DIR)/.image -- 2.10.2 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)
14.05.2017 21:22, Sven Roederer:
I just gave it another try, as I like the idea of having it in the DTS. As my
test ERX is gone I continue testing on ERX-SFP.
Please se below ...
On Sonntag, 14. Mai 2017 16:24:15 CEST Mathias Kresin wrote:
If you use the gpio-export node in the device tree source file, the gpio
pin should appear at /sys/class/gpio/. Most likely you have done
something wrong. Could it be that you used exactly the same gpio pin
number as you have it in your 03_gpio_export file? You need to decrement
the gpio pin number by the gpio base as it is done for all gpios in the
dts.
for the "gpio in dts" I used this branch
https://github.com/SvenRoederer/lede-project-source/commits/ERX-SFP_gpio-
in-dts --> see the last 2 commits. Code only changed for ERX for this
test.
Did I miss something?
Yes you did. The gpio-export,output value is wrong. It has to be either
0 or 1, similar to the values set for the gpio_switch config in
/e/c/system.
I removed the 03_gpio_export and added this to the dts:
gpio_export {
compatible = "gpio-export";
#size-cells = <0>;
poe_passthrough {
gpio-export,name = "poe_power_port0";
gpio-export,output = <1>;
gpios = <&gpio0 496 0>;
Your GPIO number is wrong.
The device tree is some kind of abstraction layer to the hardware and in
terms of GPIOs you are only using "logical/virtual" GPIO numbers.
The mt7621 has two GPIO banks: gpio0 and gpio1 (yes I know there is a
gpio2 in the mt7621.dtsi, but the SoC has only 61 GPIOs). Each GPIO bank
has 32 GPIOs and is exported to the sysfs at /sys/class/gpio/gpiochipNNN.
/sys/class/gpio/gpiochipNNN/base is the first (physical/real) GPIO
number managed by this chip. If the gpiochips base is 462, &gpio0 0 to
31 refers to the physical GPIOs 462 to 493. &gpio1 0 to 28 refers to the
physical GPIOs 494 to 522.
But it is still not the whole story. The pins of the SoC can have
different functions. Via the pinmux node you specify the purpose of the
pins[0]. For the ERX the following groups are set to GPIO mode:
uart2: &gpio0 9 to 12
uart3: &gpio0 5 to 8
i2c: &gpio0 3 to 4
pcie: &gpio0 19
rgmii2: &gpio0 22 to 31, &gpio1 0 to 1
jtag: &gpio0 13 to 17
It kinda looks like copy/paste from the MT7621.dts. Most of the GPIOs
are not used at all.
Mathias
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/mips/ralink/mt7621.c
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sun, May 14, 2017 at 10:13 PM, Sven Roederer wrote:
> On Sonntag, 14. Mai 2017 21:22:42 CEST Sven Roederer wrote:
>>
>> I removed the 03_gpio_export and added this to the dts:
>> gpio_export {
>> compatible = "gpio-export";
>> #size-cells = <0>;
>>
>> poe_passthrough {
>> gpio-export,name = "poe_power_port0";
>> gpio-export,output = <1>;
>> gpios = <&gpio0 496 0>;
>> };
>> };
>>
>> But booting this kernel gives:
>> [1.66] [ cut here ]
>> [1.67] WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:85
>> 0x801dc2fc()
>> [1.68] invalid GPIO -22
>> [1.69] Modules linked in:
>> [1.69] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.61 #0
>> [2.12] ---[ end trace ceab04cd8881362f ]---
>> [2.13] gpiod_request: invalid GPIO
>> [2.14] gpio-export gpio_export: 0 gpio(s) exported
>>
>>
>> I'm wondering on the "GPIO -22". Checking the source of
>> drivers/gpio/gpiolib.c shows gpio is of type unsigned, large enough to
>> handle gpio#496.
>>
>> Any Idea what's going on?
>> Probably it's something related to the SoC-gpios and the additional pins
>> defined from the pca9555
>>
>
> When using the following dts-file it improves, a bit:
> / {
> model = "UBNT-ERX-SFP";
>
> i2c-gpio {
> compatible = "i2c-gpio";
> gpios = <&gpio0 3 GPIO_ACTIVE_HIGH /* sda */
> &gpio0 4 GPIO_ACTIVE_HIGH /* scl */
> >;
> #address-cells = <1>;
> #size-cells = <0>;
>
> gpio_pca: pca9555@25 {
> compatible = "pca9555";
> reg = <0x25>;
you seem to be missing two properties here which indicate that this is
actually a GPIO controller:
#gpio-cells = <2>;
gpio-controller;
value 2 in #gpio-cells means that whenever you reference a GPIO (just
like you do in your poe_passthrough node) that the first parameter is
the pin number and the second parameter is the polarity (active
high/low)
gpio-controller should be self-explanatory
> };
> };
>
> gpio_export {
> compatible = "gpio-export";
> #size-cells = <0>;
>
> poe_passthrough {
> gpio-export,name = "poe_power_port0";
> gpio-export,output = <1>;
> gpios = <&gpio_pca 0 0>;
> };
>
> };
> };
>
> I think I got the trick to define a name for the PCA-gpio-chip and
> reference it in the gpio-export section.
> But it fails now with
> [ 1.64] /gpio_export/poe_passthrough: could not get #gpio-cells for
> /i2c-gpio/pca9555@25
> [1.66] [ cut here ]
> [1.67] WARNING: CPU: 3 PID: 1 at drivers/gpio/gpiolib.c:85
> 0x801dc2fc()
> [ 1.68] invalid GPIO -22
> [ 1.69] Modules linked in:
> [ 1.69] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.4.61 #0
>
> seems not to find the i2c-pca and it's gpios, as these modules are not
> compile into the kernel.
> [ 10.46] kmodloader: loading kernel modules from /etc/modules.d/*
> [ 10.47] i2c /dev entries driver
> [ 10.48] pca953x 0-0025: interrupt support not compiled in
> [ 10.50] i2c-gpio i2c-gpio: using pins 3 (SDA) and 4 (SCL)
> [ 10.51] PPP generic driver version 2.4.2
>
> They will load during init.scripts.
> I see following options:
> - use the 03-gpio script in board.d
> - compile the drivers into the kernel, but will this be done for all
> mt7621-kernels?
>
>
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)
On Sonntag, 14. Mai 2017 21:22:42 CEST Sven Roederer wrote:
>
> I removed the 03_gpio_export and added this to the dts:
> gpio_export {
> compatible = "gpio-export";
> #size-cells = <0>;
>
> poe_passthrough {
> gpio-export,name = "poe_power_port0";
> gpio-export,output = <1>;
> gpios = <&gpio0 496 0>;
> };
> };
>
> But booting this kernel gives:
> [1.66] [ cut here ]
> [1.67] WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:85
> 0x801dc2fc()
> [1.68] invalid GPIO -22
> [1.69] Modules linked in:
> [1.69] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.61 #0
> [2.12] ---[ end trace ceab04cd8881362f ]---
> [2.13] gpiod_request: invalid GPIO
> [2.14] gpio-export gpio_export: 0 gpio(s) exported
>
>
> I'm wondering on the "GPIO -22". Checking the source of
> drivers/gpio/gpiolib.c shows gpio is of type unsigned, large enough to
> handle gpio#496.
>
> Any Idea what's going on?
> Probably it's something related to the SoC-gpios and the additional pins
> defined from the pca9555
>
When using the following dts-file it improves, a bit:
/ {
model = "UBNT-ERX-SFP";
i2c-gpio {
compatible = "i2c-gpio";
gpios = <&gpio0 3 GPIO_ACTIVE_HIGH /* sda */
&gpio0 4 GPIO_ACTIVE_HIGH /* scl */
>;
#address-cells = <1>;
#size-cells = <0>;
gpio_pca: pca9555@25 {
compatible = "pca9555";
reg = <0x25>;
};
};
gpio_export {
compatible = "gpio-export";
#size-cells = <0>;
poe_passthrough {
gpio-export,name = "poe_power_port0";
gpio-export,output = <1>;
gpios = <&gpio_pca 0 0>;
};
};
};
I think I got the trick to define a name for the PCA-gpio-chip and
reference it in the gpio-export section.
But it fails n
Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)
Hi Sven, > as I've seen also not giving any copyright seems common. So dropping it > completly and saving some bytes is valid also, right? Correct, as you prefer :) Cheers, Jo 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/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)
I just gave it another try, as I like the idea of having it in the DTS. As my
test ERX is gone I continue testing on ERX-SFP.
Please se below ...
On Sonntag, 14. Mai 2017 16:24:15 CEST Mathias Kresin wrote:
> >>
> >> If you use the gpio-export node in the device tree source file, the gpio
> >> pin should appear at /sys/class/gpio/. Most likely you have done
> >> something wrong. Could it be that you used exactly the same gpio pin
> >> number as you have it in your 03_gpio_export file? You need to decrement
> >> the gpio pin number by the gpio base as it is done for all gpios in the
> >> dts.
> >>
> > for the "gpio in dts" I used this branch
> > https://github.com/SvenRoederer/lede-project-source/commits/ERX-SFP_gpio-
> > in-dts --> see the last 2 commits. Code only changed for ERX for this
> > test.
> > Did I miss something?
>
> Yes you did. The gpio-export,output value is wrong. It has to be either
> 0 or 1, similar to the values set for the gpio_switch config in
> /e/c/system.
>
I removed the 03_gpio_export and added this to the dts:
gpio_export {
compatible = "gpio-export";
#size-cells = <0>;
poe_passthrough {
gpio-export,name = "poe_power_port0";
gpio-export,output = <1>;
gpios = <&gpio0 496 0>;
};
};
But booting this kernel gives:
[1.66] [ cut here ]
[1.67] WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:85 0x801dc2fc()
[1.68] invalid GPIO -22
[1.69] Modules linked in:
[1.69] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.61 #0
[1.69] Stack : 80566862 0033
...
[1.69] Call Trace:[<800161e0>] 0x800161e0
[1.69] [<800161e0>] 0x800161e0
[1.69] [<801aba14>] 0x801aba14
[1.69] [<8002be68>] 0x8002be68
[1.69] [<8040c230>] 0x8040c230
[1.69] [<801dc2fc>] 0x801dc2fc
[1.69] [<8002bec4>] 0x8002bec4
[1.69] [<801dc2fc>] 0x801dc2fc
[1.69] [<801dac0c>] 0x801dac0c
[1.69] [<800c56f4>] 0x800c56f4
[1.69] [<801dd4c8>] 0x801dd4c8
[1.69] [<801dac0c>] 0x801dac0c
[1.69] [<80212d64>] 0x80212d64
[1.69] [<801dac74>] 0x801dac74
[1.69] [<80265fd8>] 0x80265fd8
[1.69] [<801dd960>] 0x801dd960
[1.69] [<8041edd8>] 0x8041edd8
[1.69] [<8040c230>] 0x8040c230
[1.69] [<8040c230>] 0x8040c230
[1.69] [<8040c230>] 0x8040c230
[1.69] [<80211848>] 0x80211848
[1.69] [<802668fc>] 0x802668fc
[1.69] [<801248f4>] 0x801248f4
[1.69] [<8020fe2c>] 0x8020fe2c
[1.69] [<80211b0c>] 0x80211b0c
[1.69] [<80210010>] 0x80210010
[1.69] [<8020e234>] 0x8020e234
[1.69] [<8020ff94>] 0x8020ff94
[1.69] [<8020e2f0>] 0x8020e2f0
[1.69] [<80367058>] 0x80367058
[1.69] [<8020e0c4>] 0x8020e0c4
[1.69] [<8020f524>] 0x8020f524
[1.69] [<80063328>] 0x80063328
[1.69] [<802105cc>] 0x802105cc
[1.69] [<80210760>] 0x80210760
[1.69] [<80180898>] 0x80180898
[1.69] [<8040c230>] 0x8040c230
[1.69] [<8041ec78>] 0x8041ec78
[1.69] [<80211948>] 0x80211948
[1.69] [<8041ec78>] 0x8041ec78
[1.69] [<8000f674>] 0x8000f674
[1.69] [<80118fe0>] 0x80118fe0
[1.69] [<80118de4>] 0x80118de4
[1.69] [<80043920>] 0x80043920
[1.69] [<8040cce8>] 0x8040cce8
[1.69] [<8040c230>] 0x8040c230
[1.69] [<80009ff4>] 0x80009ff4
[1.69] [<8000a004>] 0x8000a004
[1.69] [<80009ff4>] 0x80009ff4
[1.69] [<80005478>] 0x80005478
[1.69]
[2.12] ---[ end trace ceab04cd8881362f ]---
[2.13] gpiod_request: invalid GPIO
[2.14] gpio-export gpio_export: 0 gpio(s) exported
I'm wondering on the "GPIO -22". Checking the so
Re: [LEDE-DEV] [PATCH v4] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'
ad. 1) FS785 describes why, please have a look there. ad. 2) the patched code has been tested. Producing the submission of the patch for this trivial and simple change has provided me with the opportunity to make almost every error imaginable, and as you have noticed, I greatly succeeded at doing just that. The spam is an unwanted side effect. I’ve submitted a last version of this patch, s.y. Paul > Op 14 mei 2017, om 18:54 heeft Kevin Darbyshire-Bryant > het volgende geschreven: > > > > On 14/05/17 17:48, Alberto Bursi wrote: >> >> >> On 05/14/2017 02:46 PM, Paul Oranje wrote: >>> fixes FS#785 >>> --- >>> >>> v4: place patch version info in annotation (not in commit message, afraid >>> this is learning by practice) >>> v3: corrected typo (noreolv) >>> v2: also change guard in dnsmasq_stop() routine >>> v1: write /tmp/resolv.conf also when noresolv is true > > Having seen so many versions go by...the overriding questions for me are > > 1) Why do we want this? > 2) Has any of it actually been tested? > > ___ > 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] [PATCH v5] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'
fixes FS#785
Signed-off-by: Paul Oranje
---
package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index 30fec7a4ee..197aae9de1 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -947,7 +947,7 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
- [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+ [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
rm -f /tmp/resolv.conf
[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
echo "search $DOMAIN" >> /tmp/resolv.conf
@@ -982,7 +982,7 @@ dnsmasq_stop()
config_get resolvfile "$cfg" "resolvfile"
#relink /tmp/resolve.conf only for main instance
- [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+ [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
[ -f /tmp/resolv.conf ] && {
rm -f /tmp/resolv.conf
ln -s "$resolvfile" /tmp/resolv.conf
--
2.12.2
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v4] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'
On 14/05/17 17:48, Alberto Bursi wrote: On 05/14/2017 02:46 PM, Paul Oranje wrote: fixes FS#785 --- v4: place patch version info in annotation (not in commit message, afraid this is learning by practice) v3: corrected typo (noreolv) v2: also change guard in dnsmasq_stop() routine v1: write /tmp/resolv.conf also when noresolv is true Having seen so many versions go by...the overriding questions for me are 1) Why do we want this? 2) Has any of it actually been tested? ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v4] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'
On 05/14/2017 02:46 PM, Paul Oranje wrote: > fixes FS#785 > --- > > v4: place patch version info in annotation (not in commit message, afraid > this is learning by practice) > v3: corrected typo (noreolv) > v2: also change guard in dnsmasq_stop() routine > v1: write /tmp/resolv.conf also when noresolv is true > > > package/network/services/dnsmasq/files/dnsmasq.init | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/package/network/services/dnsmasq/files/dnsmasq.init > b/package/network/services/dnsmasq/files/dnsmasq.init > index 30fec7a4ee..197aae9de1 100644 > You removed also the "signed off by", please re-add it. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)
13.05.2017 20:09, Sven Roederer: On Montag, 8. Mai 2017 08:23:50 CEST Mathias Kresin wrote: 07.05.2017 23:24, Sven Roederer: On Sonntag, 7. Mai 2017 12:25:39 CEST you wrote: Just an opinion: being able to disable/enable PoE for each port is really useful when you want to remotely reboot a device plugged into your PoE switch/router. Most PoE-capable devices expose this option with the stock firmware. Does your approach with the gpio-export node allow to change the state of the GPIO at runtime? (i.e. probably from userspace) Baptiste, right, that's the point I'm also looking for. To have da clean way of controlling the state of the PoE-voltage (24V passive PoE) for the ports. As it's passive PoE there might be a big risk that having the power enabled all the time might cause some problems. When defining in dts I don't see them in uci or even in /sys/class/gpio. So via "board.d/03_gpio_switches" seems the best way to bring them to userspace for user-interaction. If you use the gpio-export node in the device tree source file, the gpio pin should appear at /sys/class/gpio/. Most likely you have done something wrong. Could it be that you used exactly the same gpio pin number as you have it in your 03_gpio_export file? You need to decrement the gpio pin number by the gpio base as it is done for all gpios in the dts. Correct me if I'm wrong, but as far I can see (and confirmed by testing it) the exported gpio in UCI doesn't have any benefit for your restart usecase. If I change the gpio value via uci and restart /etc/init.d/system the gpio value is still the same. Means, the value is only set during the actual export (on boot). Mathias Mathias, for the "gpio in dts" I used this branch https://github.com/SvenRoederer/lede-project-source/commits/ERX-SFP_gpio-in-dts --> see the last 2 commits. Code only changed for ERX for this test. Did I miss something? Yes you did. The gpio-export,output value is wrong. It has to be either 0 or 1, similar to the values set for the gpio_switch config in /e/c/system. To make it as easy as possible for people to help, please paste your patch next time into the e-mail body of your reply. You are correct, that this uci-config only gets applied on boot. but changing uci and calling "reload-config" will do the "magic". Oh indeed, reload_config does the job. I wasn't aware of this little helper. As I already wrote the last time, I'll leave it up to you to add what you are the opinion is the best for the use case. I just wanted to ensure that is wasn't added because of lack of knowledge about the alternatives. Mathias ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v3] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'
Please ignore, a v4 has been submitted without patch version bla bla in the
commit message.
Paul
> Op 14 mei 2017, om 13:54 heeft Paul Oranje het volgende
> geschreven:
>
> fixes FS#785
> v3: corrected typo (noreolv)
> v2: also change guard in dnsmasq_stop() routine
> v1: write /tmp/resolv.conf also when noresolv is true
>
> Signed-off-by: Paul Oranje
> ---
> package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
> b/package/network/services/dnsmasq/files/dnsmasq.init
> index 30fec7a4ee..197aae9de1 100644
> --- a/package/network/services/dnsmasq/files/dnsmasq.init
> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
> @@ -947,7 +947,7 @@ dnsmasq_start()
> echo >> $CONFIGFILE_TMP
> mv -f $CONFIGFILE_TMP $CONFIGFILE
>
> - [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> + [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> rm -f /tmp/resolv.conf
> [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
> echo "search $DOMAIN" >> /tmp/resolv.conf
> @@ -982,7 +982,7 @@ dnsmasq_stop()
> config_get resolvfile "$cfg" "resolvfile"
>
> #relink /tmp/resolve.conf only for main instance
> - [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> + [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> [ -f /tmp/resolv.conf ] && {
> rm -f /tmp/resolv.conf
> ln -s "$resolvfile" /tmp/resolv.conf
> --
> 2.12.2
>
>
> ___
> 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] [PATCH v4] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'
fixes FS#785
---
v4: place patch version info in annotation (not in commit message, afraid this
is learning by practice)
v3: corrected typo (noreolv)
v2: also change guard in dnsmasq_stop() routine
v1: write /tmp/resolv.conf also when noresolv is true
package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index 30fec7a4ee..197aae9de1 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -947,7 +947,7 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
- [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+ [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
rm -f /tmp/resolv.conf
[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
echo "search $DOMAIN" >> /tmp/resolv.conf
@@ -982,7 +982,7 @@ dnsmasq_stop()
config_get resolvfile "$cfg" "resolvfile"
#relink /tmp/resolve.conf only for main instance
- [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+ [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
[ -f /tmp/resolv.conf ] && {
rm -f /tmp/resolv.conf
ln -s "$resolvfile" /tmp/resolv.conf
--
2.12.2
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v3] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'
fixes FS#785
v3: corrected typo (noreolv)
v2: also change guard in dnsmasq_stop() routine
v1: write /tmp/resolv.conf also when noresolv is true
Signed-off-by: Paul Oranje
---
package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index 30fec7a4ee..197aae9de1 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -947,7 +947,7 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
- [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+ [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
rm -f /tmp/resolv.conf
[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
echo "search $DOMAIN" >> /tmp/resolv.conf
@@ -982,7 +982,7 @@ dnsmasq_stop()
config_get resolvfile "$cfg" "resolvfile"
#relink /tmp/resolve.conf only for main instance
- [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+ [ "$noresolv" = "1" -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
[ -f /tmp/resolv.conf ] && {
rm -f /tmp/resolv.conf
ln -s "$resolvfile" /tmp/resolv.conf
--
2.12.2
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/3] ramips-mt7621: add GPIO-config for Ubiquiti-EdgeRouterX(-SFP)
Hi, as I've seen also not giving any copyright seems common. So dropping it completly and saving some bytes is valid also, right? Sven On Samstag, 6. Mai 2017 14:49:29 CEST Jo-Philipp Wich wrote: > > comments inline. > > > +++ b/target/linux/ramips/base-files/etc/board.d/03_gpio_switches > > @@ -0,0 +1,28 @@ > > +#!/bin/sh > > +# > > +# Copyright (C) 2017 LEDE-project.org > > Please use your own copyright here or none at all. > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'
Please ignore, contains a syntax error.
new version will follow, sorry,
Paul
> Op 14 mei 2017, om 13:14 heeft Paul Oranje het volgende
> geschreven:
>
> fixes FS#785
> v1: write /tmp/resolv.conf also when nosolv is true
> v2: also change guard in dnsmasq_stop() routine
>
> Signed-off-by: Paul Oranje
> ---
> package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
> b/package/network/services/dnsmasq/files/dnsmasq.init
> index 30fec7a4ee..c7506ed4ea 100644
> --- a/package/network/services/dnsmasq/files/dnsmasq.init
> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
> @@ -947,7 +947,7 @@ dnsmasq_start()
> echo >> $CONFIGFILE_TMP
> mv -f $CONFIGFILE_TMP $CONFIGFILE
>
> - [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> + [ "$noreolv" -eq '1' -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> rm -f /tmp/resolv.conf
> [ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
> echo "search $DOMAIN" >> /tmp/resolv.conf
> @@ -982,7 +982,7 @@ dnsmasq_stop()
> config_get resolvfile "$cfg" "resolvfile"
>
> #relink /tmp/resolve.conf only for main instance
> - [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> + [ "$noreolv" -eq '1' -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
> [ -f /tmp/resolv.conf ] && {
> rm -f /tmp/resolv.conf
> ln -s "$resolvfile" /tmp/resolv.conf
> --
> 2.12.2
>
>
> ___
> 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] [PATCH v2] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'
fixes FS#785
v1: write /tmp/resolv.conf also when nosolv is true
v2: also change guard in dnsmasq_stop() routine
Signed-off-by: Paul Oranje
---
package/network/services/dnsmasq/files/dnsmasq.init | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index 30fec7a4ee..c7506ed4ea 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -947,7 +947,7 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
- [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+ [ "$noreolv" -eq '1' -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
rm -f /tmp/resolv.conf
[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
echo "search $DOMAIN" >> /tmp/resolv.conf
@@ -982,7 +982,7 @@ dnsmasq_stop()
config_get resolvfile "$cfg" "resolvfile"
#relink /tmp/resolve.conf only for main instance
- [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+ [ "$noreolv" -eq '1' -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
[ -f /tmp/resolv.conf ] && {
rm -f /tmp/resolv.conf
ln -s "$resolvfile" /tmp/resolv.conf
--
2.12.2
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] dnsmasq: also write /tmp/resolv.conf when UCI dhcp.dnsmasq.noresolv is '1'
fixes FS#785
Signed-off-by: Paul Oranje
---
package/network/services/dnsmasq/files/dnsmasq.init | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index 30fec7a4ee..8c052b48a0 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -947,7 +947,7 @@ dnsmasq_start()
echo >> $CONFIGFILE_TMP
mv -f $CONFIGFILE_TMP $CONFIGFILE
- [ "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
+ [ "$noreolv" -eq '1' -o "$resolvfile" = "/tmp/resolv.conf.auto" ] && {
rm -f /tmp/resolv.conf
[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
echo "search $DOMAIN" >> /tmp/resolv.conf
--
2.12.2
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] openwrt and lede - remerge proposal
On Sun, 14 May 2017, Giuseppe Lippolis wrote: *) branding - the owrt side sees no option of using the lede brand - a (minor) majority voted for openwrt as a name over lede whilst most people said they did not care - as the last vote had a 100% ACK for a remerge using the owrt brand is the only feasible option Passionate: I start to develop with lede, therefore I'm fond to this brand. More rational: Lede differ from OWRT because it should be more open to generic embedded architecture. IMHO this is a big advantage compared to OWRT that shall be kept. and others are equally passionate in the other direction, while still others are less passionate. But the vote is the vote, and stating how passionate you are on one side or another doesn't alter the vote. David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] openwrt and lede - remerge proposal
> *) branding > - the owrt side sees no option of using the lede brand > > - a (minor) majority voted for openwrt as a name over lede whilst most > people said they did not care > > - as the last vote had a 100% ACK for a remerge using the owrt brand is the > only feasible option Passionate: I start to develop with lede, therefore I'm fond to this brand. More rational: Lede differ from OWRT because it should be more open to generic embedded architecture. IMHO this is a big advantage compared to OWRT that shall be kept. Bye. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
