Re: [gentoo-dev] Re: stable gcc 5.4.0 ??
On Thu, Apr 20, 2017 at 05:52:20PM -0500, Matthias Maier wrote > (A-C) gcc-5.4.0 and gcc-4.9.4 are slotted separately. What is going to > be the default is entirely up to you. Good to hear. Like I said, on a fresh install I'd go with the current version (5.4). But for now, I'll wait for other people to experience problems. If nothing major, I might switch at a convenient time. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Re: stable gcc 5.4.0 ??
On Thu, Apr 20, 2017, at 17:17 CDT, "Walter Dnes" wrote: > ...fun !NOT. If you're doing a fresh install, ***WITH A GCC5-BUILT > INSTALL CD AND STAGE 3***, then yes, go for it. But changing horses in > mid-stream can be painfull. Would it hurt to stay with 4.9.4 for the > time being, assuming that you're not using prebuilt stuff like > firefox-bin or libreoffice-bin? What would be the best way to go about > it? The technical discussion how to proceed with the new C++ abi happend two years ago. We decided to do the only sensible thing in switching to the new C++ abi. (And hopefully only see very minor issues in ABI incompatibilities later on.) It unfortunately involves rebuilding parts of your userland. > A) Would 5.4.0 be slotted separately, and 4.9.4 left as the default? > B) Add "-D_GLIBCXX_USE_CXX11_ABI=0" to CFLAGS and CXXFLAGS > C) Mask out ">sys-devel/gcc-4.99" > D) Allow "--with-default-libstdcxx-abi=gcc4-compatible" via a USE flag? (A-C) gcc-5.4.0 and gcc-4.9.4 are slotted separately. What is going to be the default is entirely up to you. If overriding the ABI via (B) is such a great idea is yours to decide. (D) will definitely not happen. > Maybe we should what many enterprises do with Windows; i.e. skip a > version and go straight to gcc-6. No. We already stabilized gcc-5. A future stabilization of gcc-6/7 won't be nearly as painful as this one. There is no reason to skip something. Best, Matthias
Re: [gentoo-dev] Re: stable gcc 5.4.0 ??
Ühel kenal päeval, N, 20.04.2017 kell 18:17, kirjutas Walter Dnes: > On Thu, Apr 20, 2017 at 07:36:03AM +0200, Tomas Mozes wrote > > > > The default is new: > > https://www.gentoo.org/support/news-items/2015-10-22-gcc-5-new-c++1 > > 1-abi.html > > And the news item says... > > > Display-If-Installed: >=sys-devel/gcc-5 > > ...which means that people like me, who currently have 4.9.4, won't > know > about it until after the fact. Then they'd have to... You will still have 4.9.4 until you unmerge it, and will still use 4.9.4 until you gcc-config to gcc5. > GCC 5.4 Status: 2016-06-03 (regression fixes & docs only). > > GCC 6.3 Status: 2016-12-21 (regression fixes & docs only). > > GCC 7.1 Status: 2017-04-20 (frozen, all changes require RM approval). > > Development: GCC 8.0 Status: 2017-04-20 (regression fixes & docs > only). Notice how 4.9 isn't even mentioned there as receiving regression fixes or whatnot anymore. > Maybe we should what many enterprises do with Windows; i.e. skip a > version and go straight to gcc-6. No. Maybe with gcc 5 to 7. Other than that, I am terribly sorry for your inconvenience. But 2014 called and wanted its compiler back :( So we are "bleeding edge" again
Re: [gentoo-dev] Re: stable gcc 5.4.0 ??
On Thu, Apr 20, 2017 at 07:36:03AM +0200, Tomas Mozes wrote > > The default is new: > https://www.gentoo.org/support/news-items/2015-10-22-gcc-5-new-c++11-abi.html And the news item says... > Display-If-Installed: >=sys-devel/gcc-5 ...which means that people like me, who currently have 4.9.4, won't know about it until after the fact. Then they'd have to... [i660][waltdnes][~] emerge -pve @world Total: 529 packages (3 upgrades, 526 reinstalls), Size of downloads: 10,360 KiB ...fun !NOT. If you're doing a fresh install, ***WITH A GCC5-BUILT INSTALL CD AND STAGE 3***, then yes, go for it. But changing horses in mid-stream can be painfull. Would it hurt to stay with 4.9.4 for the time being, assuming that you're not using prebuilt stuff like firefox-bin or libreoffice-bin? What would be the best way to go about it? A) Would 5.4.0 be slotted separately, and 4.9.4 left as the default? B) Add "-D_GLIBCXX_USE_CXX11_ABI=0" to CFLAGS and CXXFLAGS C) Mask out ">sys-devel/gcc-4.99" D) Allow "--with-default-libstdcxx-abi=gcc4-compatible" via a USE flag? Whatever option is selected, people need to be warned about it *NOW*, not after gcc-5.4.0 has been installed. I wonder if it's going to be worth it to go to 5.4. Looking at https://gcc.gnu.org/ today, I see... GCC 5.4 Status: 2016-06-03 (regression fixes & docs only). GCC 6.3 Status: 2016-12-21 (regression fixes & docs only). GCC 7.1 Status: 2017-04-20 (frozen, all changes require RM approval). Development: GCC 8.0 Status: 2017-04-20 (regression fixes & docs only). Maybe we should what many enterprises do with Windows; i.e. skip a version and go straight to gcc-6. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Reverse use of Python/Ruby versions
On Thu, 20 Apr 2017 10:49:04 -0700 Christopher Head wrote: > > >If your writing new python code against say 3.4 and not 3.6. Not sure > >about that... Seems like it would keep things bound to older versions > >and never let things move forward. > > Not true. I will certainly move forward when a newer version becomes > stable. Stable according to whom? Gentoo or Python? Take Ansible as an example. Any contributions must work in both 2.7 and 3.x. While I think they require 2.7. Any modifications must also be good for 3.x. Its forward looking. https://docs.ansible.com/ansible/dev_guide/developing_python3.html > >Usually when writing new code, you use the latest version of stuff. > >Not always but usually best. If anything make code support older > >while targeting newer. > > No, not how I develop. It is how other projects, some rather large like Ansible are addressing the issue. >I always start by determining my target > audience and then develop using a feature set that allows my target > audience to use the code as easily as is practical. I wouldn’t use a > syscall introduced in kernel 4.9 if I could avoid it, even if it made > my code simpler, because most of my colleagues run Ubuntu LTS, they > are part of my target audience, and it wouldn’t be available there. > To me, responsible development practices mean NOT forcing my target > audience to do a manual kernel build. Eventually the syscall will be > “generally available” to my target audience, at which point I may go > back and change the code. Interesting you mention Ubuntu LTS, as that is specifically mentioned on the Ansible python FAQ. > I wouldn’t build conditional branches that do it either way if I > could possibly avoid it, either, because then I would have to do all > the work of doing it the old way plus more, and it would also be more > code which means more maintenance. That is a result of the language of choice. Why I do not bother doing anything myself with Python. I am forced to with Ansible till an alternative in another language comes about. > >Because you are not setting or dealing with the targets. You went > >with the mindless approach. Like doing a wildcard on USE flags. > > Yes, exactly. I don’t want to manually choose what version of Python > I have installed, even though I sometimes do Python development. That addresses 2 of the issues right there. You do not care what version of Python you have. Most any systems administrator does care about what version of things are installed. Not to mention what is installed. Like hardended binary systems, tend to not have gcc, etc. I am doing some python dev for Ansible. But also having to package some python stuff, and do not like it from either user, developer, nor packager perspectives. >Just > like I do a lot of C/C++ development, but I don’t want to manually > choose which version of glibc I have installed. Or libfoo, for some > foo. That’s what a depgraph is for, and if I do need some specific > thing, then I will ask for it, but not before. If you were targeting embedded and working with others like ulibc, etc then you may care. But that is interesting for anyone to be coding not caring about versions etc. I do Java dev mostly and some C. I do very much care about versions of stuff when coding. In C I have to write ifdef, etc for such. In java slotting and making sure using the right version. Only Go language seems to not care about versions, just pulling live from major versioned branches. Most everything else is versioned for a reason. > >Your enabling support for all versions across the board for anything > >that supports it. That is quite a different experience if you go > >trying to use a specific one. > > I’m not trying to invalidate the pain that some people experience, > just pointing out that I think it may be inaccurate to call that the > “ordinary user” use case. That you are on -dev mailing list. Not sure that would put you in the normal use category. Though there are normal users who run ~arch. They would experience such issues. It is different on stable, as I do not believe there is as many. -- William L. Thomson Jr. pgp6yIljSIMxC.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Reverse use of Python/Ruby versions
On April 10, 2017 11:12:10 AM PDT, "William L. Thomson Jr." wrote: >Are you running stable? There are other versions in tree. 3.4, 3.5, >3.6. If you were running unstable, you would have 4 pythons, including >2.7. That you only have 2 seems like you are running stable. Yep. Absolutely. I bring in ~ versions of packages when I have no choice. >If your writing new python code against say 3.4 and not 3.6. Not sure >about that... Seems like it would keep things bound to older versions >and never let things move forward. Not true. I will certainly move forward when a newer version becomes stable. >Usually when writing new code, you use the latest version of stuff. Not >always but usually best. If anything make code support older while >targeting newer. No, not how I develop. I always start by determining my target audience and then develop using a feature set that allows my target audience to use the code as easily as is practical. I wouldn’t use a syscall introduced in kernel 4.9 if I could avoid it, even if it made my code simpler, because most of my colleagues run Ubuntu LTS, they are part of my target audience, and it wouldn’t be available there. To me, responsible development practices mean NOT forcing my target audience to do a manual kernel build. Eventually the syscall will be “generally available” to my target audience, at which point I may go back and change the code. I wouldn’t build conditional branches that do it either way if I could possibly avoid it, either, because then I would have to do all the work of doing it the old way plus more, and it would also be more code which means more maintenance. >> Eventually 3.5 will get >> installed and 3.4 will go away. Just like every other package. I >> won’t need to do any config file editing, just a revdep-rebuild run >> perhaps. So regardless of the situation for maintainers, as a user, I >> don’t see this pain. > >Because you are not setting or dealing with the targets. You went with >the mindless approach. Like doing a wildcard on USE flags. Yes, exactly. I don’t want to manually choose what version of Python I have installed, even though I sometimes do Python development. Just like I do a lot of C/C++ development, but I don’t want to manually choose which version of glibc I have installed. Or libfoo, for some foo. That’s what a depgraph is for, and if I do need some specific thing, then I will ask for it, but not before. >Your enabling support for all versions across the board for anything >that supports it. That is quite a different experience if you go trying >to use a specific one. I’m not trying to invalidate the pain that some people experience, just pointing out that I think it may be inaccurate to call that the “ordinary user” use case. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] News item: changed default bedup configuration file in >=app-backup/burp-2.0.0
On 2017-04-19 17:39, Gokturk Yuksek wrote: >> Display-If-Installed: app-backup/burp > Wouldn't you wanna limit this to <2.0.54 ? Otherwise this will pop > up for the consumers of 2.0.54 as well. Might as well, although at present there is no 2.0.54. >> /etc/burp/burp.conf . > You have an extra '.' at the end. Yes, it's a full stop at the end of the sentence. Come to think of it it looks confusing though, I'll remove it. > I think upstream using the new path is enough justification, do you > really need to justify it any further? It's not like that. Upstream has always used $sysconfdir/burp.conf , by default however that file provides client-mode configuration and bedup refuses to run unless it is pointed to a server-mode config file. Making bedup use $sysconfig/burp-server.conf by default is achieved in burp-1 ebuilds through the means of a Gentoo patch. > Maybe it's better to also provide a one-liner of 'mv' for people who > just want to upgrade to the new path. It is not the matter of the config file having been renamed, burp has always come with both burp.conf and burp-server.conf. > Overall, my impression is that people handle conf file changes in > pkg_postinst() with REPLACING_VERSIONS rather than news items. See above. > How fatal are the consequences of not updating the conf file path? > Would the program abort or misbehave? Abort. Please note however that in a typical production scenario bedup would be run periodically by cron or a similar tool, i.e. without admin intervention, meaning that for everyone who doesn't review their logs carefully backup deduplication would simply quietly stop working. -- MS signature.asc Description: OpenPGP digital signature
