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
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 a...@gentoo.org Gentoo Security / Ruby signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
On Thu, Sep 1, 2011 at 9:23 AM, Alex Legler a...@gentoo.org 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)
Dne 1.9.2011 09:44, Corentin Chary napsal(a): On Thu, Sep 1, 2011 at 9:23 AM, Alex Leglera...@gentoo.org 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)
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: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] [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 q...@gentoo.org
# @AUTHOR:
# Bo Ørsted Andresen z...@gentoo.org
# Original Author: Ciaran McCreesh ciar...@gentoo.org
# @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)
On Wed, 31 Aug 2011 15:41:51 +0200 Corentin Chary corentin.ch...@gmail.com 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] [WTH] bash-completion useflag
On Thu, 1 Sep 2011 00:16:29 +0200 Ulrich Mueller u...@gentoo.org 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
[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] Re: euscan proof of concept (like debian's uscan)
On Thu, Sep 1, 2011 at 10:31 AM, Michał Górny mgo...@gentoo.org wrote: On Wed, 31 Aug 2011 15:41:51 +0200 Corentin Chary corentin.ch...@gmail.com 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
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] RFC: devqawarn()?
On Thu, 01 Sep 2011 13:44:47 +0300 Petteri Räty betelge...@gentoo.org 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 13.51, Michał Górny wrote: On Thu, 01 Sep 2011 13:44:47 +0300 Petteri Räty betelge...@gentoo.org 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 14:02:11 +0300 Petteri Räty betelge...@gentoo.org wrote: On 1.9.2011 13.51, Michał Górny wrote: On Thu, 01 Sep 2011 13:44:47 +0300 Petteri Räty betelge...@gentoo.org 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 14.31, Michał Górny wrote: On Thu, 01 Sep 2011 14:02:11 +0300 Petteri Räty betelge...@gentoo.org wrote: On 1.9.2011 13.51, Michał Górny wrote: On Thu, 01 Sep 2011 13:44:47 +0300 Petteri Räty betelge...@gentoo.org 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] Re: euscan proof of concept (like debian's uscan)
2011/9/1 Tomáš Chvátal scarab...@gentoo.org: 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
[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] 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
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
On Thu, 01 Sep 2011 14:56:42 +0200 Tomáš Chvátal scarab...@gentoo.org 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
Dne 1.9.2011 15:15, Michał Górny napsal(a): On Thu, 01 Sep 2011 14:56:42 +0200 Tomáš Chvátalscarab...@gentoo.org 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
[gentoo-dev] Last rites for app-accessibility/speakup-utils
# Jesus Rivero neurog...@gentoo.org (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
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
Re: [gentoo-dev] Rewriting bash-completion.eclass
On Thu, 1 Sep 2011 15:27:12 +0200 Ulrich Mueller u...@gentoo.org 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] 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 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] Re: euscan proof of concept (like debian's uscan)
On Wed, Aug 31, 2011 at 3:41 PM, Corentin Chary corentin.ch...@gmail.com 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 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] 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] 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 Thu, 01 Sep 2011 08:25:14 -0700
Zac Medico zmed...@gentoo.org 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()?
-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 zmed...@gentoo.org
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-
[gentoo-portage-dev] [PATCH 0/3] thin manifest support
This patch series adds thin manifest support. While mini-manifest feature exists in funtoo, that functionality is a global toggle- either all are mini, or none. This series makes thin controllable per repository via layout.conf; if the file exists and has 'thin-manifest = true' in it, the manifest rules switch to thin- *just* for that repository. This should allow git vcs overlays to use thin, while the mainline rsync repo continues to use full manifest2. Finally, some of the api work here is kind of ugly. I went for consistancy with the surrounding code; that said, refactoring of the RepoConfig api's likely would be beneficial (that's outside the scope of my intent however). Brian Harring (3): Bind all manifest access through repoconfigs add thin manifest support to the Manifest class add layout.conf awareness of thin-manifests bin/ebuild|5 +- bin/repoman |8 +- pym/_emerge/EbuildFetcher.py |6 +- pym/_emerge/search.py |4 +- pym/portage/dbapi/porttree.py |8 +- pym/portage/manifest.py | 149 ++-- pym/portage/package/ebuild/digestcheck.py |6 +- pym/portage/package/ebuild/digestgen.py |3 +- pym/portage/package/ebuild/doebuild.py|4 +- pym/portage/package/ebuild/fetch.py |3 +- pym/portage/repository/config.py | 14 +++- 11 files changed, 142 insertions(+), 68 deletions(-) -- 1.7.6.1
[gentoo-portage-dev] [PATCH 2/3] add thin manifest support to the Manifest class
'thin' is just distfiles. This is primarily useful when the ebuild
lives in a vcs- git for example, which already has it's own checksums
to rely on.
---
pym/portage/manifest.py | 149 ++--
pym/portage/package/ebuild/digestcheck.py |2 +-
2 files changed, 97 insertions(+), 54 deletions(-)
diff --git a/pym/portage/manifest.py b/pym/portage/manifest.py
index 13efab7..ef1a552 100644
--- a/pym/portage/manifest.py
+++ b/pym/portage/manifest.py
@@ -49,6 +49,12 @@ def guessManifestFileType(filename):
else:
return DIST
+def guessThinManifestFileType(filename):
+ type = guessManifestFileType(filename)
+ if type != DIST:
+ return None
+ return DIST
+
def parseManifest2(mysplit):
myentry = None
if len(mysplit) 4 and mysplit[0] in
portage.const.MANIFEST2_IDENTIFIERS:
@@ -93,12 +99,14 @@ class Manifest2Entry(ManifestEntry):
class Manifest(object):
parsers = (parseManifest2,)
def __init__(self, pkgdir, distdir, fetchlist_dict=None,
- manifest1_compat=False, from_scratch=False):
+ manifest1_compat=False, from_scratch=False, thin=False):
create new Manifest instance for package in pkgdir
and add compability entries for old portage versions if
manifest1_compat == True.
Do not parse Manifest file if from_scratch == True (only
for internal use)
The fetchlist_dict parameter is required only for
generation of
- a Manifest (not needed for parsing and checking
sums).
+ a Manifest (not needed for parsing and checking sums).
+ If thin is specified, then the manifest carries only
info for
+ distfiles.
self.pkgdir = _unicode_decode(pkgdir).rstrip(os.sep) + os.sep
self.fhashdict = {}
self.hashes = set()
@@ -120,7 +128,11 @@ class Manifest(object):
else:
self.fetchlist_dict = {}
self.distdir = distdir
- self.guessType = guessManifestFileType
+ self.thin = thin
+ if thin:
+ self.guessType = guessThinManifestFileType
+ else:
+ self.guessType = guessManifestFileType
def getFullname(self):
Returns the absolute path to the Manifest file for this
instance
@@ -313,64 +325,20 @@ class Manifest(object):
distfilehashes = {}
self.__init__(self.pkgdir, self.distdir,
fetchlist_dict=self.fetchlist_dict, from_scratch=True,
- manifest1_compat=False)
- cpvlist = []
+ manifest1_compat=False, thin=self.thin)
pn = os.path.basename(self.pkgdir.rstrip(os.path.sep))
cat = self._pkgdir_category()
pkgdir = self.pkgdir
+ if self.thin:
+ cpvlist = self._update_thin_pkgdir(cat, pn, pkgdir)
+ else:
+ cpvlist = self._update_thick_pkgdir(cat, pn, pkgdir)
- for pkgdir, pkgdir_dirs, pkgdir_files in os.walk(pkgdir):
- break
- for f in pkgdir_files:
- try:
- f = _unicode_decode(f,
- encoding=_encodings['fs'],
errors='strict')
- except UnicodeDecodeError:
- continue
- if f[:1] == .:
- continue
- pf = None
- if f[-7:] == '.ebuild':
- pf = f[:-7]
- if pf is not None:
- mytype = EBUILD
- ps = portage.versions._pkgsplit(pf)
- cpv = %s/%s % (cat, pf)
- if not ps:
- raise PortagePackageException(
- _(Invalid package name: '%s')
% cpv)
- if ps[0] != pn:
- raise PortagePackageException(
- _(Package name does not
- match directory name: '%s') %
cpv)
- cpvlist.append(cpv)
- elif manifest2MiscfileFilter(f):
- mytype = MISC
- else:
- continue
- self.fhashdict[mytype][f] =
perform_multiple_checksums(self.pkgdir+f, self.hashes)
- recursive_files = []
-
- pkgdir = self.pkgdir
- cut_len
[gentoo-portage-dev] [PATCH 1/3] Bind all manifest access through repoconfigs
This enables controling the behaviour (creation and validation) per repo, and while mildly ugly, refactors in the right direction. --- bin/ebuild|5 +++-- bin/repoman |8 ++-- pym/_emerge/EbuildFetcher.py |6 -- pym/_emerge/search.py |4 +++- pym/portage/dbapi/porttree.py |8 ++-- pym/portage/package/ebuild/digestcheck.py |4 +++- pym/portage/package/ebuild/digestgen.py |3 ++- pym/portage/package/ebuild/doebuild.py|4 +++- pym/portage/package/ebuild/fetch.py |3 ++- pym/portage/repository/config.py |7 ++- 10 files changed, 38 insertions(+), 14 deletions(-) diff --git a/bin/ebuild b/bin/ebuild index db7e5e3..92105bb 100755 --- a/bin/ebuild +++ b/bin/ebuild @@ -200,8 +200,9 @@ def discard_digests(myebuild, mysettings, mydbapi): portage._doebuild_manifest_exempt_depend += 1 pkgdir = os.path.dirname(myebuild) fetchlist_dict = portage.FetchlistDict(pkgdir, mysettings, mydbapi) - from portage.manifest import Manifest - mf = Manifest(pkgdir, mysettings[DISTDIR], + mf = mysettings.repositories.get_repo_for_location( + os.path.dirname(os.path.dirname(pkgdir))) + mf = mf.load_manifest(pkgdir, mysettings[DISTDIR], fetchlist_dict=fetchlist_dict, manifest1_compat=False) mf.create(requiredDistfiles=None, assumeDistHashesSometimes=True, assumeDistHashesAlways=True) diff --git a/bin/repoman b/bin/repoman index 6ec84e5..5f81a0f 100755 --- a/bin/repoman +++ b/bin/repoman @@ -1104,7 +1104,9 @@ for x in scanlist: portage._doebuild_manifest_exempt_depend += 1 try: distdir = repoman_settings['DISTDIR'] - mf = portage.manifest.Manifest(checkdir, distdir, + mf = repoman_settings.repositories.get_repo_for_location( + os.path.dirname(os.path.dirname(checkdir))) + mf = mf.load_manifest(checkdir, distdir, fetchlist_dict=fetchlist_dict) mf.create(requiredDistfiles=None, assumeDistHashesAlways=True) @@ -1314,7 +1316,9 @@ for x in scanlist: raise continue - mf = Manifest(checkdir, repoman_settings[DISTDIR]) + mf = repoman_settings.repositories.get_repo_for_location( + os.path.dirname(os.path.dirname(checkdir))) + mf = mf.load_manifest(checkdir, repoman_settings[DISTDIR]) mydigests=mf.getTypeDigests(DIST) fetchlist_dict = portage.FetchlistDict(checkdir, repoman_settings, portdb) diff --git a/pym/_emerge/EbuildFetcher.py b/pym/_emerge/EbuildFetcher.py index feb68d0..4389f84 100644 --- a/pym/_emerge/EbuildFetcher.py +++ b/pym/_emerge/EbuildFetcher.py @@ -206,8 +206,10 @@ class EbuildFetcher(SpawnProcess): def _get_digests(self): if self._digests is not None: return self._digests - self._digests = portage.Manifest(os.path.dirname( - self._get_ebuild_path()), None).getTypeDigests(DIST) + pkgdir = os.path.dirname(self._get_ebuild_path()) + mf = self.pkg.root_config.settings.repositories.get_repo_for_location( + os.path.dirname(os.path.dirname(pkgdir))) + self._digests = mf.load_manifest(pkgdir, None).getTypeDigests(DIST) return self._digests def _get_uri_map(self): diff --git a/pym/_emerge/search.py b/pym/_emerge/search.py index 096b384..4a4183d 100644 --- a/pym/_emerge/search.py +++ b/pym/_emerge/search.py @@ -317,7 +317,9 @@ class search(object): installed=False, metadata=metadata, root_config=self.root_config, type_name=ebuild) pkgdir = os.path.dirname(myebuild) - mf = Manifest( + mf = self.settings.repositories.get_repo_for_location( + os.path.dirname(os.path.dirname(pkgdir))) + mf = mf.load_manifest( pkgdir, self.settings[DISTDIR]) try: uri_map = _parse_uri_map(mycpv, metadata, diff --git a/pym/portage/dbapi/porttree.py b/pym/portage/dbapi/porttree.py index
