[gentoo-dev] Re: Final proposal: New alias maintainer-needed@g.o or some such (speak now or forever hold your peace ;) )
* Daniel Drake [EMAIL PROTECTED]: Markus Nigbur wrote: Assigning to [EMAIL PROTECTED] and adding the actual fitting herd to CC is the most elegant option, IMHO. However we do it, we should really agree on one solution, to get more structure into the chaos. Here's what I'd propose: This only applies to new packages, as opposed to version bumps or whatever else: When an ebuild or ebuild request is posted to bugzilla, the bug wranglers attempt to find an appropriate herd or developer to assign it to, and the ebuild is keyworded with EBUILD or REQUEST depending whether an ebuild was included or not. If the herd or developer does not want to maintain the package and they feel that there is another herd or developer where this package would be more appropriately maintained, then they should reassign it to them. At any point, if a developer or herd decides that they do not want to maintain the package at the current time, and there is no more appropriate herd/developer, then they reassign it to [EMAIL PROTECTED] putting the most appropriate herd(s)/developer(s) on CC. Agreed. Please don't assign bugs of packages in the tree to maintainer-needed. Proposal: Bugs for packages in the tree where bugwranglers are not able to find a maintainer go to [EMAIL PROTECTED] Bump requests might be annoying, but i think it's still the best thing to do. Comments? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] use.force support
On Wednesday 15 June 2005 20:43, Sven Wegener wrote:
On Tue, Jun 14, 2005 at 07:50:13PM -0700, Donnie Berkholz wrote:
Sven Wegener wrote:
On Mon, Jun 13, 2005 at 06:56:43PM -0400, Ned Ludd wrote:
I'm in favor of this. Would you mind calling it package.autouse,
package.use.auto or are you set on .force?
As Mike already wrote those names are too confusing with the automatic
activated USE flags. We already had some suggestions in this thread,
but none of them actually matched the purpose of the file. At least in
my opinion. use.force matches it best, but the force part is a quite
hard term. How about use.profile? Because these USE flags are activated
or needed by the profile.
How about use.required, since they're required by the profile?
Sounds good to me. use.required sounds softer than use.force but still
has this touch me and things may break horribly bit.
So use.required it is then. To recap, use.required forces USE flags to be set
and can only be overridden in a sub-profile. Transition from the current
USE_EXPAND method is by simply copying the relevant USE flags to the new
use.required file.
Currently missing from the USE_EXPAND method but what also needs to be done is
to add the alternative system USE flags to use.mask. Also, this still hasn't
addressed the QA notices output during merges. For this, I'll add support for
${PORTDIR}/profiles/use.internal which will list USE flags which can be used
anywhere without having to be specified in IUSE; that is, they can be used
with useq, SRC_URI and *DEPEND.
Note, use.internal doesn't and shouldn't cover the normal USE_EXPAND flags.
I'll cover those shortly in another post.
Regards,
Jason Stubbs
pgp0XLnXRyIXs.pgp
Description: PGP signature
[gentoo-dev] USE_EXPAND and IUSE
Hi all, So there have been many complaints about how USE_EXPANDed flags don't belong in IUSE. There haven't actually been any reasons given though. :P I've assumed that the reasons they haven't been added thus far are due to what emerge's output would look like if they were. So I've taken the liberty of fixing up the output a bit. Now IUSE flags that are expansions of USE_EXPAND will be outputted like this: [ebuild N] kde-base/kde-i18n-3.4.1 +arts -debug +kdeenablefinal -xinerama LINGUAS=-ar -bg -bn -br -bs -ca -cs -cy -da -de -el -en_GB -eo -es -et -eu -fi -fr -fy -ga -he -hi -hsb -hu -is -it +ja -lt -mk -nb -nds -nl -nn -pa -pl -pt -pt_BR -ro -ru -se -sk -sl -sr [EMAIL PROTECTED] -sv -ta -tg -tr -uk -zh_CN 0 kB The format follows the same as standard USE flags but are separated out into the individual variables that enable them. Of course, the ebuilds themselves need to be updated to add the appropriate flags to IUSE. Although I believe they should be, I'll leave it up to others to decide whether said flags should be documented in use.desc. However, if it is decided to not document them in use.desc, they won't be dropped from repoman's checks until there is some other way that they can be documented. Regards, Jason Stubbs pgpTIJAQBqpkh.pgp Description: PGP signature
Re: [gentoo-dev] USE_EXPAND and IUSE
Jason Stubbs wrote: So there have been many complaints about how USE_EXPANDed flags don't belong in IUSE. There haven't actually been any reasons given though. :P net-dialup/pppconfig-2.3.11-r1 depends on LINGUAS, but the list of supported languages is created in pkg_unpack, based on what tarball contains. The IUSE thing would raise 2 problems: - lower maintainability - not really a major problem - if user wants all languages, it will be forced to select them one by one - now if LINGUAS is empty, all available languages gets installed. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Final proposal: New alias maintainer-needed@g.o or some such (speak now or forever hold your peace ;) )
On Sun, Jun 19, 2005 at 02:31:30PM +0200, Torsten Veller wrote: Please don't assign bugs of packages in the tree to maintainer-needed. Proposal: Bugs for packages in the tree where bugwranglers are not able to find a maintainer go to [EMAIL PROTECTED] You mean new ebuilds would go to [EMAIL PROTECTED] and existing but unmaintained ebuilds to [EMAIL PROTECTED] Personally I'm most interested in an alias for bugs in packages that are already in the tree, but don't have an active maintainer. Right now it's hard if not impossible to query for these bugs. New ebuild requests are quite easily listed by querying for 'enhancement', something with ebuild in the subject, assigned to bug-wranglers or any combination of the above. Bump requests might be annoying, but i think it's still the best thing to do. Huh? Regards, Maurice. -- Maurice van der Pot Gentoo Linux Developer [EMAIL PROTECTED] http://www.gentoo.org Creator of BiteMe! [EMAIL PROTECTED] http://www.kfk4ever.com pgpNxuKqGJCFu.pgp Description: PGP signature
Re: [gentoo-dev] USE_EXPAND and IUSE
On Monday 20 June 2005 01:48, Alin Nastac wrote: Jason Stubbs wrote: So there have been many complaints about how USE_EXPANDed flags don't belong in IUSE. There haven't actually been any reasons given though. :P net-dialup/pppconfig-2.3.11-r1 depends on LINGUAS, but the list of supported languages is created in pkg_unpack, based on what tarball contains. What happened to determinism and predictability? From the user's standpoint, there is no way to know what is going to be installed until it is actually installed. The IUSE thing would raise 2 problems: - lower maintainability - not really a major problem - if user wants all languages, it will be forced to select them one by one - now if LINGUAS is empty, all available languages gets installed. FRITZCAPI_CARDS FCDSL_CARDS VIDEO_CARDS INPUT_DEVICES LINGUAS Do any of these not follow the same pattern of empty var == all installed? Any objections to making that a requirement for adding a new USE_EXPAND variable? If so, the emerge *display* issue would be no problem. Regards, Jason Stubbs pgpcb88NU0E6M.pgp Description: PGP signature
Re: [gentoo-dev] linux-2.6.12
Daniel Drake wrote: Omkhar Arasaratnam wrote: That said, we're not RedHat. We ship as MANY features as we can and let the user decide. I agree that it is valuable to get reiser4 testing done up front. Eventually - some people will use it. Last I checked I think $FOO is stupid wasn't a valid closure code in bugzilla ;-) Then you have different views from the kernel project :) We and try and make our kernel (gentoo-sources) _more_ stable than the official Linux releases. We mainly stick to bug fixes decreed worthy by the upstream developers, etc. We never include patches when we know of problems that they will introduce. Daniel Sorry I was unclear - what I meant was that we wouldn't remove all support for an fs from portage. As an example if/when reiserfs4 merges into mainline we wouldn't be ripping out all the userland support and vanilla-kernel support. You are completely correct regarding gentoo-sources, though I don't believe this was the point of the original discussion. -- Omkhar Arasaratnam - Gentoo PPC64 Developer [EMAIL PROTECTED] - http://dev.gentoo.org/~omkhar Gentoo Linux / PPC64 Linux: http://ppc64.gentoo.org -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] warning: no newline at end of file
Hi all, I've been wondering - is there any eclass for fixing gcc warnings in $SUBJ for C/C++ source files? I know it's upstream's job to fix these, and that they have no effect on the compilation, but all there needs to be done is 'echo $file', and let's face it - it looks nicer when the code compiles without unnecessary warnings, to both dev's and user's eye. This is especially valid for packages which have main development for Windows version, and upstream simply does not care. If there is not such a tool and there is some positive feedback about this, I will write an eclass for this. IDEA: merge this new functionality with fixheadtails.eclass and change the name to something like sourceutils.eclass, where possibly similar tools could be added in the future. -- Andrej Ticho Kacian ticho at gentoo dot org Gentoo Linux Developer - net-mail, antivirus, amd64 pgpRTJqlSDFhk.pgp Description: PGP signature
[gentoo-dev] flawfinder rats logs
Hi, Recently began using flawfinder rats and they're working (logging things). For now don't have time to look at the logs (beside *me* needing more time to check them), so is there some place/person which collects/is_interested in such info. Maybe some meta-bug or other, or just send they upstream (if correct)? Any experiences with them, are they correct? Thanks. Rumen. smime.p7s Description: S/MIME Cryptographic Signature
