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.
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 . 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?
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.
[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=("$p"files/*.patch "$p"files/*.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.)
