On Sun, May 26, 2019 at 10:45 PM Eli Schwartz via arch-projects
wrote:
> All your patches show up as attachments, which makes it difficult to
> review, and they don't show up in patchwork.
>
> Generally speaking, the most reliable way to send a patch is by using
> `git send-email`.
Sorry about
Signed-off-by: James P. Harvey
.../tests/pkgbuild/test_nonuniquesources.py | 36 +++
1 file changed, 36 insertions(+)
0004-nonuniquesources-Add-test-for-common-filenames.patch
Description: Binary data
Spent too much time figuring out why I was getting an error of "object
has no attribute 'rule'". Perhaps it's correct spelling and grammer for
"set up" to be two words here, being used as a verb, but I wasn't
expecting that. Maybe this will help someone someday.
Signed off by: James P. Harvey
Signed-off-by: James P. Harvey
.../tests/pkgbuild/test_nonuniquesources.py | 58 +++
1 file changed, 58 insertions(+)
create mode 100644 Namcap/tests/pkgbuild/test_nonuniquesources.py
0002-Add-test-for-non-unique-source-filenames.patch
Description: Binary data
This was originally here, because it used PkgInfoRule, but was changed to use
PkgbuildRule and was left here.
Signed-off-by: James P. Harvey
Namcap/rules/__init__.py | 1 +
Namcap/rules/nonuniquesources.py | 34
Namcap/rules/pkginfo.py | 11
Filenames in source() are required to be unique. A common violation of
this is from commonly named files (i.e. LICENSE) that aren't part of an
upstream tarball.
Warn if a source file doesn't have an overriding name, and has a
commonly used name, ignoring extension and case.
Signed-off-by: James
There's no good way for namcap to ensure source() filenames are unique
across all packages, required for users with SRCDEST. But, I think by
far the most common offending filename would be LICENSE, as
non-standard ones are required to be included, but sometimes there's
no upstream tarball or
Done by:
$ find . -not \( -name .git -prune \) -type f -print0 | xargs -0 sed
-i -E "s/[[:space:]]*$//"
And manually reviewed.
Signed-off-by: James P. Harvey
COPYING | 10 +--
Namcap/__init__.py| 6 +-
Namcap/depends.py
On Thu, Feb 7, 2019 at 8:14 AM Bruno Pagani wrote:
> Le 07/02/2019 à 12:14, james harvey via arch-projects a écrit :
> > I got extremely confused when I accidentally found out that the
> > MAKEFLAGS that is needed to be set for parallel building using
> > devtools is the one
On Thu, Feb 7, 2019 at 12:15 PM Eli Schwartz via arch-projects
wrote:
> On 2/7/19 6:14 AM, james harvey via arch-projects wrote:
> > I got extremely confused when I accidentally found out that the
> > MAKEFLAGS that is needed to be set for parallel building using
> > devtool
It could be worth a developer diff'ing:
* pacman::makepkg.conf and devtools::makepkg-x86_64.conf
* pacman::pacman.conf and devtools::pacman*.conf
When trying to figure out my /etc/ vs /usr/share/devtools/ confusion
with MAKEFLAGS, I saw these differ in more areas than I would have
expected.
I
I got extremely confused when I accidentally found out that the
MAKEFLAGS that is needed to be set for parallel building using
devtools is the one in "/etc/makepkg.conf", instead of one like
"/usr/share/devtools/makepkg-x86_64.conf".
Turns out this is because "makechrootpkg"::20180531-4::638 is:
12 matches
Mail list logo
