Re: [gentoo-dev] latest boost vs. eselected boost

Am Donnerstag, den 19.01.2012, 11:50 -0500 schrieb Ian Stakenvicius: > On 19/01/12 03:27 AM, "Paweł Hajdan, Jr." wrote: > > On 1/19/12 9:05 AM, Johannes Huber wrote: > >> Summary of the comments: 1) Ebuilds should always pick the latest > >> boost version. 2) Boost should be compared to gcc, python

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/19/2012 07:33 PM, Duncan wrote: > However, it could be argued that the various boilerplate "handholding" > we're already doing has set the precedent. That's actually where I got > the idea, after all. But I'm not going to argue it. I'd be more > inclined to argue that we're already over

[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

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. I'd find that exactly right, here.

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/19/2012 03:38 PM, Duncan wrote: @ Zac: Could the output of an emerge --pretend (or --ask) account for -newuse, and include a boilerplate sentence or so about --exclude, if the proposed package merge list includes any same-version remerges due to --newuse? Or if tracking --newuse packages

[gentoo-dev] Re: How help in arch testing work

Mike Frysinger posted on Thu, 19 Jan 2012 11:46:21 -0500 as excerpted: > On Wednesday 18 January 2012 21:23:47 Duncan wrote: >> If people want it, they can merge it, just like any other package. >> Really, the same applies to busybox, and arguably, even to >> module-init-tools (and the more recen

[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 Thu, 19 Jan 2012 08:56:57 -0500 as excerpted: > 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 ha

Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility

On 01/19/2012 07:16 PM, "Paweł Hajdan, Jr." wrote: On 1/19/12 6:02 PM, Samuli Suominen wrote: On 01/19/2012 06:56 PM, Mike Frysinger wrote: that doesn't help. the libjpeg turbo peeps themselves have said they don't guarantee compatibility across their own versions. it's forward compatible, w

Re: [gentoo-dev] latest boost vs. eselected boost

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 19 Jan 2012 11:50:47 -0500 Ian Stakenvicius wrote: > I thought there was a push to eventually de-slot boost? (in which > case this issue just disappears) Boost doesn't have any ABI stability. - -- Ciaran McCreesh -BEGIN 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/19/2012 05:56 AM, Rich Freeman wrote: 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*** aroun

Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility

On 1/19/12 6:02 PM, Samuli Suominen wrote: > On 01/19/2012 06:56 PM, Mike Frysinger wrote: >> that doesn't help. the libjpeg turbo peeps themselves have said they >> don't >> guarantee compatibility across their own versions. > > it's forward compatible, which is all we should care about Just a

Re: [gentoo-dev] How help in arch testing work

On Wednesday 18 January 2012 22:41:26 Mike Gilbert wrote: > On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger wrote: > > - you're confusing the literal @system with implicit system deps > > I don't quite follow here. By "implicit system deps", are you > referring to the "common sense" set of essen

Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility

On 01/19/2012 06:56 PM, Mike Frysinger wrote: On Thursday 19 January 2012 04:35:43 Samuli Suominen wrote: On 01/19/2012 11:19 AM, "Paweł Hajdan, Jr." wrote: While dealing with I started discussing with developers working on libjpeg-turbo support

Re: [gentoo-dev] How help in arch testing work

On Thursday 19 January 2012 09:04:08 Rich Freeman wrote: > On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger wrote: > > if it's part of the implicit system dep, they absolutely need to defend > > their actions. you want to change the policy, then start a thread on > > it. > > What policy? I don'

Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility

On Thursday 19 January 2012 04:35:43 Samuli Suominen wrote: > On 01/19/2012 11:19 AM, "Paweł Hajdan, Jr." wrote: > > While dealing with I > > started discussing with developers working on libjpeg-turbo support in > > WebKit, and I learned that despit

Re: [gentoo-dev] latest boost vs. eselected boost

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/01/12 03:27 AM, "Paweł Hajdan, Jr." wrote: > On 1/19/12 9:05 AM, Johannes Huber wrote: >> Summary of the comments: 1) Ebuilds should always pick the latest >> boost version. 2) Boost should be compared to gcc, python, ruby >> etc >> >> [1] htt

Re: [gentoo-dev] Re: How help in arch testing work

On Wednesday 18 January 2012 21:23:47 Duncan wrote: > If people want > it, they can merge it, just like any other package. Really, the same > applies to busybox, and arguably, even to module-init-tools (and the more > recent replacement, kmod...), since that's not needed if people choose to > buil

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 Thursday 19 January 2012 04:32:46 Michał Górny wrote: > On Thu, 19 Jan 2012 03:42:14 +0100 Michael Weber wrote: > > Um, what happend to the policy to not f*** around with stable ebuilds? > > I don't think such a rule has any meaning considering that those > ebuilds are mostly contained in an ec

Re: [gentoo-dev] How help in arch testing work

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/01/12 10:41 PM, Mike Gilbert wrote: > On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger > wrote: >> - you're confusing the literal @system with implicit system deps > > I don't quite follow here. > literal @system = the exact packages listed

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 Thursday 19 January 2012 04:32:01 Michał Górny wrote: > On Wed, 18 Jan 2012 22:00:52 -0500 Mike Frysinger wrote: > > > I see a violation of this rule at least on 2.13-r4, which leads to > > > useless rebuilds on `emerge -avuND world` on every single gentoo > > > install world-wide. > > > > i do

[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

On Thu, Jan 19, 2012 at 08:56:57AM -0500, Rich Freeman wrote: > So, suppose I don't want to update those 200 kde packages, but I don't > want to ignore the odd package that does come up in -N in the future? > Do I just run a daily emerge -puDN world, look at the output, then > manually remove the 2

Re: [gentoo-dev] How help in arch testing work

On Wed, Jan 18, 2012 at 10:05 PM, Mike Frysinger wrote: > if it's part of the implicit system dep, they absolutely need to defend their > actions.  you want to change the policy, then start a thread on it. What policy? I don't see any written policy stating that you aren't allowed to include sys

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? >> I think ther

Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility

On 1/19/12 10:45 AM, Michał Górny wrote: > Hmm, does this mean the ABI differs on runtime compilation options? No, at least I'm not aware of such a thing. I'd sum it up as "libjpeg-turbo is not binary-compatible with libjpeg and also with a different version of itself, and is not supposed to be".

Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility

On Thu, 19 Jan 2012 10:19:27 +0100 ""Paweł Hajdan, Jr."" wrote: > While dealing with I > started discussing with developers working on libjpeg-turbo support in > WebKit, and I learned that despite >

Re: [gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility

On 01/19/2012 11:19 AM, "Paweł Hajdan, Jr." wrote: While dealing with I started discussing with developers working on libjpeg-turbo support in WebKit, and I learned that despite

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, 19 Jan 2012 03:42:14 +0100 Michael Weber wrote: > Um, what happend to the policy to not f*** around with stable ebuilds? I don't think such a rule has any meaning considering that those ebuilds are mostly contained in an eclass. -- Best regards, Michał Górny signature.asc Description

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 Wed, 18 Jan 2012 22:00:52 -0500 Mike Frysinger wrote: > > I see a violation of this rule at least on 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 > enoug

[gentoo-dev] doubtful about libjpeg-turbo vs. libjpeg binary compatibility

While dealing with I started discussing with developers working on libjpeg-turbo support in WebKit, and I learned that despite libjpeg-turbo is not necessarily binary co

[gentoo-dev] Re: How help in arch testing work

On 19/01/2012 07:02, Mike Frysinger wrote: On Wednesday 18 January 2012 14:02:01 Markos Chandras wrote: On 01/18/2012 05:32 PM, "Paweł Hajdan, Jr." wrote: On 1/18/12 4:48 PM, Donnie Berkholz wrote: On 10:05 Wed 18 Jan , Mike Frysinger wrote: On Wednesday 18 January 2012 09:23:00 Agostino

Re: [gentoo-dev] latest boost vs. eselected boost

On 1/19/12 9:05 AM, Johannes Huber wrote: > Summary of the comments: > 1) Ebuilds should always pick the latest boost version. > 2) Boost should be compared to gcc, python, ruby etc > > [1] https://bugs.gentoo.org/show_bug.cgi?id=335108 Right, Tiziano Müller's (dev-zero) comments are pretty cle

[gentoo-dev] latest boost vs. eselected boost

Hello, a user submitted a bug[1] that cmake always select the latest boost. We the kde team as cmake maintainer found a solution to respect the (e)selected boost. The patched version is not in tree yet, because after my blog post[2] about this issue a discussion in the bug starts. Summary of t