namebench expects to be run from its own source tree (it uses relative
paths to various resources), make it work.
The current version fails like this:
$ ./result/bin/namebench.py
Traceback (most recent call last):
File "/nix/store/04d29llycr5xcxplfv4gn556nzm1mrl7-python2.7-namebench-1.0.5/bin/.namebench.py-wrapped", line 46, in <module>
(options, supplied_ns, global_ns, regional_ns) = config.GetConfiguration()
File "/nix/store/04d29llycr5xcxplfv4gn556nzm1mrl7-python2.7-namebench-1.0.5/lib/python2.7/site-packages/libnamebench/config.py", line 27, in GetConfiguration
(configured_options, global_ns, regional_ns) = ProcessConfigurationFile(options)
File "/nix/store/04d29llycr5xcxplfv4gn556nzm1mrl7-python2.7-namebench-1.0.5/lib/python2.7/site-packages/libnamebench/config.py", line 100, in ProcessConfigurationFile
general = dict(config.items('general'))
File "/nix/store/z6vp5aix4ks1zdjdry7v7dahg8dd02sy-python-2.7.10/lib/python2.7/ConfigParser.py", line 642, in items
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'general'
Changelog:
```
Version 0.7.75, 2015-06-30
+ MXF: consideraing 60 fps timecode tracks with 2 components having a difference of 2 frames as a single timecode
+ EBUCore 1.6: switch to the link of the final XSD
x XDCAM: some directory structures were wrongly detected as XDCAM structure having a XML file
x MXF: SDTI 60 fps times were wrong
x #B927, DPX: date/time specific DPX format was used instead of the ISO-like one
x #B927, EBUCore: invalid content in attribute startDate
x ProRes: streams with apcs CodecID were displayed with an incoherent bit depth instead of no bit depth
```
Changes:
- gettext is needed to build
- Switched to using non-legacy ffmpeg.
- Removed ffmpeg stuff from include path since it causes build errors related to
a time.h header.
- Removed unneeded patch.
- Adjusted NixOS service due to the binary being renamed.
Overview of the updated versions:
stable: 43.0.2357.125 -> 43.0.2357.130
beta: 44.0.2403.52 -> 44.0.2403.61
For the beta channel the following changes were necessary:
* Drop all patches which were added in c290595 because they apply to
44.0.2403.52 only. The shipped version of Blink was older than the
one used for Chromium itself and thus contained just the
cherry-picked patches from upstream Blink.
* The ffmpegsumo library is now statically linked the same way as in
the dev version, so let's not try to put it into the output store
path.
All channels were built successfully on my Hydra at:
https://headcounter.org/hydra/eval/187176
VM tests did also pass and can be found at:
x86: https://headcounter.org/hydra/build/707636
x86_64: https://headcounter.org/hydra/build/707637
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Just silencing the error will not prevent Chromium from trying to start
up the SUID sandbox anyway, thus flooding stderr with:
LaunchProcess: failed to execvp:
After digging a bit in the source code I found out that the SUID sandbox
binary is indeed used, but only for setting oom_score_adj within the
user namespace (as "root"). So let's build the sandbox binary and of
course don't set setuid bit.
These annoying error messages were originally introduced by 0aad4b7 and
I'm deeply sorry for annoying you guys out there with them.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Since 0aad4b7, we no longer need to have an external sandbox binary,
because the upstream implementation of the user namespace sandbox no
longer needs an external sandbox binary.
In our implementation of the user namespace sandbox, we (ab)used the
setuid sandbox to run non-setuid and set up user namespaces instead.
Because our implementation is no longer needed, we can safely drop the
external binary entirely.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Also switches to fetchFromGitHub to remove the need to depend on Git for
fetching the source tarball.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I've tested that ulex builds (and works) on OSX, and see no reason
it would not do so on other platforms, so I'm lifting the linux
restriction in platforms.
This breakage was cause by the package outputing its own
version of index.cache to `share/icons/hicolor`.
Used the `hicolor_icon_theme` hook to perform automated cleanup.
With this patch in place, ARMv7 NixOS can be booted in QEMU:
qemu-system-arm -kernel u-boot -M vexpress-a9 -serial stdio -sd nixos-sd-image-armv7l-linux.img -m 1024
...with all the features that boot.loader.generic-extlinux-compatible
supports, like the boot generation menu and seamless kernel upgrades
in the VM.
Instead of selecting the defconfig based on stdenv.platform.uboot,
provide different ubootFoo packages. Otherwise we couldn't easily build
U-Boots for different platforms than what we are currently running on.
All users of the ubootChooser function appear to be using only CLI tools
like mkimage, whose behaviour is not affected by the defconfig (their
build outputs are bitwise-identical). So add a separate package for the
CLI tools.
Of the removed patches, some version of sheevaplug-sdio.patch has
apparently been applied upstream (with at least mv_sdio.c renamed to
mvebu_mmc.c). sheevaplug-config.patch needs rebasing & re-testing on
real hardware.
Tested boards and input/output methods that upstream supports:
- Raspberry Pi:
- HDMI works, USB keyboard not yet supported
- Serial via the 26-pin connector (3.3V)
- pcDuino3 Nano:
- HDMI + USB keyboard (only if attached to a hub)
- Serial via the 3-pin connector (3.3V)
- Jetson TK1: RS-232 serial port only
- Versatile Express CA9 (for QEMU only): Serial via '-serial stdio'
Changes:
- liblz4: xxhash symbols are dynamically changed (namespace
emulation) to avoid symbol conflict
- liblz4.a (static library) no longer compiled with -fPIC by
default
These ARM boards are very old and quite likely used only for booting in
QEMU emulation. I'll focus on making the multiplatform image easy to
boot in QEMU instead.