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

[Mike Baker]

On 11/2/2017 1:44 PM, Hartmut Knaack wrote:

I agree, that there were no warning signs on the public mailing list.

As I said before, all history now; discussing it further serves no purpose.

- Mike

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

Re: [LEDE-DEV] [PATCH v1 1/1] uclient-fetch: correct filename w/ multple URLs

[Philip Prindeville]

> On Nov 2, 2017, at 3:54 PM, Felix Fietkau  wrote:
> 
> On 2017-11-02 22:50, Philip Prindeville wrote:
>> 
>> Okay, great.
>> 
>> When will this show up in LEDE?
> Pushed just now.
> 
> - Felix


Tested and confirmed!


___
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

[Andreas Ziegler]

Hi,

Zoltan HERPAI schrieb am 02.11.2017 um 13:20:
> For the sake of full transparency, Imre and me was not part of the vote,
> as that was sent to lede-adm, without including openwrt-hackers or
> openwrt-devel.

and your PATCH v2 didn't go to lede-adm.

a suggestion from a simple community member:
everyone subscribes to all of these four lists instead of complaining
about "this was not in the correct list".

such small things delaying the merge is really annoying to watch...

Regards

Andreas

P.S.:
no i'm not on all of these lists, but i have no voting rights, so it
doesn't delay or block something.

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

Re: [LEDE-DEV] [PATCH v1 1/1] uclient-fetch: correct filename w/ multple URLs

[Felix Fietkau]

On 2017-11-02 22:50, Philip Prindeville wrote:
> 
>> On Nov 2, 2017, at 3:03 PM, Felix Fietkau  wrote:
>> 
>> On 2017-11-02 19:23, Philip Prindeville wrote:
>>> From: Philip Prindeville 
>>> 
>>> When uclient-fetch is called with multiple URL's, it derives the
>>> first filename based on the URL. When it then handles the 2nd and
>>> subsequent URLs, it assumes that it was called with a -O filename
>>> argument as the output file, because it tries to overload the
>>> variable output_file to mean 2 different things.
>>> 
>>> The fix is to use a bool to remember whether we were called with
>>> an explicit output filename, i.e. with the -O argument, and not
>>> overload output_file for this purpose.
>>> 
>>> Signed-off-by: Philip Prindeville 
>> Thanks for debugging this. I've decided to fix this with a different
>> approach instead. I've pushed a change that avoids the overloading issue
>> entirely by renaming the global variable and overwriting a local
>> variable only.
>> 
>> - Felix
> 
> 
> Okay, great.
> 
> When will this show up in LEDE?
Pushed just now.

- Felix

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

Re: [LEDE-DEV] [PATCH v1 1/1] uclient-fetch: correct filename w/ multple URLs

[Philip Prindeville]

> On Nov 2, 2017, at 3:03 PM, Felix Fietkau  wrote:
> 
> On 2017-11-02 19:23, Philip Prindeville wrote:
>> From: Philip Prindeville 
>> 
>> When uclient-fetch is called with multiple URL's, it derives the
>> first filename based on the URL. When it then handles the 2nd and
>> subsequent URLs, it assumes that it was called with a -O filename
>> argument as the output file, because it tries to overload the
>> variable output_file to mean 2 different things.
>> 
>> The fix is to use a bool to remember whether we were called with
>> an explicit output filename, i.e. with the -O argument, and not
>> overload output_file for this purpose.
>> 
>> Signed-off-by: Philip Prindeville 
> Thanks for debugging this. I've decided to fix this with a different
> approach instead. I've pushed a change that avoids the overloading issue
> entirely by renaming the global variable and overwriting a local
> variable only.
> 
> - Felix


Okay, great.

When will this show up in LEDE?

Thanks.


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

Re: [LEDE-DEV] [PATCH v1 1/1] uclient-fetch: correct filename w/ multple URLs

[Felix Fietkau]

On 2017-11-02 19:23, Philip Prindeville wrote:
> From: Philip Prindeville 
> 
> When uclient-fetch is called with multiple URL's, it derives the
> first filename based on the URL. When it then handles the 2nd and
> subsequent URLs, it assumes that it was called with a -O filename
> argument as the output file, because it tries to overload the
> variable output_file to mean 2 different things.
> 
> The fix is to use a bool to remember whether we were called with
> an explicit output filename, i.e. with the -O argument, and not
> overload output_file for this purpose.
> 
> Signed-off-by: Philip Prindeville 
Thanks for debugging this. I've decided to fix this with a different
approach instead. I've pushed a change that avoids the overloading issue
entirely by renaming the global variable and overwriting a local
variable only.

- Felix

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

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

[Hartmut Knaack]

Mike Baker wrote on 02.11.2017 16:59:

On 11/1/2017 5:18 PM, Hartmut Knaack wrote:


This raises some more questions: which terms and conditions did people
have
to approve to get an @openwrt.org address? Where can these terms and
conditions be found? Is every email sent from such an address supposed to
be discussed and approved by the group before it gets sent?
Furthermore: how many percent of "the group" needs to agree when it comes
to disabling someones address? 50% or 67%?

The issue is the use of an openwrt email address to make an announcement
on behalf of openwrt stating that openwrt had become lede without ever
discussing it. There were no warning signs, everybody from openwrt
suddenly found out that there was a new project and they had been kicked
out.

- Mike



I'm reading over Jows announcement over and over again, but can not see,
where he would announce it on behalf of openwrt. He has been using his
@openwrt.org, just like countless times before on the mailing list.
I can also not find the claim, that LEDE would be the successor of openwrt,
just that quite a lot of active developers would try to start a new project
with a different focus on certain issues.
I agree, that there were no warning signs on the public mailing list. But
still, what have been the terms and conditions for project email addresses?
How are sanctions decided?
And if I pick up your statement, that using an openwrt email address
implies that it is sent on behalf of openwrt (and thus, reviewed by the
project members and acknowledged by the majority), there should just be one
account for public relations (like version announcements, business
communication on behalf of the project).
I understand, that your feelings got hurt by the announcement, but your
reaction was not professional. So, IMHO you messed up, now deal with it.
Thanks,

Hartmut

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

[LEDE-DEV] [PATCH 2/2] wifi: (80211r) add ft_over_ds support

[Lorenzo Santina]

It's now possibile choose if use FT over DS
protocol or FT over the Air protocol for 80211r

Signed-off-by: Lorenzo Santina 
---
 modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua | 6 ++
 1 file changed, 6 insertions(+)

diff --git 
a/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua 
b/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua
index 8528f8624..c64226931 100644
--- a/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua
+++ b/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua
@@ -801,6 +801,12 @@ if hwtype == "mac80211" or hwtype == "prism2" then
reassociation_deadline.datatype = "range(1000,65535)"
reassociation_deadline.rmempty = true
 
+   ft_protocol = s:taboption("encryption", ListValue, "ft_over_ds", 
translate("FT protocol"))
+   ft_protocol:depends({ieee80211r="1"})
+   ft_protocol:value("1", translatef("FT over DS"))
+   ft_protocol:value("0", translatef("FT over the Air"))
+   ft_protocol.rmempty = true
+
ft_psk_generate_local = s:taboption("encryption", Flag, 
"ft_psk_generate_local",
translate("Generate PMK locally"),
translate("When using a PSK, the PMK can be generated locally 
without inter AP communications"))
-- 
2.14.1


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

[LEDE-DEV] [PATCH 1/2] wifi: (80211r) add ft_psk_generate_local support

[Lorenzo Santina]

From: Lorenzo Santina 

If you are using PSK you can use ft_psk_generate_local
to simplify 80211r configuration.

Signed-off-by: Lorenzo Santina 
---
 .../luasrc/model/cbi/admin_network/wifi.lua| 32 --
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git 
a/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua 
b/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua
index f9a2dee6c..8528f8624 100644
--- a/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua
+++ b/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua
@@ -793,9 +793,22 @@ if hwtype == "mac80211" or hwtype == "prism2" then
mobility_domain.datatype = "and(hexstring,rangelength(4,4))"
mobility_domain.rmempty = true
 
+   reassociation_deadline = s:taboption("encryption", Value, 
"reassociation_deadline",
+   translate("Reassociation Deadline"),
+   translate("time units (TUs / 1.024 ms) [1000-65535]"))
+   reassociation_deadline:depends({ieee80211r="1"})
+   reassociation_deadline.placeholder = "1000"
+   reassociation_deadline.datatype = "range(1000,65535)"
+   reassociation_deadline.rmempty = true
+
+   ft_psk_generate_local = s:taboption("encryption", Flag, 
"ft_psk_generate_local",
+   translate("Generate PMK locally"),
+   translate("When using a PSK, the PMK can be generated locally 
without inter AP communications"))
+   ft_psk_generate_local:depends({ieee80211r="1"})
+
r0_key_lifetime = s:taboption("encryption", Value, "r0_key_lifetime",
translate("R0 Key Lifetime"), translate("minutes"))
-   r0_key_lifetime:depends({ieee80211r="1"})
+   r0_key_lifetime:depends({ieee80211r="1", ft_psk_generate_local=""})
r0_key_lifetime.placeholder = "1"
r0_key_lifetime.datatype = "uinteger"
r0_key_lifetime.rmempty = true
@@ -803,21 +816,13 @@ if hwtype == "mac80211" or hwtype == "prism2" then
r1_key_holder = s:taboption("encryption", Value, "r1_key_holder",
translate("R1 Key Holder"),
translate("6-octet identifier as a hex string - no 
colons"))
-   r1_key_holder:depends({ieee80211r="1"})
+   r1_key_holder:depends({ieee80211r="1", ft_psk_generate_local=""})
r1_key_holder.placeholder = "4f577274"
r1_key_holder.datatype = "and(hexstring,rangelength(12,12))"
r1_key_holder.rmempty = true
 
-   reassociation_deadline = s:taboption("encryption", Value, 
"reassociation_deadline",
-   translate("Reassociation Deadline"),
-   translate("time units (TUs / 1.024 ms) [1000-65535]"))
-   reassociation_deadline:depends({ieee80211r="1"})
-   reassociation_deadline.placeholder = "1000"
-   reassociation_deadline.datatype = "range(1000,65535)"
-   reassociation_deadline.rmempty = true
-
pmk_r1_push = s:taboption("encryption", Flag, "pmk_r1_push", 
translate("PMK R1 Push"))
-   pmk_r1_push:depends({ieee80211r="1"})
+   pmk_r1_push:depends({ieee80211r="1", ft_psk_generate_local=""})
pmk_r1_push.placeholder = "0"
pmk_r1_push.rmempty = true
 
@@ -827,8 +832,7 @@ if hwtype == "mac80211" or hwtype == "prism2" then
"This list is used to map R0KH-ID (NAS 
Identifier) to a destination " ..
"MAC address when requesting PMK-R1 key from the R0KH 
that the STA " ..
"used during the Initial Mobility Domain Association."))
-
-   r0kh:depends({ieee80211r="1"})
+   r0kh:depends({ieee80211r="1", ft_psk_generate_local=""})
r0kh.rmempty = true
 
r1kh = s:taboption("encryption", DynamicList, "r1kh", 
translate("External R1 Key Holder List"),
@@ -837,7 +841,7 @@ if hwtype == "mac80211" or hwtype == "prism2" then
"This list is used to map R1KH-ID to a 
destination MAC address " ..
"when sending PMK-R1 key from the R0KH. This is also 
the " ..
"list of authorized R1KHs in the MD that can request 
PMK-R1 keys."))
-   r1kh:depends({ieee80211r="1"})
+   r1kh:depends({ieee80211r="1", ft_psk_generate_local=""})
r1kh.rmempty = true
-- End of 802.11r options
 
-- 
2.14.1


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

[LEDE-DEV] [LUCI] [PATCH 0/2] wifi: 80211r psk_generate_local and ft_ver_ds

[Lorenzo Santina]

When using a PSK, with ft_psk_generate_local the PMK is
generate locally simplifing the configuration of 80211r.

With ft_over_ds support the user can now choose if use
FT over DS protocol or FT over the Air protocol.

Lorenzo Santina (2):
  wifi: (80211r) add ft_psk_generate_local support
  wifi: (80211r) add ft_over_ds support

 .../luasrc/model/cbi/admin_network/wifi.lua| 38 ++
 1 file changed, 24 insertions(+), 14 deletions(-)

-- 
2.14.1


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

[LEDE-DEV] [PATCH v1 1/1] uclient-fetch: correct filename w/ multple URLs

[Philip Prindeville]

From: Philip Prindeville 

When uclient-fetch is called with multiple URL's, it derives the
first filename based on the URL. When it then handles the 2nd and
subsequent URLs, it assumes that it was called with a -O filename
argument as the output file, because it tries to overload the
variable output_file to mean 2 different things.

The fix is to use a bool to remember whether we were called with
an explicit output filename, i.e. with the -O argument, and not
overload output_file for this purpose.

Signed-off-by: Philip Prindeville 
---
 uclient-fetch.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/uclient-fetch.c b/uclient-fetch.c
index 
dff144b22b7b3cd2d5982a615b9c2d68deab5042..fb3ab45935d94dce4f40aeae9bea6d7f7edc1c37
 100644
--- a/uclient-fetch.c
+++ b/uclient-fetch.c
@@ -51,6 +51,7 @@ static bool proxy = true;
 static bool default_certs = false;
 static bool no_output;
 static const char *output_file;
+static bool saw_output_filename = false;
 static int output_fd = -1;
 static int error_ret;
 static off_t out_offset;
@@ -106,12 +107,12 @@ static int open_output_file(const char *path, uint64_t 
resume_offset)
else
flags = O_WRONLY | O_TRUNC;
 
-   if (!cur_resume && !output_file)
+   if (!cur_resume && !saw_output_filename)
flags |= O_EXCL;
 
flags |= O_CREAT;
 
-   if (output_file) {
+   if (saw_output_filename) {
if (!strcmp(output_file, "-")) {
if (!quiet)
fprintf(stderr, "Writing to stdout\n");
@@ -500,6 +501,16 @@ static int no_ssl(const char *progname)
return 1;
 }
 
+static int too_many_output_files(const char *progname)
+{
+   fprintf(stderr,
+   "%s: the -O output_file option can't be used for multiple "
+   "URLs unless its value is \"-\".\n",
+   progname);
+
+   return 1;
+}
+
 enum {
L_NO_CHECK_CERTIFICATE,
L_CA_CERTIFICATE,
@@ -616,6 +627,7 @@ int main(int argc, char **argv)
break;
case 'O':
output_file = optarg;
+   saw_output_filename = true;
break;
case 'P':
if (chdir(optarg)) {
@@ -651,6 +663,12 @@ int main(int argc, char **argv)
if (argc < 1)
return usage(progname);
 
+   /* doesn't make sense to use -O with multiple URL's unless you're
+* sending them all to stdout...
+*/
+   if (argc > 1 && saw_output_filename && strcmp(output_file, "-"))
+   return too_many_output_files(progname);
+
if (!ssl_ctx) {
for (i = 0; i < argc; i++) {
if (!strncmp(argv[i], "https", 5))
-- 
2.7.4


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

[LEDE-DEV] LEDE new image on gw5520

[Outback Dingo]

seems that ive lost my eth0 / eth1 interfeaces on a RECENT ... today
image built for the gw5520
i do however see the ifb0 and ifb1 interfaces... any ideas?

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

Re: [LEDE-DEV] Busybox weirdness

[Philip Prindeville]

> On Nov 2, 2017, at 4:24 AM, edgar.sol...@web.de wrote:
> 
> hey Phillip,
> 
> On 02.11.2017 03:36, Philip Prindeville wrote:
>> Can someone else please try to reproduce this?
> 
> yes, not exactly but wrong resulting file name nonetheless. it's obviously a 
> bug. looks like a variable reuse went awry as it always hit's the second 
> file, having fragments of the first file's name. i switched the files you 
> downloaded, just to test if there might be a server side influence.
> 
> :/tmp# wget 
> http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip 
> http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz
> Downloading 
> 'http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip'
> Connecting to 2400:cb00:2048:1::6810:262f:80
> Writing to 'GeoIPCountryCSV.zip'
> GeoIPCountryCSV.zip  100% |***|  2338k  0:00:00 
> ETA
> Download completed (2394696 bytes)
> Connecting to 2400:cb00:2048:1::6810:252f:80
> Writing to 'w;o▒w;o▒ntryCSV.zip'
> w;o▒w;o▒ntryCSV.zip  100% |***|  1496k  0:00:00 
> ETA
> Download completed (1532219 bytes)
> 
> vs.
> 
> :/tmp# wget http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz 
> http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
> Downloading 
> 'http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz'
> Connecting to 2400:cb00:2048:1::6810:262f:80
> Writing to 'GeoIPv6.csv.gz'
> GeoIPv6.csv.gz   100% |***|  1496k  0:00:00 
> ETA
> Download completed (1532219 bytes)
> Connecting to 2400:cb00:2048:1::6810:252f:80
> Writing to 'w▒o▒w▒o▒csv.gz'
> w▒o▒w▒o▒csv.gz   100% |***|  2338k  0:00:00 
> ETA
> Download completed (2394696 bytes)
> 
> this is on a Lede 17.01-SNAPSHOT, r3535+35-ee32de4 with '/bin/wget -> 
> uclient-fetch' on an Ubiquiti Loco M2.
> 
> ..ede


Thank you both for looking into this.

I poked around the code last night after sending out that email, and found that 
“output_file” was being overloaded and this was causing some side-effects.

I have a tentative fix which I’ll send out.

-Philip


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

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

[Mike Baker]

On 11/1/2017 5:18 PM, Hartmut Knaack wrote:

This raises some more questions: which terms and conditions did people 
have

to approve to get an @openwrt.org address? Where can these terms and
conditions be found? Is every email sent from such an address supposed to
be discussed and approved by the group before it gets sent?
Furthermore: how many percent of "the group" needs to agree when it comes
to disabling someones address? 50% or 67%?
The issue is the use of an openwrt email address to make an announcement 
on behalf of openwrt stating that openwrt had become lede without ever 
discussing it. There were no warning signs, everybody from openwrt 
suddenly found out that there was a new project and they had been kicked 
out.


- Mike

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

Re: [LEDE-DEV] [PATCH] musl: update to 1.1.17 - LEDE version numbers?

[James Feeney]

On 11/01/2017 12:15 PM, Hannu Nyman wrote:
> At the first glance LEDE r5217-098afa1e1b compiled with 1.1.18 booted ok and
> got normally a DHCP wan address, hostapd started etc..

Excuse me what?!  "LEDE r5217-098afa1e1b"?

Why does that look like a "release 5217" and a SHA prefix "098afa1e1b"?

So what - does LEDE have two completely different versioning systems?  Is LEDE 
switching over to the openwrt versioning system?  From where comes the "r5217"? 
 Is that "r5217" a strictly reproducible LEDE version?

Somebody, please clue me in here.

___
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

[Zoltan HERPAI]

Hi Hauke,

Hauke Mehrtens wrote:

On 10/26/2017 09:05 PM, Dave Taht wrote:
  

Hannu Nyman  writes:



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?
  

I incidentally have always liked the in-your-face anti-establishment
flair of using codenames based on alcoholic beverages. The drink meme
beats the hell out of corporate blandness with selecting codenames out
of a marketing jar - "Project Olympus!", and is easier to remember than
17.X.Y.

"Blurry fish butt" I think was (until recently) a codename for the linux kernel.

and I've joked elsewhere that I'd like a codename named "green goddess".

https://www.allbud.com/marijuana-strains/sativa-dominant-hybrid/green-goddess



Please get rid of it. It makes the whole thing looks adolescent.
  

And replace it with what? (where was the voting?)


The vote happened here:
http://lists.infradead.org/pipermail/lede-adm/2017-October/000636.html

I am also for removing this, without the code names it does not makes
any sense.

This banner is the first thing companies change to add they own brand.

If you want to annoy them, use this license in some important part: ;-)
WTFPL (Do What the Fuck You Want To Public License)
  


Fine, then please advise where else this needs to be removed from, 
before I send the v3.


$ grep RELEASE include/version.mk
RELEASE:=Reboot
VERSION_NICK:=$(if $(VERSION_NICK),$(VERSION_NICK),$(RELEASE))

For the sake of full transparency, Imre and me was not part of the vote, 
as that was sent to lede-adm, without including openwrt-hackers or 
openwrt-devel.


Regards,
Zoltan H


___
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

[Hauke Mehrtens]

On 10/26/2017 09:05 PM, Dave Taht wrote:
> Hannu Nyman  writes:
> 
>> 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?
> 
> I incidentally have always liked the in-your-face anti-establishment
> flair of using codenames based on alcoholic beverages. The drink meme
> beats the hell out of corporate blandness with selecting codenames out
> of a marketing jar - "Project Olympus!", and is easier to remember than
> 17.X.Y.
> 
> "Blurry fish butt" I think was (until recently) a codename for the linux 
> kernel.
> 
> and I've joked elsewhere that I'd like a codename named "green goddess".
> 
> https://www.allbud.com/marijuana-strains/sativa-dominant-hybrid/green-goddess
> 
>> Please get rid of it. It makes the whole thing looks adolescent.
> 
> And replace it with what? (where was the voting?)
The vote happened here:
http://lists.infradead.org/pipermail/lede-adm/2017-October/000636.html

I am also for removing this, without the code names it does not makes
any sense.

This banner is the first thing companies change to add they own brand.

If you want to annoy them, use this license in some important part: ;-)
WTFPL (Do What the Fuck You Want To Public License)


Hauke

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

Re: [LEDE-DEV] Busybox weirdness

[edgar . soldin]

hey Phillip,

On 02.11.2017 03:36, Philip Prindeville wrote:
> Can someone else please try to reproduce this?
 
yes, not exactly but wrong resulting file name nonetheless. it's obviously a 
bug. looks like a variable reuse went awry as it always hit's the second file, 
having fragments of the first file's name. i switched the files you downloaded, 
just to test if there might be a server side influence.

:/tmp# wget 
http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip 
http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz
Downloading 
'http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip'
Connecting to 2400:cb00:2048:1::6810:262f:80
Writing to 'GeoIPCountryCSV.zip'
GeoIPCountryCSV.zip  100% |***|  2338k  0:00:00 ETA
Download completed (2394696 bytes)
Connecting to 2400:cb00:2048:1::6810:252f:80
Writing to 'w;o▒w;o▒ntryCSV.zip'
w;o▒w;o▒ntryCSV.zip  100% |***|  1496k  0:00:00 ETA
Download completed (1532219 bytes)

vs.

:/tmp# wget http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz 
http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
Downloading 'http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz'
Connecting to 2400:cb00:2048:1::6810:262f:80
Writing to 'GeoIPv6.csv.gz'
GeoIPv6.csv.gz   100% |***|  1496k  0:00:00 ETA
Download completed (1532219 bytes)
Connecting to 2400:cb00:2048:1::6810:252f:80
Writing to 'w▒o▒w▒o▒csv.gz'
w▒o▒w▒o▒csv.gz   100% |***|  2338k  0:00:00 ETA
Download completed (2394696 bytes)

this is on a Lede 17.01-SNAPSHOT, r3535+35-ee32de4 with '/bin/wget -> 
uclient-fetch' on an Ubiquiti Loco M2.

..ede



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

Re: [LEDE-DEV] Busybox weirdness

[tv.debian--- via Lede-dev]

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 02/11/2017 09:42, Philip Prindeville wrote:



On Nov 1, 2017, at 8:36 PM, Philip Prindeville 
 wrote:

Can someone else please try to reproduce this?

I’m using busybox’s wget on x86_64 hardware, and when I do a “wget” of 2 http: 
URI’s, it mangles the second URI’s derived filename:


root@lede:/tmp/x# c
Downloading 'http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz'
Connecting to 104.16.37.47:80
Writing to 'GeoIPv6.csv.gz'
GeoIPv6.csv.gz   100% |***|  1496k  0:00:00 ETA
Download completed (1532219 bytes)
Connecting to 104.16.37.47:80
Writing to ' z;'
z;   100% |***|  2338k  0:00:00 ETA
Download completed (2394696 bytes)
root@lede:/tmp/x# ls
z;??  GeoIPv6.csv.gz
root@lede:/tmp/x#


What the heck?

-Philip



Well, I was selecting busybox’s wget, but it was silently being overwritten by 
something else:

root@lede:/tmp/x# ls -l /bin/wget
lrwxrwxrwx1 root root13 Nov  1 19:17 /bin/wget -> 
uclient-fetch
root@lede:/tmp/x#

so that’s the real culprit.


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



I can reproduce partially (17.01.4), here I get garbled filename that 
seems due to charset mismatch:


wget http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz 
http://geolite.maxmind.com/download/geoip/da

tabase/GeoIPCountryCSV.zip
Downloading 
'http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz'

Connecting to 2400:cb00:2048:1::6810:262f:80
Writing to 'GeoIPv6.csv.gz'
GeoIPv6.csv.gz   100% |***|  1496k 
0:00:00 ETA

Download completed (1532219 bytes)
Connecting to 2400:cb00:2048:1::6810:252f:80
Writing to '��csv.gz'
��csv.gz   100% |***|  2338k 
0:00:00 ETA

Download completed (2394696 bytes)

It also misbehaves if the download is somehow redirected over https, for 
example while downloading wrtbwmon i get:


wget 
https://github.com/Kiougar/luci-wrtbwmon/releases/download/v0.6.0/luci-wrtbwmon_0.6.0_all.ipk
Downloading 
'https://github.com/Kiougar/luci-wrtbwmon/releases/download/v0.6.0/luci-wrtbwmon_0.6.0_all.ipk'

Connecting to 192.30.253.112:443
Redirected to 
/77686685/247a31e2-494d-11e7-818a-29601f00a0dc?X-Amz-Algorithm=AWS4-HMAC-SHA256=AKIAIWNJYAX4CSVEH53A%2F20171102%2Fus-east-1%2Fs3%2Faws4_request=20171102T073145Z=300=fc898a693aeb4664ba1bc51de9ae2d2f791707e50829d7fb9b4ceaae4d99bd53=host_id=0=attachment%3B%20filename%3Dluci-wrtbwmon_0.6.0_all.ipk=application%2Foctet-stream 
on github-production-release-asset-2e65be.s3.amazonaws.com
Writing to 
'247a31e2-494d-11e7-818a-29601f00a0dc?X-Amz-Algorithm=AWS4-HMAC-SHA256'
247a31e2-494d-11e7-8 100% |***|  5245 
0:00:00 ETA

Download completed (5245 bytes)

None of this happens with plain wget (and ca-certificates) installed.

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