Re: [gentoo-dev] The state and future of the OpenRC project
On Monday 09 June 2014 21:45:26 hasufell wrote: > Probably because no one mentored them on how to fix these QA issues. > Otherwise... if that's attitude, then that's just sad and has to be > fixed by those who run that overlay (review, contribution guidelines). > > And I still think that the top 1 reason people run an overlay is because > it's easier than contributing directly. > A lot of overlay maintainers I tried to convince on getting more > involved even said that. > > Even sunrise workflow has proven too slow and cumbersome... look at the > commit history, it's constantly decreasing. > > Sure, reasons may vary, but there is not much positive to say about > current gentoo workflow. Since I was mentioned here - I am one of sage overlay[1] developers - it is maybe worth sharing my point of view as someone that is not a Gentoo developer. The recent discussion[2] with hasufell on our overlay might also be interesting. I have to agree that indeed it is easier to contribute to an overlay, in my case because of a) git and b) github. As far as I am up-to-date the main Gentoo repository is still managed by cvs, right? Thats something I really would not like to work with. Not because cvs is inferior to git (I hope no one feels offended) but because now I am so used to and pleased with the workflow that comes with git that I can not even think of changing that. What I really love about github (and I don't think that similar platform differ much here) is the fact that it allows me to comment on /everything/. I can comment on commits that maybe lack something, which could then result in a new Issue; a user could be faster than I and create a pull request that fixes this problem. Maybe there is another mistake which I tell him there so he adjusts his commit and I finally accept it. Sometimes, after some months I wonder why we decided about some things the way we did and I can look it up in the Issue. There is the _complete_ discussion with direct references to the code and all people involved. If there is a lession that I learned here, than that centralizing communications and development in one place was beneficial for us. Whether this also applies to the Gentoo project - well, I don't know. Right now there are several mailing lists, IRC channels and the Bugzilla so in comparison to our little overlay it is quite decentralized. Adding another way, e.g. via github, could complicate the situation but it will defintely get the project more user contributions (if that is needed). In any case, I believe that the migration to git would be a huge step forward and it would attract at least one pontential new developer ;). Any update on this? [1] https://github.com/cschwan/sage-on-gentoo [2] https://github.com/cschwan/sage-on-gentoo/issues/294 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage QOS
Hi, you motivate your proposal by claiming the Gentoo Project stagnates which you relate with its decline in popularity: > According to Linux Counter > http://web.archive.org/web/2012010100*/http://linuxcounter.net/distribut > ions/stats.html > > In January 2012, Gentoo distro had 5.32% > In January 2012, Gentoo had 4.04% > In November 2013, Gentoo had 4,21% > > And from my experience of Gentoo forums, gentoo.wiki - I vote for Gentoo at > least not gaining new users. If in several years the number of users is not > increased - we can tell about stagnation. But let me ask this question: Is the number of users really that important to Gentoo? Since it does not strive for world domination I think all that matters is to keep the current userbase happy. From your thread I do not understand whats wrong on that side: > For various reasons many techs were not implemented and now Gentoo is in a kind of stagnation. What do you mean by that in particular? And what is wrong with bugs.gentoo.org? Wouldn't it be better to talk about how attract more developers? I guess a lot unsolved bugs stem from the fact that there are too few that can take care of them. Cheers, Christopher signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Opportunities to use slot operators
On Sunday 14 April 2013 09:09:13 Rich Freeman wrote: > For whoever is interested I tossed together a script to identify > packages that would immediately benefit from slot operator > dependencies but which are not doing so. > > The list can be found at: > http://dev.gentoo.org/~rich0/missedslotops.txt > > This was generated by: > https://github.com/rich0/finddepslotops > > Feel free to make use of either as you see fit, make improvements, > submit improvements, fork, whatever. If one of your packages is on > the list feel free to update it! (And yes, I realize that in many > cases this may have been done with newer versions of the packages not > on the list - I didn't make any attempts to filter that out.) > > Also, I'm sure I've used the portage API in less-than-ideal ways. > Having not really used it before this was half a learning exercise. > Feel free to send me suggestions/pointers. If somebody knows of an > easy way to process metadata in python (short of just parsing the xml > myself) let me know - I didn't see any kind of API for that. > > Rich Is it possible to check a local overlay? Specifying CPV for a single ebuild works, but I wonder if its possible to parse an entire overlay at once. Christopher
Re: [gentoo-dev] RFC: sed script redundancy
On Sunday 29 May 2011 13:00:32 Fabian Groffen wrote:
> On 29-05-2011 12:44:46 +0200, Christopher Schwan wrote:
> > Thank you for that script. I experimented a bit with it and have a number
> > of corrections and suggestions:
> >
> > - alias does not work because my_sed is not declared at this stage. I
> > removed the whole alias line because I want to selectively enable my_sed
> >
> > - oargs must be an array in order to make quoting work:
> >local oargs=( "${@}" )
> >
> > - In the ewarn line ${oargs} should be changed to ${nargs[@]} (!?)
> > - is it correct to treat -e and -f alike ? I am not sure about that,
> > because the latter expects a file
>
> Yes, because (also in your function) you always shift, and assume the
> next argument is there. Hence, you have two identical cases in your
> script now. I only distinguised between 1) being able to do something
> (-i) and 2) having a pattern to work with (-e/-f or first non-option
> argument as string pattern).
Ok sorry - I did not express myself clearly. Your script is replacing "-f"
with "-e" and I wasnt sure if this is correct. Buf of course, they can be
treated alike:
-e|--expression|-f|--file)
arg="$1"
shift
nargs+=( "${arg}" "$1" )
hade=yes
;;
>
> > - If no "-e" is given, the first non-option argument is treated as the
> > sed- script-expression, therefore I added hade=yes in the if-branch
>
> That one was missing indeed. I just quickly wrote the proof of concept
>
> :)
> :
> > The new function now reads:
> [snip improved function]
>
> > As you can see, I added support for long-options. However, testing the
> > individual sed commands remains to be done. This could be especially
> > difficult if input is taken from stdin (e.g. in cat foo | sed
> > "s:a:b:g").
>
> You might be able to detect input is a pipe, and temporarily
> write the input to some file, then perform the sed without the -i
> requirement and remove the temp file after the real sed.
Good idea, thanks!
>
> > I tested my_sed within our sage ebuild[1]. This ebuild contains 39 sed
> > commands and I was able to spot one useless sed.
>
> Cool, nice to see you've made it into something useful!
>
> > [1] https://github.com/cschwan/sage-on-gentoo/blob/master/sci-
> > mathematics/sage/sage-4.7.ebuild
Re: [gentoo-dev] RFC: sed script redundancy
Thank you for that script. I experimented a bit with it and have a number of
corrections and suggestions:
- alias does not work because my_sed is not declared at this stage. I removed
the whole alias line because I want to selectively enable my_sed
- oargs must be an array in order to make quoting work:
local oargs=( "${@}" )
- In the ewarn line ${oargs} should be changed to ${nargs[@]} (!?)
- is it correct to treat -e and -f alike ? I am not sure about that, because
the latter expects a file
- If no "-e" is given, the first non-option argument is treated as the sed-
script-expression, therefore I added hade=yes in the if-branch
The new function now reads:
my_sed() {
local oargs=( "$@" )
local arg
local nargs=()
local hadi=
local hade=
while [[ -n $1 ]] ; do
case "$1" in
-i|--in-place)
# ignore this flag
hadi=yes
;;
-e|--expression)
shift
nargs+=( "-e" "$1" )
hade=yes
;;
-f|--file)
shift
nargs+=( "-f" "$1" )
hade=yes
;;
-*)
nargs+=( "$1" )
;;
*)
if [[ -z ${hade} ]] ; then
nargs+=( "-e" "$1" )
hade=yes
elif [[ -z ${hadi} ]] ; then
# there is no inline replacing, not much we can
do
break
else
sed "${nargs[@]}" "$1" | diff -q "$1" - >
/dev/null && \
ewarn "sed ${nargs[@]} has no effect on
$1"
fi
;;
esac
shift
done
sed "${oargs[@]}"
}
As you can see, I added support for long-options. However, testing the
individual sed commands remains to be done. This could be especially difficult
if input is taken from stdin (e.g. in cat foo | sed "s:a:b:g").
I tested my_sed within our sage ebuild[1]. This ebuild contains 39 sed
commands and I was able to spot one useless sed.
[1] https://github.com/cschwan/sage-on-gentoo/blob/master/sci-
mathematics/sage/sage-4.7.ebuild
On Sunday 22 May 2011 12:50:43 Fabian Groffen wrote:
> On 21-05-2011 19:34:34 +0200, Jeroen Roovers wrote:
> > On Fri, 20 May 2011 17:56:00 +0200
> >
> > Fabian Groffen wrote:
> > > sed -e "" "${file}" | diff "${file}" -
> > >
> > > followed by the actual sed -i -e ...
> > >
> > > This way I didn't need to write an intermediate file.
> >
> > The problem there is that sed might be called just once on any one file,
> > but in the tree it is often invoked with multiple scripts, so this
> > simple implementation lacks a way to evaluate which sed scripts are
> > useful.
> >
> > Also, how do I ensure the sed replacement works only on invocations
> > inside the ebuild, and not, say, in portage's internals?
>
> (not tested, but as proof of concept)
>
> alias sed my_sed
> my_sed() {
> local oargs="${@}"
> local arg
> local nargs=()
> local hadi=
> local hade=
> while [[ -n $1 ]] ; do
> case "$1" in
> -i)
> # ignore this flag
> hadi=yes
> ;;
> -e|-f)
> shift
> nargs+=( "-e$1" )
> hade=yes
> ;;
> -*)
> nargs+=( "$1" )
> hade=yes
> ;;
> *)
> if [[ -z ${hade} ]] ; then
> nargs+=( "$1" )
> elif [[ -z ${hadi} ]] ; then
> # there is no inline replacing, not
> much we can do
> break
> else
> sed "${nargs[@]}" "$1" | diff -q "$1" -
> > /dev/null \
> && ewarn "sed ${oargs} has no
> effect on $1"
> fi
> ;;
> esac
> shift
> done
>
> \sed "${oargs}"
> }
Re: [gentoo-dev] Gentoo's plan to remove .la files: eutils function
Hi,
I followed this discussion quietly until now - I wonder why no one (?) has
mentioned the autotool-utils.eclass which is dedicated for this purpose (la-
file removal, static-libs USE-flag, etc), I think. This eclass also provides a
function "remove_libtool_files" which does what "delete_libtool_archives" would
do, but it also checks for situation where the files would be needed.
On Sunday 31 October 2010 05:28:42 Jorge Manuel B. S. Vicetto wrote:
> Hi.
>
> As outlined in the global email about this issue, this email is to start
> a thread about the eutils function. Please reply to this thread if you
> have any comments about this point.
>
> 1. Add a function to eutils to deal with the removal of the .la files.
>
> delete_libtool_archives() { find "${@:$D}" -name '*.la' -delete }
>
> That function was suggested by Diego, but Arfrever has argued that we
> should replace : with - as '"${@:$D}" expands to a subarray containing
> elements starting with element with index $D (where element 0 is $0)'.
> The point in having this function in eutils is to ensure we use a
> consistent way to address the .la files. This will also make it much
> easier to adapt or review this function if needed.
Cheers,
Christopher
