[gentoo-dev] Re: ARM64 stable keyword
Tom Wijsman posted on Tue, 22 Apr 2014 21:43:24 +0200 as excerpted: > On Tue, 22 Apr 2014 22:13:16 +0400 Mikle Kolyada > wrote: > >> 22.04.2014 21:59, Mike Gilbert пишет: >> >> > Ok, then the stable keyword is going to get lost when I drop old >> > versions. >> >> Vapier can restore stable keywords for newest version if needed, i >> think > > Repeating that is a flashing experience for the minor arches users. > > Stabilizing on minor arches this way feels more like a regression, than > that it is an improvement; the promise for a stable experience can't be > fulfilled like that. Caveat: Subject to Vapier's reply. I can't read minds and could indeed be very wrong in my thinking here... Yes, but... I think stable keywords on such archs must be used differently, and by virtue of necessity, mean something else than they mean on more mainstream archs. Consider, on such archs people aren't going to be able to reliably run a stable keyword system anyway, because there's simply not enough stable keyworded packages to do so. In such a situation, then, what is the value/meaning of a stable keyword at all? I'd suggest it is simply this, as adapted from the traditional mainstream arch meaning for a situation where running all-stable simply isn't possible: A stable keyword on a package for an arch where ~arch must be the norm, can only mean, "Yes, this one has actually been verified to work reasonably well, without serious known regressions." IOW, in a minor arch normally ~arch keyworded environment, a stable keyword, while a system can't require it as a system can on a mainstream arch, can still mean: "This version is more tested on this arch than others, consider trying it first." Additionally, on some packages it /might/ also be a hint: "If you have problems traced to a group of packages with this one being one of them, look at the other packages first, since this one has more testing than the others and thus is less likely to be the problem." With this meaning, on minor archs stable keyworded packages could still come and go, without the "flashing" effect mentioned above, because stable keywords alone cannot be used to build and maintain the system. But stable keywords would still have meaning where they appear, and package maintainers shouldn't mess with them, while (unlike mainstream archs) still being free to drop last-stable versions without issue, exactly /because/ the stable keyword has a someone different meaning in this case. Repeated caveat: This is what I'd take stable keywords to mean on minor non-stable archs with current policies. Subject to Vapier's reply confirming, modifying or saying I'm all wet. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] ARM64 stable keyword
On Tue, 22 Apr 2014 22:13:16 +0400 Mikle Kolyada wrote: > 22.04.2014 21:59, Mike Gilbert пишет: > > > Ok, then the stable keyword is going to get lost when I drop old > > versions. > > Vapier can restore stable keywords for newest version if needed, i > think Repeating that is a flashing experience for the minor arches users. Stabilizing on minor arches this way feels more like a regression, than that it is an improvement; the promise for a stable experience can't be fulfilled like that. Searching for broken packages and/or versions and masking them on the architecture in question could work out better; you spare out time because you only monitor new versions in general, as well as attempt to discover breakage instead of discovering stability. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-dev] Re: LTO use in the tree
> One thing I forgot to mention - LTO can also have detrimental effect on > certain > architectures. On some (eg. ppc), performance can actually be degraded due to > increased register pressure. On others like alpha it's questionable if it'll > even work at all... Worked for me on alpha, at least for what I tried. It cut eix's binary from 2 to 1.3 MB as well.
Re: [gentoo-dev] ARM64 stable keyword
22.04.2014 21:59, Mike Gilbert пишет: > On Tue, Apr 22, 2014 at 2:01 PM, Mikle Kolyada wrote: >> 22.04.2014 21:40, Mike Gilbert пишет: >>> I see that vapier has been adding arm64 as a stable keyword to lots of >>> packages. >>> >>> When I am requesting stabilization for newer versions these packages, >>> is there an arm64 arch team I should copy? If not, these stable >>> keywords are just going to get lost as old ebuilds get dropped. >>> >>> For an example, see my last commit to dev-util/scons. I moved the >>> stable keyword forward from scons-2.2.0 to scons-2.3.0 myself, but I >>> am not sure if this was the right thing to do. >>> >>> >> You should not add this, only vapier and probably armin76 have arm64 >> hardware (hardware?). Mike stabilize for minor arches if needed. (like >> sh/s390/m68k). >> > Ok, then the stable keyword is going to get lost when I drop old versions. > Vapier can restore stable keywords for newest version if needed, i think
Re: [gentoo-dev] ARM64 stable keyword
On Tue, Apr 22, 2014 at 2:01 PM, Mikle Kolyada wrote: > > 22.04.2014 21:40, Mike Gilbert пишет: >> I see that vapier has been adding arm64 as a stable keyword to lots of >> packages. >> >> When I am requesting stabilization for newer versions these packages, >> is there an arm64 arch team I should copy? If not, these stable >> keywords are just going to get lost as old ebuilds get dropped. >> >> For an example, see my last commit to dev-util/scons. I moved the >> stable keyword forward from scons-2.2.0 to scons-2.3.0 myself, but I >> am not sure if this was the right thing to do. >> >> > You should not add this, only vapier and probably armin76 have arm64 > hardware (hardware?). Mike stabilize for minor arches if needed. (like > sh/s390/m68k). > Ok, then the stable keyword is going to get lost when I drop old versions.
Re: [gentoo-dev] ARM64 stable keyword
22.04.2014 21:40, Mike Gilbert пишет: > I see that vapier has been adding arm64 as a stable keyword to lots of > packages. > > When I am requesting stabilization for newer versions these packages, > is there an arm64 arch team I should copy? If not, these stable > keywords are just going to get lost as old ebuilds get dropped. > > For an example, see my last commit to dev-util/scons. I moved the > stable keyword forward from scons-2.2.0 to scons-2.3.0 myself, but I > am not sure if this was the right thing to do. > > You should not add this, only vapier and probably armin76 have arm64 hardware (hardware?). Mike stabilize for minor arches if needed. (like sh/s390/m68k).
[gentoo-dev] ARM64 stable keyword
I see that vapier has been adding arm64 as a stable keyword to lots of packages. When I am requesting stabilization for newer versions these packages, is there an arm64 arch team I should copy? If not, these stable keywords are just going to get lost as old ebuilds get dropped. For an example, see my last commit to dev-util/scons. I moved the stable keyword forward from scons-2.2.0 to scons-2.3.0 myself, but I am not sure if this was the right thing to do.
Re: [gentoo-dev] OpenSP build fails
On Tue, Apr 22, 2014 at 5:38 AM, Nikita Tropin wrote: > Hi, I'm trying to update Gentoo with > I_KNOW_WHAT_I_AM_DOING=1 emerge --deep --update --newuse --with-bdeps=y > @world > > and process fails on OpenSP-1.5.2-r3. I am tried to compile it myself and > find those lacking `new.h' mentioned in build.log. I found in > include/xnew.h ifdef construction that responsible of choosing appropriate > file ( or ), find utility not found any `new.h' on my /usr or > build directory of OpenSP in my home dir, however `new' was found - > /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4/new. Next, I'm > calling configure with > CXXFLAGS="-DSP_ANSI_LIB" ./configure && make > > and was chosen on compilation. However many new errors was occur > (attached mybuild.log and mybuild_stderr.log). And I don't know how to fix > them. > Please try the gentoo-user list (gentoo-u...@lists.gentoo.org) or file a bug at https://bugs.gentoo.org. Thanks, -A > > Also I'm tried to avoid installation of this package by trying to find all > and installed packages that depends on this one, tried to mask it but po4a, > man-db(nls), openjade, virtual/man and man-pages-3.63 depends on OpenSP. > The paradox is that I have installed man-db-2.6.5 with nls USE flag and > update schedule man-db-2.6.6 to install but even if I mask it(2.6.6) there > still error that man-db-2.6.5 need OpenSP. I am totally confused. > > PS I've compiled OpenSP downloaded from offsite ( > http://openjade.sourceforge.net/) > PPS I'm using I_KNOW_WHAT_I_AM_DOING=1 because I have ggdb in CFLAGS in > make.conf but some packages like webkit-gtk probably need 18G for debug > symbols on some system but not in my, so. > > Thanks in advance. > > -- > Regards, > Nikita >
[gentoo-dev] Re: LTO use in the tree
Ryan Hill wrote: > > One thing I forgot to mention - LTO can also have detrimental effect on > certain architectures. On some (eg. ppc), performance can actually > be degraded due to increased register pressure. If this really is the case it is not the problem of LTO but of the optimizer: If the optimizer really produces *worse* code when he *can* see the full program instead of only parts of it, something is severely broken in the optimizer. Only decreasing the possibilities of the optimizer by removing LTO would be the wrong way to "solve" this problem. Of course, this does not touch the validity of your other arguments. On the other hand, if upstream tests and supports LTO, it should be communicated to the user somehow that this is the case. The same dilemma applies to some other CFLAGS which should not be used in general but only if the code is written for them: Is it really a good idea to produce in such cases *by default* code which is less optimal than supported by upstream and the user is not even informed about this change?
