[gentoo-dev] Last rites for x11-base/x11-drm
Hi everybody, Late last week I masked x11-base/x11-drm, it will be removed in 30 days. The corresponding bug report is #284598. As the comments in the bug state, the freedesktop git repo for drm is abandoned and active development now takes place in a kernel repository. Users should switch to using in-kernel DRM modules if they have not already done so. -- Bryan D. Stine (battousai) X11, Hardened battou...@gentoo.org signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites for net-misc/asterisk-app_rtxfax
# Mounir Lamouri (21 Sep 2009) # net-misc/asterisk-app_rtxfax fails with >=media-libs/spandsp-0.0.3, bug 180318 # Masked for removal in 30 days. net-misc/asterisk-app_rtxfax
Re: [gentoo-dev] Last rites for net-misc/asterisk-chan_bluetooth
Christian Bricart wrote: > Mounir Lamouri schrieb: > >> # Mounir Lamouri (30 Jul 2009) >> # Masked for removal in 60 days. >> # Upstream's unactive since 2005. Do not support asterisk versions in tree. >> # bug 279383 >> net-misc/asterisk-chan_bluetoot > may be replaced by (unpackaged) "chan_mobile"? > > --> http://www.chan-mobile.org/ > > Christian > Actually, chan_mobile should be available via asterisk-addons-1.6*. (sorry for the delay) -- Mounir
[gentoo-dev] Last rites for net-misc/asterisk-chan_unicall, media-libs/libsupertone, net-libs/libmfcr2 and net-libs/libunicall
# Mounir Lamouri (20 Sep 2009) # media-libs/libsupertone fails with >=media-libs/spandsp-0.0.5, bug 273995 # net-misc/asterisk-chan_unicall needs media-libs/libsupertone # net-libs/libmfcr2 needs libsupertone and only needed by asterisk-chan_unicall # net-libs/libunicall is only needed by libmfcr2 and asterisk-chan_unicall # net-libs/libunicall has also QA issues, bug 277783 # Masked for removal in 30 days. net-misc/asterisk-chan_unicall media-libs/libsupertone net-libs/libmfcr2 net-libs/libunicall
Re: [gentoo-dev] Re: perl-module.class review
On Mon, Sep 21, 2009 at 11:55 AM, Torsten Veller wrote: > if s/EXPF/TEST_EXPF/ in test.eclass, it does: > > * another_test_src_configure > * another_test_src_compile > * test_pkg_postinst Although I don't anticipate xfconf and cmake being used together, we changed xfconf.eclass. ;) Thanks for your time to test there. sed -i -e 's/EXPF/XFCONF_EXPF/g' xfconf.eclass -Jeremy
[gentoo-dev] Re: perl-module.class review
* Maciej Mrozowski :
> How about unsetting variables after use in first place so that they no longer
> pollute global env.
It's probably too late as it is used in functions like
cmake-utils_src_compile:
| has src_configure ${EXPF} || cmake-utils_src_configure
[gentoo-dev] Re: perl-module.class review
* Tomáš Chvátal :
> Dne pondělí 21 Září 2009 18:03:56 Torsten Veller napsal(a):
> > * Tomáš Chvátal :
> > > I think it is not required
> > > EXPF="src_compile src_test src_install" <- definition, also nulls
> > > anything what was in it before :]
> > > case ${EAPI:-0} in
> > > 2) EXPF="${EXPF} src_configure" ;;
> > > 1|0) ;;
> > > *) die "Unknown EAPI, Bug eclass maintainers." ;;
> > > esac
> > > EXPORT_FUNCTIONS ${EXPF} <- export
> >
> > And later in cmake-utils_src_compile you use:
> > | has src_configure ${EXPF} || cmake-utils_src_configure
> >
> > What will happen if an EAPI=2 ebuild inherits cmake-utils and another
> > eclass also using EXPF that does not EXPORT_FUNCTIONS src_configure and
> > the ebuild uses cmake-utils_src_compile?
> >
> > It will call cmake-utils_src_configure during src_configure and later in
> > cmake-utils_src_compile it will run cmake-utils_src_configure again,
> > won't it?
> >
> You dont do this magic before inherits, so you are safe, if you inherit in
> middle of your eclass code, then you probably deserve the breakage for
> writting such horrible thing ;]
I'am trying to give an example:
,- test.eclass
EXPF=pkg_postinst
EXPORT_FUNCTIONS ${EXPF}
test_pkg_postinst() {
einfo test_pkg_postinst
}
'- test.eclass
,- another_test.eclass
EXPF="src_configure src_compile"
EXPORT_FUNCTIONS ${EXPF}
another_test_src_configure() {
einfo another_test_src_configure
}
another_test_src_compile() {
einfo another_test_src_compile
has src_configure ${EXPF} || another_test_src_configure
}
'- another_test.eclass
,- test.ebuild
EAPI=2
inherit another_test test
DESCRIPTION=""
HOMEPAGE=""
SRC_URI=""
LICENSE=""
SLOT="0"
KEYWORDS="~amd64"
IUSE=""
'- test.ebuild
It outputs:
* another_test_src_configure
* another_test_src_compile
* another_test_src_configure
* test_pkg_postinst
if s/EXPF/TEST_EXPF/ in test.eclass, it does:
* another_test_src_configure
* another_test_src_compile
* test_pkg_postinst
Re: [gentoo-dev] horde and friends
On Mon, 21 Sep 2009 18:32:33 +0200, Benny Pedersen wrote: > On man 21 sep 2009 18:18:58 CEST, Alex Legler wrote > > Have you seen horde-webmail and horde-groupware? They include horde > > + several apps. > > last time i checked horde webmail would depend on horde installed > www-apps/horde-webmail is not Horde IMP. > what i suggest is horde uses use="imp" if you like to have horde > webmail This is not going to happen. Horde itself is an application framework. emerge horde-imp if you want webmail. > but this is unrelated to my php c-client problem that are shown on > some emails it cant display in horde, and related to this i would > like to know if its a known by other gentoo users that uses horde, or > not just claws :) > > php 5.2.10 will atleast reguire me to install c-client 2006k not > older, i have tryed 2007e also both does not fix the problem i have :/ > File a bug. signature.asc Description: PGP signature
Re: [gentoo-dev] horde and friends
On man 21 sep 2009 18:18:58 CEST, Alex Legler wrote Have you seen horde-webmail and horde-groupware? They include horde + several apps. last time i checked horde webmail would depend on horde installed what i suggest is horde uses use="imp" if you like to have horde webmail but this is unrelated to my php c-client problem that are shown on some emails it cant display in horde, and related to this i would like to know if its a known by other gentoo users that uses horde, or not just claws :) php 5.2.10 will atleast reguire me to install c-client 2006k not older, i have tryed 2007e also both does not fix the problem i have :/ -- xpoint
Re: [gentoo-dev] Re: perl-module.class review
On Monday 21 of September 2009 17:38:53 Tomáš Chvátal wrote:
> I think it is not required
> EXPF="src_compile src_test src_install" <- definition, also nulls anything
> what was in it before :]
> case ${EAPI:-0} in
> 2) EXPF="${EXPF} src_configure" ;;
> 1|0) ;;
> *) die "Unknown EAPI, Bug eclass maintainers." ;;
> esac
> EXPORT_FUNCTIONS ${EXPF} <- export
How about unsetting variables after use in first place so that they no longer
pollute global env.
--
regards
MM
--
Rudi Schuberth odkrywa kulisy swojego odchudzania. Ile schudnie?
Sprawdz >>> http://link.interia.pl/f236a
Re: [gentoo-dev] horde and friends
On Mon, 21 Sep 2009 18:06:51 +0200, Benny Pedersen wrote: > [...] > problem as i see it, is that we have multiple horde ebuilds, but it > would make more sense to have one horde ebuild with more use flags ? > Have you seen horde-webmail and horde-groupware? They include horde + several apps. Alex signature.asc Description: PGP signature
Re: [gentoo-dev] Re: perl-module.class review
Dne pondělí 21 Září 2009 18:03:56 Torsten Veller napsal(a):
> * Tomáš Chvátal :
> > I think it is not required
> > EXPF="src_compile src_test src_install" <- definition, also nulls
> > anything what was in it before :]
> > case ${EAPI:-0} in
> > 2) EXPF="${EXPF} src_configure" ;;
> > 1|0) ;;
> > *) die "Unknown EAPI, Bug eclass maintainers." ;;
> > esac
> > EXPORT_FUNCTIONS ${EXPF} <- export
>
> And later in cmake-utils_src_compile you use:
> | has src_configure ${EXPF} || cmake-utils_src_configure
>
> What will happen if an EAPI=2 ebuild inherits cmake-utils and another
> eclass also using EXPF that does not EXPORT_FUNCTIONS src_configure and
> the ebuild uses cmake-utils_src_compile?
>
> It will call cmake-utils_src_configure during src_configure and later in
> cmake-utils_src_compile it will run cmake-utils_src_configure again,
> won't it?
>
You dont do this magic before inherits, so you are safe, if you inherit in
middle of your eclass code, then you probably deserve the breakage for
writting such horrible thing ;]
A - inherit B
EXPF - value from B
A - define our own export_functions
EXPF - value from A
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] horde and friends
Hi gentoo fellows i started using horde with paid consulting and found some troubles in php and c-client that trigger on some mails not being displayed at all in imp :/ what i would like (a dream ?) is to have horde more stablelized in gentoo and not just it works for me, so you are wroung :/ problem as i see it, is that we have multiple horde ebuilds, but it would make more sense to have one horde ebuild with more use flags ? imho this is more simple and covers more the problem to solve what and how and where things get installed let me know if you dont agree and why squirrelmail and roundcube does not use c-client lib so thay have not this problem just in horde -- xpoint
[gentoo-dev] Re: perl-module.class review
* Tomáš Chvátal :
> I think it is not required
> EXPF="src_compile src_test src_install" <- definition, also nulls anything
> what was in it before :]
> case ${EAPI:-0} in
> 2) EXPF="${EXPF} src_configure" ;;
> 1|0) ;;
> *) die "Unknown EAPI, Bug eclass maintainers." ;;
> esac
> EXPORT_FUNCTIONS ${EXPF} <- export
And later in cmake-utils_src_compile you use:
| has src_configure ${EXPF} || cmake-utils_src_configure
What will happen if an EAPI=2 ebuild inherits cmake-utils and another eclass
also using EXPF that does not EXPORT_FUNCTIONS src_configure and the
ebuild uses cmake-utils_src_compile?
It will call cmake-utils_src_configure during src_configure and later in
cmake-utils_src_compile it will run cmake-utils_src_configure again,
won't it?
Re: [gentoo-dev] Re: perl-module.class review
Dne pondělí 21 Září 2009 17:29:26 Torsten Veller napsal(a):
> * Ciaran McCreesh :
> > Torsten Veller wrote:
> > > +EXPORTED_FUNCTIONS="src_unpack src_compile src_test src_install"
> >
> > You're probably not the only one using this trick, so it might be wise
> > to use PERL_EXPORTED_FUNCTIONS or somesuch to avoid name collisions
> > with other eclasses.
>
> git and x-modular use EXPORTED_FUNCTIONS and
> cmake and xfconf use EXPF.
>
> | eclass/git.eclass:EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
> | eclass/x-modular.eclass:EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
> |
> | eclass/cmake-utils.eclass:EXPORT_FUNCTIONS ${EXPF}
> | eclass/xfconf.eclass:EXPORT_FUNCTIONS ${EXPF}
>
> I'll use PERL_EXPORTED_FUNCTIONS in the perl eclass.
>
> Thanks :)
>
I think it is not required
EXPF="src_compile src_test src_install" <- definition, also nulls anything
what was in it before :]
case ${EAPI:-0} in
2) EXPF="${EXPF} src_configure" ;;
1|0) ;;
*) die "Unknown EAPI, Bug eclass maintainers." ;;
esac
EXPORT_FUNCTIONS ${EXPF} <- export
i used expf cause it was shorter
and in git eclass i was too lazy for adjusting for the shorter name :]
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: perl-module.class review
* Ciaran McCreesh :
> Torsten Veller wrote:
> > +EXPORTED_FUNCTIONS="src_unpack src_compile src_test src_install"
>
> You're probably not the only one using this trick, so it might be wise
> to use PERL_EXPORTED_FUNCTIONS or somesuch to avoid name collisions
> with other eclasses.
git and x-modular use EXPORTED_FUNCTIONS and
cmake and xfconf use EXPF.
| eclass/git.eclass:EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
| eclass/x-modular.eclass:EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
|
| eclass/cmake-utils.eclass:EXPORT_FUNCTIONS ${EXPF}
| eclass/xfconf.eclass:EXPORT_FUNCTIONS ${EXPF}
I'll use PERL_EXPORTED_FUNCTIONS in the perl eclass.
Thanks :)
Re: [gentoo-dev] perl-module.class review
On Sun, 20 Sep 2009 20:28:54 +0200 Torsten Veller wrote: > +EXPORTED_FUNCTIONS="src_unpack src_compile src_test src_install" You're probably not the only one using this trick, so it might be wise to use PERL_EXPORTED_FUNCTIONS or somesuch to avoid name collisions with other eclasses. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-pda/multisync
Hello, app-pda/multisync has been masked for removal in 30 days No net-wireless/bluez-4 support -- bug #279384 (blocking stabilization) Lots of build failures -- #269757 #233007 #203959 #202905 pda herd is uninterested in maintaining this Upstream abandoned package 3 years ago[1], replacement is libopensync + multisync-gui Thanks 1. http://multisync.sourceforge.net/news.php -- ~Nirbheek Chauhan GNOME+Mozilla Team, Gentoo
[gentoo-dev] Re: EAPI and system packages
On Sun, 20 Sep 2009 13:55:55 +0400 Alexey Shvetsov wrote: > On Воскресенье 20 сентября 2009 11:47:30 Rémi Cardona wrote: > > Le 20/09/2009 02:31, Ryan Hill a écrit : > > > If not, when can > > > we drop support for old EAPIs? Your opinions please. > > > > Let's drop it now. We've waited long enough. Portage with EAPI=2 has > > been stable for more than a year. > > > > Rémi > > > Yes its good idea to drop EAPI<2 from tree, but we should provide a way to > upgrade for people that don't upgrades recently. So we can: > 1 create a portage snapshot > 2 write mini how to about upgrade > 3 then drop EAPI=0 and EAPI=1 from tree to simplify tree We're talking about system packages, not the whole tree. There are 19951 ebuilds that don't declare EAPI and 1705 with EAPI=1 or EAPI="1". Even with a policy that all new ebuilds need to be EAPI 2, converting the entire tree would be several years of work IMO, at which point we'll be at EAPI zillion+1. -- fonts, Character is what you are in the dark. gcc-porting, wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
