the x86_64 build fails - any ideas?
| 0:46.59 ./rust_helper.h.stub
| 0:47.05 thread 'main' panicked at src/bindgen/config.rs:1125:34:
| 0:47.05 called `Result::unwrap()` on an `Err` value: "Couldn't parse
config file: TOML parse error at line 363, column 1\n|\n363 | \"Keyframe\"
= \
On Sat, 06 Jul 2024 11:26:14 -0600 Luke wrote:
> - librerelease:
> + Has a new `-C` flag to clean the remote staging area (a
> complement to `-c` which cleans the local staging area).
i could comment on that one too - ideally, that would not be needed - it is
there because if a release
thanks for reviewing those - ive had a lot of that pending for years - just a
few explanations
On Sat, 06 Jul 2024 11:26:14 -0600 Luke wrote:
> - librerelease:
> + librechroot.conf:REPODEST got replaced by
> TIER0_{USER,HOST,PORT,STAGING}.
> Though it is now clear that if we
>
from arch:
After upgrading to `openssh-9.8p1`, the existing SSH daemon will be unable to
accept new connections (see
<https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5>).
When upgrading remote hosts, please make sure to restart the sshd service
using `systemct
there were only a few packages in the repos, all signed by g4jc - i
deleted one (qt4-only, inactive upstream) and rebuilt the others
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
merged thanks
On Sun, 05 May 2024 16:28:25 + kwopleq wrote:
> I tried to attach a file made by mksource(), but it didn't work.
> It's not clear how people should contribute to build recipes
> that use files from Parabola as source.
just send a patch, the same as any other package `git format-
i converted iceweasel into a mksource PKGBUILD - that probably should have been
done a long time ago, seeing as the PKGBUILD indicates in several places that
it is removing "non-free bits", "pre-built bits", and such
the PKGBUILD needed to change quite a bit; but it should not add to or impede
the
On Mon, 17 Jun 2024 02:38:27 -0400 bill-auger wrote:
> i would prefer to delete the package, in orfder to clean up PCR, rather than
> maintain stuff that no one uses
assuming that all such packages are in PCR - they probably are - anything in
libre may need to be kept - IIRC that is the g
those are some very interesting numbers - unfortunately, i think what that
really demonstrates more than anything is that there is a lot of cruft in the
pool - the true stats need to be against the repo.db files, like my script does
i suspect that most of the orphaned packages (the ones actually r
offhand, i doubt that this is related to the recent makepkg config changes;
because that was three weeks ago, and everything seemed fine last week
i have been compiling kernels for about 10 days - the last builds were very
slow for all arches - i noticed because the ARM build is taking an absurdl
i have a script for that on the git server `packages-by`
https://git.parabola.nu/parabola-maintenance-tools.git/tree/packages-by
may as well start with that, enhance it, fix it, whatever
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.
On Sun, 16 Jun 2024 08:10:02 -0400 bill-auger wrote:
> only the key for the libre source-ball is valid during normal makepkg runs
more practically i suppose, users building at home only need the key for the
libre source-ball - they would not need the upstream's key
also, just a note t
ive made some changes for librestage and librefetch - only one patch for
librefetch is significant - "significant", in that i could probably make
meaningful tests for these two - the others are minor enhancements (nearby
changes i have on my WIP branches)
i have many enhancements accumulated over
my GPG key is due to expire; so i need to rebuild the keyring package this week
- i just ran the tool i made that reports the status of the keys in the
keyring, and noticed that a newly expired key appeared on the error list;
which reminded me that a clean-up is overdue - all of those keys are for
billauger closed without merging a pull-request against the project: `abslibre`
that you
are following.
Closed pull-request:
``
libre/iceweasel: 127.0-1.parabola1
``
https://pagure.io/abslibre/pull-request/99
___
Dev mailing list
Dev@lists.parabola.
billauger commented on the pull-request: `libre/iceweasel: 127.0-1.parabola1`
that you are following:
``
merged
``
To reply, visit the link below or just reply to this email
https://pagure.io/abslibre/pull-request/99
___
Dev mailing list
Dev@lists.par
also, just wondering, why did these 'REMOTE_STAGE_ENDPOINT_URL' not also
get stubbed/spoofed?
but furthermore, couldnt you simply delete the entire mobile/ directory? -
i would think that the parabola builds would never need nor touch it -
why should you need to patch any of that? - gnuzilla keep
just to note, i deleted that .nvchecker.toml file again, and added them
to .gitignore - most packages have that now - ive not been adopting them
> we dont need these - they appear to be something that arch uses internally,
> or is related to their gitlab instance, to detect new releases upstream
>
ok i had time today to nail this down
On Wed, 12 Jun 2024 09:53:57 -0400 bill-auger wrote:
> PKGDEST contains invalid characters
> SRCDEST contains invalid characters
that was for the obvious reason - those vars are not necessarily defined in
makepkg.conf - those are not defined unt
oh i could add that i made a toy PKGBUILD that exercises mksource
pcr-testing/scratch-pkg/PKGBUILD
# NOTE: This PKGBUILD is for experiments and for testing libretools.
# Packages built with this PKGBUILD are not intended for distribution.
# Only the -nonfree source-ball is published,
On Wed, 12 Jun 2024 09:53:57 -0400 bill-auger wrote:
> librefetch.conf will
> not be installed in any chroot (ive actually experimented with that, and i
> believe that it should never be)
that did not come out quite right - i mean that the lbretools package should
not be install
On Thu, 30 May 2024 19:33:58 -0600 Luke wrote:
> On Wed, 29 May 2024 00:51:18 -0600, bill-auger wrote:
> > < #
> > < #
about the licenses array - we are in the process of migrating to the SPDX
schema as arch has done - the licenses listed in almost every PKGBUILD will need
to change - we have determined that it is safe to change them now - so for
'gmid', 'ISC' is no longer 'custom'; but is now a standard license ID
there are a few problems with this one - most significantly, you did not update
the pkgver or the pkgrel - the repo would not accept that package because it
has the identical filename as the existing one - at the very least, the pkgrel
needs to be bumped - but it is not obvious what pkgver represen
billauger closed without merging a pull-request against the project: `abslibre`
that you
are following.
Closed pull-request:
``
libre/iceweasel: 126.0.1.parabola1, sync with upstreams
``
https://pagure.io/abslibre/pull-request/98
___
Dev mailing lis
billauger commented on the pull-request: `libre/iceweasel: 126.0.1.parabola1,
sync with upstreams` that you are following:
``
merged - thanks :)
``
To reply, visit the link below or just reply to this email
https://pagure.io/abslibre/pull-request/98
_
On Fri, 31 May 2024 13:07:54 -0600 Luke wrote:
> You can get this in the pacman 6.1.0-3.parabola7
> /usr/share/pacman/defaults/makepkg.conf.armv7h.
yes LTGM - most importantly, that same file gets installed to /etc (new
librechroots or .pacnew)
On Fri, 31 May 2024 13:07:54 -0600 Luke wrote:
> I
On Thu, 30 May 2024 19:42:03 -0600 Luke wrote:
> Reference: abslibre.git c049cb42c (pacman: upgrade to v6.1.0, bill-auger,
> 2024-03-19)
yeap guiltay as charged - i did not apply it in my chroots until now though
i just wanted to discuss it formally, as a well-oiled team should - its g
On Thu, 30 May 2024 19:42:03 -0600 Luke wrote:
> Fair enough, I'll push out a new pacman that has the armv7h
> makepkg.conf use the ALARM version (zstd -c -T0 --ultra -20 -) plus
> --single-thread.
i think we want to omit `--ultra -20` - the manual says that will use more
memory
we do not need to
these are the exact opts i used for armv7h:
COMPRESSZST=(zstd -c -z -q --single-thread -)
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
i think we should revert the package compression change for ARM - the latest
change made zstd too hungry
libre/pacman/makepkg.conf.archarm:
-COMPRESSZST=(zstd -c -z -q -)
+COMPRESSZST=(zstd -c -T0 --ultra -20 -)
that got me into trouble with the first package i tried - util-linux
failed with this
On Wed, 29 May 2024 01:54:49 -0400 bill-auger wrote:
> (careful to keep the "modular config" section o/c)
on second look, i think i was supposed to delete that entire section, not
modify it? - libremakepkg did not complain - this is the diff as i have it now
$ diff /etc/makepkg.
On Tue, 28 May 2024 21:26:33 -0600 Luke wrote:
> - libremakepkg: The way we adjust the makepkg configuration in the
> chroot should no longer result in .pacnew files when upgrading the
> chroot's pacman.
it did though - i just upgraded my ARM librechroot; and i had to to merge some
trivi
> +@@ -200,10 +200,11 @@ export class Downloader {
> ...
> + avoidDownload = false,
> ...
> const blob = new Blob([newBuffer]);
ewww, such foul language - should we be concerned about this?
___
Dev mailing list
Dev@lists.parabola.nu
https
billauger commented on the pull-request: `libre/iceweasel 125.0.2.parabola1`
that you are following:
``
merged
``
To reply, visit the link below or just reply to this email
https://pagure.io/abslibre/pull-request/97
___
Dev mailing list
Dev@lists.para
billauger closed without merging a pull-request against the project: `abslibre`
that you
are following.
Closed pull-request:
``
libre/iceweasel 125.0.2.parabola1
``
https://pagure.io/abslibre/pull-request/97
___
Dev mailing list
Dev@lists.parabola.n
there are built packages in pcr-testing now - plz test at least the x86_64
package to ensure that it behaves correctly - then they can be moved to pcr
# pacman -U
https://repo.parabola.nu/pool/parabola/fsearch-0.2.3-1-x86_64.pkg.tar.zst
___
Dev mailin
'tp_smapi' is at the latest version 0.44, released Jul 31, 2023
is it not working?
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
ok, i took a look at that PKGBUILD - there are several issues to address - i
have made all of these changes; but as the maintainer you should be aware of
them
* PKGBUILDs need a `Maintainer:` line, as someone who is associated with
parabola - PKGBUILDs forked from anther source (eg: the AUR) sho
you sent this to me only; so the mailing list did not get it - when replying to
mailing lists, mind that you need to press "reply-all" or "reply-list",
depending on your client
Begin forwarded message:
Date: Sat, 30 Mar 2024 15:18:52 -0700
From: Integral
To: bill-auger
Sub
FWIW, i found out about this first from the FSF tech team - they pinged me this
morning to ask me to check if parabola had a vulnerable build - the arch
announcement came several hours later; though the arch maintainer had addressed
the issue about 12 hours earlier
the warning is only to err on th
From: "Arch Linux: Recent news updates: David Runge"
TL;DR: Upgrade your systems and container images **now**!
As many of you may have already read [1], the upstream release tarballs for
`xz` in version `5.6.0` and `5.6.1` contain malicious code which adds a
as i usually ask with new submissions for PCR, would you be willing to maintain
the PKGBUILD? - that entails
* to test build each new version for all arches using libretools
* submit the updated PKGBUILD to parabola, describing any problems it may
have, such as failing to compile for one arch
*
i am making a new release of libretools (v20240324), mainly for two reasons:
1) one of the changes in the previous release broke mksource
https://git.parabola.nu/packages/libretools.git/commit/?id=a623a620f68ba19750fc4feba34d1d2db8cd08dc
that reverted a previous change, which was made specifically
it is done, thanks
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
it is done, thanks
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
it is done, thanks
BTW, you seem to be keen on these KDE things - there is one more 'konqueror'
that i would like to rescue from the webengine heap - i tried to build it
yesterday but the patch needs re-working, or maybe like the others this week,
no longer needed - if youd like to take a stab at
it is done, thanks
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
it is done, thanks
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
it is done, thanks
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
it is done, thanks
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
it is done, thanks
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
x86_64 is done, thanks
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
On Sun, 25 Feb 2024 00:11:00 -0800 Integral wrote:
> Yes, the download feature is also working.
awesome - it is done
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
is the download feature also working?
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
the arch PKGBUILD explicitly disables webkit support, suggesting that webkit is
supported upstream as an alternative to webengine - i tried that and it
compiled
i published the package to libre-testing; because i do not know how to use this
program - can you test that package to verify that it wor
Begin forwarded message:
Date: Sat, 24 Feb 2024 22:22:42 -0800
From: Integral
To: bill-auger
Subject: Re: [Dev] [PATCH] fcitx5-chinese-addons: remove qt5-webengine from
depends & change cmake args
The original "fcitx5-chinese-addons" which is from Arch Linux has a
feature to
you did not describe the changes or their motivation - eg: why are those
changes desirable? what are the consequences? 'qt5-webengine' should not be in
depends of any parabola PKGBULD now; because parabola does not have that
package - is there a related bug report?
_
just because someone forks a project, even the lead developer, that does not
itself suggest that distros should follow the fork
this is the email you posted on IRC, as a rationale
https://mailman.nginx.org/pipermail/nginx/2024-February/GPXQY27UA5SJJZ2Y6JWTRWJB2TKPTJR7.html
> I no longer able
> to
these are both fixed now - my guess is that it was already flagged
but just to be clear - "out-of-date" is not the same as "broken"; and that is
usually not a reason why a package may be broken - the "out-of-date" flag is
only a reminder that the package can be upgraded - if a package is broken, y
so this is the same program as 'flashrom-stable'; but with a new name?
so 'flashrom-stable' should be deleted? and 'flashprog' should become the libre
replacement for 'flashrom' in the blacklist? - i forgot now why we want this -
i did not blacklist 'flashrom' - should it be?
ive a few comments
thanks - it is done
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
the patch in incomplete - it adds only the PKGBUILD - it is missing all of the
support files:
"$pkgname-$pkgver.diff"
"$pkgname-$pkgver-bash.diff"
'sysuser.conf'
'tmpfile.conf'
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/
just a note
> # Maintainer (Parabola): Wael Karram
"(Parabola)" there does not serve a purpose - there neds to be at least one
entry with Maintainer followed immediately by a colon - that that does, it
shows that person as the package maintainer on the packages website - without
that the package
On Thu, 28 Dec 2023 12:50:25 -0500 bill-auger wrote:
> your assumption that no
> one needs them seems to be far off the mark in this case
just to clarify, in this case, the mystery i would try to resolve first, is
"why do the TTF fonts have drastically more votes than the OTF fon
according to the AUR, 'ttf-unifont' is the only package from that upstream with
significant interest from users (118 votes, where 'otf-unifont' has only 6
votes, and most of the others have zero votes) - also, 'ttf-unifont' was just
upgraded last month, so surely it does compile - i find it hard to
billauger closed without merging a pull-request against the project: `abslibre`
that you
are following.
Closed pull-request:
``
libre/iceweasel: 119.0-1.parabola1
``
https://pagure.io/abslibre/pull-request/90
___
Dev mailing list
Dev@lists.parabola.
billauger commented on the pull-request: `libre/iceweasel: 119.0-1.parabola1`
that you are following:
``
merged
``
To reply, visit the link below or just reply to this email
https://pagure.io/abslibre/pull-request/90
___
Dev mailing list
Dev@lists.par
On Thu, 26 Oct 2023 20:18:14 -0400 bill-auger wrote:
> if i had this motivation, i would get on that
> thread and encourage mozilla to implement it for everyone
mozilla ... and any of the thousands of other legacy programs which do not
respect the FHS
thats just how the cookie crumbles - programs have been sourcing and creating
dotfiles since long before mozilla, the FHS, $XDG_CONFIG_HOME, or the ~/.config
directory - most people are not so annoyed by it - that is why programs like
`ls`, GUI file managers, and other programs hide dotfiles by def
On Thu, 26 Oct 2023 15:10:55 +0300 Daniil wrote:
> I suppose that I can try to build a package in a clean chroot and it should
> help with at least some errors. But I don't think that having a package which
> is so reliant on correct environment for proper build is a nice idea. I'm
> going
> to pu
billauger closed without merging a pull-request against the project: `abslibre`
that you
are following.
Closed pull-request:
``
[iceweasel] 118.0.parabola1
``
https://pagure.io/abslibre/pull-request/89
___
Dev mailing list
Dev@lists.parabola.nu
http
billauger commented on the pull-request: `[iceweasel] 118.0.parabola1` that you
are following:
``
merged
``
To reply, visit the link below or just reply to this email
https://pagure.io/abslibre/pull-request/89
___
Dev mailing list
Dev@lists.parabola.n
just looking for opinions, whether or not it is worth preserving, or is more
trouble to filter than it is worth - archarm has no documentation; and it
was never documented on the parabola wiki https://wiki.parabola.nu/Repositories
i will check it against the blacklist - maybe there are some packag
does anyone known what the 'alarm' repo is for? - it is not listed in the
default pacman.conf; but it is imported
at first glance it appears to be board-specific tools, firmwares, and
applications (eg: ffmpeg-rpi, kodi-rpi, and VLC-rpi) - probably some,
many, or most of those are non-free; and pro
On Sun, 17 Sep 2023 19:38:20 -0400 bill-auger wrote:
> ok, it looks like quassel-client-small was renamed to quassel-client-qt
ok so i knew that already - looks like i changed the name in 'your-freedom' back
in februaryl but arch32 still has not renamed the package, so i
On Sun, 17 Sep 2023 21:26:10 -0400 bill-auger wrote:
> is this program broken?
ok i guess we have an answer to that question
https://labs.parabola.nu/issues/3531
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
> distorto wants to notify you that the following packages may be out-of-date:
>
> * thinkfan 1.3.1-1 [pcr] (armv7h):
> https://parabolagnulinux.org/packages/pcr/armv7h/thinkfan/
> * thinkfan 1.3.1-1 [pcr] (i686):
> https://parabolagnulinux.org/packages/pcr/i686/thinkfan/
> * thinkfan 1.3.1-1 [p
ok, it looks like quassel-client-small was renamed to quassel-client-qt
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
thanks - just some notes for the next time you do this
for most packages, it is usually not enough to bump the pkgver and checksums -
even when that is all of the needed changes, it is never the time-consuming
part of an upgrade
we try to keep the recipes as close to the arch upstreams as possibl
On Wed, 6 Sep 2023 20:49:30 +0300 Daniil wrote:
> - The new version of base creates /usr/bin/init, which conflicts with
> openrc-init which already owns the file.
i and megver looked into this - that is true, but it is not a problem -
it should not prevent anyone from upgrading - during upgrade,
thanks for noticing these things
your-init-freedom was published; but was not in the DB for some reason - that
should be fixed now
'base' should not create any files - im not sure what your problem actually is
i will look at that later
___
Dev mailing l
david upgraded pipewire this week - can ppl plz conform that the problem is
solved
probably related: https://labs.parabola.nu/issues/3416
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
from arch:
When upgrading from budgie-desktop 10.7.2-5 to 10.7.2-6, the package mutter43
must be replaced with magpie-wm, which currently depends on mutter. As mutter43
conflicts with mutter, manual intervention is required to complete the upgrade.
First remove mutter43, then immediately perfor
ok, this seems like a good solution then - so you have tried this with discover?
it works properly? - i supposed you have not tried it with gnome-software?
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/listinfo/dev
On Fri, 21 Jul 2023 20:39:19 + kwopleq wrote:
> There were webview support and TPPM functionality in discover, but now,
> hopefully it's removed (https://pagure.io/abslibre/pull-request/82).
> There's still flatpak support in "discover" that might result in nonfree
> packages. It could be pat
if license compatibility is a concern, i would suggest CC-zero, just like we
did for the PKGBUILDs - that article is not a work of creativity or a
specification, but a dry collection of facts that anyone could collect
in other words, like the PKGBUILDs, i dont think it meets the threshold of
creat
billauger commented on the pull-request: `libre/parabola-appstream data without
info about nonfree packages` that you are following:
``
depends on PR #82
``
To reply, visit the link below or just reply to this email
https://pagure.io/abslibre/pull-request/78
billauger commented on the pull-request: `libre/discover without nonfree
webview support and TPPM functionality` that you are following:
``
depends on PR #78
like i noted on #78, it is not obvious if we can use them, or what is their
value if all they can do is install the same packages that
billauger commented on the pull-request: `libre/parabola-appstream data without
info about nonfree packages` that you are following:
``
this is related to multiple open tickets on the bug tracker and an ongoing
discussion on the FSDG mailing list
https://labs.parabola.nu/issues/813
https://lab
billauger merged a pull-request against the project: `abslibre` that you are
following.
Merged pull-request:
``
libre/ktorrent without qt5-webengine
``
https://pagure.io/abslibre/pull-request/76
___
Dev mailing list
Dev@lists.parabola.nu
https://lis
just to note that i moved the tables of evaluations and proposals to the wiki,
to make it easier reference and to maintain
https://wiki.parabola.nu/TPPM_Liberation_Project
___
Dev mailing list
Dev@lists.parabola.nu
https://lists.parabola.nu/mailman/list
this is what i am suggesting - note how much smaller the comment has shrunk
- that is generally a good smell
diff --git a/pcr/prosody-modules/PKGBUILD b/pcr/prosody-modules/PKGBUILD
index e95ed62c1..29a3b983e 100644
--- a/pcr/prosody-modules/PKGBUILD
+++ b/pcr/prosody-modules/PKGBUILD
@@ -3,51 +3
On Sun, 09 Jul 2023 12:08:30 +0300 Wael wrote:
> Hence, the upstream doesn't have proper releases as such and tagging cannot be
> done.
tagging is always possible - it takes only seconds - i would ask the upstream
to do it, and i would probably reject their software if they refused
per that descr
it appears that "keeping an eye out on any changes in the situation" is the
most important part of that explanation - in my experience, that explanation
suggests to me that flashrom-stable will be very short-lived - most new
software projects lose momentum or are abandoned within six months; and th
i also set wael as the Maintainer instead of "parabola hackers"
i think we should consider it a matter of policy not to accept anything into PCR
without a dedicated maintainer - the reason is that most packages in PCR got
there because a very small number of users requested them, perhaps only one
signature is important
-
source=(https://repo.parabola.nu/other/${pkgname}-libre/${pkgname}-libre-${pkgver})
+
source=(https://repo.parabola.nu/other/${pkgname}-libre/${pkgname}-libre-${pkgver}.tar.xz{,.sig})
+ validpgpkeys+=('3954A7AB837D0EA9CFA9798925DB7D9B5A8D4B40') #
that comment in the PKGBUILD is confusing:
> # The prosody-modules repository doesn't have tags that correspond to
> # the prosody releases. So we used the commit right before June 09
> # to correspond to the prosody release.
if the upstream does not tag the VCS properly, then where does pkgver='0
actually i sent that to soon - there are two other things i would make issue of
'flashrom' is an arch package, so we can not modify the pkgdesc without
adopting the package - i assumed that the pkgdesc of 'flashrom' in this thead
was the one arch uses; but it is not so we can not use it for compar
ok so there is something different about them - the remaining thing to
nit-pick is that arch policy suggests the pkgdesc should not self-refer to the
name of the software, and should be as terse as possible - i will make only
these changes:
- Flashrom is a utility which can be used to detect,
+ Ut
1 - 100 of 597 matches
Mail list logo