This will configure Pakfire that people who install a nightly
build will also get the packages for this build, etc.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
perl 5.30 will not work on kirkwood platform and firewinfo reports less than 10 users so we will drop the support for the platform.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Maxmind has disabled the download so we ship the last free (creative commons)
database with the iso and core until we build an alternative.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
AWS Systems Manager Agent (SSM Agent) is Amazon software that can be
installed and configured on an Amazon EC2 instance, an on-premises
server, or a virtual machine (VM). SSM Agent makes it possible for
Systems Manager to update, manage, and configure these resources. The
agent processes requests from the Systems Manager service in the AWS
Cloud, and then runs them as specified in the request. SSM Agent then
sends status and execution information back to the Systems Manager
service by using the Amazon Message Delivery Service.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
The build sometimes aborted because python was not found
when Grub was being built for EFI.
Fixes: #12209
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This is a CLI implementation to test the speed of an internet
connection.
I find this quite useful when there is no access to a client
computer on the network and this will give you a rough idea
about the connection speed.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
the inode count of tmpfs defaults on availbable low memory page count
which is too low on 32bit machines
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
this is a heavy patched version and should replaced when stock
u-boot is able to boot from h3 eMMC.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Since we have now one cache for each architecture, we do not
need to make it too large.
The largest build (i586 because of the two kernels) uses around
2.5GB after one build. So 4G will give us some space.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
It does not make much sense to mix architectures into a single
ccache:
* There is never going to be a match
* The cache gets bigger and therefore slower
* If both architectures are being compiled one after the other and
the cache hits its maximum size, cached but still needed content
will be dropped
* Only both can be deleted together
This small change splits this into multiple caches. One per
architecture. Therefore we should be more efficient on builders
that build for multiple architectures.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
