I tried my best to get the right author based on git commit history, but
in the case of code being moved from one file to make another I might
have gotten something wrong.
the kernel has pending patches in -next which adjust the generated
Makefile in the output directory to include the source tree makefile
with an absolute path, this breaks envkernel which relies on it being a
relative path.
Fix this by mounting our own Makefile instead using the relative path.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Otherwise abuild will try and fail to create /dev/null
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
[ci:skip-build]: already built successfully in CI
recent changes to the kernels build infra in -next seem to have exposed
some issues with "pmbootstrap build --envkernel", specifically in the
case where the APKBUILD doesn't build out-of-tree.
We used to rely on the fact that the kernel output directory contains a
Makefile which points to the source directory, however this Makefile
now(?) contains an absolute path on the host, which won't match what's
in the chroot.
As a result, it's now necessary to build with the same output directory
as the APKBUILD.
We probably need some smarter code here... and/or more consistent
APKBUILDs.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Replace aports -> pmaports in these messages.
$ pmbootstrap build systemd
[17:37:02] NOTE: The package 'systemd' exists in extra-repos/systemd, but systemd is currently disabled
[17:37:02] ERROR: Could not find package 'systemd' in pmaports
There was an oversight when this API was originally created and it
implicitly assumed that the pmaports repository was always named
"pmaports". This unfortunately broke some peoples workflows.
Introduce a new "pkgrepo_name()" function and adjust the codebase to use
it, as well as adjusting pkgrepo internally to special case the
"pmaports" repo so that it's always named pmaports no matter what the
directory itself is named.
This is probably more complexity than we should be dealing with here, we
should probably create a new type to encode this behaviour.
Fixes: #2412
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
At some point, this function was updated to use the Arch type instead of
plain strings, but the return type was left omitted and the docstring
outdated.
Some packages in aports have their own subpackages in their
dependencies, for some reason. This causes our resolver to assume there
is a cyclical dependency.
Adjust the resolver to safely ignore these dependencies, since they'll
be built as a part of the package that depends on them.
For example, modemmanager depends on libmm-glib which is a subpackage of
modemmanager. Currently to build modemmanager in pmaports it would be
necessary to manually modify the APKBUILD after copying it from aports.
This change avoids that.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
It may be desirable to test older versions of packages, allow them to be
built when --force is specified and print a warning that they won't be
installed automatically.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
I don't think there's any case where the number of jobs would have to be
a string. It's also being assigned an integer elsewhere the code (in
ask_for_additional_options() inside of init.py), so an integer seems
like what we actually want. Also fix type errors resulting of this.
Here's the problem: Imagine a queue with 2 packages in it, the 1st
package uses crossdirect and the second uses cross-native. When building
the 1st package, pmb will configure the native chroot for crossdirect
as expected. When it gets to the 2nd package, the chroot env/config
might not be appropriate for actually doing a native cross compile.
This re-inits the cross compiler stuff if the cross compile method
changes while processing the queue.
Another approach that might solve this problem is to not re-use chroots
when building packages... I didn't think this was a good way to go
because it would greatly increase runtime (having to recreate chroots
multiple times)
When a dependency cannot be found in source or binary packages of the
selected architecture, then don't look for binary packages in other
architectures package indexes.
This leads to a confusing error down the line when building packages for
extra_repos_systemd (and e.g. stable branches), because we don't have
binary packages for all arches that pmbootstrap supports, and so it
tries to fetch a non-existing APKINDEX.
Instead, print a nice error about a non-existing dependency.
Adjust the dependency resolver, so it uses the main pkgnames in
dependency resolution, instead of subpackages. This fixes for example
that it couldn't find -dev packages even though the binary packages for
those existed.
> systemd: missing dependency linux-pam-dev, trying to queue other packages first
> linux-pam: missing dependency systemd-dev, trying to queue other packages first
> dbus: missing dependency systemd-dev, trying to queue other packages first
Have messages like the following in "pmbootstrap log" to better
understand why resolving packages fails. The bug with -dev pkgs not
being recognized will be fixed in a follow-up patch.
> systemd: missing dependency linux-pam-dev, trying to queue other packages first
> linux-pam: missing dependency systemd-dev, trying to queue other packages first
> dbus: missing dependency systemd-dev, trying to queue other packages first
Print a warning when breaking cyclical dependencies, for example with
current kde-nightly branch:
> WARNING: cyclical build dependency, building kirigami with binary package of qqc2-desktop-style
Set "stuck = False" in the "while disarray and not stuck" loop
directly, instead of setting it in the queue_item() function that gets
called from it. This way the loop logic can be understood without
looking at queue_item().
Most of the time when building it's reasonably safe to fall back on an
older binary package for building in order to break cyclical
dependencies (e.g. dbus and systemd depend on each other at build time,
but it's safe to build both against older versions of the other).
Implement the necessary logic to break cyclical dependencies by
detecting them and checking for the existence of a binary package.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Tweaked-by: Oliver Smith <ollieparanoid@postmarketos.org>
Decide the order to build packages in by looking through the build queue
and making sure dependencies are queued before any packages that depend
on them, bailing out in the case of cyclical dependencies.
This should handle subpackages too.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
When building with --src or --force, other logic to detect when to build
a package is skipped. However there are no (known) cases when someone
might want to build a package if the resulting binary package version
will be older than an existing binary package. Catch this case and fail
with recommendations for user action (update pmaports, clear local
binary repo).
This should help avoid the situation where you accidentally build an old
version of a package and it never actually gets installed.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Tweaked-by: Oliver Smith <ollieparanoid@postmarketos.org>
This function is really hard to understand, try to make this a bit
better by adjusting the wording to better reflect what it does.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
build_packages like apk-tools and alpine-base might get picked up and
queued for build as dependencies of other packages. We don't want this
since we always ensure they are queued first. Avoid queuing them in this
case.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
It turns out the current behaviour was not preserving the old behaviour
at all, and was wrong. We want to build ALL outdated or new packages we
encounter via the dependency graph.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Change to "back to pamports dir" instead of "back to aports-folder".
Naming the pmaports dir just "aports" is legacy from before pmaports.git
was split out to a separate git repository.
We handle this correctly for dependencies of the base package but not
the base package itself.... Fix this.
Should avoid duplication here ideally.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
A previous attempt inserted subpackage depends into the package depends
list returned by get_depends().
This meant that pmb would try to install subpackage depends when
building the package, which breaks for some cases like device packages
with kernel variants since the depends of different subpackages might
conflict with each other.
Let's instead just add the subpackage depends to the build queue, so
they get built like package depends, without being pulled in as build
dependencies for the package.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Bail on empty build queue after checking if build_packages need
building. So if apk-tools / alpine-base / etc are outdated but nothing
else is they'll still be built.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
