Hi,
I am currently adding LEDE support for the Netgear DM200 VDSL modem
[https://wiki.openwrt.org/toh/netgear/dm200], which uses a Lantiq VR9 SoC.
I was able to boot LEDE from RAM, and got the LEDs working, but I cannot
get the flash to work with LEDE :(
The bootloader (u-boot) has access to the
On Sun, Apr 02, 2017 at 06:16:10PM +0200, Hauke Mehrtens wrote:
> The Vendor SDK is based on UGW 6.1.1, based on OpenWrt 12.09 with kernel
> 3.10 and device tree support. Probably even the vendor image uses a
> device tree compiled into the kernel image.
> According to the configuration file in
> /
Hi,
On Thu, Apr 27, 2017 at 04:33:31PM -0700, Henry Chang wrote:
> Hi,
>
> I would like to integrate logd with a cloud logging service.
> The service only accepts certain format of log, so I decided to make logread
> support an output template.
Can't this service use standard syslog messages?
On Sat, May 06, 2017 at 08:08:54PM +0200, Mathias Kresin wrote:
> 06.05.2017 14:31, Sven Roederer:
> >On Freitag, 5. Mai 2017 14:32:12 CEST Mathias Kresin wrote:
> >>Is it necessary to control the GPIOs from userspace/via config files?
> >>If not, add a gpio_export node to the dts and set the outpu
Hi,
On Thu, Jun 15, 2017 at 04:41:50PM +0200, Jo-Philipp Wich wrote:
> > ... and, if I may throw my EUR 0.02 in, why not recompile dropbear
> > with "elliptic curve" support?
>
> whats the size impact?
There is already an option DROPBEAR_ECC to enable ECDSA, disabled by
default, and it adds 23 K
From: Baptiste Jonglez
This subtarget was added by 961c0eac, probably by mistake. It does
not contain anything beside a kernel config.
Cc: Daniel Golle
Signed-off-by: Baptiste Jonglez
---
target/linux/x86/epia/config-4.4 | 213 ---
1 file changed, 213
From: Baptiste Jonglez
This was done by simply running `make kernel_menuconfig CONFIG_TARGET=subtarget`
and then saving without changing any option.
Most of the removed options can be explained because they are already
present in the target config or in the generic 4.9 config:
- PAE-related
From: Baptiste Jonglez
Xen support for x86/generic was added in 1d6879ee. This commit also
enables it for x86/64.
This was successfully tested with Xen 4.5, although the serial console
is broken in the same way as x86/generic (see FS#787)
Signed-off-by: Baptiste Jonglez
---
.../x86/64/base
From: Baptiste Jonglez
All x86 subtargets enable USB support, so it makes sense to enable it
in the target config instead, to avoid duplication.
Also refresh subtarget configs accordingly.
Signed-off-by: Baptiste Jonglez
---
target/linux/x86/64/config-default | 9 -
target
From: Baptiste Jonglez
The Xen serial console has been broken since the xen_domu subtarget
was merged in the generic x86 subtarget (commits 1d6879ee and 371b382a).
The reason for the broken serial console seems to be an IRQ conflict
between the serial console driver and the PATA_LEGACY driver
From: Baptiste Jonglez
This is a backport of 641a65fd062987a456216cc4fa91ff2910528261 in master.
This change re-enables PAE for the 32-bit x86 subtarget, which is
interesting in its own right but also necessary for Xen support.
Commit af1d1ebd ("x86: enable 4G high memory support for ge
From: Baptiste Jonglez
Xen support for x86/generic was added in 296772f9. This commit also
enables it for x86/64.
This was successfully tested with Xen 4.5.
Signed-off-by: Baptiste Jonglez
---
target/linux/x86/64/config-default | 59 +-
1 file changed, 58
From: Baptiste Jonglez
This was done by simply running `make kernel_menuconfig CONFIG_TARGET=subtarget`
and then saving without changing any option.
Having consistent kernel config is important to avoid surprises, such
as the issue fixed with 6f0367c9 (where Xen support was silently
disabled
From: Baptiste Jonglez
The Xen serial console has been broken since the xen_domu subtarget
was merged in the generic x86 subtarget (commits 296772f9 and b36e24f3).
The reason for the broken serial console seems to be an IRQ conflict
between the serial console driver and the PATA_LEGACY driver
On Sun, Jul 16, 2017 at 02:00:30AM +0200, Daniel Golle wrote:
> On Sat, Jul 15, 2017 at 06:47:58PM +0200, Baptiste Jonglez wrote:
> > This subtarget was added by 961c0eac, probably by mistake. It does
> > not contain anything beside a kernel config.
>
> Ouh, sorry, that wa
Hi,
On Tue, Jul 11, 2017 at 12:04:13PM -0400, W. Michael Petullo wrote:
> Luiz pointed out that some versions of LEDE seem to support the Xen
> PVHVM drivers, so I decided to investigate this. I looked at:
>
> x86-17.01.2:
> http://downloads.lede-project.org/releases/17.01.2/targets/x86/gener
blinks at this...
This is x86, not exactly space-constrained.
As a trade-off against more complexity and buildbot ressources, it makes
sense to push more functionalities in a reduced number of build variants.
> > On Jul 15, 2017, at 10:48 AM, Baptiste Jonglez
> > wrote:
> >
> &g
From: Baptiste Jonglez
All patches have been refreshed, and upstream patches have been dropped.
Compile tested: ar71xx, at91, bcm53xx, brcm47xx, brcm63xx, gemini, ixp4xx,
lantiq, layerscape, malta, mvebu
Run tested: ar71xx
Signed-off-by: Baptiste Jonglez
---
include/kernel
Hi Koen,
Just so you know, it's not the first time that there are several identical
submissions to bump the kernel version. See this pull request that also
updates kernel to 4.9.39:
https://github.com/lede-project/source/pull/1236
No need to duplicate time and efforts :)
Baptiste
On Mon,
Hi,
On Sat, Jul 29, 2017 at 06:20:00AM +, txt.file wrote:
> Hey folks,
>
> I tried to build lede 17.01.2 which is using libressl 2.5.0 bug got an
> build error. The problem looks similar to the error described at
> https://wiki.debian.org/X32Port#amd64_assembly.
>
> bn/bn_div.c:279: Error: i
Hi,
On Sat, Jul 29, 2017 at 10:09:07PM +0200, Magnus Kroken wrote:
> Refresh patches, delete patches backported from upstream.
Thanks for the update! You can drop 120-remove_uclibc_rpc_check.patch
altogether, since the check has been changed from an error to a warning.
> Some BusyBox config sym
From: Baptiste Jonglez
Since mbedtls 2.5.1, SHA1 has been disallowed in TLS certificates.
This breaks openvpn clients that try to connect to servers that
present a TLS certificate signed with SHA1, which is fairly common.
Run-tested with openvpn-mbedtls 2.4.3, LEDE 17.01.2, on ar71xx.
Fixes
On Sun, Jul 30, 2017 at 05:57:37PM +0200, Baptiste Jonglez wrote:
> Since mbedtls 2.5.1, SHA1 has been disallowed in TLS certificates.
> This breaks openvpn clients that try to connect to servers that
> present a TLS certificate signed with SHA1, which is fairly common.
>
>
On Sun, Jul 30, 2017 at 06:00:48PM +0200, Baptiste Jonglez wrote:
> On Sun, Jul 30, 2017 at 05:57:37PM +0200, Baptiste Jonglez wrote:
> > Since mbedtls 2.5.1, SHA1 has been disallowed in TLS certificates.
> > This breaks openvpn clients that try to connect to servers that
&g
On Mon, Jul 31, 2017 at 06:11:49PM +0200, John Crispin wrote:
> I rebased my ages old kernel patch cleanup series. It can be found here [1].
>
> the series annotates all patches and splits them up into 3 folders
> backports/pending/hacks.
>
> I'd like to push this asap if there are no mayor issue
Hi,
As far as I can tell, the b43 driver does not support AC chipsets like
BCM4352, BCM4360, BCM4366. Support for these is marked BROKEN upstream.
This means that a few devices supported by LEDE actually have no wireless,
for instance Archer C9 v1, ASUS RT-AC68U, maybe others. Also, quite a lot
ste
> On Tue, 2017-08-01 at 00:42 +0200, Baptiste Jonglez wrote:
> > Hi,
> >
> > As far as I can tell, the b43 driver does not support AC chipsets
> > like
> > BCM4352, BCM4360, BCM4366. Support for these is marked BROKEN
> > upstream.
> >
> > T
Hi,
On Sat, Aug 05, 2017 at 06:15:46PM -0700, Rosen Penev wrote:
> LEDE currently uses CUBIC and not RENO by default. In theory, this
> change should remove RENO from the kernel, but it doesn't. Might
> as well keep it like this in case something changes.
As far as I can tell, Reno is hard-wired
On Wed, Aug 09, 2017 at 02:35:13AM -0700, Amir Sabbaghi wrote:
> Hi everyone,
>
> I have a MT7620A based router which is supposed to handle 300Mbps of
> bandwidth over WiFi. But during my tests I could only get around
> 50Mbps which is very unstable and changes between 20Mbps to to 70Mbps.
> What
On 18-08-17, Karl Palsson wrote:
> > This means that the archive will have a different checksum, and
> > thus affects reproducability. [1] suggests this is because of a
> > different block size default, but unfortunately there seems to
> > be no way to set the block size in an attempt to make it us
On 23-08-17, Koen Vandeputte wrote:
> Now this one pops up again (reported by Mauro Mozzarelli yesterday):
>
>
> find
> /mnt/ramdisk/test/firmware/builds/generic_imx6/build_dir/target-arm_cortex-a9+neon_musl_eabi/util-linux-2.30.1/ipkg-arm_cortex-a9_neon/dmesg
> -name 'CVS' -o -name '.svn' -o -n
From: Baptiste Jonglez
The order of LAN ports shown in Luci is reversed compared to what is
written on the case of the device. Fix the order so that they match.
Signed-off-by: Baptiste Jonglez
---
This patch applies cleanly to the lede-17.01 branch and should
be backported there too.
target
On 25-08-17, Kevin Darbyshire-Bryant wrote:
> I have dnsmasq listening on the bridge interfaces - it's happy doing so and
> says it's listening on the link local address (effectively the same address
> many times) all ok. It also listens on the global address. If I configure
> dns clients to use
Hi,
On 25-07-17, Sven Roederer wrote:
> On Samstag, 15. Juli 2017 22:57:53 CEST Baptiste Jonglez wrote:
> > From: Baptiste Jonglez
> >
> > This is a backport of 641a65fd062987a456216cc4fa91ff2910528261 in master.
> >
> > This change re-enables PAE for t
Hi,
On 03-08-17, Hauke Mehrtens wrote:
> This adds initial support for the A64 Allwinner SoC to LEDE.
> It will be build in the new cortexa53 subtarget.
>
> Currently it only supports the pine64 and the image is able to boot on
> this SoC.
Thanks for the patches!
I tested them on a pine64+ 1GB
On 29-08-17, Baptiste Jonglez wrote:
> Hi,
>
> On 03-08-17, Hauke Mehrtens wrote:
> > This adds initial support for the A64 Allwinner SoC to LEDE.
> > It will be build in the new cortexa53 subtarget.
> >
> > Currently it only supports the pine64 and the imag
On 01-09-17, Rosen Penev wrote:
> ssh and scp commands interfere with OpenSSH when installed in /usr/bin .
>
> One use case is when installing dropbear to get root access when only OpenSSH
> is available (OpenSSH disallows root password logins). Once dropbear
> installs, it replaces OpenSSH's ex
From: Baptiste Jonglez
Currently, if the provided hash is unsupported (length different from 32
or 64 bytes), we happily download the requested file without any kind of
checksum verification.
This is quite dangerous and may provide a false sense of security, because
a single typo in the hash
Hi,
On 05-09-17, Alexandru Ardelean wrote:
> The `proto_add_dynamic_defaults()` seems to be called mostly
> in the context of LTE/3G modems (via wwan, qmi, etc) setup.
>
> When they get setup, these devices override default routes.
>
> However, depending on setup, we want these modems to
> be pa
On 09-09-17, Baptiste Jonglez wrote:
> On 05-09-17, Alexandru Ardelean wrote:
> > The `proto_add_dynamic_defaults()` seems to be called mostly
> > in the context of LTE/3G modems (via wwan, qmi, etc) setup.
> >
> > When they get setup, these devices override defau
Thanks for merging, can this be merged to lede-17.01 as well?
On 03-09-17, Baptiste Jonglez wrote:
> Currently, if the provided hash is unsupported (length different from 32
> or 64 bytes), we happily download the requested file without any kind of
> checksum verification.
>
>
Can this be merged to lede-17.01? As I mentioned in the commit, it
applies cleanly.
Thanks,
Baptiste
On 23-08-17, Baptiste Jonglez wrote:
> The order of LAN ports shown in Luci is reversed compared to what is
> written on the case of the device. Fix the order so that they match.
>
Hi,
On 14-09-17, Toke Høiland-Jørgensen wrote:
> Toke Høiland-Jørgensen writes:
>
> > The upstream ath10k driver disables the intermediate softqueues for some
> > devices. This patch reverts that behaviour and always enables the
> > softqueues (and associated bufferbloat fixes). We have had repo
On 19-09-17, Toke Høiland-Jørgensen wrote:
> Baptiste Jonglez writes:
>
> > Hi,
> >
> > On 14-09-17, Toke Høiland-Jørgensen wrote:
> >> Toke Høiland-Jørgensen writes:
> >>
> >> > The upstream ath10k driver disables the intermediate softq
Hi,
minidlna belongs to the package feed: this patch (and the follow-up ones)
should be submitted to https://github.com/openwrt/packages/ and
https://github.com/openwrt/luci
Baptiste
On 23-09-17, James Christopher Adduono wrote:
> 1.2.1 - Released 24-Aug-2017
>
>
Hi,
On 24-09-17, Stijn Tintel wrote:
> On 03-09-17 15:01, Baptiste Jonglez wrote:
> > Note: if some users of scripts/download.pl knowingly provide an empty hash
> > because they don't need checksum verification, this change will break
> > them. This does not seem to be
On 24-09-17, Stijn Tintel wrote:
> My bad. When we update a package, we bump the version in the Makefile
> and remove the current hash, then run "make package/foo/dowload; make
> package/foo/check FIXUP=1". This downloads the tarbal for the new
> version, and FIXUP writes its hash to the Makefile.
Hi,
Any chance to get this patch serie merged to the lede-17.01 branch?
As far as I can tell:
- Xen support is still broken in 17.01
- this patch serie still applies cleanly
Thanks,
Baptiste
On 15-07-17, Baptiste Jonglez wrote:
> From: Baptiste Jonglez
>
> This is a ba
On 08-10-17, Stijn Tintel wrote:
> On 25-09-17 18:43, Stijn Tintel wrote:
> > On 25-09-17 00:20, Baptiste Jonglez wrote:
> >> On 24-09-17, Stijn Tintel wrote:
> >>> My bad. When we update a package, we bump the version in the Makefile
> >>> and remove th
On 16-10-17, Felix Fietkau wrote:
> On 2017-10-16 09:43, Baptiste Jonglez wrote:
> > Hi,
> >
> > Any chance to get this patch serie merged to the lede-17.01 branch?
> > As far as I can tell:
> >
> > - Xen support is still broken in 17.01
> > - this pa
Hi,
On 23-10-17, Emmanuel Grumbach wrote:
> I just bought a TP-Link Archer C7 AC1750 and got the v4.0 version. I
> haven't found any image in
> https://lede-project.org/toh/views/toh_fwdownload that claims it
> features that version. I can see v1 and v2, but not v4.
Support for this board has jus
Hi Hauke,
On 03-08-17, Hauke Mehrtens wrote:
> This adds initial support for the A64 Allwinner SoC to LEDE.
> It will be build in the new cortexa53 subtarget.
>
> Currently it only supports the pine64 and the image is able to boot on
> this SoC.
This was merged a while ago, but I gave it another
On 23-10-17, Hauke Mehrtens wrote:
> Could you try an image build the sunxi branch of my staging tree please:
> https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/sunxi
>
> I backproted the MMC driver in there as it got some patches which are
> probably needed for the A
Hi,
As an occasional contributor to OpenWrt/LEDE, I am often frustrated by the
lack of good technical documentation. By "technical documentation", I
mean a detailed, reasonably complete and up-to-date documentation on "How
things work under the hood" and "How to do advanced stuff with the build
s
When the new "--skip-hash" option is passed to scripts/download.pl, hash
verification of the downloaded files is completely skipped. This can be
useful when bumping package version, since the hash may not be known in
advance.
Signed-off-by: Baptiste Jonglez
---
scripts/downlo
("scripts/download.pl: fail loudly if provided hash is
unsupported")
Signed-off-by: Baptiste Jonglez
---
include/download.mk | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/download.mk b/include/download.mk
index 0a25641738..a6821b5304 100644
--- a/include/d
On 26-10-17, Karl Palsson wrote:
> Until/if your new documentation project takes off, please
> consider adding this to the "how to package" doc pages. none of
> these extra magical parameters are discoverable in any way right
> now.
Fully agreed, all this is magical enough :) While writing this p
On 27-10-17, Yousong Zhou wrote:
> On 26 October 2017 at 17:50, Baptiste Jonglez wrote:
> > When calling a download target, hash verification is now completely
> > skipped if the SKIPHASH variable is set.
> >
> > This allows to easily bump package version:
> >
&g
Hi,
On 24-10-17, John Norton wrote:
> On 24/10/2017 18:02, Javier Domingo Cansino wrote:
> Imho (what I would do) is just migrate current LEDE wiki content in OpenWRT
> wiki,
> while current OpenWRT stuff is either obsoleted (where it is replaced by the
> LEDE wiki articles) or moved to suit the s
From: Baptiste Jonglez
OpenSSL is built with the generic linux settings for most targets,
including aarch64. These generic settings are designed for 32-bit CPU and
provide no assembler optmization: this is widely suboptimal for aarch64.
This patch simply switches to the aarch64 settings that
Hi Thomas,
On 27-10-17, Thomas Endt wrote:
> That's contrary to your statements in the start posting:
>
> > [...] documentation targeted at hackers, contributors, and would-be
> > developers.
> > [...] RFC proposal of a new developer documentation
> > Links [1] [2] [3]
> > [...] more focused sco
Hi Alberto,
On 27-10-17, John Norton wrote:
> On 27/10/2017 10:46, Baptiste Jonglez wrote:
> >On 24-10-17, John Norton wrote:
> >>On 24/10/2017 18:02, Javier Domingo Cansino wrote:
> >>Imho (what I would do) is just migrate current LEDE wiki content in OpenWRT
> >
Hi,
On 27-10-17, Javier Domingo Cansino wrote:
> > This problem is well-known [1,2] and can be solved by having access to a
> > common ancestor between the two versions. A possible way to do this would
> > be to convert each wiki to a git repository [3], merge the two histories
> > using git, and
ow until I investigate.
SHA does seem to give correct results though (and is really fast).
On 27-10-17, Baptiste Jonglez wrote:
> OpenSSL is built with the generic linux settings for most targets,
> including aarch64. These generic settings are designed for 32-bit CPU and
> provide no assemble
On 28-10-17, Baptiste Jonglez wrote:
> The awesome AES performance was too good to be true: it seems to produce
> incorrect results when encrypting on the pine64 and decrypting on a x86_64
> machine :(
> Possibly some assembler is optimized away by the compiler, which would
> expl
From: Baptiste Jonglez
This patch is marked [RFC] because this is such a huge change, and some
dependent packages now fail to build because of API changes. Also, there
is no parallel build for now, but this was already the case with 1.0.2l.
Feedback is welcome!
Here is a summary of the changes
Hi,
Thanks for feedback!
On 31-10-17, Philip Prindeville wrote:
> I’d also note that some of the compatibility stuff has been deprecated,
> hasn’t it?
What do you mean?
> > define Package/openssl/Default/description
> > -The OpenSSL Project is a collaborative effort to develop a robust,
> > -c
Hi Stijn,
What is your opinion on this patch? There has been a bit of feedback, but
you were the one requesting the change in the first place :)
Thanks,
Baptiste
On 26-10-17, Baptiste Jonglez wrote:
> When calling a download target, hash verification is now completely
> skipped if the SK
On Mon, Nov 07, 2016 at 06:23:49AM +0100, Rafał Miłecki wrote:
> On 7 November 2016 at 00:40, Russell Senior wrote:
> > I have a 16-core build box which I connect to over ssh. I use scp to
> > move images to devices. I have a testbed with ethernet connections to
> > the build box and serial cons
On Mon, Nov 07, 2016 at 09:51:31AM +0100, Rafał Miłecki wrote:
> >> But what about development with modifying files in build_dir? That's
> >> the most tricky part for me.
> >
> > What do you mean exactly?
>
> Like working with quilt to modify software (kernel/packages) in the build_dir.
I see, I
Hi Jason,
Thanks for the patch. Wireguard is not part of the core OpenWRT/LEDE
systems, it is managed on https://github.com/openwrt/packages , so you
should have sent a pull request there.
Nevertheless, I will try to test and apply your patch within a few days.
Baptiste
On Thu, Nov 10, 2016 at
On Thu, Nov 10, 2016 at 04:07:44AM +0100, Jason A. Donenfeld wrote:
> The padata API is a powerful framework for doing parallel jobs inside
> the kernel, on which various modules in the package feed can depend,
> such as WireGuard. There is no item text, so that it does not show up
> in menuconfig,
Hi,
I discovered that tons of packages now have their own page in the wiki,
which is nice. It looks automated, what is the source of the data?
Here are a few observations:
- I'm not sure the list of architectures is very relevant, and it clutters
the page a lot. See for instance
https://wik
Hi,
There is a small usability issue with the wiki: there is no easy way to
get a permalink to a page section (i.e. a link that includes an anchor).
First, it would be nice to have a small clickable permalink just beside a
section title.
Also, there is a bug in the table of contents of a page.
On Wed, Nov 16, 2016 at 07:23:02PM +0100, Thomas Endt wrote:
> > There is a small usability issue with the wiki: there is no easy way to
> > get a permalink to a page section (i.e. a link that includes an
> > anchor).
> >
> > First, it would be nice to have a small clickable permalink just beside
Hi,
On Thu, Nov 17, 2016 at 07:25:21AM +0100, Rafał Miłecki wrote:
> If something goes wrong and script can't find upstream revision it will
> return something like:
> r2220
> which looks like a valid upstream revision 2220. We cant' distinguish it
> from e.g. 2200 upstream commits and 20 local on
Hi jow,
On Thu, Dec 01, 2016 at 06:34:42PM +0100, Jo-Philipp Wich wrote:
> After this commit, the relevent files will look like the examples given below:
> # cat /usr/lib/os-release
> NAME="LEDE"
> VERSION="CURRENT, Reboot"
> ID="lede"
> ID_LIKE="lede openwrt"
> PRETTY_NAME
Hi,
While investigating an issue with module loading order¹, I discovered that
some kernel packages use AutoProbe, like this:
AUTOLOAD:=$(call AutoProbe,xt_hashlimit)
while some kernel packages use the AutoLoad helper I was used to, with a
priority:
AUTOLOAD:=$(call AutoLoad,28,raid0)
Dear babeld users on OpenWRT/LEDE,
Starting from babeld 1.5.1, the UCI format for configuring babeld on
OpenWRT had changed to be more consistent with upstream babeld (use the
same option names, and a few other changes).
At the time, I had ensured backward compatibility, see:
https://wiki.open
Hi,
I am using the "procd_set_param file" feature of procd, so that calling
"/etc/init.d/myscript reload" only restarts the process if one of the
config file has changed.
I was wondering if I can do the same thing on a directory? Basically, my
daemon can now take configuration from all files in
Hi Sebastian,
On Mon, Dec 19, 2016 at 11:58:26PM +0100, Sebastian Kemper wrote:
> Hi all,
>
> I'm running LEDE git from yesterday (but also observed this on an older
> git revision from a few weeks back) on a small mips router. When I start
> freeswitch compiled without libedit via procd, CPU usa
On Mon, Jan 09, 2017 at 04:36:25PM +0100, Felix Fietkau wrote:
> It does not support passing a directory. You should do:
> procd_set_param file /tmp/babeld.d/*.conf (without quotes)
I wanted to avoid this solution if possible, because it does not handle
file creation. However, that is not a major
On Mon, Jan 09, 2017 at 04:58:23PM +0100, Baptiste Jonglez wrote:
> On Mon, Jan 09, 2017 at 04:36:25PM +0100, Felix Fietkau wrote:
> > It does not support passing a directory. You should do:
> > procd_set_param file /tmp/babeld.d/*.conf (without quotes)
>
> I wanted to a
On Tue, Jan 10, 2017 at 07:56:36AM +0100, John Crispin wrote:
> >> While investigating an issue with module loading order¹, I discovered
> >> that
> >> some kernel packages use AutoProbe, like this:
> >>
> >> AUTOLOAD:=$(call AutoProbe,xt_hashlimit)
> >>
> >> while some kernel packages use the
On Tue, Jan 10, 2017 at 07:11:56PM +0800, Yousong Zhou wrote:
> On 10 January 2017 at 18:27, John Crispin wrote:
> > correct, which is why we tend to add subsystem and lib stuff using
> > AutoLoad and the rest using AutoProbe
>
> I think the problem with wireguard in github issue 3790 [1] is that
Hi,
Here is yet another OpenWRT-related change for babeld: I just merged procd
support for babeld [2], after more than two years of lingering [1].
The only user-visible changes should be:
- babeld now logs to the system log (visible with "logread") instead of a
file in /var/log. This is nice
Hi Dennis,
Please report this bug to the specific package feed:
https://github.com/openwrt/telephony
It simply looks like a missing dependency (libxml), but bug reports like
this should go there, so that maintainers can do something.
Baptiste
On Tue, Jan 31, 2017 at 10:10:13AM +0100, Dennis Sc
Hi,
Thanks for taking care of this!
On Fri, Jan 27, 2017 at 06:57:40PM -0500, Rich Brown wrote:
> Since no changes have occurred to the release notes in the last 5 days, I
> assume they are complete and final.
>
> If you wish to prove me wrong, please send me a note, or update them directly
>
On Tue, Jan 31, 2017 at 05:20:13PM +0100, Daniel Golle wrote:
> openvpn-mbedtls didn't like my vpn server for some reason:
> The certificate is signed with an unacceptable hash.
>
> openvpn-openssl worked without any problems.
This looks similar to this bug report:
https://bugs.lede-project.or
On Tue, Jan 31, 2017 at 10:14:04AM +, David Woodhouse wrote:
> On Tue, 2017-01-31 at 10:54 +0100, Baptiste Jonglez wrote:
> >
> > - IPv6 support: since that was the focus of CC, at least mention that
> > nothing was intentionally broken (and maybe there were s
Hi,
On Sun, Feb 05, 2017 at 04:50:29PM +, Nick Lowe wrote:
> I have an apu2c4 (quad core AMD GX-412TC) with two AR9390 cards, one
> offering service at 2.4 GHz and one offering service at 5 GHz with the
> same SSID.
>
> I decided to test out the latest x86-64 LEDE snapshot, as of this
> Satur
From: Baptiste Jonglez
When running "make kernel_menuconfig" in a clean tree, it fails with:
make[1]: *** No rule to make target 'tools/quilt/install'. Stop.
Replacing the dependency with 'tools/quilt/compile' fixes the issue (quilt
and all its prerequisites
From: Baptiste Jonglez
When the source repository is on a detached commit (such as when building
a release tag), the git URL for the "base" feed is incorrect in the SDK.
Before this commit:
On branch "master": src-git base git://git.lede-project.org/source
On branc
Hi,
On Sun, Feb 19, 2017 at 12:06:20PM +, david--- via Lede-dev wrote:
> I have a MT7620A board with 2 ethernet ports. I connect the WAN port to
> another router and the LAN port to my laptop. During boot, my laptop gets an
> IP address from the parent router, because it seems that kernel is
>
On Sun, Feb 19, 2017 at 01:48:04PM +0100, yanosz wrote:
> Hello,
>
> I've some trouble installing kmod-ebtables on lede 17.01 rc2.
>
> root@Node-2:/etc/config# opkg install kmod-ebtables
> Package kmod-ebtables (4.4.47-1) installed in root is up to date.
It looks like kmod-ebtables is already in
Hi Thomas,
Is the github login integration supposed to work? There is a bug reported
about a 404 error when trying to login:
https://bugs.lede-project.org/index.php?do=details&task_id=531
Thanks!
Baptiste
On Sat, Oct 01, 2016 at 05:25:54PM +0200, Thomas Endt wrote:
> IIRC it was Martin who p
From: Baptiste Jonglez
This fixes FS#391 for lede-17.01
Signed-off-by: Baptiste Jonglez
---
.../patches/000-fix-servfail-handling.patch| 130 +
1 file changed, 130 insertions(+)
create mode 100644
package/network/services/dnsmasq/patches/000-fix-servfail
Sorry, I forgot to add the 17.01 tag. I am resending it with the proper tag.
On Mon, Feb 20, 2017 at 04:48:49PM +0100, Baptiste Jonglez wrote:
> From: Baptiste Jonglez
>
> This fixes FS#391 for lede-17.01
>
> Signed-off-by: Baptiste Jonglez
> ---
> .../pat
From: Baptiste Jonglez
This fixes FS#391 for lede-17.01
Signed-off-by: Baptiste Jonglez
---
.../patches/000-fix-servfail-handling.patch| 130 +
1 file changed, 130 insertions(+)
create mode 100644
package/network/services/dnsmasq/patches/000-fix-servfail
On Mon, Feb 20, 2017 at 06:52:15PM +, Alberto Bursi wrote:
> The wiki feature showing what packages are in LEDE (and some information
> about them) is now complete! Hooray! :)
>
> https://lede-project.org/packages/start
Great, thanks Alberto!
Here are a few questions and comments:
- what i
1 - 100 of 117 matches
Mail list logo
