As Hauke noted, whole patch is white space damaged. Please re-send properly.
> @@ -184,7 +204,7 @@ mtd_fixtrx(const char *mtd, size_t offset)
> }
>
> trx = (struct trx_header *) (buf + offset);
> - if (trx->magic != STORE32_LE(0x30524448)) {
> + if (!is_trx_magic(trx->magic)) {
Is dropping S
Karl Palsson wrote:
> > John Crispin wrote:
> > > On 27/05/2015 18:03, Karl Palsson wrote:
> > > > + my $this_feed_target = lookup_target($feed, $name);
> > > > + $this_feed_target and do {
> > >
> > > how about just calling it $target ?
> >
> > Because even though the method is "l
* micke.p...@telldus.se [2015-06-22 12:37:47 +0200]:
> I have discovered that python is broken using musl. When a thread created
> using the threading library exists, python segfaults.
>
> This is a simple example application showing the issue:
fwiw i cant reproduce this on alpine-linux
so this
@micke.prag : mind to re-test.
I could not reproduce it with an x86 VM.
I don't have an ar71xx around to test with; i.e. I have pre-CC firmware on
them.
This issue could be a temp-issue.
At the moment the OpenWRT trunk with musl is shifting like an earth-quake,
and this could have been fixed alrea
Thanks for the feedback, will have another attempt at submitting the patch.
> @@ -184,7 +204,7 @@ mtd_fixtrx(const char *mtd, size_t offset)
> }
>
> trx = (struct trx_header *) (buf + offset);
> - if (trx->magic != STORE32_LE(0x30524448)) {
> + if (!is_trx_magic(trx->magic)) {
> Is dropping S
>From d38c8c72b99908d3d9a39bd858d1c76e9864faac Mon Sep 17 00:00:00 2001
From: Joseph East
Date: Wed, 10 Jun 2015 19:19:26 +0930
Subject: [PATCH] Belkin F7D (BCM47XX based) Support for Linux 3.18
Patchset based on previous work by Cody Schafer and Luc Forcier to allow TRX
images with Belkin I
Hi,
Oldpackages feed in CC still points to head of packages.git. As packages are
being removed, they will no longer be available for CC (pptpd for instance
has been moved to github, but is not present in 'for-15.05' branch of
packages). Is there a specific revision/commit of oldpackages that shoul
px5g-standalone: fix compilation after fortify-headers
New fortify-headers functionality (default after r46117) is apparently
conflicting with gcc "-pedantic" option. The package px5g-standalone fails to
compile due to "error: #include_next is a GCC extension" errors. See
https://dev.openwrt.o
I believe this to be an independent problem from the pthread_detach()
discussion: "musl breaks python". I’m re-posting this to openwrt-devel to get
more devos aware of the issue. Note that I am using the latest musl/gcc patches
as of today (23-Jun).
FWIW -- Here's what I know...
To easily repr
A duplicate include guard prevents inclusion of barrier.h in UML build and
this prevents mac80211 from building.
This patch re-enables mac80211 hwsim and renames the include guard.
See https://lists.openwrt.org/pipermail/openwrt-devel/2015-June/033614.html
for details.
Signed-off-by: Martin Tipp
Hi,
I am tried to build the firmware for Ubiquiti EdgeRouter Lite.
CONFIG_HAVE_DOT_CONFIG=y
CONFIG_TARGET_octeon=y
CONFIG_TARGET_octeon_generic=y
CONFIG_TARGET_BOARD="octeon"
CONFIG_TARGET_ARCH_PACKAGES="octeon"
When compiling the images, i get the following build error.
How can i fix this ?
oldpackages are obsolete and in many instances riddled with security issues.
They should not be used at all.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
12 matches
Mail list logo
