Re: [gentoo-dev] RFC: 0-day bump requests
On Friday 04 July 2008, Tony "Chainsaw" Vroon wrote: > How about a metadata.xml tag that indicates whether early bump requests are > welcome? People obviously don't care about what it says on the website, why should they start looking into metadata.xml? I think we should remove the useless restrictions on filing bump requests and welcome users to open bugs. Closing (valid) bugs feels good and is also sort of a psychological reward for the user who opened the bug, perhaps encouraging them to stay in direct contact with Gentoo and contribute other, less trivial work. -- Torsten Rehn <[EMAIL PROTECTED]> Gentoo AMD64 Arch Tester http://scel.info signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Bugzilla enhancements wrt AT work
On Saturday 15 March 2008, Rémi Cardona wrote: > Just curious, who would be the default assignee for those 2 new components? I don't think anything should be changed here. Unpriviledged users automatically assign to bug-wranglers, everyone else goes for the target packages' maintainer. Do you see any problem with this? -- Torsten Rehn <[EMAIL PROTECTED]> Gentoo AMD64 Arch Tester http://scel.info signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [RFC] Bugzilla enhancements wrt AT work
Two weeks ago, dirtyepic suggested making some modifications to how ATs and
developers interact using Bugzilla [1].
<+jakub> scel: basically... instead of KEYWORDREQ/STABLEREQ
<+jakub> create keywording and stabilization components
<+jakub> and use flags accordingly there
<+jakub> bugzilla already has the features, why not use them
<+jakub> also, nuke things like TESTED and STABLE
This is trivial to implement and would greatly improve the ability to search
for {STABLE,KEYWORD}REQs that have been tested by ATs. All ATs I've spoken to
(most of the active ones at amd64) would really appreciate this change.
Discuss.
Also notice bug 213514 [2] for actual progress on this.
[1]
http://archives.gentoo.org/gentoo-dev/msg_a5495659df35010ae44c266dd785ae4e.xml
[2] http://bugs.gentoo.org/213514
--
Torsten Rehn <[EMAIL PROTECTED]>
Gentoo AMD64 Arch Tester
http://scel.info
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Keyword request interface (SoC candidate?)
On Thursday 28 February 2008, Santiago M. Mola wrote: > A lot of users don't feel comfortable using Bugzilla and often are > lost with our procedures for keyword (both ~ and stable) requests. I > think we could use an easy web interface for requesting specific > keywords for packages in a point-and-click fashion. I have been working on something like this and would like to continue doing so for SoC (see [1]). However, it is a fairly large project and I would appreciate some input on what specific goals to target for SoC. Also, I anticipate some resistance, so I'd suggest seeing that project as a long term experiment starting with SoC, that may eventually produce something that satisfies most of the developer staff. [1] http://scel.info/blog/posts/google-soc-proposal/ -- Torsten Rehn <[EMAIL PROTECTED]> Gentoo AMD64 Arch Tester http://scel.info signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Deprecating an eclass
On Monday 18 February 2008, Doug Klima wrote: > Potentially doing something like: > DEPRECIATED="$DEPRECATED $ECLASS" > at the top of each deprecated eclass. Adding deprecation info directly into the eclass file feels wrong to me. (Eclasses are free software after all and can be reused - ok, nobody will ever do that, but we're talking theory here - so we shouldn't put Gentoo policy in there.) What about /usr/portage/profiles/deprecated_eclasses looking like old_eclass_1,old_eclass_2:new_eclass_1,new_eclass_2 indicating that the old_eclasses have been deprecated by the new_eclasses. Having multiple eclasses deprecated by multiple eclasses may not be that common, but this kind of syntax allows for some grouping of related eclasses being replaced together. -- Torsten Rehn <[EMAIL PROTECTED]> Gentoo AMD64 Arch Tester http://scel.info signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] public system of ratings
On Saturday 16 February 2008, Oleg Puchinin wrote: > " is not compiled At all " > "works" All stable ebuilds in the tree should work, if they don't that's an exception and will probably get fixed soon after the failure is discovered anyway. Anyone who is willing to test a new keyword in an ebuild shouldn't have a problem filing a KEYWORDREQ in Bugzilla. > "It is excellent" If you want package ratings, take a look at ohloh.net or something, shouldn't be hard (for a human) to map the package names there to the ones in Gentoo. > "I wish to see a package in Gentoo " Again, all the most important software is already in the tree, if you need something else, filing a bug is not too much effort. -- Torsten Rehn <[EMAIL PROTECTED]> Gentoo AMD64 Arch Tester http://scel.info signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] How to get more involved?
On Thursday 31 January 2008, Mateusz Mierzwinski wrote: > What should I do to make ebuilds and upload it to main portage mirror? Take a look at the Gentoo docs on writing[1] and contributing[2] ebuilds. If you've got any further questions, try the gentoo-dev-help mailing list or the #gentoo-dev-help irc channel. Please note that this list is intended to be used for discussion of Gentoo development, not ebuild development. [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 [2] http://www.gentoo.org/doc/en/ebuild-submit.xml -- Torsten Rehn <[EMAIL PROTECTED]> Gentoo AMD64 Arch Tester http://scel.info signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass: emul-linux-x86.eclass
On Wednesday 14 November 2007, Ferris McCormick wrote:
> Note, however, that for example in /usr/lib/portage/bin/ebuild.sh, it's
> always quoted (except once, which looks like an oversight).
I was talking about referencing variables when declaring other variables.
Whenever you actually use a variable in-line (e.g. as a parameter to a
command), you have to quote as well of course.
i.e.
A=${B}
and not
cd ${B}
The difference is that bash handles variable assignments all interally and is
smart enough to handle ${B} properly, while vars that are passed to some
command are just evaluated and passed to the command in question and cannot
be "protected" anymore by bash. AFAIK.
--
Torsten Rehn <[EMAIL PROTECTED]>
Gentoo AMD64 Arch Tester
http://scel.info
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass: emul-linux-x86.eclass
On Wednesday 14 November 2007 14:21, you wrote:
> But why is it standard to quote other assignments like in DESCRIPTION and
> HOMEPAGE then?
When assigning literal values as in DESCRIPTION and HOMEPAGE, you have to
quote. ${WORKDIR} is quoted on its assignment and therefore does not have to
be quoted when assigning its value to another variable (${S}) by reference.
[EMAIL PROTECTED] > cat test.sh
#!/bin/bash
TEXT="A B"
Q=${TEXT}
echo ${TEXT}
FAIL=DONT TRYTHISATHOME
[EMAIL PROTECTED] > ./test.sh
A B
./test.sh: line 5: TRYTHISATHOME: command not found
--
Torsten Rehn <[EMAIL PROTECTED]>
Gentoo AMD64 Arch Tester
http://scel.info
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass: emul-linux-x86.eclass
On Wednesday 14 November 2007, Mike Doty wrote:
> S=${WORKDIR}
Shouldn't ${WORKDIR} be quoted here, too?
Kind regards
--
Torsten Rehn <[EMAIL PROTECTED]>
Gentoo AMD64 Arch Tester
http://scel.info
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Nero-3.0.0.0 license needs RESTRICT="fetch" ?
On Friday 06 July 2007 19:56, Harald van Dijk wrote: > And what if they decide they don't accept the license on the first run? > They'll already have installed the software, which requires acceptance > of the license. No violation here: "[...] IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT, PROMPTLY UNINSTALL AND DELETE THE SOFTWARE [...]" cheers pgpGSz0kzU2Mk.pgp Description: PGP signature
