[arch-dev-public] Namcap 3.0 coming soon
Hello people, Namcap can still be found at the usual Git repository. I should release version 3.0 in a few days. Here are some highlights of what's new: * it works with Python 3.x (tested with Python 3.2) * it no longer outputs crazy contradicting messages about dependencies missing/unneeded at the same time (FS #15591 and #17166) * it finally can read split PKGBUILDs : a very basic rule has been implemented (FS #15027). It is however as poorly useful as the old depends module * it has a fairly extensive test suite (with currently 3 expected failures) * new rules have been implemented (FS#23003, FS#22881, FS#22929, FS#18852) * the help message gives more useful information about available options * the undocumented option "-r list" giving the rule list is now the documented option "-L" Big changes in code have been made : * it works with Python 3 * it uses the distribute module to build * the rules and the tests are derived from abstract base classes to help with code factorization * rules are in the rules/ subdirectory * the PacmanPackage class has a dictionary-API which avoids using hasattr/getattr/setattr everywhere and gives more Python-looking source code * none of the rules needs a complete extraction of a tarball. Only ELF files are written to disk because neither objdump nor readelf wantes to read from stdin. * parsepkgbuild is now a wrapper in /usr/bin and an auxiliary script in /usr/share which is run under "bash -r". -- Rémy.
On 2011/2/27 Rémy Oudompheng
* it finally can read split PKGBUILDs : a very basic rule has been implemented (FS #15027). It is however as poorly useful as the old depends module
It behaves now better. A preliminary built package can be found at http://dev.archlinux.org/~remy/namcap/namcap-3.0-1-any.pkg.tar.xz -- Rémy.
And additionally, don't swallow error output from parsepkgbuild calls-
this helped debug the next issue with a patch to come.
Signed-off-by: Dan McGee
A lot clearer and not magical.
Signed-off-by: Dan McGee
We regressed when splitting the package parser into two scripts; add a
variable to configure the path it is found on and add a 'namcap-devel'
script that allows running the whole deal from the current git checkout.
Signed-off-by: Dan McGee
On 2011/2/27 Rémy Oudompheng
Hello people,
Namcap can still be found at the usual Git repository. I should release version 3.0 in a few days. Here are some highlights of what's new:
Namcap 3.0 has been released in [testing], including Dan's latest patchset. -- Rémy.
On 13/03/11 22:29, Rémy Oudompheng wrote:
On 2011/2/27 Rémy Oudompheng
wrote: Hello people,
Namcap can still be found at the usual Git repository. I should release version 3.0 in a few days. Here are some highlights of what's new:
Namcap 3.0 has been released in [testing], including Dan's latest patchset.
Looks good to me. I just ran it on a whole heap of PKGBUILDs and packages and nothing looked too wrong. There is a bunch of false positives in the form of: W: Non standard variable 'foo' doesn't start with an underscore e.g. the perl PKGBUILD. I'm not sure if they are new or not. What is more concerning (and unrelated to namcap...) is the number of PKGBUILDs giving this error even though they were recently updated: Use $srcdir instead of $startdir/src Allan
On Sun, Mar 13, 2011 at 8:30 AM, Allan McRae
On 13/03/11 22:29, Rémy Oudompheng wrote:
On 2011/2/27 Rémy Oudompheng
wrote: Hello people,
Namcap can still be found at the usual Git repository. I should release version 3.0 in a few days. Here are some highlights of what's new:
Namcap 3.0 has been released in [testing], including Dan's latest patchset.
Looks good to me. I just ran it on a whole heap of PKGBUILDs and packages and nothing looked too wrong.
There is a bunch of false positives in the form of: W: Non standard variable 'foo' doesn't start with an underscore e.g. the perl PKGBUILD. I'm not sure if they are new or not.
I'm not so sure these are false positives- the rule just didn't run at all before, if I remember one of Rémy's emails, so you never saw this trigger a warning. -Dan
On 2011/3/13 Dan McGee
On Sun, Mar 13, 2011 at 8:30 AM, Allan McRae
wrote: Looks good to me. I just ran it on a whole heap of PKGBUILDs and packages and nothing looked too wrong.
There is a bunch of false positives in the form of: W: Non standard variable 'foo' doesn't start with an underscore e.g. the perl PKGBUILD. I'm not sure if they are new or not.
I'm not so sure these are false positives- the rule just didn't run at all before, if I remember one of Rémy's emails, so you never saw this trigger a warning.
By the way if someone could explain the exact purpose of the "CARCH" rule, which does not work currently with the various syntaxes ($CARCH, ${CARCH}, "$CARCH"), I could try to fix it, but I really don't know its purpose. -- Rémy.
participants (4)
-
Allan McRae
-
Dan McGee
-
Dan McGee
-
Rémy Oudompheng