Currently only xml2-config is installed, for both the normal libxml2
package as well as the host package. The problem with that is that due
to multilib considerations the build host may have xml2-config installed
with a host triplet prefix, like x86_64-pc-linux-gnu-xml2-config (and
xml2-config as a symbolic link to it). Gentoo for instance sets it up
like this.
Packages may actually search for a prefixed xml2-config before searching
for xml2-config. An example would be Asterisk:
checking for x86_64-pc-linux-gnu-xml2-config... /usr/bin/x86_64-pc-linux-gnu-xml2-config
This then introduces wrong information into the build, for instance
bad includes:
~/tmp/openwrt $ /usr/bin/x86_64-pc-linux-gnu-xml2-config --cflags
-I/usr/include/libxml2
When the intention is to use OpenWrt's own (host) libxml2 one would like
to see this output used instead:
~/tmp/openwrt $ ./staging_dir/hostpkg/bin/xml2-config --cflags
-I/home/sk/tmp/openwrt/staging_dir/hostpkg/include/libxml2
This commit addresses this by installing xml2-config with a suitable
prefix and creating a symbolic link xml2-config. This is done for both
the host package and the normal package. The latter also needs this fix
because the target may use the same triplet as the host system (for
instance x86_64 cross-compiling for x86_64).
Signed-off-by: Sebastian Kemper <sebastian_ml@gmx.net>
- rename the section instance to yggdrasil (feat. request)
- allow zone to cover both ip4 and ip6 fam
Signed-off-by: William Fleurant <meshnet@protonmail.com>
The host build requires libxml2-dev. This commit adds the dependency for
libxml2/host, as the host system may not have it installed. This also
avoids using the host's xml2-config (in /usr/bin for instance) while
linking to libraries in staging_dir/hostpkg.
ldd staging_dir/hostpkg/bin/xsltproc | grep xml2
libxml2.so.2 => /home/sk/tmp/openwrt/staging_dir/hostpkg/lib/libxml2.so.2 (0x00007fcc0644c000)
Signed-off-by: Sebastian Kemper <sebastian_ml@gmx.net>
After many failed attempts at upgrading Django to 2.2.6, the solution seems
to be to split a `python-django1` package that works with Python2 and
upgrade `python3-django` to the latest 2.2[.6] LTS release.
This also means that all Python2 Django packages will be stuck & based on
Django 1.11[.24] LTS release. But, it's currently the sanest approach I
could find to be able to perform an upgrade of Django to 2.2, and not break
Seafile.
Upgrading Seafile is also pretty difficult, as their Python3 support is not
yet finished & released. And in the meantime, we want to allow people to
use newer Django versions.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Update to the latest findutils. This eliminates the need for
the sysmacro patch. While we're at it switch to smaller xz
tarball (saves bandwidth)
Signed-off-by: Daniel F. Dickinson <cshored@thecshore.com>
Upstream release message:
"Letsencrypt CA recent changed the CDN provider, which resulted in hanging issues.
Any downstream package should update.
This is important."
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
