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
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.
>
>
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.
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
>>> curr
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 e
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 provi
> 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) start
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.1
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 +
Hi Ted,
Maybe a stupid idea, but is there a tab in front of the depends? Does removing
it help?
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-f
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
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.
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 w
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/Def
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
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 i
> 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 recentl
17 matches
Mail list logo
