systemd is using the depedencies of the LSB section and according to
the debian documentation all applications accessing /var should depend
on the localfs. This makes the watchdog start properly on systemd systems.
This sanity check is included in the used bbclass directly and to
support both Edison and master we will need to remove the custom
python code due a change in indention in the python code.
We should use perf for future performance problems but it might
require more work (e.g. not to install the source into the -dbg
package, adding newt, etc.). But oprofile is not very nice to
use right now anyway.
Ask the buildsystem to install the manpages to the mandir. This will avoid
the following warning.
WARNING: QA Issue: lmsensors-apps: Files/directories were installed but not shipped
/usr/man
RROR: There is a confusing multiline, partially commented expression on line 22 of file /home/ich/firmen/gesmokom/source/meta-sysmocom-bsp/recipes-extra/gpsd/gpsd_3.7.bb (SRC_URI[md5sum] = "52d9785eaf1a51298bb8900dbde88f98").
Some of our target applications require ext3/ext4 support for mounting
an MMC card. While the sysmobts-v1 hardware does not have an external
MMC card slot it is nice to have the same image available for this
hardware.
Install the sysmobts firmware headers on top of the Osmocom toolchain.
This way the SDK can be used to re-compile both the OpenBSC and the
osmo-bts software.
Make sure the -dev package of the femtobts-api has not runtime
dependencies to a library that does not exist.
The name will be resolved to the hash during parse time. This will
not work when not having access to the internet. Use the sha1 sum
to make offline builds work.
This sadly still prints the firmware reload messages. But this is
necessary right now. The fpgadl/dspdl drivers do not log fatal
failures so the 'success' is the only information we have. This
is to be fixed in the driver.
If the first partition of a MMC card is mounted and has a logs/
directory syslog will start to write log messages to the MMC card
in the directory /media/mmcblk0p1.
This issue is documented in PRJ#72. The easiest is to to keep the
old software running as everything else is racy and start-stop-daemon
does not appear to implement the --retry command. Let's see how
far we get with this workaround.
We want to only log a given loglevel, backport the start up script
from OE-Core to get the LOGLEVEL variable. This removes the MARKINT
and adds DROPDUPLICATES and LOGLEVEL.
The kernel has been rebased to target 3.2.40 with various bug
fixes in the upstream work. The sysmobts v2 config has been
changed to allocate space for two more UARTs. These are required
for the multi-trx configuration and they make a warning go away.
* Fix the link timeout handling as found in post-review.
* Fix the set bts attr parsing due a funny parsing error.
* Sleep 10 seconds after the execution, reload DSP and FPGA firmware
We could use "fakeroot do_install() {}" but this will still not
make the spool directory be owned by uucp. Use a postinst script
to make this up. The logic is copied from the cronie bitbake file
and we will see how this works at image creation time.
FIXME: this will actually assume a GPS that is indirectly attached
to a GSM Modem which will be handled by openmoko-gsmd and forwarded via
UDP. However, we might have a GPS receiver attached directly to the
GPS UART in other hardware versions!
This will include
* Fix of CHAN_NR IEI in common channel RSL messages generated by BTS
* zecke/request_queueing
* Improve shutdown of DSP on exit
* various calib updates
* GSMTAP: use RxLevel and RxQual
* DSP power control bypass on ul_power_target==0
* Add radio link timeout procedure
The upgrade of the unit broke due killing all client connections. opkg
got a SIGHUP and didn't write out the state files. Do not kill the
client connections on upgrade.
The modules depend on kernel-base (renamed kernel-3.2.35) package,
the tasks depend on some modules and nothing needed the kernel package.
In OE Core/Poky the machines depend on kernel-modules which will pull
the kernel package into the rootfs. We do it by hand using the essential
depends and bumping the PR for the task-core-boot.
I have verified that on a kernel ugrade task-core-boot will be updated
and the kernel package is installed.
Holger Hans Peter Freyther
Harald Welte