Re: [gentoo-dev] RFC: devqawarn()?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/01/2011 09:19 AM, Michał Górny wrote:
> On Thu, 01 Sep 2011 08:25:14 -0700 Zac Medico
> wrote:
>
>> On 09/01/2011 04:02 AM, Petteri Räty wrote:
>>> Have Portage defaults so that users only see if them if they
>>> read the merge logs and then developer profiles can set the
>>> settings to log them?
>>
>> As far as I know, this is already the case. The current default
>> set by portage in /usr/share/portage/config/make.globals is
>> PORTAGE_ELOG_CLASSES="log warn error", and in the developer
>> profile gentoo-x86/profiles/targets/developer/make.defaults we
>> have PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa".
>
> How about adjusting the eutils.eclass fallback to do so?
>
> Patch attached.
>
> Index: eutils.eclass
> ===
>
>
RCS file: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v
> retrieving revision 1.362 diff -u -B -d -u -p -r1.362
> eutils.eclass --- eutils.eclass 9 Aug 2011 00:43:48 - 1.362
> +++
> eutils.eclass 1 Sep 2011 16:16:40 - @@ -70,7 +70,9 @@ fi #
> implementation if available. if ! declare -F eqawarn >/dev/null ;
> then eqawarn() { -einfo "$@" +if has qa
> ${PORTAGE_ELOG_CLASSES}; then + ewarn "$@" +
> fi } fi
Looks good to me.
- --
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5fvMQACgkQ/ejvha5XGaMyQwCgqS63azOhQF/pWBNq1kN4vNr0
nMQAnRdnwUG8GFaSv9o5RawemeaXFWqb
=AL1B
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: devqawarn()?
On Thu, 01 Sep 2011 08:25:14 -0700
Zac Medico wrote:
> On 09/01/2011 04:02 AM, Petteri Räty wrote:
> > Have Portage defaults so that users only see if them if they read
> > the merge logs and then developer profiles can set the settings to
> > log them?
>
> As far as I know, this is already the case. The current default set by
> portage in /usr/share/portage/config/make.globals is
> PORTAGE_ELOG_CLASSES="log warn error", and in the developer profile
> gentoo-x86/profiles/targets/developer/make.defaults we have
> PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa".
How about adjusting the eutils.eclass fallback to do so?
Patch attached.
--
Best regards,
Michał Górny
Index: eutils.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v
retrieving revision 1.362
diff -u -B -d -u -p -r1.362 eutils.eclass
--- eutils.eclass 9 Aug 2011 00:43:48 - 1.362
+++ eutils.eclass 1 Sep 2011 16:16:40 -
@@ -70,7 +70,9 @@ fi
# implementation if available.
if ! declare -F eqawarn >/dev/null ; then
eqawarn() {
- einfo "$@"
+ if has qa ${PORTAGE_ELOG_CLASSES}; then
+ ewarn "$@"
+ fi
}
fi
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: devqawarn()?
On 1.9.2011 17.12, Donnie Berkholz wrote: > On 14:44 Thu 01 Sep , Petteri Räty wrote: >> One thing to note is that we should get eqawarn into the next EAPI. > > Why? > So that it wouldn't fall back on einfo where not available. Regards, Petteri
Re: [gentoo-dev] RFC: devqawarn()?
On 09/01/2011 04:02 AM, Petteri Räty wrote:
> Have Portage defaults so that users only see if them if they read the
> merge logs and then developer profiles can set the settings to log them?
As far as I know, this is already the case. The current default set by
portage in /usr/share/portage/config/make.globals is
PORTAGE_ELOG_CLASSES="log warn error", and in the developer profile
gentoo-x86/profiles/targets/developer/make.defaults we have
PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa".
--
Thanks,
Zac
Re: [gentoo-dev] Rewriting bash-completion.eclass
> On Thu, 1 Sep 2011, Michał Górny wrote: > So, here it goes. However, I'm not sure if that even deserves > a dedicated function as the destination is pretty constant. > # @BLURB: A few quick functions to install bash-completion files > # @DESCRIPTION: > # A few simple functions to help installing bash-completion scripts. Looks somewhat redundant. Omit DESCRIPTION? Ulrich
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
On Wed, Aug 31, 2011 at 3:41 PM, Corentin Chary wrote: > Hi, > > some news about euscan (still available at http://euscan.iksaif.net) > > - New design (yay !) > - Atom feeds available for each herd/category/maintainer/package > (http://euscan.iksaif.net/maintainers/59/feed/) > - Specific handlers for PyPi, RubyGems, pecl and PEAR packages (check > http://git.iksaif.net/?p=euscan.git;a=tree;f=pym/euscan/handlers;h=9a995dfcebe6beecce71851abb84a875cf6e5979;hb=HEAD > ). A quick example of what a custom site handler can bring (rubygems here): http://euscan.iksaif.net/categories/dev-ruby/charts/versions-weekly.png :) > Now, maybe we should find a way to integrate that with the GSoC > statistic project and with http://packages.gentoo.org/ (like done at > http://packages.qa.debian.org/p/php-net-ipv4.html ). A quick way would > be to host euscan on a gentoo server, and add some webservices to > publish the data in json or xml, then packages.gentoo.org and others > could parse that and display it. > > Thanks, > > -- > Corentin Chary > http://xf.iksaif.net > -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] Rewriting bash-completion.eclass
On 15:20 Thu 01 Sep , Tomáš Chvátal wrote: > Dne 1.9.2011 15:15, Michał Górny napsal(a): > > We can either go with a new func and retroactively replace the > > eclass, or retroactively fix all uses and fix the old funcs. > > As even if you fix main tree you can't ensure that you won't mess with > some overlay (silently as it would not be seen by default). > > I would then go proactively and fix the packages inheriting the bashcomp > eclass and when done just mark the eclass as dead. Yes, please stop breaking backwards compat without version bumps to a new eclass. It's just as annoying in an eclass as in a shared library. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpe4A1WUfHEv.pgp Description: PGP signature
Re: [gentoo-dev] RFC: devqawarn()?
On 14:44 Thu 01 Sep , Petteri Räty wrote: > One thing to note is that we should get eqawarn into the next EAPI. Why? -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgpC80OrHx438.pgp Description: PGP signature
Re: [gentoo-dev] Rewriting bash-completion.eclass
On Thu, 1 Sep 2011 15:27:12 +0200 Ulrich Mueller wrote: > > On Thu, 1 Sep 2011, Michał Górny wrote: > > > I think the way to go would be to reimplement it completely. Maybe > > just put dobashcomp() and newbashcomp() functions in eutils (to not > > collide) and deprecate bash-completion.eclass? > > I'd rather keep this in a separate bash-completion-2.eclass. > We shouldn't start moving all do* and new* functions from other > eclasses to eutils, but keep it somewhat modular. So, here it goes. However, I'm not sure if that even deserves a dedicated function as the destination is pretty constant. -- Best regards, Michał Górny bash-completion-r1.eclass Description: Binary data signature.asc Description: PGP signature
Re: [gentoo-dev] Rewriting bash-completion.eclass
> On Thu, 1 Sep 2011, Michał Górny wrote: > I think the way to go would be to reimplement it completely. Maybe > just put dobashcomp() and newbashcomp() functions in eutils (to not > collide) and deprecate bash-completion.eclass? I'd rather keep this in a separate bash-completion-2.eclass. We shouldn't start moving all do* and new* functions from other eclasses to eutils, but keep it somewhat modular. Ulrich
[gentoo-dev] Last rites for app-accessibility/speakup-utils
# Jesus Rivero (01 Sep 2011) # Masked for removal in 30 days. This package does not # work with any version of app-accessibility/speakup # anymore. app-accessibility/speakup-utils -- Jesus Rivero (Neurogeek) Gentoo Developer
Re: [gentoo-dev] Rewriting bash-completion.eclass
Dne 1.9.2011 15:15, Michał Górny napsal(a): On Thu, 01 Sep 2011 14:56:42 +0200 Tomáš Chvátal wrote: That function doesn't follow do*() argument scheme; it matches rather one used by new*() funcs. Sadly, a number of ebuilds is using that scheme to rename installed file. Furthermore, it uses two eclass variables to switch the behavior. BASHCOMPFILES allows it to install multiple files (but works only if no arguments are passed). BASHCOMPLETION_NAME renames the installed file (if BASHCOMPFILES is not used) and makes it ignore the second argument. I think the way to go would be to reimplement it completely. Maybe just put dobashcomp() and newbashcomp() functions in eutils (to not collide) and deprecate bash-completion.eclass? I would go with the eutils.eclass update, but remember that you have to keep backcompat for the old call :( Ah, forgot about stats. dobashcompletion() with two args is used a lot of times. BASHCOMPFILES is used in ONE ebuild in gx86. BASHCOMPLETION_NAME is used in 4-5 ebuilds. We can either go with a new func and retroactively replace the eclass, or retroactively fix all uses and fix the old funcs. how about new calls completely? dobashcomp newbashcomp As even if you fix main tree you can't ensure that you won't mess with some overlay (silently as it would not be seen by default). I would then go proactively and fix the packages inheriting the bashcomp eclass and when done just mark the eclass as dead. Tom
Re: [gentoo-dev] Rewriting bash-completion.eclass
On Thu, 01 Sep 2011 14:56:42 +0200 Tomáš Chvátal wrote: > > That function doesn't follow do*() argument scheme; it matches > > rather one used by new*() funcs. Sadly, a number of ebuilds is > > using that scheme to rename installed file. > > > > Furthermore, it uses two eclass variables to switch the behavior. > > > > BASHCOMPFILES allows it to install multiple files (but works only > > if no arguments are passed). > > > > BASHCOMPLETION_NAME renames the installed file (if BASHCOMPFILES is > > not used) and makes it ignore the second argument. > > > > I think the way to go would be to reimplement it completely. Maybe > > just put dobashcomp() and newbashcomp() functions in eutils (to not > > collide) and deprecate bash-completion.eclass? > > > I would go with the eutils.eclass update, but remember that you have > to keep backcompat for the old call :( Ah, forgot about stats. dobashcompletion() with two args is used a lot of times. BASHCOMPFILES is used in ONE ebuild in gx86. BASHCOMPLETION_NAME is used in 4-5 ebuilds. We can either go with a new func and retroactively replace the eclass, or retroactively fix all uses and fix the old funcs. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Rewriting bash-completion.eclass
On 09/01/2011 07:48 AM, Michał Górny wrote: Hello, Our bash-completion.eclass is awful and ugly. I'm not even talking about flags and stuff now but dobashcompletion() itself. That function doesn't follow do*() argument scheme; it matches rather one used by new*() funcs. Sadly, a number of ebuilds is using that scheme to rename installed file. Furthermore, it uses two eclass variables to switch the behavior. BASHCOMPFILES allows it to install multiple files (but works only if no arguments are passed). BASHCOMPLETION_NAME renames the installed file (if BASHCOMPFILES is not used) and makes it ignore the second argument. I think the way to go would be to reimplement it completely. Maybe just put dobashcomp() and newbashcomp() functions in eutils (to not collide) and deprecate bash-completion.eclass? De-facto maintainer signing off, your ideas have been read and well-accepted by myself. Carry on as you see fit, IMO. -Jeremy
Re: [gentoo-dev] Rewriting bash-completion.eclass
Dne 1.9.2011 14:48, Michał Górny napsal(a): Hello, Our bash-completion.eclass is awful and ugly. I'm not even talking about flags and stuff now but dobashcompletion() itself. That function doesn't follow do*() argument scheme; it matches rather one used by new*() funcs. Sadly, a number of ebuilds is using that scheme to rename installed file. Furthermore, it uses two eclass variables to switch the behavior. BASHCOMPFILES allows it to install multiple files (but works only if no arguments are passed). BASHCOMPLETION_NAME renames the installed file (if BASHCOMPFILES is not used) and makes it ignore the second argument. I think the way to go would be to reimplement it completely. Maybe just put dobashcomp() and newbashcomp() functions in eutils (to not collide) and deprecate bash-completion.eclass? I would go with the eutils.eclass update, but remember that you have to keep backcompat for the old call :( Tom
[gentoo-dev] Rewriting bash-completion.eclass
Hello, Our bash-completion.eclass is awful and ugly. I'm not even talking about flags and stuff now but dobashcompletion() itself. That function doesn't follow do*() argument scheme; it matches rather one used by new*() funcs. Sadly, a number of ebuilds is using that scheme to rename installed file. Furthermore, it uses two eclass variables to switch the behavior. BASHCOMPFILES allows it to install multiple files (but works only if no arguments are passed). BASHCOMPLETION_NAME renames the installed file (if BASHCOMPFILES is not used) and makes it ignore the second argument. I think the way to go would be to reimplement it completely. Maybe just put dobashcomp() and newbashcomp() functions in eutils (to not collide) and deprecate bash-completion.eclass? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
2011/9/1 Tomáš Chvátal : > Dne 1.9.2011 09:55, Corentin Chary napsal(a): >>> >>> Btw I have feature request, could it remember the sorting method i set? >>> (so I don't have to click and reorder it every time i refresh) >> >> Per-page or globally ? >> > I would say globaly i smore sane here I did that per-page, as it was only one line to add, I'll try to do it globally later. -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] RFC: devqawarn()?
On 1.9.2011 14.31, Michał Górny wrote: > On Thu, 01 Sep 2011 14:02:11 +0300 > Petteri Räty wrote: > >> On 1.9.2011 13.51, Michał Górny wrote: >>> On Thu, 01 Sep 2011 13:44:47 +0300 >>> Petteri Räty wrote: >>> On 1.9.2011 12.03, Michał Górny wrote: > Hello, > > A quick idea. Right now eclasses sometimes do API changes and > start yelling at users merging ebuilds using outdates APIs. This > often means users start filling bugs about outdated ebuilds > requiring maintainers either to ignore that or start updating old > ebuilds retroactively. > > Maybe we should add some kind of devqawarn() function to > eutils.eclass, which would trigger special QA warnings only when > ebuild is merged by a developer? This could be triggered e.g. by > some kind of voluntary make.conf setting. > What's wrong with eqawarn that's already provided by eutils? >>> >>> The first paragraph? >>> >> >> Have Portage defaults so that users only see if them if they read the >> merge logs and then developer profiles can set the settings to log >> them? > > 1) that's changing existing behavior, > 2) what with non-portage users? > 1) eqawarn == devqawarn. I don't see a reason to come up with a new function just to avoid changing Portage configuration. 2) How messages from each e* function is shown is left to the package manager to decide. One thing to note is that we should get eqawarn into the next EAPI. Regards, Petteri
Re: [gentoo-dev] RFC: devqawarn()?
On Thu, 01 Sep 2011 14:02:11 +0300 Petteri Räty wrote: > On 1.9.2011 13.51, Michał Górny wrote: > > On Thu, 01 Sep 2011 13:44:47 +0300 > > Petteri Räty wrote: > > > >> On 1.9.2011 12.03, Michał Górny wrote: > >>> Hello, > >>> > >>> A quick idea. Right now eclasses sometimes do API changes and > >>> start yelling at users merging ebuilds using outdates APIs. This > >>> often means users start filling bugs about outdated ebuilds > >>> requiring maintainers either to ignore that or start updating old > >>> ebuilds retroactively. > >>> > >>> Maybe we should add some kind of devqawarn() function to > >>> eutils.eclass, which would trigger special QA warnings only when > >>> ebuild is merged by a developer? This could be triggered e.g. by > >>> some kind of voluntary make.conf setting. > >>> > >> > >> What's wrong with eqawarn that's already provided by eutils? > > > > The first paragraph? > > > > Have Portage defaults so that users only see if them if they read the > merge logs and then developer profiles can set the settings to log > them? 1) that's changing existing behavior, 2) what with non-portage users? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: devqawarn()?
On 1.9.2011 13.51, Michał Górny wrote: > On Thu, 01 Sep 2011 13:44:47 +0300 > Petteri Räty wrote: > >> On 1.9.2011 12.03, Michał Górny wrote: >>> Hello, >>> >>> A quick idea. Right now eclasses sometimes do API changes and start >>> yelling at users merging ebuilds using outdates APIs. This often >>> means users start filling bugs about outdated ebuilds requiring >>> maintainers either to ignore that or start updating old ebuilds >>> retroactively. >>> >>> Maybe we should add some kind of devqawarn() function to >>> eutils.eclass, which would trigger special QA warnings only when >>> ebuild is merged by a developer? This could be triggered e.g. by >>> some kind of voluntary make.conf setting. >>> >> >> What's wrong with eqawarn that's already provided by eutils? > > The first paragraph? > Have Portage defaults so that users only see if them if they read the merge logs and then developer profiles can set the settings to log them? Regards, Petteri
Re: [gentoo-dev] RFC: devqawarn()?
On Thu, 01 Sep 2011 13:44:47 +0300 Petteri Räty wrote: > On 1.9.2011 12.03, Michał Górny wrote: > > Hello, > > > > A quick idea. Right now eclasses sometimes do API changes and start > > yelling at users merging ebuilds using outdates APIs. This often > > means users start filling bugs about outdated ebuilds requiring > > maintainers either to ignore that or start updating old ebuilds > > retroactively. > > > > Maybe we should add some kind of devqawarn() function to > > eutils.eclass, which would trigger special QA warnings only when > > ebuild is merged by a developer? This could be triggered e.g. by > > some kind of voluntary make.conf setting. > > > > What's wrong with eqawarn that's already provided by eutils? The first paragraph? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: devqawarn()?
On 1.9.2011 12.03, Michał Górny wrote: > Hello, > > A quick idea. Right now eclasses sometimes do API changes and start > yelling at users merging ebuilds using outdates APIs. This often means > users start filling bugs about outdated ebuilds requiring maintainers > either to ignore that or start updating old ebuilds retroactively. > > Maybe we should add some kind of devqawarn() function to eutils.eclass, > which would trigger special QA warnings only when ebuild is merged by > a developer? This could be triggered e.g. by some kind of voluntary > make.conf setting. > What's wrong with eqawarn that's already provided by eutils? Regards, Petteri
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
On Thu, Sep 1, 2011 at 10:31 AM, Michał Górny wrote: > On Wed, 31 Aug 2011 15:41:51 +0200 > Corentin Chary wrote: > >> - Specific handlers for PyPi, RubyGems, pecl and PEAR packages (check >> http://git.iksaif.net/?p=euscan.git;a=tree;f=pym/euscan/handlers;h=9a995dfcebe6beecce71851abb84a875cf6e5979;hb=HEAD >> ). > > AFAICS that specific handlers are required to grab a list of versions. > Is it or will it be possible to add a kind of semi-handlers which would > just grab a list of all URIs (e.g. on github project) and let euscan > match them with SRC_URI? Yep, it's possible, you can do some specific stuff and import functions from euscan.helpers for euscan.handlers.generic to do a "generic" scan, then return a correct list of version. -- Corentin Chary http://xf.iksaif.net
[gentoo-dev] RFC: devqawarn()?
Hello, A quick idea. Right now eclasses sometimes do API changes and start yelling at users merging ebuilds using outdates APIs. This often means users start filling bugs about outdated ebuilds requiring maintainers either to ignore that or start updating old ebuilds retroactively. Maybe we should add some kind of devqawarn() function to eutils.eclass, which would trigger special QA warnings only when ebuild is merged by a developer? This could be triggered e.g. by some kind of voluntary make.conf setting. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [WTH] bash-completion useflag
On Thu, 1 Sep 2011 00:16:29 +0200 Ulrich Mueller wrote: > > On Wed, 31 Aug 2011, Mike Frysinger wrote: > > > installing the files unconditionally does fall into the > > logrotate/xinetd category, so it should get punted. but people > > should not end up with the depends installed all the time. > > The eclass currently has RDEPEND=app-admin/eselect and > PDEPEND=app-shells/bash-completion. I believe that the former is > not necessary, because eselect will already be pulled in by the > bash-completion package. > > And users who want bash completion can just install > app-shells/bash-completion, so maybe PDEPEND could be removed too? Or maybe it should be added somehow to the bash ebuild? Maybe a conditional there. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
On Wed, 31 Aug 2011 15:41:51 +0200 Corentin Chary wrote: > - Specific handlers for PyPi, RubyGems, pecl and PEAR packages (check > http://git.iksaif.net/?p=euscan.git;a=tree;f=pym/euscan/handlers;h=9a995dfcebe6beecce71851abb84a875cf6e5979;hb=HEAD > ). AFAICS that specific handlers are required to grab a list of versions. Is it or will it be possible to add a kind of semi-handlers which would just grab a list of all URIs (e.g. on github project) and let euscan match them with SRC_URI? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] check-reqs.eclass.patch
Addressed last bunch of suggestions :)
Tom
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/check-reqs.eclass,v 1.8 2011/08/22
04:46:31 vapier Exp $
# @ECLASS: check-reqs.eclass
# @MAINTAINER:
# QA Team
# @AUTHOR:
# Bo Ørsted Andresen
# Original Author: Ciaran McCreesh
# @BLURB: Provides a uniform way of handling ebuild which have very high build
requirements
# @DESCRIPTION:
# This eclass provides a uniform way of handling ebuilds which have very high
# build requirements in terms of memory or disk space. It provides a function
# which should usually be called during pkg_setup().
#
# The chosen action only happens when the system's resources are detected
# correctly and only if they are below the threshold specified by the package.
#
# @CODE
# # need this much memory (does *not* check swap)
# CHECKREQS_MEMORY="256M"
#
# # need this much temporary build space
# CHECKREQS_DISK_BUILD="2G"
#
# # install will need this much space in /usr
# CHECKREQS_DISK_USR="1G"
#
# # install will need this much space in /var
# CHECKREQS_DISK_VAR="1024M"
#
# @CODE
#
# If you don't specify a value for, say, CHECKREQS_MEMORY, then the test is not
# carried out.
#
# These checks should probably mostly work on non-Linux, and they should
# probably degrade gracefully if they don't. Probably.
inherit eutils
# @ECLASS-VARIABLE: CHECKREQS_MEMORY
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much RAM is needed? Eg.: CHECKREQS_MEMORY=15M
# @ECLASS-VARIABLE: CHECKREQS_DISK_BUILD
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much diskspace is needed to build the package? Eg.:
CHECKREQS_DISK_BUILD=2T
# @ECLASS-VARIABLE: CHECKREQS_DISK_USR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space in /usr is needed to install the package? Eg.:
CHECKREQS_DISK_USR=15G
# @ECLASS-VARIABLE: CHECKREQS_DISK_VAR
# @DEFAULT_UNSET
# @DESCRIPTION:
# How much space is needed in /var? Eg.: CHECKREQS_DISK_VAR=3000M
EXPORT_FUNCTIONS pkg_setup
case "${EAPI:-0}" in
0|1|2|3) ;;
4) EXPORT_FUNCTIONS pkg_pretend ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
# @FUNCTION: check_reqs
# @DESCRIPTION:
# Obsolete function executing all the checks and priting out results
check_reqs() {
debug-print-function ${FUNCNAME} "$@"
echo
ewarn "QA: Package calling old ${FUNCNAME} function."
ewarn "QA: Please file a bug against the package."
ewarn "QA: It should call check-reqs_pkg_pretend and
check-reqs_pkg_setup"
ewarn "QA: and possibly use EAPI=4 or later."
echo
check-reqs_pkg_setup "$@"
}
# @FUNCTION: check-reqs_pkg_setup
# @DESCRIPTION:
# Exported function running the resources checks in pkg_setup phase.
# It should be run in both phases to ensure condition changes between
# pkg_pretend and pkg_setup won't affect the build.
check-reqs_pkg_setup() {
debug-print-function ${FUNCNAME} "$@"
check-reqs_prepare
check-reqs_run
check-reqs_output
}
# @FUNCTION: check-reqs_pkg_pretend
# @DESCRIPTION:
# Exported function running the resources checks in pkg_pretend phase.
check-reqs_pkg_pretend() {
debug-print-function ${FUNCNAME} "$@"
check-reqs_pkg_setup "$@"
}
# @FUNCTION: check-reqs_prepare
# @DESCRIPTION:
# Internal function that checks the variables that should be defined.
check-reqs_prepare() {
debug-print-function ${FUNCNAME} "$@"
if [[ -z ${CHECKREQS_MEMORY} &&
-z ${CHECKREQS_DISK_BUILD} &&
-z ${CHECKREQS_DISK_USR} &&
-z ${CHECKREQS_DISK_VAR} ]]; then
eerror "Set some check-reqs eclass variables if you want to use
it."
eerror "If you are user and see this message fill a bug against
the package."
die "${FUNCNAME}: check-reqs eclass called but not actualy
used!"
fi
}
# @FUNCTION: check-reqs_run
# @DESCRIPTION:
# Internal function that runs the check based on variable settings.
check-reqs_run() {
debug-print-function ${FUNCNAME} "$@"
# some people are *censored*
unset CHECKREQS_FAILED
[[ -n ${CHECKREQS_MEMORY} ]] && \
check-reqs_memory \
${CHECKREQS_MEMORY}
[[ -n ${CHECKREQS_DISK_BUILD} ]] && \
check-reqs_disk \
"${T}" \
"${CHECKREQS_DISK_BUILD}"
[[ -n ${CHECKREQS_DISK_USR} ]] && \
check-reqs_disk \
"${EROOT}/usr" \
"${CHECKREQS_DISK_USR}"
[[ -n ${CHECKREQS_DISK_VAR} ]] && \
check-reqs_disk \
"${EROOT}/var" \
"${CHECKREQS_DISK_VAR}"
}
# @FUNCTION: check-reqs_get_megs
# @DESCRIPTION:
# Internal function that returns number in mebibytes.
# Converts from 1G=1024 or 1T=1048576
check-reqs_get_mebibytes() {
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
Dne 1.9.2011 09:55, Corentin Chary napsal(a): Btw I have feature request, could it remember the sorting method i set? (so I don't have to click and reorder it every time i refresh) Per-page or globally ? I would say globaly i smore sane here Tom
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
> Btw I have feature request, could it remember the sorting method i set? > (so I don't have to click and reorder it every time i refresh) Per-page or globally ? -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
Dne 1.9.2011 09:44, Corentin Chary napsal(a): On Thu, Sep 1, 2011 at 9:23 AM, Alex Legler wrote: On Wednesday 31 August 2011 15:41:51 Corentin Chary wrote: Hi, some news about euscan (still available at http://euscan.iksaif.net) - New design (yay !) Glad you like it. Be sure to credit where you got it from, though. Sorry, that was done in the dev version, but I forgot to push it (http://euscan.iksaif.net/about/). Thanks, So now we just need to put this onto gentoo infrastructure and make you dev :P Btw I have feature request, could it remember the sorting method i set? (so I don't have to click and reorder it every time i refresh) Cheers Tom
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
On Thu, Sep 1, 2011 at 9:23 AM, Alex Legler wrote: > On Wednesday 31 August 2011 15:41:51 Corentin Chary wrote: >> Hi, >> >> some news about euscan (still available at http://euscan.iksaif.net) >> >> - New design (yay !) > > Glad you like it. Be sure to credit where you got it from, though. Sorry, that was done in the dev version, but I forgot to push it (http://euscan.iksaif.net/about/). Thanks, -- Corentin Chary http://xf.iksaif.net
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
On Wednesday 31 August 2011 15:41:51 Corentin Chary wrote: > Hi, > > some news about euscan (still available at http://euscan.iksaif.net) > > - New design (yay !) Glad you like it. Be sure to credit where you got it from, though. -- Alex Legler Gentoo Security / Ruby signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About upstreams appending additional CFLAGS when building with some configure options
On 31-08-2011 18:29:35 -0400, Aaron W. Swenson wrote: > You shouldn't let upstream jerk you or our users around, though. If I > want to build my packages with -march=native -mtune=native -pipe -O3 > - -fzomg -freakin-fast -man -fo-sho, then by golly, let me. > > We have a 'custom-cflags' USE flag. The definition of which has been > to allow the CFLAGS the user wants, but if it breaks, that's his or > her problem but not ours -- the Gentoo developers -- nor upstream's. I thought this was more the standard definition. The custom-cflags thing is there for upstreams which *demand* that we use their CFLAGS, and nothing else. Setting USE=custom-cflags there just overrides upstream's flags in that case, which means you can expect upstream to immediately flag any question/bug/complaint as invalid. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
