to make the bridge work we need to run an askfirst instance on the ttyS.
additionally add the lua scripts needed to make REST work. this is really ugly
code but it works. i already cleaned up to the original code, but there are still
issues such as a new luci session being created for each request.
Signed-off-by: John Crispin <blogic@openwrt.org>
Changes since oldpackages:
- updated to 1.0.25
* most of openwrt patches are upstreamed now
- cups dependency was completely removed
- small musl patch
- small uclibc patch
- removed link to extra libraries in libsane (used only
for preload backends)
- sane-libs and sane-backends merged and exploded into
individual packages for each backend:
* libsane for sane library (which backends should dep on)
* sane-daemon for saned daemon
* sane-xxx for sane backend for xxx
** each backend has its own custom dep libraries
* sane-backends-all (with no files) that deps on all backends
* sane-qcam is only available for x86/x86_64
** other archs does not implement inb/outb (at least in musl)
Now it is possible to use SANE with much less FS space (KB
instead of MB).
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
dfu-programmer is a Device Firmware Update based USB programmer for
Atmel chips with a USB bootloader. It's comparable to avrdude, but
optimized for Atmel chips with integrated USB DFU Bootloader.
Signed-off-by: Stefan Hellermann <stefan@the2masters.de>
Some collectd plugins launch third-party plugins that have variation in
initialisation time (like libpcap). Recently (since kernel bump to 4.1)
the DNS plugin has been causing collectd to crash semi-randomly at startup
on MIPS based WNDR3700.
Debugging led to realisation that the DNS plugin seems to require at least
0.1s time to start, before the first data reading attempt starts.
By default, the first data read cycle starts immediately, while apaprently
some of the plugins may still be asyncronously initialising. To make things
safe, this patch adds 1 second delay before the first data read cycle.
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
The 2015g release of the tz code and data is available. It reflects the
following changes, which were either circulated on the tz mailing list
or are relatively minor technical or administrative changes:
Changes affecting future time stamps
Turkey's 2015 fall-back transition is scheduled for Nov. 8, not
Oct. 25.
(Thanks to Fatih.)
Norfolk moves from +1130 to +1100 on 2015-10-04 at 02:00 local time.
(Thanks to Alexander Krivenyshev.)
Fiji's 2016 fall-back transition is scheduled for January 17, not 24.
(Thanks to Ken Rylander.)
Fort Nelson, British Columbia will not fall back on 2015-11-01. It has
effectively been on MST (-0700) since it advanced its clocks on
2015-03-08.
New zone America/Fort_Nelson. (Thanks to Matt Johnson.)
Changes affecting past time stamps
Norfolk observed DST from 1974-10-27 02:00 to 1975-03-02 02:00.
Changes affecting code
localtime no longer mishandles America/Anchorage after 2037.
(Thanks to Bradley White for reporting the bug.)
On hosts with signed 32-bit time_t, localtime no longer mishandles
Pacific/Fiji after 2038-01-16 14:00 UTC.
The localtime module allows the variables 'timezone', 'daylight',
and 'altzone' to be in common storage shared with other modules,
and declares them in case the system <time.h> does not.
(Problems reported by Kees Dekker.)
On platforms with tm_zone, strftime.c now assumes it is not NULL.
This simplifies the code and is consistent with zdump.c.
(Problem reported by Christos Zoulas.)
Changes affecting documentation
The tzfile man page now documents that transition times denote the
starts (not the ends) of the corresponding time periods.
(Ambiguity reported by Bill Seymour.)
Signed-off-by: Vladimir Ulrich <admin@evl.su>
if a user's env has PERL_MM_OPT defined collect will fail to build. Adding
--with-perl-bindings="" will override this env var.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Buildbots are reporting the following error:
../mme/ARPCPrint.c: In function 'ARPCPrint':
../mme/ARPCPrint.c:123:2: error: incompatible type for argument 3 of 'vfprintf'
vfprintf (fp, (char *)(&data->LIST [LE16TOH (data->STROFFSET)]), (void *)(&data->LIST [LE16TOH (data->ARGOFFSET)]));
^
In file included from /store/buildbot/slave/mxs/build/staging_dir/toolchain-arm_arm926ej-s_gcc-4.8-linaro_musl-1.1.11_eabi/include/fortify/stdio.h:20:0,
from ../mme/ARPCPrint.c:68:
/store/buildbot/slave/mxs/build/staging_dir/toolchain-arm_arm926ej-s_gcc-4.8-linaro_musl-1.1.11_eabi/include/stdio.h:108:5: note: expected '__isoc_va_list' but argument is of type 'void *'
Fix this by definition __UCLIBC__ to enable a workaround for this
issue.
While at, switch to HTTPS URL for cloning the git repo.
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
Changes since oldpackages:
- cups dependency was completely removed
* This also happened in sane trunk version
- small musl patch
- added detection of inb,outb (link error with musl)
* this also removes hack 020-non-i386-qcam.patch
- fix for segfault when using sane-test backend
- removed link to extra libraries in libsane (used only
for preload backends)
- added format-security fix
- sane-libs and sane-backends merged and exploded into
individual packages for each backend:
* libsane for sane library (which backends should dep on)
* sane-daemon for saned daemon
* sane-xxx for sane backend for xxx
** each backend has its own custom dep libraries
* sane-backends-all (with no files) that deps on all backends
* sane-qcam is only available for x86/x86_64
** other archs does not implement inb/outb (at least in musl)
Now it is possible to use SANE with much less FS space (KB
instead of MB).
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
This commit updates (and also fixes) the lvm2 package.
The previous Makefile version, was using an incorrect
package version (2.02.126), which does not exists
at the specified FTP source site.
Signed-off-by: Carlos Ferreira <carlosmf.pt@gmail.com>
Also already mentioned in ba4338d6f7,
the security feature FORTIFY_SOURCE could be set globally.
The current approach tries to undefine and redefine it, however,
the order on the command line prevents this from being successfully, e.g.:
arm-openwrt-linux-muslgnueabi-gcc ... -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 ... -D_FORTIFY_SOURCE=1 ...
`---------------v-------------------' `--------v--------'
AM_CFLAGS OpenWrt params
So to have the original source (static) _FORTIFY_SOURCE=2 define,
the only option is to remove it from AM_CFLAGS completely, and
to pass it after the OpenWrt settings explicitely in the Makefile.
This should fix the buildbots finally.
Signed-off-by: Michael Heimpold <mhei@heimpold.de>