[gentoo-dev] Last rites: sys-kernel/kerneloops
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras (04 Feb 2012) # Dead upstream # Bug #276412. Removal in 30 days sys-kernel/kerneloops - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJPLImyAAoJEPqDWhW0r/LC36MP/R0vq+uEsmtXEgVR41JJIpOK p7dpvw+hkGZfBB+hcbefeq6wfigJ0EsVtEB8Hna2iO509kxIv8PcLIgdQCgPErPQ 2X+HREmGROZtvn+1hX1QC5sYqhjT6bJ+udYkwteNjJNkoMR3YmFQ4bYGcP15Yyky IaeE3JMT0SDloOp2sccyb7DXqF6HhJ4/Naty1WTYx44kV3tXO8m+dP6ZXGw/mhgS Qq9PYddMiwuoVoS6f6KPQX2jlgwy8wrPfPby5JuGMbIsCGdnEwmbC24TuSKIybwS /Ep+09TFWsEHLrNQzgf8sDzX3/a5ltg58XaD9e7P7Yea3qp53W62ozskaMRijGBS E1ofFoxdhkmZZrCjMQLPW2N//Z8fOU4kNk+sWsbwCQ16ci8Xq0q/b4KevQivoF5P ftSLou0fWGv06tzi603lLYFImaZYFhKmUyKn135zKwfaYIgIVOB4qfQzGyJbZEal WMnUctuKZjYIio09okdFFxz5/7Pl4+VVpNpIMo46CTVAC3Sn3B7Loe/nCzGe1LYj MeGlesCSpqBel3hyEzqcRfhBkyt57kAV8ZVRM/zW6olBbGFSH+4npWMEyk+cE2Ga xV2m94pNhUyyHuDndlwIJk6OXtR0cTNdJuJecDbKI8XJpN+UHtHxZvEnK7/8y5LY OtESu8HASa3UA2dR+RnQ =roqE -END PGP SIGNATURE-
[gentoo-dev] Lat rites: app-portage/autounmask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras (04 Feb 2012) # No maintainer. Functionality is now embedded in portage # Bug #398935. Removal in 30 days app-portage/autounmask - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJPLIfDAAoJEPqDWhW0r/LC+bMP/0iXTazbk/DMQW3JLylf259+ t8Agt0AiNwYVKAC1t/edpHz3jHYL4HdDDvb+tFcIlb//WPecIIvXLHJzIK5vmB3+ Ye5k1Eo+3hC5UA8ReuUvnsyFFFWYpw01fvJfqT5ddH9Tg2LgQZ+iOI2vGMsGuVb0 MOT9tolyDBDlBzSgrBAlewB6BrtR1qfhXBffB4bmSfPtRCcsOe2TxTSAx7ep2vxG LT1QWHef8+PV1yU8k8L37qsaG9WGCG8hV1lYG/2XU6O6jH0VqIhX7eM/4vZ3JO0J apeNhLmHoYHQ2DyVGPXH5+j9YM7btZhEYmrhY06PWNCGiwMo+dwIYRxxBU69wzxi lknbPiFMaEGcQ768xwG+QBwxUPDp1aFwUue60mkizINbGcNT2IacLX2KFrdlsKAF 2XYQxi3tmqRhSmvHxb5faU0llYF28I1/LTv5oK4Izs9qzBzvH8SE1gangAOaxqrC RcaY2ia8WOcgBHqjzxx6kqEBaqKYbx/fiXOdxjyQj39P2O+Og6hZfxuHPTEgE3jO zZFISVUO+GLmf2cPK+x//nuoRtiaHlf6FV86EL5rLGdWL3eVVTY601XPJw9LWP42 nGqkvb+GhvMUahLVg3ieEy5QjWosJzssQaNVnEXC/FWasj4ZbTsdZm2lLbp5SYJg Mh/gyc3NYpsOXb6RqNSr =lULz -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: New eclass: mozlinguas.eclass
On Friday, February 03, 2012 10:14:42 PM Nirbheek Chauhan wrote:
> >> if [[ ${x} = en ]] || [[ ${x} = en-US ]]; then
> >
> > should be == imo
>
> Fixed
I prefer == for [[ too, but no difference. = is required for [ by POSIX but
Bash allows either (bad though). The real issue is executing two commands
since [[ can short-circuit and works as you expect. Two are only needed with [
because -a and -o are so unpredictable.
[[ $x == en || $x == en-US ]]
or
case $x in en|en-US) ...;; esac;
or
[[ $x == @(en|en-US) ]]
or
[[ $x == en?(-US) ]]
--
Dan Douglas
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: New eclass: mozlinguas.eclass
On Sat, Feb 4, 2012 at 12:57 AM, Mike Frysinger wrote:
> On Friday 03 February 2012 11:44:42 Nirbheek Chauhan wrote:
> > On Fri, Feb 3, 2012 at 3:26 PM, Mike Frysinger
> wrote:
> > >> mozlinguas() {
> > >
> > > missing eclass documentation
> >
> > Is it really needed for private functions? Nothing should ever call this.
>
> needed ? no. nice ? sure. up to you as the maintainer, but the eclass
> doc
> format does support @INTERNAL on functions so it doesn't get exported to
> the
> man page.
>
Okay, that was my only concern (eclass doc). The function itself is
documented in the second line of the function body. I just moved that up
now.
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: RFC: New eclass: mozlinguas.eclass
On Friday 03 February 2012 11:44:42 Nirbheek Chauhan wrote:
> On Fri, Feb 3, 2012 at 3:26 PM, Mike Frysinger wrote:
> >> mozlinguas() {
> >
> > missing eclass documentation
>
> Is it really needed for private functions? Nothing should ever call this.
needed ? no. nice ? sure. up to you as the maintainer, but the eclass doc
format does support @INTERNAL on functions so it doesn't get exported to the
man page.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: New eclass: mozlinguas.eclass
On Fri, Feb 3, 2012 at 3:26 PM, Mike Frysinger wrote:
> please post it inline to make review easier
>
>> # @MAINTAINER: mozi...@gentoo.org
>> # @AUTHOR: Nirbheek Chauhan
>
> goes on newline, not inlined
>
Fixed
>> # @DESCRIPTION: Array containing the list of language pack xpis available
>
> text starts on the next line, not the existing line
>
Fixed
>> # @ECLASS-VARIABLE: LANGS
>> # @ECLASS-VARIABLE: LANGPACK_PREFIX
>> # @ECLASS-VARIABLE: LANGPACK_SUFFIX
>
> these prob could use MOZ prefixes as well
>
Fixed
>> : ${LANGS:=""}
>
> you say it's an array but then you initialize it to a string ...
>
Meh, no real difference. :p
Changed anyway!
>> if ! [[ ${PV} =~ alpha|beta ]]; then
>> for x in "${LANGS[@]}" ; do
>
> x is a global variable here ... one reason to write this as an internal func
> and then call it so you can use `local`
>
I just added an "unset x" at the end of the chunk, that should be
sufficient I think.
>> if [[ ${x} = en ]] || [[ ${x} = en-US ]]; then
>
> should be == imo
>
Fixed
>> SRC_URI="${SRC_URI}
>
> SRC_URI+="...
>
Fixed
>> IUSE="${IUSE} linguas_${x/-/_}"
>
> IUSE+="...
>
Fixed
>> mozlinguas() {
>
> missing eclass documentation
>
Is it really needed for private functions? Nothing should ever call this.
>> # Generate the list of language packs called "linguas"
>> # This list is used to unpack and install the xpi language packs
>
> shouldn't this initialize linguas=() ?
>
> and shouldn't it name the return value mozlinguas ?
>
Fixed, and renamed the function to mozlinguas_export()
>> # If this language is supported by ${P},
>> elif has ${lingua} "${LANGS[@]//-/_}"; then
>> # Add the language to linguas, if it isn't already
>> there
>> has ${lingua//_/-} "${linguas[@]}" ||
>> linguas+=(${lingua//_/-})
>> continue
>> # For each short lingua that isn't in LANGS,
>> # We used to add *all* long LANGS to the linguas list,
>> # but we stopped doing that due to bug 325195.
>> fi
>
> indentation on these comments seem to be off
>
No, that's on purpose. There used to be an `else` statement there.
That comment doesn't belong to the previous `elif` block. I've added
it outside a blank else block to clarify that.
>> # FIXME: Add support for unpacking xpis to portage
>> xpi_unpack "${MOZ_P}-${x}.xpi"
>
> or, add it to the new unpacker.eclass ;)
>
> also, seems to be missing `use linguas_${x} && xpi_unpack ...` ? otherwise,
> you just unpack all linguas and not just the ones the user has requested ...
> same goes for the install ...
>
No, "${mozlinguas[@]}" is already the intersection of MOZ_LANGS and LINGUAS.
>> if [[ "${linguas[*]}" != "" && "${linguas[*]}" != "en" ]]; then
>> einfo "Selected language packs (first will be default):
>> ${linguas[*]}"
>
> since linguas[*] will be big by default, i'd put the variable expansion into
> its own einfo
It's actually really small by default since it's the list of enabled langpacks.
Fixed version attached, thanks for the review!
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: mozlinguas.eclass
# @MAINTAINER:
# mozi...@gentoo.org
# @AUTHOR:
# Nirbheek Chauhan
# @BLURB: Handle language packs for mozilla products
# @DESCRIPTION:
# Sets IUSE according to MOZ_LANGS (language packs available). Also exports
# src_unpack and src_install for use in ebuilds.
inherit mozextension
case "${EAPI:-0}" in
0|1)
die "EAPI ${EAPI:-0} does not support the '->' SRC_URI
operator";;
2|3|4)
EXPORT_FUNCTIONS src_unpack src_install;;
*)
die "EAPI ${EAPI} is not supported, contact eclass
maintainers";;
esac
# @ECLASS-VARIABLE: MOZ_LANGS
# @DEFAULT-UNSET
# @DESCRIPTION:
# Array containing the list of language pack xpis available for
# this release. The list can be updated with scripts/get_langs.sh from the
# mozilla overlay.
: ${MOZ_LANGS:=()}
# @ECLASS-VARIABLE: MOZ_PV
# @DESCRIPTION:
# Ebuild package version converted to equivalent upstream version.
# Defaults to ${PV}, and should be overridden for alphas, betas, and RCs
: ${MOZ_PV:="${PV}"}
# @ECLASS-VARIABLE: MOZ_PN
# @DESCRIPTION:
# Ebuild package name converted to equivalent upstream name.
# Defaults to ${PN}, and should be overridden for binary ebuilds.
: ${MOZ_PN:="${PN}"}
# @ECLASS-VARIABLE: MOZ_P
# @DESCRIPTION:
# Ebuild package name + version converted to upstream equivalent.
# Defaults to ${MOZ_PN}-${MOZ_PV}
: ${MOZ_P:="${MOZ_PN}-${MOZ_PV}"}
# @ECLASS-VARIABLE: MOZ_FTP_URI
# @DEFAULT-UNSET
# @DESCRIPTION:
# The ftp URI prefix for the release tarballs and language packs.
: ${MOZ_FTP_URI:=""}
# @ECLASS-VARIABLE: MOZ_LANGPACK_PREFIX
[gentoo-dev] Maintainer needed: app-office/libreoffice, app-office/libreoffice-bin, app-office/libreoffice-l10n
Dear all, Right now, noone is taking care of named packages and/or their bugs, after the most active dev left the herd. I've asked on the herd alias some days ago if anyone is willing to step in, however there was no positive reply (and barely a reply at all). For this reason I've assigned app-office/libreoffice app-office/libreoffice-bin app-office/libreoffice-l10n to maintainer-needed, and would like to ask anyone interested and willing to help to step in and revive the openoffice team. Cheers, Andreas [PS. If anyone wonders why I'm taking care of this, the "openoffice" team was about to become the "office" team some time ago, and I'm taking care of koffice / calligra and occasionally other kde-related office apps as kmymoney...] [PPS. However fitting, this only coincides with Chithanh's mail by accident...] -- Andreas K. Huettel Gentoo Linux developer kde, sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: New eclass: mozlinguas.eclass
please post it inline to make review easier
> # @MAINTAINER: mozi...@gentoo.org
> # @AUTHOR: Nirbheek Chauhan
goes on newline, not inlined
> # @DESCRIPTION: Array containing the list of language pack xpis available
text starts on the next line, not the existing line
> # @ECLASS-VARIABLE: LANGS
> # @ECLASS-VARIABLE: LANGPACK_PREFIX
> # @ECLASS-VARIABLE: LANGPACK_SUFFIX
these prob could use MOZ prefixes as well
> : ${LANGS:=""}
you say it's an array but then you initialize it to a string ...
> if ! [[ ${PV} =~ alpha|beta ]]; then
> for x in "${LANGS[@]}" ; do
x is a global variable here ... one reason to write this as an internal func
and then call it so you can use `local`
> if [[ ${x} = en ]] || [[ ${x} = en-US ]]; then
should be == imo
> SRC_URI="${SRC_URI}
SRC_URI+="...
> IUSE="${IUSE} linguas_${x/-/_}"
IUSE+="...
> mozlinguas() {
missing eclass documentation
> # Generate the list of language packs called "linguas"
> # This list is used to unpack and install the xpi language packs
shouldn't this initialize linguas=() ?
and shouldn't it name the return value mozlinguas ?
> # If this language is supported by ${P},
> elif has ${lingua} "${LANGS[@]//-/_}"; then
> # Add the language to linguas, if it isn't already there
> has ${lingua//_/-} "${linguas[@]}" ||
> linguas+=(${lingua//_/-})
> continue
> # For each short lingua that isn't in LANGS,
> # We used to add *all* long LANGS to the linguas list,
> # but we stopped doing that due to bug 325195.
> fi
indentation on these comments seem to be off
> # FIXME: Add support for unpacking xpis to portage
> xpi_unpack "${MOZ_P}-${x}.xpi"
or, add it to the new unpacker.eclass ;)
also, seems to be missing `use linguas_${x} && xpi_unpack ...` ? otherwise,
you just unpack all linguas and not just the ones the user has requested ...
same goes for the install ...
> if [[ "${linguas[*]}" != "" && "${linguas[*]}" != "en" ]]; then
> einfo "Selected language packs (first will be default):
> ${linguas[*]}"
since linguas[*] will be big by default, i'd put the variable expansion into
its own einfo
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages masked for lack of maintainer, but metadata.xml says otherwise
2012/2/2 Chí-Thanh Christopher Nguyễn : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Mike Frysinger schrieb: >> On Thursday 02 February 2012 17:56:16 Chí-Thanh Christopher Nguyễn >> wrote: >>> there have been a number of packages masked lately due to lack >>> of maintainer. However, their metadata.xml does not list >>> maintainer-needed@g.o which I think should be the first step in >>> searching for a new maintainer. >> >> if there is no and no , then >> "maintainer-needed@g.o" is implicit. why do we need to explicitly >> list it ? -mike > > If that is the case, then removing would also be ok. But my point was > that the packages still had other maintainers listed. I want to avoid setting rules in stone. We are not correctly tooled, trained, or have any kind of vigor for that sort of approach. Metadata.xml is a useful guide to knowing who might care (have cared?) about a package. It is not 100% accurate despite the efforts of the developer community. When buggy software is buggy for months (nay, years?) it is treecleaner policy to mask it. Casting about for maintainers is sometimes useful. You see the undertakers do this often when retiring individuals. That being said, the quickest way to get a response from the community is to mask it and wait for someone who cares to step up, ergo the policy to mask packages we cannot find time to fix. For reference, the list of developers who are listed as active but have not committed anything in gentoo-x86 'recently' is around 95. I am set to eventually retire 33 of them (still getting some bugs out of the scripts.) The entire list is (active) + (inactive) or (162) + (95). Obviously not everyone in the inactive list is really inactive (the limit afaik is 30d) but the point is that even if the metadata.xml lists someone there is a 1 in 3 chance that they may not be following closely anyway. Developers on devaway are a similar issue (https://bugs.gentoo.org/show_bug.cgi?id=338829) -A > > > Best regards, > Chí-Thanh Christopher Nguyễn > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.17 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk8rNAsACgkQ+gvH2voEPRDbvACeKmIgmkscKmm4C4MbHMko90Bf > 2+cAmwdjHK5IPzUF7ZDH4QvSSqRiZytE > =rfFY > -END PGP SIGNATURE- >
Re: [gentoo-dev] Packages masked for lack of maintainer, but metadata.xml says otherwise
On 02/03/2012 03:10 AM, Chí-Thanh Christopher Nguyễn wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger schrieb: On Thursday 02 February 2012 17:56:16 Chí-Thanh Christopher Nguyễn wrote: there have been a number of packages masked lately due to lack of maintainer. However, their metadata.xml does not list maintainer-needed@g.o which I think should be the first step in searching for a new maintainer. if there is no and no, then "maintainer-needed@g.o" is implicit. why do we need to explicitly list it ? -mike If that is the case, then removing would also be ok. But my point was that the packages still had other maintainers listed. In hylafax's case, the package has been broken since the addition of tiff-4.0.0_beta5, which got added to tree "12 May 2010" Both tiff and hylafax are with nerdboy as maintainer. At this point I've looked at the commitrate of said maintainer With version bump request open from year ago Now that tiff-4 is going stable, the breakage enters stable tree. In the lastrite mail, I've sent the mail also directly to the maintainer, CCing him. I've never got any reply, and the bugs don't have any comment from the marked maintainer Personally I hope someone who can also test the runtime, would commit hylafax+ instead of fixing hylafax to tree (bug 168890). Or both. So it was really 2+2=4 which lead to this, all the things combined, case-by-case review, and I'm not sure the situation can even be reflected by the metadata.xml. Except the maintainer could have removed himself from it, when he realized he doesn't have enough time or intrest for it Overall I think the lastrites had the desired effect of causing enough buzz around it for other people to notice/get intrest to it
Re: [gentoo-dev] Re: RFC: New eclass: mozlinguas.eclass
Le jeudi 02 février 2012 à 01:44 +0530, Nirbheek Chauhan a écrit :
> ECLASS-VARIABLE: FTP_URI
> # @DEFAULT-UNSET
> # @DESCRIPTION: The ftp URI prefix for the release tarballs and
> language packs.
> : ${FTP_URI:=""}
It might be a good idea to prefix this "generic" variable by MOZ_ as
well.
--
Gilles Dartiguelongue
Gentoo
signature.asc
Description: This is a digitally signed message part
