| Age | Commit message (Collapse) | Author |
|---|
|
Despite what its name suggest, the PCR repository is not only for
PKGBUILDs that come from AUR.
In the Parabola wiki[1], there is the criteria for packages meant to
go in PCR, and we can deduce from what is written there that PCR is
for packages that both:
* "are not included on official repos of Arch Linux"[1]
* "are not considered to be essential enough for the base system."[1]
So here even if the nvramtool PKGBUILD doesn't come from AUR, it is
meant to go in PCR.
[1]https://wiki.parabola.nu/Repositories#.5Bpcr.5D
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
|
|
|
|
|
Signed-off-by: David P <megver83@parabola.nu>
|
|
|
|
|
|
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
Hyperbola also imported that license in their core repository and Eli
Schwartz uses the Unlicense for pers PKGBUILDs, so using compatible
licenses would enable more code sharing between various distributions
using PKGBUILDs.
In addition several contributors consider many of the PKGBUILDs not to
be copyrightable (because they are very simple).
Note that just adding a license without any clear statements
associated with it brings some legal uncertainty. From the GPL
howto[1]: "If a program has a copy of a license FOO alongside the
source files, but doesn't have an explicit statement that “This
program is released under license FOO,” that leaves room for
uncertainty about whether the license FOO applies to the code of that
program." so it's better to add statements somewhere to use that
license.
[1]https://www.gnu.org/licenses/gpl-howto.html
Link: https://labs.parabola.nu/issues/2862
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
|
The min package depends on electron, and since it's a web browser, and
that electron is unlikely to be fixed any time soon as fixing it would
require substancial work, it's safe to remove it.
Link: https://labs.parabola.nu/issues/3227
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
|
|
|
|
|
this 'pacman' package replaced 'pacman-parabola' in 2014,
when pacman was at major ver 4 - it is extremely unlikely
that anyone would attempt upgrading a system that old,
or that it would be successful
9d87540a9f774ae8a808d1a3bb6d9b112277accd
i would suggest as a rule of thumb, to place _some_ reasonable
limit on backward-compatibilty (eg: 5 years, or 2 pacman major versions)
it has been 8 years and we are at pacman 6 now - it is safe to declare
'pacman-parabola' as irrelevant/obsolete
|
|
|
|
|
|
|
|
|
|
|
|
1. Code has been moved from bookmarks.html.in to another file, see [1]
2. Code from region.properties has been moved as well, see [2]
3. Mozilla added yet another page for promotion of their products, this
time it's in Preferences, and is called "More from Mozilla", which
contains QR code and a feature to send a link to email, which lead to
Firefox Mobile, which is not compatible with the FSDG. So the page
has been removed.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1749435
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1733497
|
|
|
|
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
The uboot-sunxi PKGBUILD is completely unmaintained and it has long
been replaced by the uboo4extlinux-sunxi PKGBUILD.
All the devices that were supported by uboot-sunxi are now supported
by the uboo4extlinux-sunxi PKGBUILD.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
|
|
|
|
|
|
|
The status quo is that any Parabola hacker is expected to (be able to)
modify any packages, and having a single maintainer of a package
discourages that practice as people would typically send a patch to
the maintainer instead of pushing it directly.
So for a start we can add common maintainership on package lacking any
"Maintainer: " header for packages in repositories that are supposed
to be maintained.
As for finding who worked on a given package (in case it could be
needed), the git log should have all the information.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
The status quo is that any Parabola hacker is expected to (be able to)
modify any packages, and having a single maintainer of a package
discourages that practice as people would typically send a patch to
the maintainer instead of pushing it directly.
So for a start we can add common maintainership on package lacking any
"Maintainer: " header for packages in repositories that are supposed
to be maintained.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
Not only it is already in community, but it also needs to be removed
(along with the community version) due to licensing issue: some artworks
are under a CC-BY-NC license.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
|
|
|
|
|
|
this build has problem with playback of some media files
https://lists.parabola.nu/pipermail/dev/2022-March/008200.html
reverting the branding changes only as a precaution,
to reduce the diff, until that problem goes away
most likely, there is nothing wrong with the branding changes though,
and they are not the cause of the media troubles
they worked fine against 97.0.2
|
|
|
|
|
|
this corresponds to (requires) the change in iceweasel-branding.git
with commit message: 'rename user profile dir'
|
|
|
|
|
|
see note in the 'revert v98 branding' commit, and
https://lists.parabola.nu/pipermail/dev/2022-March/008200.html
|
|
|
|
|
|
software
If we use prepare() instead of mksource(), we end up redistributing
nonfree software inside the package source, and it would be better not
to have to do that as this could potentially create licensing issues.
The standard solution to avoid that in Parabola is to use mksource(),
however while this worked fine with other packages, I didn't manage to
make it work with this package, probably because the package code is
complex and that we don't fit into simpler cases handled by
mksource().
The complexity here comes from the need to lower the maintenance cost
of supporting multiple ARM computers and setups: the automation
enables to more easily add new computers, make testing way faster, and
simplify the installation instructions.
Since at the end of the day the goal was to share this deblobing work
with other FSDG compliant distributions, I looked for a distro neutral
project that could be interested in deblobing u-boot and which has
also some infrastructure that we could reuse for that (this avoids
costs in time and money of setting up new infrastructure and of
maintaining it).
As Libreboot planned to add support for u-boot anyway and that its
build system is distribution neutral, it was a good fit.
As for the ability to have patches merged in Libreboot for
u-boot-libre, the initial discussions were complicated:
- Libreboot releases sources and binaries of bootloaders targeting
specific computers. So it would be natural to deblob u-boot and on
top of that, add support for specific computers in Libreboot in the
exact same way it is done for the computers that are supported
through deblobed versions of Coreboot.
However here we want the various distributions (like Parabola and
Guix) to be able to use deblobed u-boot source tarballs that follow
very closely upstream u-boot releases, and that only have changes
related to deblobing. Linux-libre does the latter and this makes it
very easy for FSDG compliant distributions to reuse it as-is.
When adding support for specific computers through u-boot, Libreboot
would instead be more interested in having specific configuration
through u-boot environment and/or by combining u-boot with other
bootloaders like GRUB. It would also be interested in having the
ability to choose specific u-boot versions and specific extra
patches to support specific computers.
As distributions and Libreboot requirements are very similar (they
both need to deblob u-boot) and also slightly different, it was not
easy to get that point across, and I hope that people reading this
commit also get the point across.
- Once I managed to get an agreement that doing that was a good idea
and that I would be able to get my code merged (provided that the
code quality was good) and have Libreboot release the files needed,
I started to implement the code, but I found out week(s) later that
the agreement was gone. The fix for that was simply to restart
explaining it all from scratch and get an agreement again.
Beside the initial complications, getting the code reviewed and merged
was really fast (each patch serie review took 1 week or less) and we
can now just ping the Libreboot maintainer on IRC to get files
released.
According to the Libreboot maintainer I'm the de-facto maintainer of
the u-boot related code in Libreboot, so I'll probably have to be
involved somehow in reviewing the code, and then we need to ping her
to get the code merged.
The discussions were done in #libreboot on liberachat, and the merge
requests were sent against Libreboot repositories (both lbmk and
lbwww) in notabug, so following a similar method will probably result
in future patches being merged rapidely if we hope/assume that I will
manage to review the patches as fast as the Libreboot maintainer did.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
