This package should use the pmb:strict option, in order to force
pmbootstrap to always build it in strict mode. Otherwise it can have
a conflict with packages installed earlier.
I've just noticed that the merged patch was still using the early name
of the option, "pmbootstrap-strict". It was later changed to
"pmb:strict" in the related pmbootstrap!1771 merge request, for
consistency with !pmb:kconfig-check. Fix grub-x86 to use the proper
option name.
[ci:skip-vercheck]: version bump not needed
Disable for arm arches, because there it fails with:
[89/300] Compiling C object 'xcursor/c7765ab@@wlr_xcursor@sta/xcursor.c.o'.
FAILED: xcursor/c7765ab@@wlr_xcursor@sta/xcursor.c.o
gcc -Ixcursor/c7765ab@@wlr_xcursor@sta -Ixcursor ...
cc1: error: /home/pmos/build/pkg/mesa/usr/include: No such file or directory [-Werror=missing-include-dirs]
I suspect, that this relates to our custom mesa packaging, which is only
built for arm architectures currently. Phosh isn't running on anything
other than x86_64 so far in postmarketOS, so let's just disable wlroots
arm too until this is figured out.
[ci:skip-vercheck]: only modified the arch line
Remove Alpine's maintainers and contributors from the APKBUILDs in temp
where we still had them. In general, we don't keep them there, because
we don't want them to get e-mailed about questions from the postmarketOS
aports. It is obvious that they were copy pasted from Alpine, with minor
adjustments.
Remove "Remember to increase pkgrel after changing _pkgver!" from
temp/mesa, because we have a CI check for that now.
[ci:skip-build]: cosmetic changes only
Do not require ci:ignore-count, when using ci:skip-build in a MR that
has change a lot of packages. If the user already supplies ci:skip-build
then we can safely assume that we don't to check the package count.
Fixes#267
When running on upstream/master, don't compare HEAD against
upstream/master. This is the same commit, so all versions will be the
same. Instead compare against HEAD~1.
Make sure that changed aports always have a higher version than what is
currently in master. This check can be skipped with ci:skip-vercheck (in
square brackets).
Related: #187
Fix the regression from the mesa refactoring and from switching to armv7
in hammerhead.
[ci:skip-build]: already built successfully in CI for x86_64; I've
tested manually that it builds for armv7.
Move most code from build_changed_aports.py to common.py. Another patch
will follow soon, which uses common.py to check the versions of changed
aports.
Related: #187
Instead of simply skipping the build check, when ci:skip-build is in
the last commit message (in brackets), download the sources and verify
their checksums.
Depends: pmbootstrap!1788
Fix up for !359: the pkgrel was not bumped, and because the real mesa
version was stored in _pkgver instead of pkgver (which is set to 9999),
this means that the APKBUILD has exactly the same version as before. So
pmbootstrap will not try to build it, resulting in a missing
mesa-dri-lima package and general confusion.
See also:
https://gitlab.com/postmarketOS/pmaports/merge_requests/359#note_170054969
They are available in Alpine again for armhf and armv7.
Networkmanager is still missing, so we keep it it temp for now. Upstream
patch submitted: https://github.com/alpinelinux/aports/pull/7626
Related: #244
Due to the following dependency chain, it is currently not available
in Alpine for armhf and armv7. This breaks postmarketos-base.
postmarketos-base -> networkmanager -> polkit -> mozjs60
This can be reverted, when networkmanager is back for arm{hf,v7} in
Alpine. The mozjs60 arm fix is from here:
https://github.com/alpinelinux/aports/pull/7561
Related: #244
Rebuild to fix missing dependencies:
so:libicui18n.so.63, so:libicuuc.so.63
Currently we are facing another upstream compatibility issue with
Alpine, which is why CI will fail: polkit and therefore
networkmanager don't exist for armhf, armv7. See #244 for details.
Adjust the depends of the GCC-8 cross compiler packages after the change
from pmbootstrap!1778. This does not have any effect (since the GCC-8
aports don't have !tracedeps in options, in contrary to the other GCC
aports we ship). But it makes sure that we don't get any changes after
running the repository maintenance script from here:
https://wiki.postmarketos.org/wiki/Repository_maintenance
[ci:skip-build]: cosmetic change, build would take too long anyway
Explicitly depend on mpc1. Our generated gcc aports use the !tracedeps
option, so we need to explicitly set the libraries it depends on.
This has mostly not been an issue, as we are installing our gcc
packages together with Alpine's gcc package, which causes the libraries
to get installed anyway.
Fixes#236.
[ci:skip-build]: takes too long to build.
This package was a workaround for out-of-tree modules (wireguard). We
have dropped the wireguard kernel module package already, and since
kernel-scripts is failing to build now (it would need to be updated),
let's drop it as well.
If somebody wants to bring back *and maintain* the wireguard
out-of-tree kernel module, I've documented how we had done it here:
https://wiki.postmarketos.org/wiki/Out-of-tree_kernel_modules
[ci:skip-build]: building the kernels that have been adjusted to drop
kernel-scripts related code would take too long for CI,
but I'm making sure that everything still builds before
merging.
All bugs should be ironed out now. Let's get some more testing by
enabling crossdirect in CI again. The crossdirect feature is still only
in pmbootstrap master, not in the latest pmbootstrap release. But if it
works without problems for some time, we're ready to make a release.
This reverts commit 6e3252e401.
Cross linker (e.g. ld from binutils-armhf) does not support any method
of setting additional link paths, and this causes problems when building
various packages. Work around this problem by calling the qemu binary
instead of the cross binary from the native chroot, whenever we are
linking.
I have tested that this allows successfully building hello-world,
coreinfo, libhybris for armhf. So this fixes#227 and fixes#228.
Regarding performance, this is the same way as distcc does it. We would
get a performance gain if we were able to use the cross-linker. But so
far I could not figure out how to patch the binutils source to make it
work like we want to have it. Maybe I'll ask on some binutils mailing
list for advice. In the meantime, this workaround should make
crossdirect work for all use-cases, and it is still faster than the
previous distcc setup, because we can avoid the overhead of setting up
and running a ssh server locally to work around missing authentication
in distcc (see pmbootstrap!1649). Let's test this for some more time,
and then make a pmbootstrap release that rolls out crossdirect for
everyone.
Instead of running compilers directly, let them go through the native
ccache binary. Note that it will still use the foreign arches cache dir
because the native cache dir would be at /native/home/pmos/.ccache.
Use execve instead of setenv and execv, because that didn't work with
LD_LIBRARY_PATH (ccache was complaining that it couldn't load zlib).
Enable -Werror, because we are maintaining this program and it helps
us catching bugs early.
Create symlinks for all supported arches (armhf, armv7, aarch64, x86_64,
x86), not only armhf and aarch64. Skip creating symlinks for the arch
that the package gets built for, so we can include x86_64 in the list
without conflicting with the ccache package from Alpine.
Link to ../../../bin/ccache instead of /usr/bin/ccache, so it works
properly with crossdirect (where we mount the native chroot to /native
in the foreign chroot).
Add symlinks for clang and clang++.
This version has the "crossdirect" package, which will be required for
the new pmbootstrap code that uses the crossdirect compilation method by
default.
Thanks to Robert Yang's pmbootstrap patch, we can now avoid flashing
anything to the boot and recovery partition of the Ouya. With this
patch, the latest pmbootstrap will refuse to do so with:
ERROR: 'boot' partition is blacklisted from being flashed! See the Ouya device wiki page for more information.
Do not crash when a MR was made from the same repository, because the
"allow_maintainer_to_push" key does not exist in the GitLab API's
output. Check first if the "source_project_id" is the same as the
"target_project_id", and if it is, do not try to access
"allow_maintainer_to_push" at all.
Check if users activated the 'Allow commits from members who can merge
to the target branch' option in their MRs.
Add the "only" parameter to each job in .gitlab.yml, so the pipeline
can properly run in a "merge request specific context" and give us the
environment variable that contains the MR ID.
Make it possible to build old kernels with gcc4 for armv7 and aarch64.
The packages have been generated with (as usually):
$ pmbootstrap aportgen gcc4-aarch64 gcc4-armv7
[ci:skip-build]: I have tested that this builds locally.
Fixes#193.
Allow skipping the "too many packages changed" check by specifying
"ci:ignore-count" in the commit message.
Allow skipping the package build step by specifying "ci:skip-build"
in the commit message. In contrary to the usual "skip ci" method,
this will still run all the other CI checks.
This isn't building anymore, because linux-postmarketos-stable has been
switched from armhf to armv7 in pma!240.
We could change the arch of wireguard-postmarketos-stable too, but the
package is not maintained at all, and I doubt that anybody is using it.
So I'm dropping it. If there are any users, please step up to maintain
the package.
Ignore this kernel in "pmbootstrap kconfig check" by default, so we can
use the upstream kernel config without any changes. But still enable the
kernel config check again.
The related pmbootstrap change will be merged soon:
https://gitlab.com/postmarketOS/pmbootstrap/merge_requests/1753
[skip ci]: this change doesn't affect the build
Plasma-framework 5.55.0 isn't building for aarch64 without this patch.
Aleix Pol ran into the same problem with flatpak builds, and created the
patch: https://codereview.qt-project.org/#/c/253276/
Fails to build for armhf with the error below, and doesn't seem to be
tested on anything but x86_64 anyway according to the project's
README.md file. I did not report this upstream, because we are using
the version from Purism's repository that is at 1.2.31. Upstream is
already at 1.2.68, which may have fixed this already. So if somebody
needs to have it working for anything other than x86_64, we should try
the upstream version first.
[ 83%] Creating preprocessed clst file /home/pmos/build/src/mfgtools-uuu_1.2.31/uuu/gen/emmc_burn_all.clst
gen_txt_include.sh: applet not found
make[2]: *** [uuu/CMakeFiles/uuu.dir/build.make:63: uuu/gen/uuu.clst] Error 127
make[2]: *** Waiting for unfinished jobs....
gen_txt_include.sh: applet not found
make[2]: *** [uuu/CMakeFiles/uuu.dir/build.make:68: uuu/gen/emmc_burn_loader.clst] Error 127
gen_txt_include.sh: applet not found
gen_txt_include.shmake[2]: *** [uuu/CMakeFiles/uuu.dir/build.make:73: uuu/gen/emmc_burn_all.clst] Error 127
: applet not found
make[2]: *** [uuu/CMakeFiles/uuu.dir/build.make:93: uuu/gen/sd_burn_all.clst] Error 127
make[1]: *** [CMakeFiles/Makefile2:184: uuu/CMakeFiles/uuu.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 83%] Built target uuc
make: *** [Makefile:130: all] Error 2
Do not replace compiler-gcc.h. This is necessary now, as we are
replacing compiler-gcc.h by default again, as it is needed for most
kernels. Not increasing the pkgrel to avoid unnecessary rebuild, I have
verified that this works.
NOTE: in the last commit message, I wrote about OVERWRITE_GCC=0. But
the variable is called REPLACE_GCC, as I've decided to rename it before
submitting. I forgot to change it in the commit message.
[skip ci]: this kernel takes more than one hour to build, so it won't
finish in CI.
Instead of never overwriting compiler-gcc.h if it exists, overwrite it
by default except if OVERWRITE_GCCH=0 is set in the environment.
Most kernels *do* need this file replaced and won't build without this
patch.
When we bump the version in pmaports.cfg and the min. required pmaports
version in the pmbootstrap code, then forks of pmaports.git must be
rebased on pmaports.git master. Otherwise "pmbootstrap init" fails, and
because we have it set to quiet (so the output does not distract from
the interesting output if everything goes fine), there was no meaningful
error message yet.
Wrap the "pmbootstrap init" call and display a helpful message that
tells the user to rebase.
Right now, this doesn't build anymore, it is failing with:
/home/pmos/build/src/itinerary-c47772e49de6662acd7769d5c8cef94379ea7bcf/src/app/reservationmanager.h:21:10: fatal error: KItinerary/ExtractorRepository: No such file or directory
#include <KItinerary/ExtractorRepository>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I've tried to update it to the latest commit, but then it fails with
another error. Turns out, this package depends on kitinerary (with a
k!), and whenever we update that, we also need to update this package
to the latest commit. Unfortunatelly, itinerary does not have tagged
versions yet.
So I would like to remove it for now, it does not seem like anybody is
using it at this point, and so it's just additional maintenance effort
for nothing. We could package it again, when it has tagged versions and
is therefore easy to update together with kitinerary.
Remove kitinerary too, because it isn't used by anything else.
Add python2 to makedepends, so it builds in strict mode for armv7.
Otherwise it would fail with:
checking whether /usr/bin/python2 version >= 2.6... configure: error: too old
Turns out we do need to fork this aport, as it builds qgpgme, which
Alpine's aport does not build as of now. Updated to 1.12.0 and changed
the pkgver to 9999, so it does not conflict with Alpine's aport.
We had probably added this, because no binary package was present in
Alpine at the time. Now it is present, and the package has been updated
in Alpine. No need to keep this outdated version around.
Run 'pmbootstrap aportgen gcc6-aarch64 gcc6-armhf' again and commit
the resulting changes, as these packages are meant to be always
auto-generated and therefore in sync with main/gcc6.
This changes the pkgver to 9999, as it was required in main/gcc6 to
avoid conflicts with Alpine's gcc6 package.
Rename test_aports_kde.py to test_aports_framework_versions.py and
generalize all referenes in the code from "KDE frameworks" to
"frameworks". Check that all Qt packages have the same version, support
having the real version in _pkgver and pkgver=9999.
Scan all pmaports, not only the ones in the kde dir. Do not output all
packages of the "other" category anymore, the package count is enough.
Let pmbootstrap properly parse the package URLs, this is required for
the next commit where we start comparing the pkgver of all QT packages
- based on the URL like we do it for the KDE packages.
Regenerate these aports, so the test case does not complain anymore
that they are outdated. Adds armv7 to the arch lines, as that is the
aportgen change which was done in pmbootstrap!1730.
Workaround for a build error on aarch64, where the binary package
repository is currently stuck. Compiling it for aarch64 like this:
$ pmbootstrap build --strict --arch=aarch64 qemu
Resulted in:
>>> qemu: Analyzing dependencies...
ERROR: unsatisfiable constraints:
openssl-dev-1.1.1a-r0:
conflicts: libressl-dev-2.7.4-r2[pc:libcrypto=1.1.1a]
libressl-dev-2.7.4-r2[pc:libssl=1.1.1a]
libressl-dev-2.7.4-r2[pc:openssl=1.1.1a]
satisfies: curl-dev-7.62.0-r2[openssl-dev]
libssh2-dev-1.8.0-r4[pc:libcrypto]
libssh2-dev-1.8.0-r4[pc:libssl]
spice-dev-0.14.1-r3[pc:openssl]
libressl-dev-2.7.4-r2:
conflicts: openssl-dev-1.1.1a-r0[pc:libcrypto=2.7.4]
openssl-dev-1.1.1a-r0[pc:libssl=2.7.4]
openssl-dev-1.1.1a-r0[pc:openssl=2.7.4]
satisfies: world[libressl-dev]
libssh2-dev-1.8.0-r4[pc:libcrypto]
libssh2-dev-1.8.0-r4[pc:libssl]
spice-dev-0.14.1-r3[pc:openssl]
>>> ERROR: qemu: builddeps failed
Note that the only package not mentioned in both "satisfies" outputs is
curl-dev. The real questions are: why is libressl-dev getting pulled in
at all? (Alpine switched back from libressl to openssl, so this should
not happen). And why does this only happen for aarch64, but not for
x86_64 and armhf? But at least this patch unblocks the package builder.
Oliver Smith