Re: [gentoo-dev] The Plethora of Patches
Andrew D Kirch wrote: Denis Dupeyron wrote: On Thu, Aug 14, 2008 at 4:17 AM, Andrew D Kirch [EMAIL PROTECTED] wrote: [...] Looks like you counted the number of files in the files/ subdirectories. Not all of these are patches. Also, you probably forgot to count seds, as some of us use sed more than patches. Oh, and like Jeremy was hinting, please contact QA. They need somebody like you. Denis. How would one get ahold of this QA? [EMAIL PROTECTED] ? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: The Plethora of Patches
Andrew D Kirch wrote:
Here's the script that I used to generate this.
Just some bash hints. In a nutshell: please don't use ls in scripts.
I have not manually
reviewed all of thousands of patches to determine the unique situation
of each patch, however I would like a suggestion on how to demonstrate
_real_ statistics short of auditing each and every patch in portage
which I personally don't have time to do.
I think it's a great idea, and the other reply from robbat gives you a great
spec to start from in terms of classification.
for I in `ls`; do
for f in *; do
Globs have a lot to recommend them: see http://wooledge.org:8000/glob
PATCH=`ls -R ${I} | grep patch | wc -l`
DIFF=`ls -R ${I} | grep diff | wc -l`
COUNT=$(( ${PATCH} + ${DIFF} ))
while read -rd ''; do let count++
done (find $dir \( -name '*.diff' -o -name '*.patch' \) -print0)
..in the general case, where you actually need a recursive descend. (We
don't here.)
if ! [ ${COUNT} == 0 ]
then
echo $I $COUNT
fi
((count)) { echo $dir : $count }
See http://bash-hackers.org/wiki/doku.php?id=syntax:words for an explanation
of why the quotes make a difference.
Putting it together you end up with this:
#!/bin/bash
# ./countPatchFiles patchCount
# sed -nr '/^Category: (.*): (.*)/s//\1\2/p' patchCount |sort -n -k 2
PORTDIR=$(portageq envvar PORTDIR)
declare -i count tot=0 cTot
shopt -s nullglob
for d in $PORTDIR/*/; do
c=${d#$PORTDIR/}; c=${c%/}
[[ $c = *-* ]] || continue
cTot=0
echo $c 2
for p in $d*/; do
files=($pfiles/*.patch $pfiles/*.diff)
[EMAIL PROTECTED]
((count)) || continue
p=${p#$d}; echo $c/${p%/} : $count
((tot+=count,cTot+=count))
done
echo Category: $c : $cTot
done
echo Total: $tot
-- HTH,
igli.
(The files are in that array, if their names should be needed.)
Re: [gentoo-dev] best way to use profiles and package.use.mask?
On Wed, 13 Aug 2008 23:33:04 +0300 Petteri Räty [EMAIL PROTECTED] wrote: As a distribution we should strive to make as many packages available with as many features as possible on as many architectures (or indeed operating systems) as possible.[1] Not communicating important changes in ebuilds to arch teams, even making decisions on their behalf, we risk having to mend increasingly complex systems of profiles and flags. I have been instructing people to adjust the files themselves. The changes affect only the package in question and as such it falls under the responsibility of the maintainer of the package. Sadly, I've been adding capitalised boilerplate pleas to the heads (and sometimes the tails) of hppa profile files requesting bug reports instead of adding silently to the ancient cruft that's there already. That doesn't mean that either you or I are wrong, but it does clearly show that we should put this all down in writing[2] when we find agreement. :) I personally think no, individual ebuild devs shouldn't touch arch-profiles. They should simply drop the (broken) keywords and file a keywordreq bug for those arches. Then the arch-teams can test and eventually decide whether to keyword the package or mask the use-flag. There should be no problem committing the ebuild with dropped keywords, then filing a KEYWORDREQ bug report describing the problem and the solution, and CC'ing the stricken arch teams. The arch teams don't have that much staff so not adding to their work load is the best way to go imho. Cleaning up *use.mask is annoying work and removing a flag from *use.mask could affect many users (emerge --newuse world). We should therefore reluctantly mask USE flags and let profile maintainers decide what is useable and practical to have on their OS/arch. When in doubt whether to mask a USE flag or drop a keyword, a package maintainer should commit the ebuild, drop the keyword and file a bug to have the arch team decide. Important note: leaving the keyword dropped is no option for active, security supported arches[3]. Kind regards, JeR [1] That's my interpretation of much of what http://www.gentoo.org/main/en/philosophy.xml says. [2] The end result should probably trickle down into the devmanual (and/or the Developer Handbook?) at some point. I feel like writing a section or two about arch workflows and keywording processes that could be included in http://devmanual.gentoo.org/keywording/index.html . [3] When an arch team cannot handle the workload any longer, the support level should be dropped to ~arch anyway. I would really hate to see people do what amounts to crippling packages (removing features), just to decrease some arch team's workload. In the mean time, do pile up the work regardless of staffing problems - somebody new may just volunteer to help an arch team out when the going gets tough.
Re: [gentoo-dev] [GLEP 56] metadata.xml USE flag descriptions [Clarifications]
On Wed, 13 Aug 2008 16:13:26 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: What is the benefit? There is none really. Allow all use flags to exist in metadata.xml. It's really more of a clarification to the GLEP if this is allowed. I personally think that this would facilitate a lot of duplication that would ultimately amount to bitrot. Of course having, say, repoman suggest cleanups would be one solution to the problem of bitrot, but then I still fail to see the advantage over having both an IUSE per ebuild as well as maintaining gentoo-x86/profiles/use.desc. In my opinion the GLEP needs clarification on this matter. It should forbid the use of these empty flag tags, and the DTD should reflect that[1]. Kind regards, JeR [1] Come to think of it, in the recent metadata.xml / no-herd debate, wasn't having an empty herd tag ever suggested? herd /
Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins
Robin H. Johnson wrote: Getting the bot out there - If you would like to have the new bot in your #gentoo-* channel, would each channel founder/leader please respond to this thread, stating the channel name, and that they are the contact for any problems/troubles. #gentoo-bsd, welp would be contact but he's away. Thanks.
[gentoo-portage-dev] portage-py3k status report
Hi, I've written a status report¹ about portage py3k conversion. It tells about the current state, what needs to be done etc. I'll be updating the page so people can learn about the current status. ¹: http://dev.gentoo.org/~hawking/portage-2to3/status.xml -- Regards, Ali Polatel pgpBFbU1QeIVp.pgp Description: PGP signature
Re: [gentoo-portage-dev] portage-py3k status report
What's the best way to send patches for the patches ;) ? For example in http://dev.gentoo.org/~hawking/portage-2to3/auto/11-portage-2to3-map.patch - there is the following hunk: hunk diff --git a/pym/portage/process.py b/pym/portage/process.py index f766d30..dc425af 100644 --- a/pym/portage/process.py +++ b/pym/portage/process.py @@ -21,7 +21,7 @@ except ImportError: if os.path.isdir(/proc/%i/fd % os.getpid()): def get_open_fds(): - return map(int, [fd for fd in os.listdir(/proc/%i/fd % os.getpid()) if fd.isdigit()]) + return list(map(int, [fd for fd in os.listdir(/proc/%i/fd % os.getpid()) if fd.isdigit()])) else: def get_open_fds(): return xrange(max_fd_limit) /hunk But the complete expression could be rewritten as: return [int(fd) for fd in os.listdir(/proc/%i/fd % os.getpid()) if fd.isdigit()] This is more readable - and you don't need to traverse the list multiple times. Alternatively - if you like the functional style more: return list(map(int, filter(str.isdigit, os.listdir(/proc/%i/fd % os.getpid() Again more readable (if you are used to the functional style ;)) - and only one traversal (as iterators are used). /edit: I sent this mail twice, because Roundcube had chosen the wrong sender name and I guess, that this mail was blocked then. Excuses if you get the mail twice. Regards, Necoro
[gentoo-portage-dev] Re: portage-py3k status report
René 'Necoro' Neumann yazmış: What's the best way to send patches for the patches ;) ? In this particular case you shouldn't send patches for patches, so it's not a problem, see below ;) snip But the complete expression could be rewritten as: return [int(fd) for fd in os.listdir(/proc/%i/fd % os.getpid()) if fd.isdigit()] This is more readable - and you don't need to traverse the list multiple times. Alternatively - if you like the functional style more: return list(map(int, filter(str.isdigit, os.listdir(/proc/%i/fd % os.getpid() Again more readable (if you are used to the functional style ;)) - and only one traversal (as iterators are used). Portage aims for 2.4 compatibility and your snippets should work on 2.4 afaik. So you can submit it as a patch to the current trunk. Changing the automatically generated output is not a good idea. Regards, Necoro -- Regards, Ali Polatel pgpE4ozCfOnGL.pgp Description: PGP signature
[gentoo-portage-dev] [PATCH] Fix warning for lib2to3/fixes/fix_map.py
2to3 gives a warning while converting portage codebase using map¹ fix:
RefactoringTool: Warnings/messages while refactoring:
RefactoringTool: ### In file ./pym/portage/dbapi/porttree.py ###
RefactoringTool: Line 266: You should use a for loop here
This is a valid warning because map() will change in py3k. Read the docstring of
fix_map.py for more information.
¹: http://svn.python.org/view/python/trunk/Lib/lib2to3/fixes/fix_map.py
---
pym/portage/dbapi/porttree.py |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/pym/portage/dbapi/porttree.py b/pym/portage/dbapi/porttree.py
index 2948ba6..4e76b1e 100644
--- a/pym/portage/dbapi/porttree.py
+++ b/pym/portage/dbapi/porttree.py
@@ -263,7 +263,8 @@ class portdbapi(dbapi):
# if newer version, wipe everything and negate eapi
eapi = metadata[EAPI]
metadata = {}
- map(lambda x: metadata.setdefault(x, ), auxdbkeys)
+ for x in auxdbkeys:
+ metadata.setdefault(x, )
metadata[EAPI] = - + eapi
if metadata.get(INHERITED, False):
--
Regards,
Ali Polatel
Re: [gentoo-portage-dev] [PATCH] Fix warning for lib2to3/fixes/fix_map.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ali Polatel wrote: 2to3 gives a warning while converting portage codebase using map¹ fix: RefactoringTool: Warnings/messages while refactoring: RefactoringTool: ### In file ./pym/portage/dbapi/porttree.py ### RefactoringTool: Line 266: You should use a for loop here This is a valid warning because map() will change in py3k. Read the docstring of fix_map.py for more information. ¹: http://svn.python.org/view/python/trunk/Lib/lib2to3/fixes/fix_map.py Applied, thanks. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkilxLcACgkQ/ejvha5XGaMC4wCg2/a8N2jZcC8X5wzGon3a0PNE Mo8AoLks+4IMVXUkAFTVfNGnM0XckT3s =KvEC -END PGP SIGNATURE-
Re: [gentoo-portage-dev] portage-py3k status report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 René 'Necoro' Neumann wrote: But the complete expression could be rewritten as: return [int(fd) for fd in os.listdir(/proc/%i/fd % os.getpid()) if fd.isdigit()] Applied, thanks. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkilxyUACgkQ/ejvha5XGaPxXgCgkGAmT1Gf2lF840SXov8RbL31 7ucAnRyJnA3/HSKbV538YBQ0cRxqTSdG =pcZr -END PGP SIGNATURE-
