| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
permissions
|
|
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
Signed-off-by: David P <megver83@parabola.nu>
|
|
Signed-off-by: David P <megver83@parabola.nu>
|
|
Signed-off-by: David P <megver83@parabola.nu>
|
|
|
|
|
|
|
|
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
Signed-off-by: David P <megver83@parabola.nu>
|
|
|
|
|
|
Signed-off-by: David P <megver83@parabola.nu>
|
|
Some key packages are signed by bill-auger, however for some reasons,
creating a chroot with librechroot results in an error related to
Bill's key. For instance if we create a new chroot with the following
commands:
$ sudo rm -rf /var/lib/archbuild/parabola-x86_64/
$ sudo librechroot -n parabola-x86_64 -A x86_64 make
We end up with:
(116/116) checking package integrity [...] 100%
[...]
error: filesystem: signature from "bill-auger
<bill-auger@peers.community>" is unknown trust
:: File
/var/cache/pacman/pkg/filesystem-2020.09.03-1.parabola1-x86_64.pkg.tar.xz
is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
It also prevent builds in existing librechroot due to
dependency issues.
The associated bugreport is available here:
https://labs.parabola.nu/issues/2925
While other Parabola developers are also busy trying to fix
the root cause of this issue, it might be a good idea to also
restore the ability to create librechroots in parallel. That
may also be useful to build potential fixes.
To build the previous packages (linux-libre-api-headers and
pacman-mirrorlist), I used use the workaround present in the
bugreport (date --set=2020-11-01) in a KVM vm not to mess up
the date of the host. More lightweight VM systems like lxc
don't allow to change the date.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
Some key packages are signed by bill-auger, however for some reasons,
creating a chroot with librechroot results in an error related to
Bill's key. For instance if we create a new chroot with the following
commands:
$ sudo rm -rf /var/lib/archbuild/parabola-x86_64/
$ sudo librechroot -n parabola-x86_64 -A x86_64 make
We end up with:
(116/116) checking package integrity [...] 100%
[...]
error: pacman-mirrorlist: signature from "bill-auger
<bill-auger@peers.community>" is unknown trust
:: File
/var/cache/pacman/pkg/pacman-mirrorlist-20201002-1.parabola1-any.pkg.tar.xz
is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
It also prevent builds in existing librechroot due to
dependency issues.
The associated bugreport is available here:
https://labs.parabola.nu/issues/2925
While other Parabola developers are also busy trying to fix
the root cause of this issue, it might be a good idea to also
restore the ability to create librechroots in parallel. That
may also be useful to build potential fixes.
To build the previous package (linux-libre-api-headers) I used
use the workaround present in the bugreport (date --set=2020-11-01)
in a KVM vm not to mess up the date of the host. More lightweight
VM systems like lxc don't allow to change the date.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
Some key packages are signed by bill-auger, however for some reasons,
creating a chroot with librechroot results in an error related to
Bill's key. For instance if we create a new chroot with the following
commands:
$ sudo rm -rf /var/lib/archbuild/parabola-x86_64/
$ sudo librechroot -n parabola-x86_64 -A x86_64 make
We end up with:
(116/116) checking package integrity [...] 100%
error: linux-libre-api-headers: signature from "bill-auger
<bill-auger@peers.community>" is unknown trust
:: File
/var/cache/pacman/pkg/linux-libre-api-headers-5.8.13_gnu-1-x86_64.pkg.tar.xz
is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
To make sure it wasn't an issue only affecting my builder, I made
the host recreate the /etc/pacman.d/gnupg directory from scratch
after deleting this directory and killing all gpg, dirmngr and
gpg-agent instances. I then refreshed the keys, during that,
Bill's key was not updated:
gpg: key 25DB7D9B5A8D4B40: "bill-auger <bill-auger@peers.community>"
not changed
After that this problem persisted.
It also affects the reinstallation of some key packages on the host
as well:
# pacman -S linux-libre-api-headers
warning: linux-libre-api-headers-5.8.13_gnu-1 is up to date -- reinstalling
[...]
(1/1) checking package integrity [...]
error: linux-libre-api-headers: signature from
"bill-auger <bill-auger@peers.community>" is unknown trust
:: File
/var/cache/pacman/pkg/linux-libre-api-headers-5.8.13_gnu-1-x86_64.pkg.tar.xz
is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n] n
error: failed to commit transaction (invalid or corrupted package
(PGP signature))
Errors occurred, no packages were upgraded.
So in order to be able to enable Parabola hackers to still build
packages, and not end up in a chicken and egg issue, I'll try to
rebuild it from the librechroot(s) that I have left.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
Note that simtrace and simtrace2 is not the same software: simtrace
is for the first generation hardware while simtrace2 is for the
second generation.
While the PCB is mostly the same, the microcontroller, the (free)
software inside that microcontroller and the host software are
different.
So while the microcontroller can be upgraded by people that know
how to unsolder and resolder microcontrollers, it's still a good
idea to support both devices in Parabola.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
|
instead of native
|
|
list from PKGBUILD
|
|
from PKGBUILD
|
|
|
|
|
|
updatelanglist.sh to manage shasums
|
|
|
|
this package can be removed once the arch package is working again
https://bugs.archlinux.org/task/65898
|
|
|
|
Signed-off-by: David P <megver83@parabola.nu>
|
|
|
|
|
|
|
|
|
|
originally, the libre.patch simply deleted the documentation usage examples;
because they referred to non-FSDG-fit distros;
and the 'osinfo-db' package has no definitions for FSDG-fit distros
this commit adds back the usage examples, referring to FSDG distros instead
the exact usage examples given will not work, without also adding
the 'parabola' definition to the osinfo database
the documentation is complete however; so that is already an improvement
we could fork the 'osinfo-db' package, to add the parabola definition;
but experimentation suggests that it can be accomplished
via the 'libosinfo' package, which parabola already patches
ideally, we should request that parabola be added to the osinfo-db upstream
(which is probably a good idea anyways)
|
|
the changes in this patch are more extensive
than what the commit message would suggest
they are predominantly for the sake of
minimizing the diff with upstream
this is a split package upstream; but only 'virt-install' is on the blacklist
originally, the package_virt-manager() function was deleted
and the package_virt-install() function was left in tact,
including the code that splits the output files into two packages
that made this PKGBUILD quite confusing:
* the pkgbase and abslibre directory are named 'virt-manager'
* the PKGBUILD is still formatted as a split package,
which happens to output only one single package
* some non-package files are stashed aside, for apparently no reason,
rather than making the intention obvious by deleting them
all of the work necessary to output the 'virt-manager' package,
is necessarily done by this PKGBUILD while building 'virt-install'
(the package_virt-manager() function is merely a `mv` statement);
so there is no reason not to package both
packaging 'virt-manager' also has the benefit, of the pinned
'virt-install' dependency of 'virt-manager', being always satisfiable
been added to the blacklist with reason: 'technical'
virt-manager has been added to the blacklist with reason: 'technical'
|
|
|
|
|
|
|
|
|
|
|
