Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On Thu, Jan 19, 2012 at 10:33 PM, Duncan 1i5t5.dun...@cox.net wrote: Zac Medico posted on Thu, 19 Jan 2012 16:39:12 -0800 as excerpted: Maybe it would be enough to add a suggestion about --exclude in the --newuse section of the emerge man page? I don't think this is confusing enough to qualify for an interactive suggestion. However, it could be argued that the various boilerplate handholding we're already doing has set the precedent. I think the manpage is the right place to fix it. Users would find out about -N from the manpage or from following -dev. Fixing it in that place seems appropriate. Right now I think experienced users are more likely to be using it. I'd still like to see our handbook include a recommended workflow for keeping gentoo up-to-date. Perhaps that should include a few options with the pros/cons of each. I'd think that emerge -auDNv world would be one of those options. Perhaps another might be including build deps. One advantage of having people running a uniform update command that tends to keep everything up to date (even if not strictly necessary), is that it would cut down on the diversity of our install base. Right now a stable user could be running various versions of various libraries based on when they first merged them and whether they use -D, and so on. Keeping everybody moving along to newer versions (and more freshly compiled ones) could help to cut down on the bugs. Bugs filed with older versions still in portage would still be legitimate, but unless somebody really needs the older version there is no sense making more work for ourselves. Perhaps this is worth its own thread, as this one is already drifting way off topic. Rich
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glib
Rich Freeman posted on Fri, 20 Jan 2012 07:49:07 -0500 as excerpted: I'd still like to see our handbook include a recommended workflow for keeping gentoo up-to-date. Perhaps that should include a few options with the pros/cons of each. Agreed. I'd think that emerge -auDNv world would be one of those options. Perhaps another might be including build deps. One advantage of having people running a uniform update command that tends to keep everything up to date (even if not strictly necessary), is that it would cut down on the diversity of our install base. Right now a stable user could be running various versions of various libraries based on when they first merged them and whether they use -D, and so on. Keeping everybody moving along to newer versions (and more freshly compiled ones) could help to cut down on the bugs. Bugs filed with older versions still in portage would still be legitimate, but unless somebody really needs the older version there is no sense making more work for ourselves. From what I've gathered in various list discussions, etc, people running ~arch tend to like to run --deep (-D) as well. That would definitely include me. They're doing both for much the same reasons -- they like to be as upto date as possible. --newuse is in practice an extreme variant on the same theme, people who know what they're doing choose it when they want to stay as upto date as possible. Many stable users prefer /not/ to use --deep, again, for much the same reason they're using stable; they like the flexibility of gentoo, but much prefer something that just works with as little hassle and churn as possible, to chasing after the latest shiny version. Avoiding deep dependency updates is preferable for them, and they rely on gentoo masking and minimum dependencies on what they do update to keep things working. Of course, they'll want to stay even farther away from --newuse than from --deep, tho they might use it very occasionally as a troubleshooting tool for a specific package only, almost certainly with --pretend first, and they may not continue past that. This second group is never going to like --deep and will stay even further away from --newuse, but having a clear explanation of the alternatives and the groups they apply to in the handbook, much like I hope the above was, groupwise (I didn't explain the functionality), would be quite helpful indeed, helping to ensure users pick the best option for their needs. Not everybody reads the handbook for anything but the initial install, but that too is a handholding thing. As long as gentoo provides it, users get to do what they want, and if they choose not to read the handbook and end up with a broken system or in this case more likely just an extremely deoptimized for their needs gentoo updating workflow, well, they have the handbook available to read if they want; it's then their problem. (FWIW, I had read the handbook thru several times and was already helping people with problems on the list based on what I'd read, even before I had gentoo installed myself due to an issue with the then (2004) quite new NPTL. I never did get 2004.0 to install properly, but whether it was due to my experience with .0 or that there was a fix in 2004.1, /that/ installed properly, and I've been gentooing every since! =:^) I never could quite figure out the folks who were making it harder for themselves by not scouring that handbook to make the best use of their gentoo system possible, but they're certainly out there! Meanwhile, I'm still proud of the fact that I was able to help, for instance, people who lost their fstab due to not being careful with etc-update (fstab was handled like any other config file back then; if you selected replace with the new version, that's exactly what happened!), because I'd read the after all quite clear warnings on the subject, well before I got anywhere close to needing that info myself, and they obviously hadn't.) Perhaps this is worth its own thread, as this one is already drifting way off topic. =:^) -- 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] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On Fri, 20 Jan 2012 07:49:07 -0500 Rich Freeman ri...@gentoo.org wrote: On Thu, Jan 19, 2012 at 10:33 PM, Duncan 1i5t5.dun...@cox.net wrote: Zac Medico posted on Thu, 19 Jan 2012 16:39:12 -0800 as excerpted: Maybe it would be enough to add a suggestion about --exclude in the --newuse section of the emerge man page? I don't think this is confusing enough to qualify for an interactive suggestion. However, it could be argued that the various boilerplate handholding we're already doing has set the precedent. I think the manpage is the right place to fix it. Users would find out about -N from the manpage or from following -dev. Fixing it in that place seems appropriate. Right now I think experienced users are more likely to be using it. I'd still like to see our handbook include a recommended workflow for keeping gentoo up-to-date. Perhaps that should include a few options with the pros/cons of each. I'd think that emerge -auDNv world would be one of those options. Perhaps another might be including build deps. One advantage of having people running a uniform update command that tends to keep everything up to date (even if not strictly necessary), is that it would cut down on the diversity of our install base. Right now a stable user could be running various versions of various libraries based on when they first merged them and whether they use -D, and so on. Keeping everybody moving along to newer versions (and more freshly compiled ones) could help to cut down on the bugs. Bugs filed with older versions still in portage would still be legitimate, but unless somebody really needs the older version there is no sense making more work for ourselves. Perhaps this is worth its own thread, as this one is already drifting way off topic. Rich I'm sure there is already such a thread on *-dev and the only sane thing would be to introduce an option along the line of emerge --update world which condenses all best practice options into a single one and which can change over time together with the best practices. Though this doesn't change the fact that messing with stable ebuilds is dangerous and clearly labelled a don't do in the dev-manual even so it is sometimes unavoidable.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On Thu, Jan 19, 2012 at 12:37 AM, Duncan 1i5t5.dun...@cox.net wrote: Mike Frysinger posted on Wed, 18 Jan 2012 22:00:52 -0500 as excerpted: On Wednesday 18 January 2012 21:42:14 Michael Weber wrote: Um, what happend to the policy to not f*** around with stable ebuilds? take a chill pill phil I see a violation of this rule at least on [glibc-]2.13-r4, which leads to useless rebuilds on `emerge -avuND world` on every single gentoo install world-wide. i don't have too much compassion for -N. if people really care enough about it, they'd read the ChangeLog and see that it is meaningless. Considering glibc was just one of some 200-ish packages I rebuilt early today due to -N, most of the rest being kde-4.7.97 (aka 4.8-rc2) which will be in-overlay for just a few more days as 4.8-release is due next week, because gentoo/kde just removed the long-masked kdeenablefinal USE flag, which because it was masked (and I didn't unmask it) did NOT affect my kde as installed so I basically did the rebuild for nothing... Paragraphs like these are why I have such a hard time reading your entire emails. :P
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On 19 January 2012 09:22, Zac Medico zmed...@gentoo.org wrote: On 01/19/2012 05:56 AM, Rich Freeman wrote: On Thu, Jan 19, 2012 at 12:37 AM, Duncan1i5t5.dun...@cox.net wrote: Mike Frysinger posted on Wed, 18 Jan 2012 22:00:52 -0500 as excerpted: On Wednesday 18 January 2012 21:42:14 Michael Weber wrote: Um, what happend to the policy to not f*** around with stable ebuilds? I think there is a legitimate issue with changing dependencies on stable ebuilds. If for whatever reason a mistake is made, you just broke tons of stable systems - especially if people rebuild with -N. The idea is that stuff goes through testing before it hits stable, which is why we call it stable. If you change stable directly, then it isn't stable. :) Care certainly needs to be taken. However, for things like eclass changes, there may be no choice but to modify the metadata of all eclass consumers (regardless of stable keywords). I see a violation of this rule at least on [glibc-]2.13-r4, which leads to useless rebuilds on `emerge -avuND world` on every single gentoo install world-wide. i don't have too much compassion for -N. if people really care enough about it, they'd read the ChangeLog and see that it is meaningless. Until somebody posts a definitive list of which features we have compassion on, and which ones we don't, we should have compassion on anybody using standard portage features. It seems like when things go wrong with somebody's box the knee-jerk reaction is to say well, you should be running daily emerge -alphabetsoup world where alphabetsoup tends to vary by individual preference. I do recall some talk a few months ago about how it might not hurt to come up with a best-practices suggestion for doing regular upgrades, but it hasn't happened yet. I'm pretty sure -N was one of the items that was tossed around as a best practice. The fact is, the user is not being forced to rebuild anything. They can simply run full system updates with --newuse less often if it puts too much strain on them. It holds back progress for everyone if developers have to try to avoid making changes that trigger --newuse rebuilds. I'm more concerned about the tendency to introduce flags in our package manager, have them get promoted in various forums, and then have people more-or-less rebuked for using them. There is no problem in having flags that shouldn't be routinely used, but man pages and such should clearly indicate when this is the case (as is the case with --unmerge and so on). If we don't warn people not to use a flag, we shouldn't punish them when they do. It's only perceived as punishment to a person who is compelled to run a full system update with --newuse, but is unhappy with the number of packages it will cause to be rebuilt. As said, they can run updates less often if it's too much strain. I'd like to chime in here. I started a thread on gentoo-user (Portage option --changed-use not working?) pretty much about this. I use --changed-use instead of --newuse to get the advantages of a fully up-to-date system without the unnecessary churn. From the man page I understand that (part of) the idea behind --changed-use is to *not* rebuild packages where an unused/disabled USE flag is dropped. Which ought to apply to kdeenablefinal, right? It seems my understanding is incorrect because I see --new-use + --exclude is being recommended, not --changed-use. Would somebody please set me straight?
[gentoo-dev] Upcoming changes in boost python bindings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi all,
You all know that boost builds certain python bindings. Right now, boost
installs only one version of each boost python library, however
packages linking to these libraries may compile against a different
python version than the one used to build the boost python bindings.
The ebuild and patches created by Arfrever for Progress Overlay
[1][2][3][4] fix this problem by including the ${PYTHON_ABI} string in
each boost python library filename. The following packages need
modifications on their build system to link against the correct boost
library.
dev-python/cgkitpyt...@gentoo.org
dev-python/pycuda sp...@gentoo.org
dev-python/pyopencl pyt...@gentoo.org, sp...@gentoo.org
dev-python/pythonmagick pyt...@gentoo.org
dev-python/tagpysbrie...@gentoo.org
dev-python/visual pyt...@gentoo.org
media-video/mirovolk...@gentoo.org
net-libs/rb_libtorrent net-...@gentoo.org, q...@gentoo.org,
hwoar...@gentoo.org
net-mail/libpst forens...@gentoo.org
sci-chemistry/avogadro sci-chemis...@gentoo.org
sci-electronics/kicad sci-electron...@gentoo.org
sci-geosciences/mapnik sci-geoscien...@gentoo.org, nerd...@gentoo.org
sci-libs/cctbx sci-chemis...@gentoo.org, j...@gentoo.org
sci-physics/camfr sci-phys...@gentoo.org
sci-visualization/hippodraw s...@gentoo.org
sys-apps/paludisdag...@gentoo.org
The approach we will follow is to revbump all of these packages. The
current
version will depend on boost-1.48 whereas the new revisions will
depend on
=boost-1.48. The patches in the build systems are trivial. The new
boost and
the new revisions of the said packages will remain masked for further
testing. The migration period will start this weekend.
[1]
http://code.google.com/p/gentoo-progress/source/browse/overlays/progress/dev-libs/boost/boost-1.48.0-r1.ebuild
[2]
http://code.google.com/p/gentoo-progress/source/browse/overlays/progress/dev-libs/boost/files/boost-1.48.0-disable_libboost_python3.patch
[3]
http://code.google.com/p/gentoo-progress/source/browse/overlays/progress/dev-libs/boost/files/boost-1.48.0-respect_python-buildid.patch
[4]
http://code.google.com/p/gentoo-progress/source/browse/overlays/progress/dev-libs/boost/files/boost-1.48.0-support_dots_in_python-buildid.patch
- --
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAEBCgAGBQJPGb5cAAoJEPqDWhW0r/LCMpgP/0bLsxFxCKFbYoE5B3BYPeqi
i3zCZEet0mBKHcpGZPSIs1jA1TQxVKS9JwNbcEdGKsN5Y4/xtsgWL5GXmIHw/A6n
fOQBfBw9vst00i7qd5GY+q44QD6P1ndwUPrSJWVwUrzDbz3aLMFqt9FoVkNhIL6i
39vsGjdgqRsNnTcbe+k4lLh2C5I/xEXQS0nB3XMKntcSqxg7giUL45zGV0M5hMs/
4Xot30Z9GNA0ELswwMfZcAOUN4oAHyYZq9ub/i27C3DEUZgPe4u0j6cQMvqyz5cy
+gNOK4hqQqkJ8lV5oyKJ1X2XUF4qfN0U1jCrEc8g3w/p71nU0tbaaDhbWjfkjli1
5zweNG6+jK6Bmey96w2hkhmuaQUXQNpFOmHkFKebZ9rPI6k4hnoSWHatmupxh/mW
yXQJJ+j1kU7zUrgI0a2rzh+Fb3gcNhsaXZKN06v3fhXbvFifjmCZb2jH214XVBAJ
MQ9AJFV1ork10MH9AZqnEYfNmsCPapJG0xRWGafnWNYmbDKnlD2cS7qM/gEWFy63
w4REhwdIJJNJkuRya3UvjkXrKI6DCYtf4qlz6KQWcXJLDxnsRYzwluhDuaZcwAY+
CCsfFWhzkqC5AcwiO4dHhzS01XsOHIhcAIqiDsqdbM0pBV4gfm+xXJNj+1Rr7flg
o2SxyXmzJJiVY8heFvYU
=JgbU
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On 01/20/2012 10:28 AM, Hilco Wijbenga wrote: I'd like to chime in here. I started a thread on gentoo-user (Portage option --changed-use not working?) pretty much about this. I use --changed-use instead of --newuse to get the advantages of a fully up-to-date system without the unnecessary churn. From the man page I understand that (part of) the idea behind --changed-use is to *not* rebuild packages where an unused/disabled USE flag is dropped. Which ought to apply to kdeenablefinal, right? It seems my understanding is incorrect because I see --new-use + --exclude is being recommended, not --changed-use. Would somebody please set me straight? You've found a bug. It's fixed in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a77292d37e3c2604479514abed2dda64dabace25 As a workaround, you can add --binpkg-respect-use=n to your options. -- Thanks, Zac
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On 20 January 2012 12:31, Zac Medico zmed...@gentoo.org wrote: On 01/20/2012 10:28 AM, Hilco Wijbenga wrote: I'd like to chime in here. I started a thread on gentoo-user (Portage option --changed-use not working?) pretty much about this. I use --changed-use instead of --newuse to get the advantages of a fully up-to-date system without the unnecessary churn. From the man page I understand that (part of) the idea behind --changed-use is to *not* rebuild packages where an unused/disabled USE flag is dropped. Which ought to apply to kdeenablefinal, right? It seems my understanding is incorrect because I see --new-use + --exclude is being recommended, not --changed-use. Would somebody please set me straight? You prefer/recommend --new-use + --exclude over --changed-use? You've found a bug. It's fixed in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a77292d37e3c2604479514abed2dda64dabace25 As a workaround, you can add --binpkg-respect-use=n to your options. Sweet, thanks!
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On 01/20/2012 01:12 PM, Hilco Wijbenga wrote: On 20 January 2012 12:31, Zac Medico zmed...@gentoo.org wrote: On 01/20/2012 10:28 AM, Hilco Wijbenga wrote: I'd like to chime in here. I started a thread on gentoo-user (Portage option --changed-use not working?) pretty much about this. I use --changed-use instead of --newuse to get the advantages of a fully up-to-date system without the unnecessary churn. From the man page I understand that (part of) the idea behind --changed-use is to *not* rebuild packages where an unused/disabled USE flag is dropped. Which ought to apply to kdeenablefinal, right? It seems my understanding is incorrect because I see --new-use + --exclude is being recommended, not --changed-use. Would somebody please set me straight? You prefer/recommend --new-use + --exclude over --changed-use? It depends on your goal, because the results are different. -- Thanks, Zac
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On Friday 20 January 2012 07:49:07 Rich Freeman wrote: Perhaps this is worth its own thread, as this one is already drifting way off topic. i don't mind thread drift too much as it often times results in good things in related areas. in this case, i think we've had good fallout. -mike signature.asc Description: This is a digitally signed message part.
