[gentoo-dev] Re: [Bug 483274] app-text/poppler-0.22.5 Please stabilize
On 17/09/2013 15:58, Duncan wrote: Note that it wasn't JUST punctuation/capitalization that changed in the given example, but the version number, 1.2.3 = 1.7.3, as well. Is that still a trivial change? Altho I'm not sure whether kensington changed the version number in his example deliberately, or if that was just a typo, but never-the-less, as posted, the version number changed too, and at least to me, that's not the trivial change that just ordering/category-adds/punctuation/caps changes are. Sorry, that was a mistake on my part. The version number did not actually change.
Re: [gentoo-dev] [PATCH] multilib eclass support for building binaries for none-default ABI
Alexis Ballier schrieb: just to be clear: I prefer the 1st patch but I would give the variable (COMPLETE_MULTILIB) a more private name and document this is only for multilib-portage and it will not work with regular portage. Since you only argued against such implementation in general, but did not write any reasoning behind your choice, not much i could get out of this. I have been doing the second choice now, as written in my answer to Ian. For your variable request: I left it this way, since it is intended for end users, who use regular portage. In addition, it is a cleaner solution for multilib-portage, since i dont have to internally overwrite an eclass function, but that is just a side effect, since this issue never blocked multilib-portage. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] multilib eclass support for building binaries for none-default ABI
Ian Stakenvicius schrieb: On 25/08/13 10:15 AM, Ulrich Mueller wrote: On Sun, 25 Aug 2013, Thomas Sachau wrote: workaround: add a variable, which changes the return of the function checking for the current ABI (always true with variable, without only true, when $ABI == $DEFAULT_ABI) Would this variable be set by the user, in profiles, or in ebuilds? first version (multilib1.patch) directly changes the output of the currently used multilib_is_native_abi() function: I think this would be very misleading. If a function is called multilib_is_native_abi then it should test for exactly that, not for something else. - From the discussion on this that we had ~2 weeks ago, it seems that 'multilib_is_native_abi' is only used in the wild now (and only meant to be used) to handle the cases where we want to say, build everything for default_abi and only build certain bits for the others. If there was a common usage that is important for the actual native abi (for instance, some sort of check enabling alternate code in a build system for a specific CHOST or whatnot), then keeping multilib_is_native_abi as it is would make a lot of sense, but since there isn't any cases of this I'm not sure it matters -- changing it's functionality to essentially become multilib_is_default_abi() (whether we rename it or not) seems to make the most sense to me. While there may currently only be one usecase for the function, it may be used in other cases too with time and wider usage of the new multilib eclasses. If i modify the function for the binaries part, this would require a new function for other usecases. If this really does not happen, the multilib_is_native_abi function could still be deprecated and removed in the future. So i decided to go with a new function. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] multilib eclass support for building binaries for none-default ABI
Thomas Sachau schrieb:
Ulrich Mueller schrieb:
On Sun, 25 Aug 2013, Thomas Sachau wrote:
workaround: add a variable, which changes the return of the function
checking for the current ABI (always true with variable, without
only true, when $ABI == $DEFAULT_ABI)
Would this variable be set by the user, in profiles, or in ebuilds?
This variable can be set by users and profiles, when they want binaries
for a different ABI (e.g. 64bit toolchain with 32bit userland).
first version (multilib1.patch) directly changes the output of the
currently used multilib_is_native_abi() function:
I think this would be very misleading. If a function is called
multilib_is_native_abi then it should test for exactly that, not for
something else.
second version (multilib2.patch) creates a new function, which
should then be used by ebuild authors to check, if they should build
ABI-specific content or not (using build_binaries() function instead
of multilib_is_native_abi() function)
+build_binaries() {
Name space pollution? Prefix with multilib please.
i dont really care about the naming, so if you prefer some multilib in
there, how about this:
multilib_build_binaries()?
+if [[ ${COMPLETE_MULTILIB} == yes ]] ; then
+return 0
+else
+multilib_is_native_abi
+fi
This can be expressed much shorter (and clearer):
[[ ${COMPLETE_MULTILIB} == yes ]] || multilib_is_native_abi
Thanks for the suggestion, this has now been added with my above
suggested name and your suggested shorter version.
I will give ebuild maintainers some days to adapt their ebuilds and will
likely start opening bugs against ebuilds next week. Anyone, who wants
to delegate that work to me, just tell me and i will modify your ebuilds
to use the new function.
--
Thomas Sachau
Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Minor arches (was: Call for agenda items - Council meeting 2013-09-10)
On Sun, 15 Sep 2013, Rich Freeman wrote: I didn't really get any response to this one way or another. At the last council meeting a majority of the votes were in favor of delaying taking action, so this is back on the agenda. I have yet to see either of the following on this list: 1. Specific examples of bugs where a minor arch is making a maintainer's life difficult. Please post if you have them. 2. Members of these arch teams posting here committing to either stabilize new versions or unkeyword old versions in a timely manner. The responses to either of these (or lack thereof) are likely to influence my vote at the meeting. Note, I'm not interested in mere comments that people want an arch to stay stable supported (which I've seen plenty of). I'm interested in COMMITMENT to be stable-supportable (which I've seen none of). The lack of the latter is what is going to cause a package to be dropped - I'd love to see every arch that exists stable-supported on Gentoo, along with world peace. This is a volunteer distro - in general you get the features you pitch in to help deliver, and if you're depending on a minor arch you REALLY need to step up as there aren't many of you out there. That said, I would like specific examples of cases where dropping a minor arch would have helped - the onus is on those wanting the status quo changed to present a case. [Crossposting to -dev. Replies should go to -project if possible.] Again, no reply. I suspect the outcome of today's vote will be that stable keywords for the architectures in question (alpha, ia64, m68k, s390, sh, sparc) should be dropped. Arch teams, last chance to speak up. Ulrich
Re: [gentoo-dev] [PATCH] multilib eclass support for building binaries for none-default ABI
On Tue, 17 Sep 2013 14:38:08 +0200 Thomas Sachau to...@gentoo.org wrote: Alexis Ballier schrieb: just to be clear: I prefer the 1st patch but I would give the variable (COMPLETE_MULTILIB) a more private name and document this is only for multilib-portage and it will not work with regular portage. Since you only argued against such implementation in general, but did not write any reasoning behind your choice, not much i could get out of this. you simply ignored it... http://article.gmane.org/gmane.linux.gentoo.devel/87862 I have been doing the second choice now, as written in my answer to Ian. For your variable request: I left it this way, since it is intended for end users, who use regular portage. it's certainly not intended that way in its current state; maybe you believe it is or want to make it that way but the truth is that if regular users set this variable with regular portage they end up with broken deps and packages failing to build... In addition, it is a cleaner solution for multilib-portage, since i dont have to internally overwrite an eclass function, but that is just a side effect, since this issue never blocked multilib-portage. I understood this, hence the request for a more private name in order not to make your work harder...
[gentoo-dev] Re: [gentoo-project] Minor arches (was: Call for agenda items - Council meeting 2013-09-10)
On Tue, Sep 17, 2013 at 6:04 AM, Ulrich Mueller u...@gentoo.org wrote: On Sun, 15 Sep 2013, Rich Freeman wrote: I didn't really get any response to this one way or another. At the last council meeting a majority of the votes were in favor of delaying taking action, so this is back on the agenda. I have yet to see either of the following on this list: 1. Specific examples of bugs where a minor arch is making a maintainer's life difficult. Please post if you have them. 2. Members of these arch teams posting here committing to either stabilize new versions or unkeyword old versions in a timely manner. The responses to either of these (or lack thereof) are likely to influence my vote at the meeting. Note, I'm not interested in mere comments that people want an arch to stay stable supported (which I've seen plenty of). I'm interested in COMMITMENT to be stable-supportable (which I've seen none of). The lack of the latter is what is going to cause a package to be dropped - I'd love to see every arch that exists stable-supported on Gentoo, along with world peace. This is a volunteer distro - in general you get the features you pitch in to help deliver, and if you're depending on a minor arch you REALLY need to step up as there aren't many of you out there. That said, I would like specific examples of cases where dropping a minor arch would have helped - the onus is on those wanting the status quo changed to present a case. [Crossposting to -dev. Replies should go to -project if possible.] Again, no reply. I suspect the outcome of today's vote will be that stable keywords for the architectures in question (alpha, ia64, m68k, s390, sh, sparc) should be dropped. Arch teams, last chance to speak up. Ulrich I've already spoken up as have others. I'm an alpha maintainer and I'm against this. jmorgan is a sparc maintainer and he's against it. I don't care about the others, and frankly understand the frustration with long stable requests, but leave alpha out of it.
[gentoo-dev] Introducing python-exec:2 (and the migration plan)
Hello, all. I have committed today the eclass support code for python-exec:2, and first package.mask-ed version of it. The benefits of the new solution were explained in the earlier RFC mail [1]. Now for the migration plan. The eclasses cleanly support either version of the wrapper. They use := dep and a has_version check to use the latest slot installed. That is, you won't get the new behavior until you install python-exec:2. Afterwards, the packages should cleanly switch on next rebuild. We're planning on keeping python-exec:2 in package.mask for a while for testing, then unleash it to the ~arch population. When tested well enough, we will stabilize it and start deprecating the old wrapper. For most of our users, this process should be seamless and pain-free. However, we know of some ebuilds that are going to be broken with the new wrapper since they rely too much on wrapping mechanism [2]. Since many of those can't really be fixed much better, those ebuilds will be 'locked' at a single version of the wrapper. If you know that a package does not work with python-exec:2, the following snippet needs to be added to it: DEPEND=dev-python/python-exec:0 _PYTHON_WANT_PYTHON_EXEC2=0 This will ensure keeping the old wrapper around and override the has_version check to force using the old wrapper. If you know that your package works only with python-exec:2, use the following snippet instead: DEPEND=dev-python/python-exec:2 No override is necessary here, since install of new wrapper will cause the eclass to automatically switch to it. But please note that your package's visibility/keywords will need to follow python-exec:2. All testing will be appreciated. Enjoy. [1]:http://thread.gmane.org/gmane.linux.gentoo.devel/88095 [2]:https://bugs.gentoo.org/show_bug.cgi?id=484398 -- Best regards, Michał Górny signature.asc Description: PGP signature
