Yann E. MORIN [Sat, 6 Dec 2014 22:40:04 +0000 (23:40 +0100)]
package/mke2img: new package
Currently, we are using a shell script called genext2fs, that
impersonates the real genext2fs. But that script does much more than
just call genextfs: it also calls tune2fs and e2fsck.
Because it impersonates genext2fs, we can not easily add new options,
and are constrained by the genext2fs options.
But it turns out that, of all the options supported by the real
genext2fs, we only really care for a subset, namely:
- number of blocks
- number of inodes
- percentage of blocks reeserved to root
- the root directory which to generate the image from
So, we introduce a new host package, mke2img, that is intended to
eventually replace genext2fs.sh.
This new script is highly modeled from the existing genext2fs.sh, but
was slightly refreshed, and a new, supposedly sane set of options has
been choosen for the features we need (see above), and some new options
were added, too, rather than relying on the arguments order or
environment variables:
-b <nb-blocks> number of blocks in the filesystem
-i <nb-inodes> number of inodes in the filesystem
-r <pc-reserved> percentage of reserved blocks
* -d <root-dir> directory containing the root of the filesystem
* -o <img-file> output image file
-G <ext-gen> extfs generation: 2, 3, or 4 (default: 2)
-R <ext-rev> ext2 revision: 0 or 1 (default 1)
-l <label> filesystem label
-u <uid> filesystem UUID; if not specified, a random one is used
* Mandatory options
Since the upstream e2fsprogs are expected to release a new mke2fs that
will be able to generate a filesystem image from a directory, we then
will be able to replace all the logic in mke2img, to use mke2fs instead
of the (relatively fragile) combination of the three tools we currently
use.
An entry is added for it in the "Host utilities" menu, so it can be
selected for use by post-{build,image} scripts. The ext2 filesystem
selection is changed to select that now.
Nathaniel Roach [Mon, 1 Dec 2014 14:18:16 +0000 (22:18 +0800)]
package/dhcp: Only install the relevant unit file
Previous to this patch, if BR2_PACKAGE_DHCP_CLIENT was selected,
dhcpd.service was installed to the target on systemd systems.
On the resultant system, this would mean that systemctl would
show an error starting dhcpd.service, as the requisite files
do not exist. This does not cause issue on sysvinit systems
as the init scripts silently error when the files aren't found.
Fix this by adding a conditional check to the install define.
The cmake-package documentation was referring to
BR2_PREFER_STATIC_LIBS, while the option is actually named
BR2_PREFER_STATIC_LIB. This commit fixes this mistake.
Also remove unneeded sub-shell usage in the build and installation
steps. It is kept for the configure step as it is actually useful, and
works fine because "|| exit 1" is outside the sub-shell.
Yann E. MORIN [Fri, 5 Dec 2014 18:06:24 +0000 (19:06 +0100)]
docs/manual: document the new patch naming convention
To ease generating patches, we now use a naming convention that is in
line with what git-format-patch does, that is:
- do not prefix patches with the package name
- prefix patches with a 4-digit mber
- start numbering at 0001
Bernd Kuhls [Sun, 30 Nov 2014 16:48:54 +0000 (17:48 +0100)]
package/lxc: disable broken toolchains on nios2
As discussed with Thomas
http://article.gmane.org/gmane.comp.lib.uclibc.buildroot/100998
only the current toolchains are broken:
"it's better to blacklist the individual toolchains that are known
to be broken, so that if we add another toolchain, we will be able
to see if the same bug happens as well or not."
Bernd Kuhls [Sun, 30 Nov 2014 16:48:53 +0000 (17:48 +0100)]
package/crda: disable broken toolchains on nios2
As discussed with Thomas
http://article.gmane.org/gmane.comp.lib.uclibc.buildroot/100998
only the current toolchains are broken:
"it's better to blacklist the individual toolchains that are known
to be broken, so that if we add another toolchain, we will be able
to see if the same bug happens as well or not."
Bernd Kuhls [Sun, 30 Nov 2014 16:48:52 +0000 (17:48 +0100)]
package/aiccu: disable broken toolchains on nios2
As discussed with Thomas
http://article.gmane.org/gmane.comp.lib.uclibc.buildroot/100998
only the current toolchains are broken:
"it's better to blacklist the individual toolchains that are known
to be broken, so that if we add another toolchain, we will be able
to see if the same bug happens as well or not."
xlib_libXau needs pkg-config during the configure phase. Otherwise it
will fail with an error like this one:
checking for XAU... configure: error: in
`/br/output/build/xlib_libXau-1.0.8':
configure: error: The pkg-config script could not be found or is too
old. Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.
This patch updates to the latest bootstrap versione (3.3.0) and
contextually pushes the colour theme and fonts required by
our style. The patch provides source files (*.less) to
recompile bootstrap.min.css .
Yann E. MORIN [Mon, 1 Dec 2014 23:13:21 +0000 (00:13 +0100)]
package/bdwgc: only enable on supported architectures
bdwgc has support for a sub-set of the architectures we support.
Since there is roughly a 50-50 split of our architectures that have
support in bdwgc vs. those that do not, use a positive dependency logic,
rather than a negative one.
The list was constructed by visual inspection of the source code of
bdwgc, but the header doing the check is, to say it politely, a bit
difficult to read...
So, some working archotectures may be missing. Users needing it may
investigate if their architectures are indeed supported.
Baruch Siach [Tue, 2 Dec 2014 06:58:49 +0000 (08:58 +0200)]
ifplugd: remove spurious newline escape
Commit 5ad5d55924bcc (ifplugd: install configuration files unconditionally)
removed the conditional configuration file install, but left an redundant
newline escape, causing the following error:
Thomas Petazzoni [Sun, 30 Nov 2014 14:19:01 +0000 (15:19 +0100)]
mpd: install configuration file unconditionally
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
Thomas Petazzoni [Sun, 30 Nov 2014 14:18:59 +0000 (15:18 +0100)]
php: install configuration file unconditionally
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
[Peter: fix indentation as noted by Yann] Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: Peter Korsgaard <[email protected]>
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
Thomas Petazzoni [Sun, 30 Nov 2014 14:18:52 +0000 (15:18 +0100)]
samba: install configuration file unconditionally
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
Thomas Petazzoni [Sun, 30 Nov 2014 14:18:50 +0000 (15:18 +0100)]
fluxbox: install session file unconditionally
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
Thomas Petazzoni [Sun, 30 Nov 2014 14:18:47 +0000 (15:18 +0100)]
transmission: install init script unconditionally
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
Thomas Petazzoni [Sun, 30 Nov 2014 14:18:46 +0000 (15:18 +0100)]
rsyslog: install init script and config file unconditionally
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
Also, we take this opportunity to rename RSYSLOG_INSTALL_CONF_SCRIPT
to RSYSLOG_INSTALL_CONF because it is no longer installing an init
script.
Thomas Petazzoni [Sun, 30 Nov 2014 14:18:45 +0000 (15:18 +0100)]
rpcbind: install init script unconditionally
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
Thomas Petazzoni [Sun, 30 Nov 2014 14:18:44 +0000 (15:18 +0100)]
lighttpd: install init script and config file unconditionally
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
Thomas Petazzoni [Sun, 30 Nov 2014 14:18:43 +0000 (15:18 +0100)]
iucode-tool: install init script unconditionally
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
Thomas Petazzoni [Sun, 30 Nov 2014 14:18:42 +0000 (15:18 +0100)]
dmraid: install init script unconditionally
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
Thomas Petazzoni [Sun, 30 Nov 2014 14:18:41 +0000 (15:18 +0100)]
busybox: install init script and config file unconditionally
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
[Peter: drop && conditional from watchdog installation as noted by Yann] Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: Peter Korsgaard <[email protected]>
Thomas Petazzoni [Sun, 30 Nov 2014 14:18:40 +0000 (15:18 +0100)]
aiccu: install init script and config file unconditionally
As discussed, users should use a rootfs overlay or a post-build script
instead of a custom skeleton to override files installed by Buildroot,
so there is no point in having conditions when installing init scripts
or configuration files.
Thomas Petazzoni [Sun, 30 Nov 2014 14:18:23 +0000 (15:18 +0100)]
gnupg: don't bother removing a man page
The target-finalize target in the main Makefile removes
$(TARGET_DIR)/usr/share/man entirely, so there's no point in having
some package specific logic to remove man pages.
Thomas Petazzoni [Sun, 30 Nov 2014 14:18:21 +0000 (15:18 +0100)]
iostat: remove legacy code
Some custom iostat-source target was mistakenly left in place when the
iostat package was migrated to gentargets in commit ee77963588b09babfd71befb0b5eb9fd1e776bbc, back 4 years ago. This
commit removes this unnecessary custom target.
projects / buildroot-mgba.git / log