date:20170829

[LEDE-DEV] libmpdclient - meson/ninja ?

2017-08-29 Thread Ted Hess

Hi all -

The latest releases of libmpdclient, part of the Music Player Daemon (mpd), has
been revised to build with the Meson build system and Ninja. It no longer has
support for autotools & make. Since we do not have the availability of this
build environment / toolchain, the current version (2.11) will be frozen in the
packages library.

Any thoughts?

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

Re: [LEDE-DEV] Conditional dependencies in Makefiles

2017-08-29 Thread Sebastian Kemper

On Tue, Aug 29, 2017 at 05:15:51PM +, Sebastian Kemper wrote:
> Hi Ted,
> 
> Maybe a stupid idea, but is there a tab in front of the depends? Does
> removing it help?

No, that doesn't help.

I remember trying to do something like this with PKG_BUILD_DEPENDS and
couldn't get it working either.

Maybe the best you can do is this:

define Package/libffmpeg-full
$(call Package/libffmpeg/Default)
 TITLE+= (full)
 DEPENDS+= @BUILD_PATENTED +alsa-lib +PACKAGE_libopus:libopus @!SOFT_FLOAT 
+PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264
 VARIANT:=full
endef

Downside would be no libffmpeg-full for SOFT_FLOAT setups, obviously :)

On another note, are you sure you want deps like these:

+PACKAGE_libopus:libopus?

According to https://wiki.openwrt.org/doc/devel/dependencies it means
that libopus will only get selected by libffmpeg-full if libopus is
enabled. I think

+PACKAGE_libffmpeg-full:libopus

is what you're after.

Regards,
Sebastian

> 
> Seb
> 
> Am 29. August 2017 19:08:11 MESZ schrieb Ted Hess
> :
> >Hi all -
> >
> >I have a package (ffmpeg) build problem which is trying to specify a
> >different DEPENDS for soft-float systems and one for hard-float. The
> >package definition is as follows:
> >
> >> define Package/libffmpeg-full $(call Package/libffmpeg/Default)
> >>  TITLE+= (full)  DEPENDS+= @BUILD_PATENTED +alsa-lib
> >> +PACKAGE_libopus:libopus  ifeq ($(CONFIG_SOFT_FLOAT),y)
> >> DEPENDS+= +PACKAGE_shine:shine  else DEPENDS+=
> >> +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264  endif
> >>  VARIANT:=full endef
> >
> >Thinking the 'ifeq', etc is not proper within a function definition,
> >I have also tried:
> >
> >  DEPENDS+=$(if
> >$(CONFIG_SOFT_FLOAT),+PACKAGE_shine:shine,+PACKAGE_lame- lib:lame-lib
> >+PACKAGE_libx264:libx264)
> >
> >In both cases, the behavior is as if CONFIG_SOFT_FLOAT is not
> >defined.
> >
> >Any help would be greatly appreciated.
> >
> >/ted
> >
> >
> >___ Lede-dev mailing list
> >Lede-dev@lists.infradead.org
> >http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> ___ Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

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

[LEDE-DEV] Sysupgrade and networking

2017-08-29 Thread Philip Prindeville

Hi.

I was wondering about why the network interfaces stay up during a sysupgrade.

No services are available, so about all you can do is ping the box or have your 
connections reset if you try to connect to it.

Would it make more sense to bring all network interfaces down?

Worst case scenario is you’re in the middle of an update, and then someone 
sends you a packet-of-death while the update is incomplete… now you’ve got a 
corrupted filesystem.

-Philip


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

Re: [LEDE-DEV] Conditional dependencies in Makefiles

2017-08-29 Thread Felix Fietkau

On 2017-08-29 19:08, Ted Hess wrote:
> Hi all -
> 
> I have a package (ffmpeg) build problem which is trying to specify a different
> DEPENDS for soft-float systems and one for hard-float. The package definition 
> is
> as follows:
> 
>> define Package/libffmpeg-full
>> $(call Package/libffmpeg/Default)
>>  TITLE+= (full)
>>  DEPENDS+= @BUILD_PATENTED +alsa-lib +PACKAGE_libopus:libopus
>>  ifeq ($(CONFIG_SOFT_FLOAT),y)
>> DEPENDS+= +PACKAGE_shine:shine
>>  else
>> DEPENDS+= +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264
>>  endif
>>  VARIANT:=full
>> endef
> 
> Thinking the 'ifeq', etc is not proper within a function definition, I have 
> also
> tried:
> 
>   DEPENDS+=$(if $(CONFIG_SOFT_FLOAT),+PACKAGE_shine:shine,+PACKAGE_lame-
> lib:lame-lib +PACKAGE_libx264:libx264)
Please don't introduce dependencies that magically get added based on
whether a different package is selected or not.
Either always use shine, or add a separate option to configure whether
or not it should be used.
Also make sure that anything that affects the build gets proper
treatment in CONFIGURE_ARGS and PKG_CONFIG_DEPENDS.

Aside from that, there is an easy way to deal with conditional
dependencies that depend on multiple options: Just create an
intermediate config symbol via Package//config that is hidden and
depends on the relevant multiple config symbols.

- Felix

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

[LEDE-DEV] Conditional dependencies in Makefiles

2017-08-29 Thread Ted Hess

Hi all -

I have a package (ffmpeg) build problem which is trying to specify a different
DEPENDS for soft-float systems and one for hard-float. The package definition is
as follows:

> define Package/libffmpeg-full
> $(call Package/libffmpeg/Default)
>  TITLE+= (full)
>  DEPENDS+= @BUILD_PATENTED +alsa-lib +PACKAGE_libopus:libopus
>  ifeq ($(CONFIG_SOFT_FLOAT),y)
> DEPENDS+= +PACKAGE_shine:shine
>  else
> DEPENDS+= +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264
>  endif
>  VARIANT:=full
> endef

Thinking the 'ifeq', etc is not proper within a function definition, I have also
tried:

  DEPENDS+=$(if $(CONFIG_SOFT_FLOAT),+PACKAGE_shine:shine,+PACKAGE_lame-
lib:lame-lib +PACKAGE_libx264:libx264)

In both cases, the behavior is as if CONFIG_SOFT_FLOAT is not defined.

Any help would be greatly appreciated.

/ted


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

Re: [LEDE-DEV] Strange build error

2017-08-29 Thread Zoltan Gyarmati


Zoltan Gyarmati
https://zgyarmati.de

On 08/29/2017 02:33 AM, Philip Prindeville wrote:
>> On Aug 28, 2017, at 6:17 PM, Zoltan Gyarmati  
>> wrote:
>>
>> On 08/28/2017 01:52 PM, Zoltan Gyarmati wrote:
>>> Dear All,
>>>
>>> i'm fighting with an odd build error on my build server VPS, using
>>> current master and the RT5350F-OLINUXINO profile:
>>>
>>> When trying to re-build the LEDE tree (after a successful initial
>>> build), i get this error:
>>>
 make[5]: Entering directory
 '/home/zgyarmati/lede/build_dir/target-mipsel_24kc_musl/linux-ramips_rt305x/linux-4.9.44'
  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  GEN usr/initramfs_data.cpio
  AS  usr/initramfs_data.o
  LD  usr/built-in.o
  AR  lib/lib.a
  EXPORTS lib/lib-ksyms.o
  LD  lib/built-in.o
  LD  vmlinux.o
  MODPOST vmlinux.o
  GEN .version
  CHK include/generated/compile.h
 lib/lib.a(decompress.o):(.init.rodata+0x2c): undefined reference to
 `unlzma'
 lib/lib.a(decompress.o):(.init.rodata+0x38): undefined reference to
 `unlzma'
 Makefile:972: recipe for target 'vmlinux' failed
>>> The odd thing is that the same config on my laptop (Debian
>>> testing/Buster) builds and rebuilds correctly, while on the VPS (Debian
>>> 9/Stretch) it fails with the error above.
>>> I've checked all the dependencies, digged into the environment to figure
>>> out what is the significant difference, but i couldn't hunt this down.
>>> My best guess it that is related to the fact that the build server runs
>>> on a VPS, but no solid evidence on this yet...
>>>
>>> Do you have maybe an idea where to look?
>>>
>> I've tried cross check with building and rebuilding Atheros
>> AR7xxx/AR9xxx/8devices Carambola2 profle,
>> and it builds and rebuilds without the error above in the same
>> environment...
>
> I’ll ask the obvious question… Are the .config files identical in both cases?
>
> -Philip
>

 Yes, and anyway, the problem persist if i just do a `make menuconfig`, and
select 'MediaTek Ralink MIPS -- RT3x5x/RT5350 based boards --
RT5350F-OLinuXino'
target profile, so it doesn't seem to be an issue with my own .config.
Since than i've ran a build without ccache, but got the same result...






signature.asc
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Recent issues w/ sysupgrade

2017-08-29 Thread Philip Prindeville

Hi all,

I don’t know if sysupgrade is the problem, or if this is where things manifest.

But I recently (within the last week, but I only rebase once or twice a week) 
started seeing issues with doing sysupgrade on x86_64 hardware.

The sysupgrade will appear to go okay, but then when the machine reboots, I see:

...
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[6.322701] mount_root: loading kmods from internal overlay
[6.331183] kmodloader: loading kernel modules from //etc/modules-boot.d/*
[6.339194] kmodloader: done loading kernel modules from 
//etc/modules-boot.d/*
[6.470650] block: attempting to load /etc/config/fstab
[6.483431] block: extroot: not configured
[6.488267] random: procd: uninitialized urandom read (4 bytes read)
[6.506070] mount_root: rootdisk overlay filesystem has not been formatted 
yet


Is this related to the mk.f2f changes on Thursday?

Or maybe the mkimage fix?

I’ll try resetting my cloning further and further back until I can’t reproduce 
the problem…

That might take me a day or so to isolate.

-Philip


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

Re: [LEDE-DEV] [PATCH 13/13] sunxi: Add A64 support with cortex53 subtarget

2017-08-29 Thread Baptiste Jonglez

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 image is able to boot on
> > this SoC.
> 
> Thanks for the patches!
> 
> I tested them on a pine64+ 1GB but it does not seem to work: the green NIC
> LED keeps blinking on and off and the device stays unreachable from the
> network.  If I force the other end to use 100baseTx-FD, the green NIC LED
> stays on instead of blinking, but the device is still unreachable.

I just found this comment in the DTS:

  /* TODO: Camera, Ethernet PHY, touchscreen, etc. */

So, the non-working NIC seems to be expected: this should be more apparent
in the patch descriptions to avoid surprises :)

(I totally understand that this patch series is about preliminary support
for the board)

> I will soon look at it more closely with a serial cable.
> 
> > Signed-off-by: Hauke Mehrtens 
> > ---
> >  target/linux/sunxi/Makefile |   2 +-
> >  target/linux/sunxi/cortexa53/config-default | 100 
> > 
> >  target/linux/sunxi/cortexa53/target.mk  |  13 
> >  target/linux/sunxi/image/Makefile   |   1 +
> >  target/linux/sunxi/image/cortex-a53.mk  |  20 ++
> >  5 files changed, 135 insertions(+), 1 deletion(-)
> >  create mode 100644 target/linux/sunxi/cortexa53/config-default
> >  create mode 100644 target/linux/sunxi/cortexa53/target.mk
> >  create mode 100644 target/linux/sunxi/image/cortex-a53.mk
> > 
> > diff --git a/target/linux/sunxi/Makefile b/target/linux/sunxi/Makefile
> > index 65d43358c9..982eecbcbd 100644
> > --- a/target/linux/sunxi/Makefile
> > +++ b/target/linux/sunxi/Makefile
> > @@ -11,7 +11,7 @@ ARCH:=arm
> >  BOARD:=sunxi
> >  BOARDNAME:=Allwinner A1x/A20/A3x
> >  FEATURES:=fpu usb ext4 display rtc squashfs
> > -SUBTARGETS:=cortexa8 cortexa7
> > +SUBTARGETS:=cortexa8 cortexa7 cortexa53
> >  MAINTAINER:=Zoltan HERPAI 
> >  
> >  KERNEL_PATCHVER:=4.9
> > diff --git a/target/linux/sunxi/cortexa53/config-default 
> > b/target/linux/sunxi/cortexa53/config-default
> > new file mode 100644
> > index 00..58ac214695
> > --- /dev/null
> > +++ b/target/linux/sunxi/cortexa53/config-default
> > @@ -0,0 +1,100 @@
> > +CONFIG_64BIT=y
> > +CONFIG_ARCH_DMA_ADDR_T_64BIT=y
> > +CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> > +CONFIG_ARCH_HAS_GIGANTIC_PAGE=y
> > +CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
> > +CONFIG_ARCH_HAS_KCOV=y
> > +CONFIG_ARCH_MMAP_RND_BITS=18
> > +CONFIG_ARCH_MMAP_RND_BITS_MAX=24
> > +CONFIG_ARCH_MMAP_RND_BITS_MIN=18
> > +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
> > +CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> > +CONFIG_ARCH_SPARSEMEM_DEFAULT=y
> > +CONFIG_ARCH_SPARSEMEM_ENABLE=y
> > +CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> > +CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
> > +CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y
> > +CONFIG_ARCH_WANT_FRAME_POINTERS=y
> > +CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> > +CONFIG_ARM64=y
> > +# CONFIG_ARM64_16K_PAGES is not set
> > +CONFIG_ARM64_4K_PAGES=y
> > +# CONFIG_ARM64_64K_PAGES is not set
> > +CONFIG_ARM64_CONT_SHIFT=4
> > +# CONFIG_ARM64_CRYPTO is not set
> > +# CONFIG_ARM64_HW_AFDBM is not set
> > +# CONFIG_ARM64_LSE_ATOMICS is not set
> > +CONFIG_ARM64_PAGE_SHIFT=12
> > +# CONFIG_ARM64_PAN is not set
> > +# CONFIG_ARM64_PTDUMP is not set
> > +# CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET is not set
> > +# CONFIG_ARM64_UAO is not set
> > +CONFIG_ARM64_VA_BITS=39
> > +CONFIG_ARM64_VA_BITS_39=y
> > +# CONFIG_ARM64_VA_BITS_48 is not set
> > +# CONFIG_ARM64_VHE is not set
> > +CONFIG_ARM_AMBA=y
> > +CONFIG_ARM_GIC_V3=y
> > +# CONFIG_ARM_SBSA_WATCHDOG is not set
> > +# CONFIG_ARM_SP805_WATCHDOG is not set
> > +CONFIG_AUDIT_ARCH_COMPAT_GENERIC=y
> > +# CONFIG_COMMON_CLK_VERSATILE is not set
> > +CONFIG_COMMON_CLK_XGENE=y
> > +# CONFIG_COMPAT is not set
> > +# CONFIG_DEBUG_ALIGN_RODATA is not set
> > +CONFIG_DEBUG_RODATA=y
> > +CONFIG_FRAME_POINTER=y
> > +# CONFIG_FSL_ERRATUM_A008585 is not set
> > +CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> > +CONFIG_GENERIC_CPU_AUTOPROBE=y
> > +CONFIG_GENERIC_CSUM=y
> > +CONFIG_GENERIC_IRQ_MIGRATION=y
> > +CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
> > +CONFIG_HAVE_ARCH_HUGE_VMAP=y
> > +CONFIG_HAVE_ARCH_KASAN=y
> > +CONFIG_HAVE_CMPXCHG_DOUBLE=y
> > +CONFIG_HAVE_CMPXCHG_LOCAL=y
> > +CONFIG_HAVE_DEBUG_BUGVERBOSE=y
> > +CONFIG_HAVE_EBPF_JIT=y
> > +CONFIG_HAVE_KVM_MSI=y
> > +CONFIG_HAVE_MEMORY_PRESENT=y
> > +CONFIG_HAVE_PATA_PLATFORM=y
> > +CONFIG_ILLEGAL_POINTER_VALUE=0xdead
> > +# CONFIG_KASAN is not set
> > +CONFIG_KERNEL_MODE_NEON=y
> > +CONFIG_KVM_ARM_PMU=y
> > +CONFIG_KVM_ARM_VGIC_V3_ITS=y
> > +CONFIG_MODULES_USE_ELF_RELA=y
> > +CONFIG_NEED_SG_DMA_LENGTH=y
> > +CONFIG_NO_IOPORT_MAP=y
> > +# CONFIG_NUMA is not set
> > +CONFIG_PARTITION_PERCPU=y
> > +# CONFIG_PCI_DOMAINS is not set
> > +# CONFIG_PHY_XGENE is not set
> > +#

Re: [LEDE-DEV] Recent issues w/ sysupgrade

2017-08-29 Thread Stijn Tintel

On 29-08-17 09:09, Philip Prindeville wrote:
> Hi all,
>
> I don’t know if sysupgrade is the problem, or if this is where things 
> manifest.
>
> But I recently (within the last week, but I only rebase once or twice a week) 
> started seeing issues with doing sysupgrade on x86_64 hardware.
>
> The sysupgrade will appear to go okay, but then when the machine reboots, I 
> see:
>
> ...
> Press the [f] key and hit [enter] to enter failsafe mode
> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
> [6.322701] mount_root: loading kmods from internal overlay
> [6.331183] kmodloader: loading kernel modules from //etc/modules-boot.d/*
> [6.339194] kmodloader: done loading kernel modules from 
> //etc/modules-boot.d/*
> [6.470650] block: attempting to load /etc/config/fstab
> [6.483431] block: extroot: not configured
> [6.488267] random: procd: uninitialized urandom read (4 bytes read)
> [6.506070] mount_root: rootdisk overlay filesystem has not been formatted 
> yet
>
>
> Is this related to the mk.f2f changes on Thursday?
I doubt this will be related. The only real change is
https://git.lede-project.org/cdb494fd, and on little endian systems
cpu_to_le64 is a noop. Additionaly I tested this on x86/64 and didn't
notice any isses. Just look a bit further and you should see this:

Tue Aug 29 07:12:57 2017 user.info kernel: [    5.607837] mount_root:
overlay filesystem has not been fully initialized yet
Tue Aug 29 07:12:57 2017 user.info kernel: [    5.608986] mount_root:
switching to f2fs overlay

root@LEDE:~# mount  | grep overlay
/dev/loop0 on /overlay type f2fs
(rw,lazytime,noatime,background_gc=on,user_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6)
overlayfs:/overlay on / type overlay
(rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)

Stijn

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

Re: [LEDE-DEV] [PATCH 4/4] ramips/RT5350F-OLINUXINO(-EVB) dts: enable ttyS1

2017-08-29 Thread John Crispin


Hi,

comment inline


On 26/08/17 21:54, Zoltan Gyarmati wrote:

  The RT5350F's second UART pins are available on the base module and on
the EVB as well, so enable it in the device tree.
  Additionaly, the uartlite@c00 and uart@500 nodes swapped in rt5350.dtsi
to keep the serial console as ttyS0.

Signed-off-by: Zoltan Gyarmati 
---
  target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi | 11 +-
  target/linux/ramips/dts/rt5350.dtsi| 30 +-
  2 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi 
b/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
index 955a13cddd..1632f3c085 100644
--- a/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
+++ b/target/linux/ramips/dts/RT5350F-OLINUXINO.dtsi
@@ -46,9 +46,13 @@
   {
state_default: pinctrl0 {
gpio {
-   ralink,group = "jtag", "rgmii", "mdio", "uartf";
+   ralink,group = "jtag", "rgmii", "mdio";
ralink,function = "gpio";
};
+   uartf_gpio {
+   ralink,group = "uartf";
+   ralink,function = "gpio uartf";
+   };
};
  };
  
@@ -77,3 +81,8 @@

   {
status = "okay";
  };
+
+ {
+   status = "okay";
+};
+
diff --git a/target/linux/ramips/dts/rt5350.dtsi 
b/target/linux/ramips/dts/rt5350.dtsi
index a92c113043..f027e17d9d 100644
--- a/target/linux/ramips/dts/rt5350.dtsi
+++ b/target/linux/ramips/dts/rt5350.dtsi
@@ -83,21 +83,6 @@
interrupts = <3>;
};
  
-		uart: uart@500 {

-   compatible = "ralink,rt5350-uart", "ralink,rt2880-uart", 
"ns16550a";
-   reg = <0x500 0x100>;
-
-   resets = < 12>;
-   reset-names = "uart";
-
-   interrupt-parent = <>;
-   interrupts = <5>;
-
-   reg-shift = <2>;
-
-   status = "disabled";
-   };
-
gpio0: gpio@600 {
compatible = "ralink,rt5350-gpio", "ralink,rt2880-gpio";
reg = <0x600 0x34>;
@@ -221,6 +206,21 @@
reg-shift = <2>;
};
  
+		uart: uart@500 {

+   compatible = "ralink,rt5350-uart", "ralink,rt2880-uart", 
"ns16550a";
+   reg = <0x500 0x100>;
+
+   resets = < 12>;
+   reset-names = "uart";
+
+   interrupt-parent = <>;
+   interrupts = <5>;
+
+   reg-shift = <2>;
+
+   status = "disabled";
+   };


moving the node makes no sense. the change is a no-op. please remove it 
and update the patch description


John


+
systick: systick@d00 {
compatible = "ralink,rt5350-systick", 
"ralink,cevt-systick";
reg = <0xd00 0x10>;



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

Re: [LEDE-DEV] Recent issues w/ sysupgrade

2017-08-29 Thread Philip Prindeville


> On Aug 29, 2017, at 9:16 AM, Philip Prindeville 
>  wrote:
> 
>> On Aug 29, 2017, at 1:19 AM, Stijn Tintel  wrote:
>> 
>>> On 29-08-17 09:09, Philip Prindeville wrote:
>>> Hi all,
>>> 
>>> I don’t know if sysupgrade is the problem, or if this is where things 
>>> manifest.
>>> 
>>> But I recently (within the last week, but I only rebase once or twice a 
>>> week) started seeing issues with doing sysupgrade on x86_64 hardware.
>>> 
>>> The sysupgrade will appear to go okay, but then when the machine reboots, I 
>>> see:
>>> 
>>> ...
>>> Press the [f] key and hit [enter] to enter failsafe mode
>>> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
>>> [6.322701] mount_root: loading kmods from internal overlay
>>> [6.331183] kmodloader: loading kernel modules from 
>>> //etc/modules-boot.d/*
>>> [6.339194] kmodloader: done loading kernel modules from 
>>> //etc/modules-boot.d/*
>>> [6.470650] block: attempting to load /etc/config/fstab
>>> [6.483431] block: extroot: not configured
>>> [6.488267] random: procd: uninitialized urandom read (4 bytes read)
>>> [6.506070] mount_root: rootdisk overlay filesystem has not been 
>>> formatted yet
>>> 
>>> 
>>> Is this related to the mk.f2f changes on Thursday?
>> I doubt this will be related. The only real change is
>> https://git.lede-project.org/cdb494fd, and on little endian systems
>> cpu_to_le64 is a noop. Additionaly I tested this on x86/64 and didn't
>> notice any isses. Just look a bit further and you should see this:
>> 
>> Tue Aug 29 07:12:57 2017 user.info kernel: [5.607837] mount_root:
>> overlay filesystem has not been fully initialized yet
>> Tue Aug 29 07:12:57 2017 user.info kernel: [5.608986] mount_root:
>> switching to f2fs overlay
>> 
>> root@LEDE:~# mount  | grep overlay
>> /dev/loop0 on /overlay type f2fs
>> (rw,lazytime,noatime,background_gc=on,user_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6)
>> overlayfs:/overlay on / type overlay
>> (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
>> 
>> Stijn
> 
> It never gets to that point.
> 
> The message about it not being formatted is the last output then it hangs.
> 


I do not see that (the “switching to f2fs overlay” message) on the console when 
the hang happens at reboot following a sysupgrade (and sometimes even just 
reflashing the CF card).

I have noted, when sysupgrade runs, I do see:


[  379.758026] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
Upgrade completed
Rebooting system...
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy


but I was seeing those before.

So, some progress on the bi-section.

I can rebase to here:

af922c0 mediatek: update to latest kernel patchset from v4.13-rc
3ec259a procd: fix hotplug-preinit.json syntax
1a3b17a procd: fix hotplug.json syntax
a678eb0 ca-certificates: Update to 20170717
8e16e19 imx6: refresh kernel config
c0d5990 imx6: add driver for temp/voltage monitoring
2deed55 uboot-lantiq: Enable TFTP PUT support for backups
47dcfcf gpio-button-hotplug: leave platform_device.dev.platform_data untouched

but then I need to cherry-pick this fix so things will build:

dfee19f mediatek: drop kernel dep on userland module

If I try to rebase any further, to:

e622b30 netifd: update to latest git HEAD

then I see the flakiness at boot time.  John or Felix, are there any changes 
here that would affect booting if the way described above?

-Philip



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

Re: [LEDE-DEV] [PATCH] dnsmasq: forward.c: fix CVE-2017-13704

2017-08-29 Thread Hans Dedecker

On Tue, Aug 29, 2017 at 3:29 PM, Kevin Darbyshire-Bryant
 wrote:
> Fix SIGSEGV in rfc1035.c answer_request() line 1228 where memset()
> is called with header & limit pointing at the same address and thus
> tries to clear memory from before the buffer begins.
>
> answer_request() is called with an invalid edns packet size provided by
> the client.  Ensure the udp_size provided by the client is bounded by
> 512 and configured maximum as per RFC 6891 6.2.3 "Values lower than 512
> MUST be treated as equal to 512"
>
> The client that exposed the problem provided a payload udp size of 0.
>
> Signed-off-by: Kevin Darbyshire-Bryant 
Acked-by: Hans Dedecker 
> ---
>  package/network/services/dnsmasq/Makefile  |  2 +-
>  .../dnsmasq/patches/020-fix-CVE-2017-13704.patch   | 37 
> ++
>  2 files changed, 38 insertions(+), 1 deletion(-)
>  create mode 100644 
> package/network/services/dnsmasq/patches/020-fix-CVE-2017-13704.patch
>
> diff --git a/package/network/services/dnsmasq/Makefile 
> b/package/network/services/dnsmasq/Makefile
> index d7f14f9..bd7f610 100644
> --- a/package/network/services/dnsmasq/Makefile
> +++ b/package/network/services/dnsmasq/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>
>  PKG_NAME:=dnsmasq
>  PKG_VERSION:=2.77
> -PKG_RELEASE:=9
> +PKG_RELEASE:=10
>
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
>  PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/
> diff --git 
> a/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch 
> b/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch
> new file mode 100644
> index 000..8848131
> --- /dev/null
> +++ b/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch
> @@ -0,0 +1,37 @@
> +From 38af9b1ac3242a4128e88069c495024caa565f0e Mon Sep 17 00:00:00 2001
> +From: Kevin Darbyshire-Bryant 
> +Date: Tue, 29 Aug 2017 12:35:40 +0100
> +Subject: [PATCH] forward.c: fix CVE-2017-13704
> +
> +Fix SIGSEGV in rfc1035.c answer_request() line 1228 where memset()
> +is called with header & limit pointing at the same address and thus
> +tries to clear memory from before the buffer begins.
> +
> +answer_request() is called with an invalid edns packet size provided by
> +the client.  Ensure the udp_size provided by the client is bounded by
> +512 and configured maximum as per RFC 6891 6.2.3 "Values lower than 512
> +MUST be treated as equal to 512"
> +
> +The client that exposed the problem provided a payload udp size of 0.
> +
> +Signed-off-by: Kevin Darbyshire-Bryant 
> +---
> + src/forward.c | 2 ++
> + 1 file changed, 2 insertions(+)
> +
> +diff --git a/src/forward.c b/src/forward.c
> +index f22556a..62c5a5a 100644
> +--- a/src/forward.c
>  b/src/forward.c
> +@@ -1408,6 +1408,8 @@ void receive_query(struct listener *listen, time_t now)
> +defaults to 512 */
> +   if (udp_size > daemon->edns_pktsz)
> +   udp_size = daemon->edns_pktsz;
> ++  if (udp_size < 512)
> ++  udp_size = 512; /* RFC 6891 6.2.3 */
> + }
> +
> + #ifdef HAVE_AUTH
> +--
> +2.7.4
> +
> --
> 2.7.4
>
>
> ___
> 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] dnsmasq: forward.c: fix CVE-2017-13704

2017-08-29 Thread Kevin Darbyshire-Bryant

Fix SIGSEGV in rfc1035.c answer_request() line 1228 where memset()
is called with header & limit pointing at the same address and thus
tries to clear memory from before the buffer begins.

answer_request() is called with an invalid edns packet size provided by
the client.  Ensure the udp_size provided by the client is bounded by
512 and configured maximum as per RFC 6891 6.2.3 "Values lower than 512
MUST be treated as equal to 512"

The client that exposed the problem provided a payload udp size of 0.

Signed-off-by: Kevin Darbyshire-Bryant 
---
 package/network/services/dnsmasq/Makefile  |  2 +-
 .../dnsmasq/patches/020-fix-CVE-2017-13704.patch   | 37 ++
 2 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 
package/network/services/dnsmasq/patches/020-fix-CVE-2017-13704.patch

diff --git a/package/network/services/dnsmasq/Makefile 
b/package/network/services/dnsmasq/Makefile
index d7f14f9..bd7f610 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=dnsmasq
 PKG_VERSION:=2.77
-PKG_RELEASE:=9
+PKG_RELEASE:=10
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/
diff --git 
a/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch 
b/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch
new file mode 100644
index 000..8848131
--- /dev/null
+++ b/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch
@@ -0,0 +1,37 @@
+From 38af9b1ac3242a4128e88069c495024caa565f0e Mon Sep 17 00:00:00 2001
+From: Kevin Darbyshire-Bryant 
+Date: Tue, 29 Aug 2017 12:35:40 +0100
+Subject: [PATCH] forward.c: fix CVE-2017-13704
+
+Fix SIGSEGV in rfc1035.c answer_request() line 1228 where memset()
+is called with header & limit pointing at the same address and thus
+tries to clear memory from before the buffer begins.
+
+answer_request() is called with an invalid edns packet size provided by
+the client.  Ensure the udp_size provided by the client is bounded by
+512 and configured maximum as per RFC 6891 6.2.3 "Values lower than 512
+MUST be treated as equal to 512"
+
+The client that exposed the problem provided a payload udp size of 0.
+
+Signed-off-by: Kevin Darbyshire-Bryant 
+---
+ src/forward.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/forward.c b/src/forward.c
+index f22556a..62c5a5a 100644
+--- a/src/forward.c
 b/src/forward.c
+@@ -1408,6 +1408,8 @@ void receive_query(struct listener *listen, time_t now)
+defaults to 512 */
+   if (udp_size > daemon->edns_pktsz)
+   udp_size = daemon->edns_pktsz;
++  if (udp_size < 512)
++  udp_size = 512; /* RFC 6891 6.2.3 */
+ }
+ 
+ #ifdef HAVE_AUTH
+-- 
+2.7.4
+
-- 
2.7.4


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

[LEDE-DEV] Advertising Opportunities

2017-08-29 Thread Annie Mai 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 ---

Hello

I hope you don't mind me emailing you. My name is Annie and I am the Editorial
lead at EditorialPR.com in the UK. We have a client at the moment that's
interested in being featured on your website.

Do you have any editorial advertising opportunities on the site that we could work together on?

Please note; I am on a tight deadline and need to get my placements for next
month agreed as soon as possible. So if you are interested please get back to
me as soon as possible so I can supply you with the full details of the
project. Also if you have more than one site, it would be great if you let me
know so we can see if it's suitable for any of our other campaigns.

Many thanks

Annie-Mai

EditorialPR.com

This e-mail message (and its attachments) may contain confidential, proprietary
or legally privileged information and is intended only for the individual named
addressee. You should not review, disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received this e-mail
by mistake and delete this e-mail from your system. E-mail transmissions cannot
be guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late, incomplete or contain viruses. The
sender, therefore, does not accept liability for any errors or omissions in the
contents of the message.

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

Re: [LEDE-DEV] Recent issues w/ sysupgrade

2017-08-29 Thread Philip Prindeville

> On Aug 29, 2017, at 1:19 AM, Stijn Tintel  wrote:
> 
>> On 29-08-17 09:09, Philip Prindeville wrote:
>> Hi all,
>> 
>> I don’t know if sysupgrade is the problem, or if this is where things 
>> manifest.
>> 
>> But I recently (within the last week, but I only rebase once or twice a 
>> week) started seeing issues with doing sysupgrade on x86_64 hardware.
>> 
>> The sysupgrade will appear to go okay, but then when the machine reboots, I 
>> see:
>> 
>> ...
>> Press the [f] key and hit [enter] to enter failsafe mode
>> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
>> [6.322701] mount_root: loading kmods from internal overlay
>> [6.331183] kmodloader: loading kernel modules from //etc/modules-boot.d/*
>> [6.339194] kmodloader: done loading kernel modules from 
>> //etc/modules-boot.d/*
>> [6.470650] block: attempting to load /etc/config/fstab
>> [6.483431] block: extroot: not configured
>> [6.488267] random: procd: uninitialized urandom read (4 bytes read)
>> [6.506070] mount_root: rootdisk overlay filesystem has not been 
>> formatted yet
>> 
>> 
>> Is this related to the mk.f2f changes on Thursday?
> I doubt this will be related. The only real change is
> https://git.lede-project.org/cdb494fd, and on little endian systems
> cpu_to_le64 is a noop. Additionaly I tested this on x86/64 and didn't
> notice any isses. Just look a bit further and you should see this:
> 
> Tue Aug 29 07:12:57 2017 user.info kernel: [5.607837] mount_root:
> overlay filesystem has not been fully initialized yet
> Tue Aug 29 07:12:57 2017 user.info kernel: [5.608986] mount_root:
> switching to f2fs overlay
> 
> root@LEDE:~# mount  | grep overlay
> /dev/loop0 on /overlay type f2fs
> (rw,lazytime,noatime,background_gc=on,user_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6)
> overlayfs:/overlay on / type overlay
> (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
> 
> Stijn

It never gets to that point.

The message about it not being formatted is the last output then it hangs.



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

Re: [LEDE-DEV] Conditional dependencies in Makefiles

2017-08-29 Thread Ted Hess

I think I tried that variation too and it was as if CONFIG_SOFT_FLOAT wasn't defined when the dependencies are calculated. I usally 
check the .packageinfo file to see what the enabled dependency config is. Strangely,  I think the problem lies with 
CONFIG_SOFT_FLOAT itself and the order of config evaluation?


/ted
-Original Message- 
From: Alexandru Ardelean

Sent: Tuesday, August 29, 2017 2:50 PM
To: LEDE Development List ; Ted Hess
Subject: Re: [LEDE-DEV] Conditional dependencies in Makefiles

What if you do outside of the function def.

ifeq ($(CONFIG_SOFT_FLOAT),y)
 FLOAT_DEPENDS:= +PACKAGE_shine:shine
else
  FLOAT_DEPENDS+= +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264
endif

and then

DEPENDS+=$(FLOAT_DEPENDS)

?



On Tue, Aug 29, 2017 at 9:34 PM, Sebastian Kemper  wrote:

On Tue, Aug 29, 2017 at 05:15:51PM +, Sebastian Kemper wrote:

Hi Ted,

Maybe a stupid idea, but is there a tab in front of the depends? Does
removing it help?


No, that doesn't help.

I remember trying to do something like this with PKG_BUILD_DEPENDS and
couldn't get it working either.

Maybe the best you can do is this:

define Package/libffmpeg-full
$(call Package/libffmpeg/Default)
 TITLE+= (full)
 DEPENDS+= @BUILD_PATENTED +alsa-lib +PACKAGE_libopus:libopus @!SOFT_FLOAT 
+PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264
 VARIANT:=full
endef

Downside would be no libffmpeg-full for SOFT_FLOAT setups, obviously :)

On another note, are you sure you want deps like these:

+PACKAGE_libopus:libopus?

According to https://wiki.openwrt.org/doc/devel/dependencies it means
that libopus will only get selected by libffmpeg-full if libopus is
enabled. I think

+PACKAGE_libffmpeg-full:libopus

is what you're after.

Regards,
Sebastian



Seb

Am 29. August 2017 19:08:11 MESZ schrieb Ted Hess
:
>Hi all -
>
>I have a package (ffmpeg) build problem which is trying to specify a
>different DEPENDS for soft-float systems and one for hard-float. The
>package definition is as follows:
>
>> define Package/libffmpeg-full $(call Package/libffmpeg/Default)
>>  TITLE+= (full)  DEPENDS+= @BUILD_PATENTED +alsa-lib
>> +PACKAGE_libopus:libopus  ifeq ($(CONFIG_SOFT_FLOAT),y)
>> DEPENDS+= +PACKAGE_shine:shine  else DEPENDS+=
>> +PACKAGE_lame-lib:lame-lib +PACKAGE_libx264:libx264  endif
>>  VARIANT:=full endef
>
>Thinking the 'ifeq', etc is not proper within a function definition,
>I have also tried:
>
>  DEPENDS+=$(if
>$(CONFIG_SOFT_FLOAT),+PACKAGE_shine:shine,+PACKAGE_lame- lib:lame-lib
>+PACKAGE_libx264:libx264)
>
>In both cases, the behavior is as if CONFIG_SOFT_FLOAT is not
>defined.
>
>Any help would be greatly appreciated.
>
>/ted
>
>
>___ Lede-dev mailing list
>Lede-dev@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/lede-dev

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


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



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

[LEDE-DEV] libmpdclient - meson/ninja ?

Re: [LEDE-DEV] Conditional dependencies in Makefiles

[LEDE-DEV] Sysupgrade and networking

Re: [LEDE-DEV] Conditional dependencies in Makefiles

[LEDE-DEV] Conditional dependencies in Makefiles

Re: [LEDE-DEV] Strange build error

[LEDE-DEV] Recent issues w/ sysupgrade

Re: [LEDE-DEV] [PATCH 13/13] sunxi: Add A64 support with cortex53 subtarget

Re: [LEDE-DEV] Recent issues w/ sysupgrade

Re: [LEDE-DEV] [PATCH 4/4] ramips/RT5350F-OLINUXINO(-EVB) dts: enable ttyS1

Re: [LEDE-DEV] Recent issues w/ sysupgrade

Re: [LEDE-DEV] [PATCH] dnsmasq: forward.c: fix CVE-2017-13704

[LEDE-DEV] [PATCH] dnsmasq: forward.c: fix CVE-2017-13704

[LEDE-DEV] Advertising Opportunities

Re: [LEDE-DEV] Recent issues w/ sysupgrade

Re: [LEDE-DEV] Conditional dependencies in Makefiles

16 matches

Site Navigation

Mail list logo

Footer information