[gentoo-dev] RFC: Reviving GLEP33
Hi folks, I've been told that my use of eblits in dev-lang/php is something I should get rid of as soon as possible. Suggested alternative by ferring: use elibs. So here goes: I want to see GLEP33[1] implemented in portage, so I can shift the eblits core and currently global functions into elibs and probably push the eblits I use for php into the same structure. Basic question: what needs to be done to get this GLEP accepted and implemented (it's current status is moribound)? I extracted a list of things we (or rather the portage and all other PM teams) need to do: (1) create elibs() function to enable importing elibs (2) extend repoman to handle new style elibs and eclass signing/checking (3) profit ;) Also, there're some question I have: (1) The GLEP (under "The reduced role of Eclasses,[...]") speaks of "Cases where the constant [metadata] requirement is violated are known" - who exactly are the current offenders? (2) What's the dev community feeling on "The end of backwards compatibility..." section in the GLEP? Personal opinion: when the council reached consensus that old eclasses can be removed with due last-rites, this section became obsolete. Just putting new-style eclasses in their own dirs in eclass/ might again be an option. Please discuss. (3) Continuing with (2) do you feel we still need to provide a eclass compat build (tarball) to users *still* not using a sane portage version? If no, section "The start of a different phase of backwards compatibility" can probably be stripped from the GLEP. I silently assumed that our infra servers are running >=portage-2.1.4.4 here. Instead of all the backwards-compatibility issues the GLEP deals with, we could just sneak the implementation into EAPI4 and be done with it. [1] http://www.gentoo.org/proj/en/glep/glep-0033.html signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Reviving GLEP33
On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote: > Hi folks, > > I've been told that my use of eblits in dev-lang/php is something I > should get rid of as soon as possible. Suggested alternative by ferring: > use elibs. > > So here goes: I want to see GLEP33[1] implemented in portage, so I can > shift the eblits core and currently global functions into elibs and > probably push the eblits I use for php into the same structure. > > Basic question: what needs to be done to get this GLEP accepted and > implemented (it's current status is moribound)? > > I extracted a list of things we (or rather the portage and all other PM > teams) need to do: > > (1) create elibs() function to enable importing elibs There's a caveat here; imagine one of the current PM's processing an EAPI=4 (or whatever) ebuild that uses elib- specifically there will be a global scope function invocation of a function that doesn't exist. In the past, a minority of folk have raised complaints about this- it was never stated as best I know, but my assumption looking back is that it was due primarily to paludis getting pissy about ebuilds outputing anything during metadata sourcing (paludis at this point isn't pissy about it- mainly sinc eclasses can invoke die after all). Managers should implementat that functionality; orthogonal to it, we've got a few options for how to deal with an EAPI=4 ebuild being metadata sourced by a <=EAPI3 PM (meaning, there will be a "command not found" spat to stderr during sourcing): 1) if 'elib' isn't defined, define it as a no-op w/in a profile.bashrc. This doesn't work for paludis (they don't do profile bashrc at all), but works for pkgcore/portage- would silence the output in the majority basically. This address gentoo-x86, but cleanly for stand alone repositories. 2) variation of #1, require consuming ebuilds to inherit an eclass that has the fallback no-op in it, rather than profile. This would work for paludis, although again, it's gentoo-x86 specific and would be limited to overlays. All standalone tree's would have to bundle their own eclass w/ the no-op. 3) glep55; note that I'm purely listing out options here, will leave the people pushing that glep to advocate it. 4) I should've thought of this a few years back, but frankly another option is to fix the @!#*ing package managers. They should collect stdout/stderr output during sourcing, but only output it if the metadata sourcing resulted in an EAPI the PM supported. If it's an EAPI the PM doesn't support, it wouldn't know how to write the cache for the ebuild anyways. 5) ignore that their may be output, and get on with our lives and implementing features. From where I'm sitting, #4 should be implemented regardless of what solution is choosen. Personally, I prefer #1, but #2 is easy enough to jam in if people really are bother by a couple of overlays making noise for people running a stale package manager. Either way, this particular naggle needs a decision. > (2) extend repoman to handle new style elibs and eclass signing/checking > (3) profit ;) I'd suggest breaking this up- specifically try to get elibs in, but do not bind their timelines/existance to eclass refactoring. > Also, there're some question I have: > (1) The GLEP (under "The reduced role of Eclasses,[...]") speaks of > "Cases where the constant [metadata] requirement is violated are known" > - who exactly are the current offenders? Talk to vapier- he had some abuses of SLOT rewriting during merging (nasty hack that only works for portage) last time I knew. Php had something similar at the time this glep was written, although that's since been removed. > (2) What's the dev community feeling on "The end of backwards > compatibility..." section in the GLEP? Personal opinion: when the > council reached consensus that old eclasses can be removed with due > last-rites, this section became obsolete. Just putting new-style > eclasses in their own dirs in eclass/ might again be an option. Please > discuss. The env saving part of that section is no longer relevant, and the question of how long to keep eclasses around was addressed in the last council meeting: http://www.gentoo.org/proj/en/council/meeting-logs/20100726-summary.txt Now, if eclasses2 went forward, how long to keep the old eclass directory around is a seperate question. > Instead of all the backwards-compatibility issues the GLEP deals with, > we could just sneak the implementation into EAPI4 and be done with it. Exempting tweaking the inherit mechanism to use a new eclass location, a lot of the env saving bits of that glep are no longer relevant. My suggestion? Split this into two, elibs, and eclass refactoring. ~brian pgpXAFChcB47d.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Reviving GLEP33
On 2 August 2010 12:11, Brian Harring wrote: > On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote: >> Hi folks, >> >> I've been told that my use of eblits in dev-lang/php is something I >> should get rid of as soon as possible. Suggested alternative by ferring: >> use elibs. There's a couple of hundred lines of repeated metadata between php-5.3.2 and php-5.3.3 - not identical, but similar enough that there would be gains from factoring it out, and elibs won't help with that. Am I understanding correctly in that you didn't use an eclass to avoid cluttering up the main eclass directory with something specific to this one package? If so, it sounds like what you really want is per-package eclasses (maybe with elibs as well to hold the non-metadata code), which aren't covered by GLEP33 but ought to be easy enough to add. > There's a caveat here; imagine one of the current PM's processing an > EAPI=4 (or whatever) ebuild that uses elib- specifically there will be > a global scope function invocation of a function that doesn't exist. > > In the past, a minority of folk have raised complaints about this- it > was never stated as best I know, but my assumption looking back is > that it was due primarily to paludis getting pissy about ebuilds > outputing anything during metadata sourcing I can't speak for other people who may have complained, but it seems to me that for ebuilds to be calling non-existent commands is fairly obviously wrong, even if the consequences happen to be benign - not the end of the world, but something that ought to be avoided if possible. (As far as paludis goes, it's more stdout that it used to get upset about than stderr.) > Managers should implementat that functionality; orthogonal to it, > we've got a few options for how to deal with an EAPI=4 ebuild being > metadata sourced by a <=EAPI3 PM (meaning, there will be a "command > not found" spat to stderr during sourcing): > > [...] Regarding the stuff about other standalone repositories, I don't think it's a big deal to require them to carry a small amount of extra stuff (only if they actually start using elibs in any case), considering all the profiles, eclasses etc that they'd need anyway. Overlays based on the main Gentoo tree would be fine without any effort. (For the record, +1 for GLEP55 from me, but the reasons for and against don't need to be repeated yet again.) > My suggestion? Split this into two, elibs, and eclass refactoring. Per-package eclasses would be beneficial IMHO regardless of the other eclass stuff from 33, might be worth thinking about those as another item (consistent with the existing design plans of course) if the rest isn't going to happen soon.
Re: [gentoo-dev] RFC: Reviving GLEP33
On Monday, August 02, 2010 05:56:08 Matti Bickel wrote: > I've been told that my use of eblits in dev-lang/php is something I > should get rid of as soon as possible. current eblits support isnt going anywhere. so dont waste time trying to change code if there is no real alternative. see Bug 327999. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Reviving GLEP33
On Mon, 02 Aug 2010 11:56:08 +0200 Matti Bickel wrote: > I've been told that my use of eblits in dev-lang/php is something I > should get rid of as soon as possible. Suggested alternative by > ferring: use elibs. > > So here goes: I want to see GLEP33[1] implemented in portage, so I can > shift the eblits core and currently global functions into elibs and > probably push the eblits I use for php into the same structure. Aren't you really after per-package eclasses, not elibs? Now that eclasses for installed packages are handled sanely, elibs are just a way to reduce the metadata generation impact of changing a widely used eclass, and processors are getting faster faster than the tree is growing. > Instead of all the backwards-compatibility issues the GLEP deals with, > we could just sneak the implementation into EAPI4 and be done with it. No, you can't make global scope changes just in an EAPI without screwing up user systems. You have to do the whole "wait several years" thing for them. If you don't want to screw things up for users, the only way of avoiding a huge wait for all of this would be to adopt GLEP 55, and of course GLEP 55 won't ever be adopted without years of noise anyway, so this whole discussion is purely academic. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Locale check in python_pkg_setup()
2010-07-31 22:25:26 Petteri Räty napisał(a):
> On 07/31/2010 11:10 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> >>
> >> If the variable is set but not exported then it is local to the shell
> >> env. When bash goes to exec() python the local shell variables are
> >> not in the env; so os.environ() will not contain them.
> >>
> >> anta...@kyoto ~ $ foo=BAR
> >> anta...@kyoto ~ $ echo $foo
> >> BAR
> >> anta...@kyoto ~ $ python -c 'import os; print os.environ.get("foo")'
> >> None
> >> anta...@kyoto ~ $ export foo
> >> anta...@kyoto ~ $ python -c 'import os; print os.environ.get("foo")'
> >> BAR
> >
> > I want only variables exported to Python processes.
> >
>
> export -p
It would have to be parsed using e.g. grep and sed. It's easier to call Python
in this case.
The call to Python is sufficiently fast:
$ time python -c 'import os; print(os.environ.get("LC_ALL",
os.environ.get("LC_CTYPE", os.environ.get("LANG", "POSIX"' > /dev/null
real0m0.062s
user0m0.051s
sys 0m0.011s
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Locale check in python_pkg_setup()
A milder warning will be printed.
--
Arfrever Frehtes Taifersar Arahesis
--- python.eclass
+++ python.eclass
@@ -355,6 +355,8 @@
# Check if phase is pkg_setup().
[[ "${EBUILD_PHASE}" != "setup" ]] && die "${FUNCNAME}() can be used only in pkg_setup() phase"
+ local locale
+
if [[ "$#" -ne 0 ]]; then
die "${FUNCNAME}() does not accept arguments"
fi
@@ -407,6 +409,15 @@
unset -f python_pkg_setup_check_USE_flags
fi
+ if [[ "$(locale charmap)" != "UTF-8" ]]; then
+ locale="$(python -c 'import os; print(os.environ.get("LC_ALL", os.environ.get("LC_CTYPE", os.environ.get("LANG", "POSIX"')"
+ ewarn
+ ewarn "Currently used locale '${locale}' can cause UnicodeDecodeError or UnicodeEncodeError"
+ ewarn "exceptions. It is recommended to use a UTF-8 locale to avoid problems."
+ ewarn "See http://www.gentoo.org/doc/en/utf-8.xml for information on how to change locale."
+ ewarn
+ fi
+
PYTHON_PKG_SETUP_EXECUTED="1"
}
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Locale check in python_pkg_setup()
On Mon, Aug 02, 2010 at 11:02:20PM +0200, Arfrever Frehtes Taifersar Arahesis
wrote:
> It would have to be parsed using e.g. grep and sed. It's easier to call
> Python in this case.
It's even easier not to.
> The call to Python is sufficiently fast:
>
> $ time python -c 'import os; print(os.environ.get("LC_ALL",
> os.environ.get("LC_CTYPE", os.environ.get("LANG", "POSIX"' > /dev/null
>
> real0m0.062s
> user0m0.051s
> sys 0m0.011s
Let's compare. On my system:
time python -c 'import os; print(os.environ.get("LC_ALL",
os.environ.get("LC_CTYPE", os.environ.get("LANG", "POSIX"'
en_GB.UTF-8
real0m0.020s
user0m0.016s
sys 0m0.004s
time sh -c 'echo "${LC_ALL:-${LC_CTYPE:-${LANG:-POSIX}}}"'
en_GB.UTF-8
real0m0.001s
user0m0.000s
sys 0m0.000s
And that's after several runs for both, so it's not caused by the
initial load of python, which wasn't in memory yet.
Yes, 0.019s is very little, but in this case I see absolutely no benefit
whatsoever in calling python. Plus sh has the advantage of actually
working when LC_ALL is exported as "" (which in LC_* means the same as
having it unset)...
But why exactly are you concerned about LC_* being defined but not
exported anyway? You're checking from an ebuild; locales are going to
get inherited from portage or profile.env anyway, so you can just
assume that if they _are_ set, they're exported. The only way they might
not be is if the user is messing with the locale from the bashrc, and if
the user's doing that, the user really needs to fix the bashrc and
export the vars anyway.
None of this changes the fact that locale checks warns about bugs in packages,
not bugs in the user's configuration.
Re: [gentoo-dev] RFC: Reviving GLEP33
On 08/02/2010 08:16 PM, David Leverton wrote: > On 2 August 2010 12:11, Brian Harring wrote: >> On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote: >>> Hi folks, >>> >>> I've been told that my use of eblits in dev-lang/php is something >>> I should get rid of as soon as possible. Suggested alternative by >>> ferring: use elibs. > > There's a couple of hundred lines of repeated metadata between > php-5.3.2 and php-5.3.3 - not identical, but similar enough that > there would be gains from factoring it out, and elibs won't help with > that. Sure. I was thinking of providing php.eclass with the common metadata for php-5*, including patchset code, core DEPEND and the like. With the php team rather stretched nowadays, it will take a few days before that'll happen. I'm still trying to cope with the complexity of the whole php eco-system. > Am I understanding correctly in that you didn't use an eclass to > avoid cluttering up the main eclass directory with something specific > to this one package? Yes. Actually, that was hoffie's goal, when he decided to use eblits. I continued this and actually made php5_2-sapi.eclass obsolete by using eblits in php-5.2.14. Interesting sidenote: I only needed one more eblit for this - the amount of code shared went through the ceiling. > If so, it sounds like what you really want is per-package eclasses > (maybe with elibs as well to hold the non-metadata code), which > aren't covered by GLEP33 but ought to be easy enough to add. It's actually covered by GLEP33: http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring And yes, it's one of it's most obvious advantages. I hate the clutter of php-* eclasses with passion (I'm aware most of them serve a good purpose). >> My suggestion? Split this into two, elibs, and eclass >> refactoring. > > Per-package eclasses would be beneficial IMHO regardless of the > other eclass stuff from 33, might be worth thinking about those as > another item (consistent with the existing design plans of course) if > the rest isn't going to happen soon. If we can get that going asap without waiting, I'm all for it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Locale check in python_pkg_setup()
the env lookup is still way more complicated than it needs to be:
locale=${LC_ALL:-${LC_CTYPE:-${LANG}}}
it is not possible for these variables to be set but not exported unless an
ebuild is doing it, and those are broken anyways.
the message should also reference an open bug report for people to follow so
that this issue is properly fixed. you cant drop warnings like this into
places without a referenced bug # otherwise they can easily become outdated
but no one knows how to easily determine "can this be punted yet".
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Reviving GLEP33
On 08/02/2010 09:51 PM, Mike Frysinger wrote: > On Monday, August 02, 2010 05:56:08 Matti Bickel wrote: >> I've been told that my use of eblits in dev-lang/php is something I >> should get rid of as soon as possible. > > current eblits support isnt going anywhere. so dont waste time trying to > change code if there is no real alternative. see Bug 327999. Yes, from my reading GLEP33 wouldn't solve bug #327999. But that's a different issue, isn't it? I don't see how elibs are not an alternative for eblits. What can you do with eblits you can't do with elibs? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Reviving GLEP33
On 08/02/2010 10:15 PM, Ciaran McCreesh wrote: > Aren't you really after per-package eclasses, not elibs? Yes. I don't care whether the snippets may affect metadata. They already don't (at one time they did, but we got warned that that's illegal - that's why php-5.3 ebuilds have their metadata folded back into them). >> Instead of all the backwards-compatibility issues the GLEP deals with, >> we could just sneak the implementation into EAPI4 and be done with it. > > No, you can't make global scope changes just in an EAPI without > screwing up user systems. You have to do the whole "wait several years" > thing for them. Bad. So I guess it's back to ferring's "use a new directory not readable by old PMs" idea. GLEP55++, but having to wait several months for that and GLEP33 *on top* is not very motivation for me. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Locale check in python_pkg_setup()
On Mon, 2 Aug 2010 23:18:59 +0200 Arfrever Frehtes Taifersar Arahesis wrote: > A milder warning will be printed. I distinctly remember several voices being raised in this thread very recently, suggesting if not demanding that you should not convey a message like that at all, but fix the affected packages instead. jer
Re: [gentoo-dev] RFC: Reviving GLEP33
On Monday, August 02, 2010 17:47:01 Matti Bickel wrote: > On 08/02/2010 09:51 PM, Mike Frysinger wrote: > > On Monday, August 02, 2010 05:56:08 Matti Bickel wrote: > >> I've been told that my use of eblits in dev-lang/php is something I > >> should get rid of as soon as possible. > > > > current eblits support isnt going anywhere. so dont waste time trying to > > change code if there is no real alternative. see Bug 327999. > > Yes, from my reading GLEP33 wouldn't solve bug #327999. But that's a > different issue, isn't it? I don't see how elibs are not an alternative > for eblits. What can you do with eblits you can't do with elibs? i didnt mean to indicate that you shouldnt look at moving forward. progress is a good thing after all. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Locale check in python_pkg_setup()
On Mon, 2 Aug 2010 23:18:59 +0200 Arfrever Frehtes Taifersar Arahesis wrote: > + ewarn "exceptions. It is recommended to use a UTF-8 > locale to avoid problems." > + ewarn "See http://www.gentoo.org/doc/en/utf-8.xml > for information on how to change locale." In fact the documentation you point to positively encourages users/admins to set up locales and explains how to do it system-wide, and in no place does it warn against any adverse effects of doing so. So you can't even point to that documentation in defence of this "milder warning". jer
Re: [gentoo-dev] RFC: Reviving GLEP33
On 2 August 2010 22:40, Matti Bickel wrote: > On 08/02/2010 08:16 PM, David Leverton wrote: >> If so, it sounds like what you really want is per-package eclasses >> (maybe with elibs as well to hold the non-metadata code), which >> aren't covered by GLEP33 but ought to be easy enough to add. > > It's actually covered by GLEP33: > http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring I interpreted that more as a way to organise the global eclasses, but yes, it could be used for per-package stuff too. I'd still prefer to have the eclasses next to the ebuilds they're meant to be used by, but that's just a detail (and as I say, could easily be added to the GLEP if anyone else wants it).
Re: [gentoo-dev] RFC: Reviving GLEP33
On 08/03/2010 12:17 AM, David Leverton wrote:
> On 2 August 2010 22:40, Matti Bickel wrote:
>> On 08/02/2010 08:16 PM, David Leverton wrote:
>>> If so, it sounds like what you really want is per-package eclasses
>>> (maybe with elibs as well to hold the non-metadata code), which
>>> aren't covered by GLEP33 but ought to be easy enough to add.
>>
>> It's actually covered by GLEP33:
>> http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring
>
> I interpreted that more as a way to organise the global eclasses
Yes, I thought you were talking about them. Introducing eclasses into
the rest of the tree - is that possible from the implementation side?
That is, how can PMs support that w/o much hassle? Are there any speed
considerations that need to be taken into account?
I like the idea. Having dev-lang/php/php-common.eclass makes a lot more
sense then putting it into ${PORTDIR}/include/eclass.
PHP will still need global eclasses for PEAR and pecl stuff, so I like
them moving forward, too. And hiding them into
${PORTDIR}/include/eclass/php/ might be a good first step.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Locale check in python_pkg_setup()
On Mon, Aug 02, 2010 at 11:18:59PM +0200, Arfrever Frehtes Taifersar Arahesis wrote: > A milder warning will be printed. Guessing you didn't get the part about "no warning should be put in" that everyone stated? You're ignoring that this message also will make users think that switching their locale will magically fix programs that chuck encoding errors (validly so, if not particularly user friendly) when running into improperly encoded files (regardless of locale). This locale crap doesn't belong in the tree, mild warning or not- do not add it. Take it up to the council if you really think everyone else is wrong and still want it. ~harring pgplJh89Kgb3h.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-3.1.2_p20100801. ebuild python-2.7_p20100801.ebuild python-2.6.5_p20100801.ebuild
> Modified: ChangeLog > Removed: python-3.1.2_p20100801.ebuild > python-2.7_p20100801.ebuild > python-2.6.5_p20100801.ebuild > Log: > remove the backported versions; they're autogenerated, obviously > not tested for 2.6 (bug 330937, breaking portage for anyone runing > unstable python at time of commit), and have been the source of a > shitload of other rather odd bugs till identification of what was > occuring (bug 330667). ignoring a PDEPEND.bad for 3.1.2-r3 for > >=app-admin/python-updater-0.8 also to get these removed > + -python-2.6.5_p20100801.ebuild, -python-2.7_p20100801.ebuild, > + -python-3.1.2_p20100801.ebuild: > + Remove untested versions, one of which flat out breaks emerge (bug > 330937). > + These should not be re-added without going through devrel/qa. Hello fellow developers, There is quite an issue with python here that I want a wider audience to be aware of because it did affect our users. Especially ~arch users that were trying to avoid python-3. The intent of this email is purely FYI. (You can find a fix on the mentioned bug, if you are wondering) -Jeremy
[gentoo-dev] Re: gentoo-x86 commit in mail-filter/mailfilter: ChangeLog mailfilter-0.8.2.ebuild
> EAPI=2
> -
> inherit eutils
>
> DESCRIPTION="Mailfilter is a utility to get rid of unwanted spam mails"
> @@ -19,16 +18,16 @@
> RDEPEND=""
>
> src_prepare() {
> - epatch "${FILESDIR}"/0.8.2-gcc44.patch
> + epatch "${FILESDIR}"/0.8.2-gcc44.patch \
> + "${FILESDIR}"/0.8.2-openssl-1.patch
> }
>
> src_compile() {
> - # bug #281069
> - emake -j1 || die "emake failed"
> + emake -j1 || die #281069
> }
>
> src_install() {
> - emake DESTDIR="${D}" install || die "make install failed"
> + emake DESTDIR="${D}" install || die
> dodoc INSTALL doc/FAQ "${FILESDIR}"/rcfile.example{1,2} \
> - README THANKS ChangeLog AUTHORS NEWS || die "doc failed"
> + README THANKS ChangeLog AUTHORS NEWS || die
> }
Etiquette policy
:
| Respect developers' coding preferences. Unnecessarily changing the
| syntax of an ebuild increases the load on the CVS server and can cause
| complications for others. Syntax changes should only be done if there is
| a real benefit, such as faster compilation, improved information for the
| end user, or compliance to Gentoo policies.
If you are not the maintainer, don't quote any policy compliance in
ChangeLog, I think this is a breach of the etiquette policy.
Thanks
