[gentoo-dev] Re: jam -> ftjam
Ryan Hill <[EMAIL PROTECTED]>: > what's the best way to go about this? a package move? Don't think so, as it is not the same package in another category. > get ftjam keyworded the same and change all the ebuilds that DEPEND > on it at once? or change the ebuilds to do `|| (dev-util/ftjam > dev-util/jam)` first? The latter so people actually test it until you get all the KEYWORDS. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
[gentoo-dev] jam -> ftjam
i'd like to change the jam build-system implementation in Gentoo from dev-util/jam to dev-util/ftjam. ftjam is maintained by the freetype project and is a drop in replacement for jam. jam itself hasn't seen much if any development upstream in quite some while and has some issues with strict aliasing and GCC 4.2 so i'd like to drop it from the tree. both ebuilds install /usr/bin/jam so they block each other. what's the best way to go about this? a package move? get ftjam keyworded the same and change all the ebuilds that DEPEND on it at once? or change the ebuilds to do `|| (dev-util/ftjam dev-util/jam)` first? the ebuilds that this affects are: /usr/portage/dev-games/cel/cel-0.98.2.ebuild /usr/portage/dev-games/cel/cel-1.0.1.ebuild /usr/portage/dev-games/crystalspace/crystalspace-0.98.4.ebuild /usr/portage/dev-games/crystalspace/crystalspace-1.0.1.ebuild /usr/portage/dev-games/crystalspace/crystalspace-1.2.ebuild /usr/portage/games-engines/gargoyle/gargoyle-20060917-r1.ebuild /usr/portage/games-simulation/lincity-ng/lincity-ng-1.1.0.ebuild /usr/portage/games-simulation/lincity-ng/lincity-ng-1.1.1.ebuild /usr/portage/games-sports/trigger/trigger-0.5.2.1.ebuild /usr/portage/games-strategy/glest/glest-2.0.1.ebuild /usr/portage/games-strategy/netpanzer/netpanzer-0.8.1.ebuild /usr/portage/games-strategy/netpanzer/netpanzer-0.8.2.ebuild -- fonts / wxWindows / gcc-porting / treecleaners EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in app-misc/note: ChangeLog note-1.3.3.ebuild
On Tue, Oct 16, 2007 at 03:14:12AM +0100, Steve Long wrote:
> Gilles Dartiguelongue wrote:
> > I haven't reread the fine mans for a while but iirc, + could lead you to
> > hit the argument buffer limit of your shell. xargs has --max-args to get
> > around that and is also way faster than any -exec variant (at least
> > that's what the bench I did on a PIV2.6Ghz showed me about 4 months ago)
> >
> It doesn't: find will just execute the command as many times as needed (each
> time with an argument length maximally less than ARG_MAX. Well, it did when
> we tested this a couple of months ago.) So it's optimal in that sense. I
> have no idea on the timing measurements, but I don't like pipes and
> subshells as a rule (externals are bad enough!;>) It'd be interesting to
> see measurements over 10 loops with long argument lists requiring
> multiple invocations per pass, I suppose.
Here's a quick benchmark:
% \
repeat 3 \time find -name '*.ebuild' | xargs cat >/dev/null; echo; \
repeat 3 \time find -name '*.ebuild' -exec cat {} ';' >/dev/null; echo; \
repeat 3 \time find -name '*.ebuild' -exec cat {} '+' >/dev/null
66.28 real 0.77 user 4.71 sys
30.95 real 0.76 user 4.73 sys
30.08 real 0.76 user 4.67 sys
174.72 real18.10 user 112.92 sys
208.69 real18.07 user 117.05 sys
173.64 real18.10 user 110.79 sys
62.61 real 1.26 user10.88 sys
54.98 real 1.25 user10.46 sys
41.84 real 1.25 user10.00 sys
the third variant doesn't get any faster than on the last line.
( tested in zsh, with bsd time and gnu find )
-- Elias
pgpUglx1YKVOi.pgp
Description: PGP signature
[gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in app-misc/note: ChangeLog note-1.3.3.ebuild
Gilles Dartiguelongue wrote: > I haven't reread the fine mans for a while but iirc, + could lead you to > hit the argument buffer limit of your shell. xargs has --max-args to get > around that and is also way faster than any -exec variant (at least > that's what the bench I did on a PIV2.6Ghz showed me about 4 months ago) > It doesn't: find will just execute the command as many times as needed (each time with an argument length maximally less than ARG_MAX. Well, it did when we tested this a couple of months ago.) So it's optimal in that sense. I have no idea on the timing measurements, but I don't like pipes and subshells as a rule (externals are bad enough!;>) It'd be interesting to see measurements over 10 loops with long argument lists requiring multiple invocations per pass, I suppose. An array expansion can lead to an argument length greater than ARG_MAX however, eg funcToFix "[EMAIL PROTECTED]" (I'd be kind of perturbed if the last case were infeasible since it would imply poor memory handling in BASH, and limit the scope of its usability.) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
Doug Goldstein wrote: > I still stand by my original feeling that we'd better the community NOT > only the developers doing the commits by updating the devmanual, which > is accessible to all developers and all users in the Gentoo community. This would be a great thing, but I'm under the impression that it's somewhat difficult to get changes made to the devmanual for various reasons. That said I've never actually tried so I'm probably talking out my ass. > The commits review is flawed because if we're not documenting this stuff > in one central place, then when new developers join. The same lessons > have to be learned over and over again. I think the review work is already very useful. However I do agree that actually documenting this stuff would be even more useful. > Then again, this depends on the QA guys actually doing something about > the outstanding bugs. This would not be the least of the various reasons. ;P -- fonts / wxWindows / gcc-porting / treecleaners EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in app-misc/note: ChangeLog note-1.3.3.ebuild
Le lundi 15 octobre 2007 à 23:43 +0100, Steve Long a écrit :
> Roy Marples wrote:
> The unintended globbing is indeed unsafe, in the general case. I'd do this:
>
> find "$D" -type f -name '*'"$v"'.*pm' -exec rm {} +
>
> The shell will still treat that all as one argument (this method is
> typically used to insert variables into awk commands, or sed ones which
> use ".) The + will make the command execution more efficient for commands
> that take multiple filenames. The one caveat with + is that the {} must
> appear at the end of the command.[3]
I haven't reread the fine mans for a while but iirc, + could lead you to
hit the argument buffer limit of your shell. xargs has --max-args to get
around that and is also way faster than any -exec variant (at least
that's what the bench I did on a PIV2.6Ghz showed me about 4 months ago)
--
Gilles Dartiguelongue <[EMAIL PROTECTED]>
Gentoo
signature.asc
Description: Ceci est une partie de message numériquement signée
[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in app-misc/note: ChangeLog note-1.3.3.ebuild
Roy Marples wrote:
> On Mon, 2007-10-15 at 10:43 +0200, Fabian Groffen wrote:
>> On 15-10-2007 09:35:35 +0100, Roy Marples wrote:
>> > find "${D}" -type f -name *${v}.*pm -delete
>>
>> Looks like you rely on your shell here to assume that you meant
>> "*${v}.*pm" because there is nothing that matches that pattern by
>> coincidence. If it does, your find probably doesn't do what you expect
>> it to.
>
> It was like that in the original code snippet, I assumed that is what
> the author intended? Anyway, you're probably right.
>
Well if portability is a concern, -delete is not specified in POSIX[1]
afaict. -exec is, it turns out, including -exec blah {} + which really made
me wonder why people still have such a thing for xargs. It turns out GNU
didn't include this til recently, and it isn't in OpenBSD either for one[2]
(..disgraceful, if you ask me ;)
The unintended globbing is indeed unsafe, in the general case. I'd do this:
find "$D" -type f -name '*'"$v"'.*pm' -exec rm {} +
The shell will still treat that all as one argument (this method is
typically used to insert variables into awk commands, or sed ones which
use ".) The + will make the command execution more efficient for commands
that take multiple filenames. The one caveat with + is that the {} must
appear at the end of the command.[3]
[1] http://www.opengroup.org/onlinepubs/009695399/utilities/find.html
[2]
http://www.openbsd.org/cgi-bin/man.cgi?query=find&apropos=0&sektion=1&manpath=OpenBSD+Current&arch=i386&format=html
[3] http://wooledge.org/mywiki/UsingFind (highly recommended)
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-office/gnotime: ChangeLog gnotime-2.2.3.ebuild
On 21:34 Mon 15 Oct , Christian Faulhammer (opfer) wrote:
> 1.1 app-office/gnotime/gnotime-2.2.3.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-office/gnotime/gnotime-2.2.3.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-office/gnotime/gnotime-2.2.3.ebuild?rev=1.1&content-type=text/plain
> pkg_setup() {
> # upstream knows about the fix and has promised to incorporate it
> if has_version ">=dev-scheme/guile-1.8" && ! built_with_use
> dev-scheme/guile deprecated;then
> eerror "rebuild dev-scheme/guile with USE=deprecated"
> die
> fi
> }
You could drop the has_version check and pass '--missing true' to
built_with_use().
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/qof: qof-0.7.2.ebuild metadata.xml ChangeLog Manifest
On 21:28 Mon 15 Oct , Christian Faulhammer (opfer) wrote:
> src_compile() {
> econf || die "econf failed"
> emake || die "emake failed"
> }
This is the default, you can get rid of it.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-emulation/xen: ChangeLog xen-3.1.1.ebuild
On 18:33 Mon 15 Oct , Micheal Marineau (marineam) wrote:
> 1.1 app-emulation/xen/xen-3.1.1.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emulation/xen/xen-3.1.1.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emulation/xen/xen-3.1.1.ebuild?rev=1.1&content-type=text/plain
> src_compile() {
> local myopt
> use debug && myopt="${myopt} debug=y"
> use pae && myopt="${myopt} pae=y"
>
> if use custom-cflags; then
> filter-flags -fPIE -fstack-protector
> else
> unset CFLAGS
> fi
>
> # Send raw LDFLAGS so that --as-needed works
> emake LDFLAGS="$(raw-ldflags)" -C xen ${myopt} || die "compile failed"
> }
>
> src_install() {
> local myopt
> use debug && myopt="${myopt} debug=y"
> use pae && myopt="${myopt} pae=y"
The environment should be preserved across phases, so you shouldn't have
to repeat this stuff.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
On 16:57 Mon 15 Oct , Doug Goldstein wrote: > I still stand by my original feeling that we'd better the community NOT > only the developers doing the commits by updating the devmanual, which > is accessible to all developers and all users in the Gentoo community. > In addition to updating and cleaning up repoman checks, which is a tool > that everyone in the community can use. This is versus individual > examples in random ebuilds in random e-mails that all have almost an > identical subject on the mailing list. > > The commits review is flawed because if we're not documenting this stuff > in one central place, then when new developers join. The same lessons > have to be learned over and over again. Doing the review helps us figure out what the common issues are, so we actually know what's worth documenting. I've had in mind all along getting common issues into docs and into repoman, which is why I wrote the original quoting patch. Also, just because something is documented doesn't mean people do it. Furthermore, just because a doc says "write code without bugs" doesn't mean people are physically capable of doing so. More eyes on the code can never hurt. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in sys-cluster/pvfs2: ChangeLog pvfs2-2.6.3-r1.ebuild
Matti Bickel wrote: > Steve Long <[EMAIL PROTECTED]> wrote: >> >> > Mixing 'gt' and 'ge' is a bad idea. >> >> >> >> Just outa curiosity, why? >> > >> > Because it's inconsistent and one generally assumes that people will be >> > consistent with the way they test numbers. That way you only need to >> > read the number rather than continually checking every single line to >> > see how exactly it's tested for. >> > >> I don't see how this is inconsistent either: two tests are needed, so >> that both patches are only applied for >=2.6.22 and first only if >> >2.6.20. > > The point is that if you stick to "ge" OR "gt", everyone could just skip > reading the comparison and focus on the numbers. Will be fixed in the > next release, along with kernel-2.4 support... > OIC: so the argument was it should be ge 2.6.21 as well? Does that catch all the same cases? I must say I find this criticism unusual: if someone were looking at the ebuild to check the numbers, I would guess it were because something was going wrong. As such, they would be paying attention to which version they were on, and what the tests were. I don't see the use-case for limiting what maintainers can do in such a fashion, but if it makes no difference to the outcome (ie which cases are covered), i guess it makes sense. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
Doug Goldstein wrote: > I know the other thing I didn't answer was the fact that some variables > aren't quoted. It doesn't matter at all considering their configure > script can't handle spaces in the path names anyway. We've been though > that already. Additionally, qmake can't handle spaces in there even if > you do quote so it really doesn't matter much. > I disagree: it's important to do the correct thing, wrt spaces in filenames, in scripts, since there is a well-understood method of doing so (quoting) and once it is correct, it is always correct no matter what use is made of it in the future. If upstream tools can't deal with them, then they need to be fixed. I appreciate that might not happen for this configure script, but it shoud happen for qmake. (I find it hard to believe that qmake can't deal with spaces in filenames tbh, not from experience: it just sounds amateurish.) > Some of these review changes truly feel like working at a company where > you know the ins and outs of your tool. You can rattle off its > capabilities to a millimeter. A new boss/manager comes in and has no > idea what the tool is or the mission but by god he knows how to do your > job better and you will follow his procedures. It makes no difference if > his steps have no effect on the tool and waste more of your time. You > additionally have to start giving him progress reports on how you're > doing using his procedures, which instantly means you get less work done. > > That's what this commits review list feels like. Fair enough: that's how you feel about it. The quoting issue isn't new though[1]: that it hasn't been picked up on before is no excuse for not fixing it now, imo. The tool in question is bash, not the upstream configure script or qmake, and correct usage should be a point of pride: again, only my opinion. Then again, no-one's making you report back-- you're not under any contractual obligation to respond: must just be professional pride? ;-) [1] http://www.grymoire.com/Unix/Quote.html http://bash-hackers.org/wiki/doku.php?id=syntax:words explains why and how the issue arises. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
Christian Faulhammer wrote: > Doug Goldstein <[EMAIL PROTECTED]>: > > >> Jonathan Adamczewski wrote: >> >>> Doug Goldstein wrote: >>> That's what this commits review list feels like. >>> Nearly every suggestion (from Donnie and others) has been over some >>> issue that relates directly to either correctness or >>> maintainability. It doesn't matter if you can "rattle off >>> capabilities to a millimeter" - if they're not documented somewhere >>> (like, say, in the comments of the ebuild) then the maintainer that >>> comes after you gets to go and break it all over again. >>> >> Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild. >> Do it. I dare you. Then try to compile. >> Guess what? When it blows up... that's called INcorrect. The opposite >> of the right thing. >> > > You were kindly asked if is not possible to use, so why do you feel > attacked? Do a comment on it and everybody would be fine, even the > people that would have to maintain it some time in the future. If you > don't like the review process, just ignore it. > Reviews are not a way to show what kind of idiot the committer is, but > to improve the overall quality of the tree. Nothing more, nothing less. > No. You clearly don't understand where I'm coming from. I think the commits review is pointless and a waste of resources that could be better used doing other things. Since commits review is a cyclic process you will never achieve a perfect state that all developers commit perfect ebuilds to the tree since new devs come and go. And since we don't document any of this stuff properly in the devmanual, incoming devs have to constantly relearn the same lessons that previous incoming devs learned through the review process. Effective workers work in 4 stages, we're effectively with this approach remaining in stage 1 and never progressing and admitting we will never progress. > > >> The maintainer who comes after me would be someone with a experience >> with the package. Some bumkin isn't going to come to maintain package >> XYZ unless they know or use the package, and guess what? That means >> experience. >> > > Yes, and the same goes for GNU Emacs, I needed some time to figure out > what all those things did and I broke it several times because I tried > to be clever. Now we documented it and I think everyone coming after us > will have a less hard time to understand it. Better document it, you > never know what happens. > > V-Li > > Read the ChangeLog. It's there for a reason. It provides valuable knowledge and information about the package. I would expect any developer worth their salt to at least brush up on the ChangeLog for any package they are taking over. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
Alec Warner wrote: > On 10/15/07, Doug Goldstein <[EMAIL PROTECTED]> wrote: > >> Jonathan Adamczewski wrote: >> >>> Doug Goldstein wrote: >>> >>> That's what this commits review list feels like. >>> Nearly every suggestion (from Donnie and others) has been over some >>> issue that relates directly to either correctness or maintainability. >>> It doesn't matter if you can "rattle off capabilities to a millimeter" - >>> if they're not documented somewhere (like, say, in the comments of the >>> ebuild) then the maintainer that comes after you gets to go and break it >>> all over again. >>> >>> >>> jonathan. >>> >>> >> Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild. >> Do it. I dare you. Then try to compile. >> >> Guess what? When it blows up... that's called INcorrect. The opposite of >> the right thing. >> >> The maintainer who comes after me would be someone with a experience >> with the package. Some bumkin isn't going to come to maintain package >> XYZ unless they know or use the package, and guess what? That means >> experience. >> > > I think this assumption is false. People maintain packages they don't > know the intricate details of all the time. You are of course, free > to ignore any and all suggestions offered; but you are not allowed to > silence them. > > -Alec > I must have not received my silence/moderate remote control for the Gentoo mailing lists. Since I haven't received it, I clearly can't silence anyone on the mailing lists. I still stand by my original feeling that we'd better the community NOT only the developers doing the commits by updating the devmanual, which is accessible to all developers and all users in the Gentoo community. In addition to updating and cleaning up repoman checks, which is a tool that everyone in the community can use. This is versus individual examples in random ebuilds in random e-mails that all have almost an identical subject on the mailing list. The commits review is flawed because if we're not documenting this stuff in one central place, then when new developers join. The same lessons have to be learned over and over again. Then again, this depends on the QA guys actually doing something about the outstanding bugs. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
On 10/15/07, Doug Goldstein <[EMAIL PROTECTED]> wrote: > Jonathan Adamczewski wrote: > > Doug Goldstein wrote: > > > >> That's what this commits review list feels like. > >> > >> > > > > > > Nearly every suggestion (from Donnie and others) has been over some > > issue that relates directly to either correctness or maintainability. > > It doesn't matter if you can "rattle off capabilities to a millimeter" - > > if they're not documented somewhere (like, say, in the comments of the > > ebuild) then the maintainer that comes after you gets to go and break it > > all over again. > > > > > > jonathan. > > > Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild. > Do it. I dare you. Then try to compile. > > Guess what? When it blows up... that's called INcorrect. The opposite of > the right thing. > > The maintainer who comes after me would be someone with a experience > with the package. Some bumkin isn't going to come to maintain package > XYZ unless they know or use the package, and guess what? That means > experience. I think this assumption is false. People maintain packages they don't know the intricate details of all the time. You are of course, free to ignore any and all suggestions offered; but you are not allowed to silence them. -Alec -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
Doug Goldstein <[EMAIL PROTECTED]>: > Jonathan Adamczewski wrote: > > Doug Goldstein wrote: > >> That's what this commits review list feels like. > > Nearly every suggestion (from Donnie and others) has been over some > > issue that relates directly to either correctness or > > maintainability. It doesn't matter if you can "rattle off > > capabilities to a millimeter" - if they're not documented somewhere > > (like, say, in the comments of the ebuild) then the maintainer that > > comes after you gets to go and break it all over again. > Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild. > Do it. I dare you. Then try to compile. > Guess what? When it blows up... that's called INcorrect. The opposite > of the right thing. You were kindly asked if is not possible to use, so why do you feel attacked? Do a comment on it and everybody would be fine, even the people that would have to maintain it some time in the future. If you don't like the review process, just ignore it. Reviews are not a way to show what kind of idiot the committer is, but to improve the overall quality of the tree. Nothing more, nothing less. > The maintainer who comes after me would be someone with a experience > with the package. Some bumkin isn't going to come to maintain package > XYZ unless they know or use the package, and guess what? That means > experience. Yes, and the same goes for GNU Emacs, I needed some time to figure out what all those things did and I broke it several times because I tried to be clever. Now we documented it and I think everyone coming after us will have a less hard time to understand it. Better document it, you never know what happens. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Last Rites - Oct 7th - 14th, 2007
On Sun, 14 Oct 2007 15:45:07 -0600 Ryan Hill <[EMAIL PROTECTED]> wrote: > Attached are the packages that have been scheduled for removal this > week. > > > dev-lang/anubisSamuli Suominen <[EMAIL PROTECTED]> > 08 Nov 2007 Not really going anywhere yet, upstream responded and they are releasing upgraded binary version which will be unmasked.. if.. maybe.. when.. they release no sources :) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
Jonathan Adamczewski wrote: > Doug Goldstein wrote: > >> That's what this commits review list feels like. >> >> > > > Nearly every suggestion (from Donnie and others) has been over some > issue that relates directly to either correctness or maintainability. > It doesn't matter if you can "rattle off capabilities to a millimeter" - > if they're not documented somewhere (like, say, in the comments of the > ebuild) then the maintainer that comes after you gets to go and break it > all over again. > > > jonathan. > Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild. Do it. I dare you. Then try to compile. Guess what? When it blows up... that's called INcorrect. The opposite of the right thing. The maintainer who comes after me would be someone with a experience with the package. Some bumkin isn't going to come to maintain package XYZ unless they know or use the package, and guess what? That means experience. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
Doug Goldstein wrote: > > That's what this commits review list feels like. > Nearly every suggestion (from Donnie and others) has been over some issue that relates directly to either correctness or maintainability. It doesn't matter if you can "rattle off capabilities to a millimeter" - if they're not documented somewhere (like, say, in the comments of the ebuild) then the maintainer that comes after you gets to go and break it all over again. jonathan. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
Donnie Berkholz wrote: > On 00:12 Sun 14 Oct , Doug Goldstein wrote: > >> Because if you pass the inverse the script blows up. It's ffmpeg's >> configure script that's a hand written script and modified by the MythTV >> developers. >> > > Sigh. Any chance of getting things to move to autotools? > > Thanks, > Donnie > Donnie, In my 4 years of experience with this package and maintaining it and contributing patches upstream. You don't think I've suggested it? You don't think I've tweaked this ebuild to work as best as possible for our users? I know the other thing I didn't answer was the fact that some variables aren't quoted. It doesn't matter at all considering their configure script can't handle spaces in the path names anyway. We've been though that already. Additionally, qmake can't handle spaces in there even if you do quote so it really doesn't matter much. Some of these review changes truly feel like working at a company where you know the ins and outs of your tool. You can rattle off its capabilities to a millimeter. A new boss/manager comes in and has no idea what the tool is or the mission but by god he knows how to do your job better and you will follow his procedures. It makes no difference if his steps have no effect on the tool and waste more of your time. You additionally have to start giving him progress reports on how you're doing using his procedures, which instantly means you get less work done. That's what this commits review list feels like. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-p2p/btg: btg-0.9.6.ebuild Manifest metadata.xml ChangeLog
On Monday 15 October 2007, Donnie Berkholz wrote: > > einfo > > einfo "Compile dev-libs/boost with USE=threads or > > USE=threads-only" > > einfo "if you want threading support for btg" > > einfo Shouldn't that be "threadsonly" ? -- /PA -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/note: ChangeLog note-1.3.3.ebuild
On Mon, 2007-10-15 at 10:43 +0200, Fabian Groffen wrote:
> On 15-10-2007 09:35:35 +0100, Roy Marples wrote:
> > find "${D}" -type f -name *${v}.*pm -delete
>
> Looks like you rely on your shell here to assume that you meant
> "*${v}.*pm" because there is nothing that matches that pattern by
> coincidence. If it does, your find probably doesn't do what you expect
> it to.
It was like that in the original code snippet, I assumed that is what
the author intended? Anyway, you're probably right.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/note: ChangeLog note-1.3.3.ebuild
On 15-10-2007 09:35:35 +0100, Roy Marples wrote:
> find "${D}" -type f -name *${v}.*pm -delete
Looks like you rely on your shell here to assume that you meant
"*${v}.*pm" because there is nothing that matches that pattern by
coincidence. If it does, your find probably doesn't do what you expect
it to.
--
Fabian Groffen
Gentoo on a different level
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/note: ChangeLog note-1.3.3.ebuild
On Mon, 2007-10-15 at 01:01 -0700, Donnie Berkholz wrote:
> On 09:56 Mon 15 Oct , Bo Ørsted Andresen wrote:
> > Written like this u certainly can't since the output of the find expression
> > is
> > subjected to word splitting before u gets set. Hence this will fail if ${D}
> > contains spaces even if ${u} gets quoted. The best way to solve this is to
> > use
> > find ... -print0 | xargs -0 rm. Unfortunately that solution means using GNU
> > extensions that I'm not sure are guaranteed to be available in the ebuild
> > environment. If they aren't maybe they should be.
>
> Cool, I hadn't dealt with this before. Thanks for pointing that out! We
> were just talking about whether to require GNU find the other day, but I
> don't recall the conclusion. Does anyone else?
I think most people wanted to force all GNU tools.
So once it's all keyworded BSD and installed outside of our normal $PATH
or g prefixed (gfind, gsed, etc) then you can start
DEPEND="your-find-of-choice" and use it in the ebuild.
But we're not there yet so lets use something that all platforms
support. Like say find's -delete action which should fit the bill quite
nicely.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/note: ChangeLog note-1.3.3.ebuild
On Mon, 2007-10-15 at 09:56 +0200, Bo Ørsted Andresen wrote:
> On Monday 15 October 2007 09:42:50 Donnie Berkholz wrote:
> > On 07:40 Mon 15 Oct , Christian Faulhammer (opfer) wrote:
> > > 1.1 app-misc/note/note-1.3.3.ebuild
> > >
> > > file :
> > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/note/note-1.3.3.ebuild?rev=1.1&view=markup
> > > plain:
> > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/note/note-1.3.3.ebuild?rev=1.1&content-type=text/plain
> > >
> > > for v in mysql text dbm general; do
> > > if ! use ${v}; then
> > > for u in `find "${D}" -type f -name *${v}.*pm`; do
> > > rm ${u}
> >
> > Looks like 'u' could have spaces in it, since it's based on D.
>
> Written like this u certainly can't since the output of the find expression is
> subjected to word splitting before u gets set. Hence this will fail if ${D}
> contains spaces even if ${u} gets quoted. The best way to solve this is to use
> find ... -print0 | xargs -0 rm. Unfortunately that solution means using GNU
> extensions that I'm not sure are guaranteed to be available in the ebuild
> environment. If they aren't maybe they should be.
>
find "${D}" -type f -name *${v}.*pm -delete
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: x11-misc/xcut
# Krzysiek Pawlik <[EMAIL PROTECTED]> (15 Oct 2007) # Copying doesn't work, use xclip instead, see bug #191553 x11-misc/xcut Bug: https://bugs.gentoo.org/show_bug.cgi?id=191553 Will be removed on 2007/11/15 -- Krzysiek Pawlik key id: 0xBC51 desktop-misc, desktop-dock, x86, java, apache, ppc... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/note: ChangeLog note-1.3.3.ebuild
> On Mon, 15 Oct 2007, Bo Ørsted Andresen wrote:
> The best way to solve this is to use find ... -print0 | xargs -0 rm.
cd "${D}"; find . ... | xargs rm -f
and you won't need any GNU extensions.
Ulrich
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/note: ChangeLog note-1.3.3.ebuild
On 09:56 Mon 15 Oct , Bo Ørsted Andresen wrote:
> Written like this u certainly can't since the output of the find expression is
> subjected to word splitting before u gets set. Hence this will fail if ${D}
> contains spaces even if ${u} gets quoted. The best way to solve this is to use
> find ... -print0 | xargs -0 rm. Unfortunately that solution means using GNU
> extensions that I'm not sure are guaranteed to be available in the ebuild
> environment. If they aren't maybe they should be.
Cool, I hadn't dealt with this before. Thanks for pointing that out! We
were just talking about whether to require GNU find the other day, but I
don't recall the conclusion. Does anyone else?
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/note: ChangeLog note-1.3.3.ebuild
On Monday 15 October 2007 09:42:50 Donnie Berkholz wrote:
> On 07:40 Mon 15 Oct , Christian Faulhammer (opfer) wrote:
> > 1.1 app-misc/note/note-1.3.3.ebuild
> >
> > file :
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/note/note-1.3.3.ebuild?rev=1.1&view=markup
> > plain:
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/note/note-1.3.3.ebuild?rev=1.1&content-type=text/plain
> >
> > for v in mysql text dbm general; do
> > if ! use ${v}; then
> > for u in `find "${D}" -type f -name *${v}.*pm`; do
> > rm ${u}
>
> Looks like 'u' could have spaces in it, since it's based on D.
Written like this u certainly can't since the output of the find expression is
subjected to word splitting before u gets set. Hence this will fail if ${D}
contains spaces even if ${u} gets quoted. The best way to solve this is to use
find ... -print0 | xargs -0 rm. Unfortunately that solution means using GNU
extensions that I'm not sure are guaranteed to be available in the ebuild
environment. If they aren't maybe they should be.
--
Bo Andresen
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-misc/note: ChangeLog note-1.3.3.ebuild
On 07:40 Mon 15 Oct , Christian Faulhammer (opfer) wrote:
> 1.1 app-misc/note/note-1.3.3.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/note/note-1.3.3.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/note/note-1.3.3.ebuild?rev=1.1&content-type=text/plain
> for v in mysql text dbm general; do
> if ! use ${v}; then
> for u in `find "${D}" -type f -name *${v}.*pm`; do
> rm ${u}
Looks like 'u' could have spaces in it, since it's based on D.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2007-10-14 23h59 UTC
On Mon, Oct 15, 2007 at 12:15:02AM +, Robin H. Johnson wrote: > The attached list notes all of the packages that were added or removed > from the tree, for the week ending 2007-10-14 23h59 UTC. > Removals: > Additions: > net-p2p/btg 2007-10-14 23:37:13 angelos Please ignore this version. It overflowed from the addition of all the texlive ebuilds. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpRzKD3Plv8H.pgp Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2007-10-14 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2007-10-14 23h59 UTC. Removals: www-client/planet 2007-10-10 02:54:29 beandog games-sports/sturmbahnfahrer2007-10-14 06:48:45 mr_bones_ Additions: sys-kernel/kccmp2007-10-08 12:00:34 mpagano dev-php/PEAR-Text_Figlet2007-10-08 12:03:32 anant dev-php/PEAR-Image_Text 2007-10-08 12:05:31 anant dev-php/PEAR-Text_CAPTCHA 2007-10-08 12:07:09 anant net-im/jabberd2 2007-10-08 12:59:52 nelchael x11-themes/camaelon-themes 2007-10-08 20:12:36 voyageur media-plugins/vdr-menuorg 2007-10-08 20:50:30 zzam virtual/editor 2007-10-10 06:03:22 opfer profiles/default-darwin 2007-10-10 08:01:30 opfer profiles/embedded 2007-10-10 08:03:02 opfer virtual/blas2007-10-10 12:22:32 bicatali virtual/cblas 2007-10-10 12:27:59 bicatali app-portage/portpeek2007-10-10 14:43:09 mpagano dev-python/pygtksourceview 2007-10-10 21:22:53 remi app-office/rubrica 2007-10-10 22:50:43 opfer app-text/rarian 2007-10-12 12:12:12 remi app-emacs/bm2007-10-13 11:04:03 ulm java-virtuals/javamail 2007-10-14 05:14:32 ali_bush app-text/texlive-core 2007-10-14 07:56:33 aballier dev-texlive/texlive-documentation-base 2007-10-14 08:11:36 aballier dev-texlive/texlive-basic 2007-10-14 08:12:58 aballier dev-texlive/texlive-latex 2007-10-14 08:15:03 aballier dev-texlive/texlive-fontsrecommended2007-10-14 08:17:03 aballier dev-texlive/texlive-fontsextra 2007-10-14 08:20:21 aballier dev-texlive/texlive-metapost2007-10-14 08:22:11 aballier dev-texlive/texlive-langgreek 2007-10-14 08:24:27 aballier dev-texlive/texlive-context 2007-10-14 08:25:37 aballier dev-texlive/texlive-bibtexextra 2007-10-14 08:27:06 aballier dev-texlive/texlive-latex3 2007-10-14 08:28:50 aballier dev-texlive/texlive-pstricks2007-10-14 08:30:19 aballier dev-texlive/texlive-formatsextra2007-10-14 08:31:59 aballier dev-texlive/texlive-omega 2007-10-14 08:33:31 aballier dev-texlive/texlive-xetex 2007-10-14 08:35:13 aballier dev-texlive/texlive-texinfo 2007-10-14 08:37:08 aballier dev-texlive/texlive-science 2007-10-14 08:38:42 aballier dev-texlive/texlive-publishers 2007-10-14 08:40:19 aballier dev-texlive/texlive-psutils 2007-10-14 08:42:23 aballier dev-texlive/texlive-plainextra 2007-10-14 08:43:53 aballier dev-texlive/texlive-pictures2007-10-14 08:46:06 aballier dev-texlive/texlive-music 2007-10-14 08:47:33 aballier dev-texlive/texlive-mathextra 2007-10-14 08:49:31 aballier dev-texlive/texlive-latexrecommended2007-10-14 08:51:21 aballier dev-texlive/texlive-latexextra 2007-10-14 08:53:47 aballier dev-texlive/texlive-games 2007-10-14 08:55:27 aballier dev-texlive/texlive-humanities 2007-10-14 09:00:13 aballier dev-texlive/texlive-genericrecommended 2007-10-14 09:01:50 aballier dev-texlive/texlive-genericextra2007-10-14 09:03:16 aballier dev-texlive/texlive-htmlxml 2007-10-14 09:04:46 aballier dev-texlive/texlive-documentation-bulgarian 2007-10-14 09:06:33 aballier dev-texlive/texlive-langafrican 2007-10-14 09:08:40 aballier dev-texlive/texlive-langarab2007-10-14 09:10:12 aballier dev-texlive/texlive-langarmenian2007-10-14 09:11:51 aballier dev-texlive/texlive-documentation-chinese 2007-10-14 09:13:56 aballier dev-texlive/texlive-langcjk 2007-10-14 09:15:25 aballier dev-texlive/texlive-langcroatian2007-10-14 09:16:51 aballier dev-texlive/texlive-langcyrillic2007-10-14 09:32:48 aballier dev-texlive/texlive-langczechslovak 2007-10-14 09:34:29 aballier dev-texlive/texlive-langdanish 2007-10-14 09:36:13 aballier dev-texlive/texlive-langdut
