Signed-off-by: Dan McGee
---
namcap.py | 31 +--
1 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/namcap.py b/namcap.py
index d9fccee..19c6ceb 100755
--- a/namcap.py
+++ b/namcap.py
@@ -89,6 +89,10 @@ def check_rules_exclude(optlist):
The rpath module is another one that exhibits rather poor behavior, as it
also tried to call readelf on things that didn't make sense at all. Squash
this and get some big gains on packages with a lot of files.
As a point of reference, running all modules on 4 varying packages has gone
from 29.7 se
This will lay the ground for the next patch, as this function is useful for
more than just the depends module.
Signed-off-by: Dan McGee
---
Namcap/depends.py | 17 +
Namcap/util.py| 38 ++
2 files changed, 39 insertions(+), 16 deletions
Namcap being slow pissed me off enough that I wanted to figure out what
could be taking so long. As is usual with software, 1 module was causing
about 90% of the slowdown. Compare the before and after with this patch:
$ time namcap -m -r depends {4 packages} >/dev/null
real0m18.001s
user0m
Signed-off-by: Dan McGee
---
namcap.py | 96 +++--
1 files changed, 49 insertions(+), 47 deletions(-)
diff --git a/namcap.py b/namcap.py
index 06c79ea..d9fccee 100755
--- a/namcap.py
+++ b/namcap.py
@@ -89,6 +89,52 @@ def check_rules_excl
Signed-off-by: Dan McGee
---
namcap.py | 52
1 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/namcap.py b/namcap.py
index e36bb7a..06c79ea 100755
--- a/namcap.py
+++ b/namcap.py
@@ -89,6 +89,33 @@ def check_rules_exclude(optli
Signed-off-by: Dan McGee
---
namcap.py | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/namcap.py b/namcap.py
index 55c5240..e36bb7a 100755
--- a/namcap.py
+++ b/namcap.py
@@ -150,6 +150,10 @@ if (args == []):
m = process_tags(machine=machine_readable)
packages
Signed-off-by: Dan McGee
---
namcap.py |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/namcap.py b/namcap.py
index 509ca3f..55c5240 100755
--- a/namcap.py
+++ b/namcap.py
@@ -152,12 +152,12 @@ packages = args
# Go through each package, get the info, and apply the ru
We don't even need to look at the tags file if we are outputting machine
readable tags, so don't bother. Make process_tags just return the lambda
directly and even find a valid case for using a closure!
Signed-off-by: Dan McGee
---
namcap.py | 14 --
1 files changed, 8 insertions(+
It was a rather generic name for a file. More importantly, it prevented the
use of ctags in this projects since ctags creates a file named 'tags' by
default for storing its information.
Signed-off-by: Dan McGee
---
README | 10
namcap-tags | 65 +++
In the spirit of Eli making a bunch of patches for the AUR, I finally decided
to sit down tonight and figure out why the heck namcap was sucking it up, and
did a little code cleanup along the way. namcap.py is now a bit cleaner and
separated into functions, and the real treat is namcap is a hell of
On Fri, Sep 25, 2009 at 12:39 AM, Andreas Radke wrote:
> 2 upstream updates for the LTS stable kernel series:
>
> http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.27.34
> http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.27.35
>
> one change in the kernel config: build ext4 now as
On Fri, Sep 25, 2009 at 1:20 AM, Ronald van Haren wrote:
> new upstream release, please signoff for both architectures.
> Ronald
signoff x86_64
Eric
On Sat, Sep 26, 2009 at 5:21 AM, Thomas Bächler wrote:
> Kernel is in testing for both architectures, please sign off (at least one
> for x86_64, two for i686).
>
> I think tpowa had the kernel all ready to move to core, except he was
> waiting for the .1 release, which is there now.
>
> The only
On Tue, Sep 22, 2009 at 11:43 PM, Allan McRae wrote:
> Upstream update, added info install script.
>
> Signoff both,
> Allan
>
Signoff both arches
Eric
On Sat, Sep 19, 2009 at 8:37 PM, Eric Bélanger wrote:
> Hi,
>
> device-mapper & lvm2 2.02.52-1 are now in testing.
>
> Update:
> - Minor upstream update:
> lvm2: 2.02.48 -> 2.02.52
> device-mapper: 1.02.33 -> 1.02.37
>
> - Implemented split package. For this to work, I had to set t
Pierre Schmitz schrieb:
Am Sonntag 27 September 2009 16:01:38 schrieb Thomas Bächler:
Package is in testing for review.
How should we test this? Will there be a new netcfg soon? Why not include iths
in netcfg or might tis be usefull stand-alone?
1) netcfg can be -any
2) I maintain it, Jam
Am Sonntag 27 September 2009 16:01:38 schrieb Thomas Bächler:
> Package is in testing for review.
How should we test this? Will there be a new netcfg soon? Why not include iths
in netcfg or might tis be usefull stand-alone?
--
Pierre Schmitz, http://users.archlinux.de/~pierre
On Sun, Sep 20, 2009 at 10:47 PM, Eric Bélanger wrote:
> On Sun, Sep 20, 2009 at 1:46 AM, Eric Bélanger
> wrote:
>> Hi,
>>
>> gpm-1.20.6-2 is in testing. Please test and signoff.
>>
>> Update:
>> - Updated stock config to work with newer udev (close FS#16126)
>> - Fixed rc.d script. It was somet
On Sun, Sep 27, 2009 at 9:01 AM, Thomas Bächler wrote:
> This is a small daemon that was originally part of autowifi. It will be a
> depend or optdepend on the next netcfg's auto-wireless mode. This will be a
> reliable wireless roaming mode.
>
> The daemon is somewhat similar to wpa_cli -a $scrip
This is a small daemon that was originally part of autowifi. It will be
a depend or optdepend on the next netcfg's auto-wireless mode. This will
be a reliable wireless roaming mode.
The daemon is somewhat similar to wpa_cli -a $script, but adds logging
and avoids race conditions by adding a ti
On Sat, Sep 26, 2009 at 10:35 PM, Aaron Griffin wrote:
> On Fri, Sep 25, 2009 at 6:17 PM, Allan McRae wrote:
> > Aaron Griffin wrote:
> >>
> >> On Fri, Sep 25, 2009 at 4:01 AM, Xavier wrote:
> >>
> >>>
> >>> By the way, I am curious about pacbuild :
> >>> http://wiki.archlinux.org/index.php/Pacb
22 matches
Mail list logo
