On Thu, Oct 13, 2011 at 11:01 PM, Mike Frysinger wrote:
> On Thursday 13 October 2011 14:15:54 Sebastian Luther wrote:
>> WARNING: One or more updates have been skipped due to a dependency
>> conflict:
>>
>> dev-python/numpy:0
>> (dev-python/numpy-1.6.0::gentoo, ebuild scheduled for merge) confl
Original-Nachricht
> Datum: Fri, 14 Oct 2011 02:01:00 -0400
> Von: Mike Frysinger
> An: gentoo-dev@lists.gentoo.org
> Betreff: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in
> net-im/qutecom: metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
&
On Thursday 13 October 2011 14:15:54 Sebastian Luther wrote:
> WARNING: One or more updates have been skipped due to a dependency
> conflict:
>
> dev-python/numpy:0
> (dev-python/numpy-1.6.0::gentoo, ebuild scheduled for merge) conflicts
> with ~dev-python/numpy-1.5.1 required by
> (sci-mathemat
Samuli Suominen schrieb:
>> This is something that I have been asking for all the time. If you think
>> that what qutecom did should be illegal in Gentoo, then disallow it in
>> policy or code.
>
> Drop that "should be" act, please. It looks as if you were still
> suggesting it was fine to do wh
Am 13.10.2011 15:13, schrieb Ciaran McCreesh:
> On Thu, 13 Oct 2011 12:23:07 +0200
> Chí-Thanh Christopher Nguyễn wrote:
>> So qutecom is not broken and needs not be removed as long as
>>
> Dependencies using <, <=, =, ~ or =* are broken, except in certain
> special situations inside ||.
>
Why
On Thu, 13 Oct 2011 13:52:37 -0400
Rich Freeman wrote:
> While slotting libraries is often an option, that gets a lot messier
> when you're talking about things like header files.
You can make slots mutually blocking if you do it carefully. It does
get a bit horrible without := dependencies thoug
On Thu, Oct 13, 2011 at 1:45 PM, Samuli Suominen wrote:
> Merely saying if we had some documentation snippet, or an end-quiz
> question for this, QA could more easily/faster revoke access if someone
> were to do this intentionally in tree. This could be minor motivation
> for me to write such snip
On 10/13/2011 06:09 PM, Chí-Thanh Christopher Nguyễn wrote:
> Samuli Suominen schrieb:
>> you're right. sorry. that came out too harsh. lets rephrase this as:
>
> No offense taken :)
>
>> "This /topic should be in the end-quiz, and mentioned in the mentoring
>> guide to cover basis as part of the
On Thu, Oct 13, 2011 at 11:26 AM, Michał Górny wrote:
> So, in your opinion, if we have 'foo' and 'libfoo' which are strictly
> version-bound, we can't allow users to install older versions?
Obviously the real issue is when libfoo is libpng or openssl or whatever.
It almost makes you wonder if t
On Thu, 13 Oct 2011 14:13:11 +0100
Ciaran McCreesh wrote:
> On Thu, 13 Oct 2011 12:23:07 +0200
> Chí-Thanh Christopher Nguyễn wrote:
> > So qutecom is not broken and needs not be removed as long as
> >
> Dependencies using <, <=, =, ~ or =* are broken, except in certain
> special situations in
Samuli Suominen schrieb:
> you're right. sorry. that came out too harsh. lets rephrase this as:
No offense taken :)
> "This /topic should be in the end-quiz, and mentioned in the mentoring
> guide to cover basis as part of the KEYWORDS visibility handling."
This is something that I have been ask
Ciaran McCreesh schrieb:
> On Thu, 13 Oct 2011 12:23:07 +0200
> Chí-Thanh Christopher Nguyễn wrote:
>> So qutecom is not broken and needs not be removed as long as
>> Dependencies using <, <=, =, ~ or =* are broken, except in certain
> special situations inside ||.
I don't find that documented a
On Thu, 13 Oct 2011 12:23:07 +0200
Chí-Thanh Christopher Nguyễn wrote:
> So qutecom is not broken and needs not be removed as long as
>
signature.asc
Description: PGP signature
Mike Frysinger schrieb:
>>> by splitting my reply, you changed the meaning. having qutecom in the
>>> tree with a depend on versions that i'm now removing breaks the
>>> depgraph.
>> The depgraph is broken after the old versions are removed, not before.
> which is what i said
So qutecom is not br
On 10/13/2011 03:10 AM, Matt Turner wrote:
> On Wed, Oct 12, 2011 at 7:58 PM, Samuli Suominen wrote:
>> On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote:
>>> Mike Frysinger schrieb:
> The removed qutecom ebuild was not broken at any time.
by splitting my reply, you changed
On 10/13/2011 03:19 AM, Mike Frysinger wrote:
> On Wednesday 12 October 2011 19:58:31 Samuli Suominen wrote:
>> On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote:
>>> Mike Frysinger schrieb:
> The removed qutecom ebuild was not broken at any time.
by splitting my reply, you c
On Wednesday 12 October 2011 19:58:31 Samuli Suominen wrote:
> On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote:
> > Mike Frysinger schrieb:
> >>> The removed qutecom ebuild was not broken at any time.
> >>
> >> by splitting my reply, you changed the meaning. having qutecom in the
> >>
On Wednesday 12 October 2011 19:27:41 Chí-Thanh Christopher Nguyễn wrote:
> Mike Frysinger schrieb:
> >> The removed qutecom ebuild was not broken at any time.
> >
> > by splitting my reply, you changed the meaning. having qutecom in the
> > tree with a depend on versions that i'm now removing br
On Wed, Oct 12, 2011 at 7:58 PM, Samuli Suominen wrote:
> On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote:
>> Mike Frysinger schrieb:
The removed qutecom ebuild was not broken at any time.
>>>
>>> by splitting my reply, you changed the meaning. having qutecom in the tree
>>> with
On 10/13/2011 02:27 AM, Chí-Thanh Christopher Nguyễn wrote:
> Mike Frysinger schrieb:
>>> The removed qutecom ebuild was not broken at any time.
>>
>> by splitting my reply, you changed the meaning. having qutecom in the tree
>> with a depend on versions that i'm now removing breaks the depgraph.
Mike Frysinger schrieb:
>> The removed qutecom ebuild was not broken at any time.
>
> by splitting my reply, you changed the meaning. having qutecom in the tree
> with a depend on versions that i'm now removing breaks the depgraph.
The depgraph is broken after the old versions are removed, not
On Wednesday 12 October 2011 17:42:47 Chí-Thanh Christopher Nguyễn wrote:
> Mike Frysinger schrieb:
> > otherwise, Rich summed up things nicely in his later post.
>
> If you mean that common sense thing: if there is disagreement about it,
> then it is obviously not common.
you're mixing "common"
Mike Frysinger schrieb:
> otherwise, Rich summed up things nicely in his later post.
If you mean that common sense thing: if there is disagreement about it,
then it is obviously not common.
>> The second time the package was removed was even without mask or
>> announcement.
> well, it shouldn't
On Sunday 02 October 2011 16:40:18 Chí-Thanh Christopher Nguyễn wrote:
> Another example from the X.org packages, installing the proprietary
> ATI/NVidia drivers will cause downgrades for xorg-server on ~arch
> systems. Nobody in his right mind is proposing to treeclean them because
> of this.
yes
2011/10/3 Chí-Thanh Christopher Nguyễn :
> I asked for authoritative documentation which forbids downgrades several
> times, but got only vague references (and "common sense") as reply.
>
While I'm all for documenting QA policies, ultimately common sense
does need to prevail. As I've commented be
On 10/03/2011 02:45 AM, malc wrote:
> Really... it took me less time to chuck the new-videodev.patch from [1]
> into src_prepare() and compile-test than it did to read the noise in
> this thread... :)
>
> HTH,
> malc.
>
> [1] http://patch-tracker.debian.org/package/qutecom/2.2.1+dfsg1-2
>
I hav
> On Mon, 3 Oct 2011, Ciaran McCreesh wrote:
> We could just ban upper-bounded dependencies that aren't done by
> slots inside ebuilds in future EAPIs...
That's probably going to far, as there are valid usage cases.
For example, "|| ( bar
On Sun, 02 Oct 2011 20:48:55 -0700
""Paweł Hajdan, Jr."" wrote:
> Finally, forcing downgrades _is_ broken (are you using stable?). If
> that's not clear, I'm totally for putting it in the devmanual/quiz or
> some other place like that.
We could just ban upper-bounded dependencies that aren't done
"Paweł Hajdan, Jr." schrieb:
> I find the back-and-forth or the "edit war" most disturbing. Okay, so
> the package got removed and re-introduced, and removed and re-introduced...
There is no edit war, I restored the package once because I assumed it
was mistakenly removed too early.
When it was re
Chí-Thanh Christopher Nguyễn writes:
> My point is that packages can cause downgrades through "<" dependencies.
> There is no rule against it.
Nearly all of which prevent the upgrade of the dependent package rather
forcing the downgrade of an already installed package.
On 10/2/11 8:26 PM, Arun Raghavan wrote:
> Removing the package again seems to just be unnecessary when the
> maintainer has stated that he'll fix the problem. Would masking it
> till it was fixed not suffice? Seems like a bit unjustified to me
> (from information on this thread alone).
I find the
On 2 October 2011 13:50, Samuli Suominen wrote:
> On 10/02/2011 02:44 AM, Chí-Thanh Christopher Nguyễn wrote:
[...]
>> Bug 361181 is certainly on my TODO list, just not very high up to now.
>> If you think that there is some urgency in getting rid of the package,
>> please do explain so in advance
On 00:31 Mon 03 Oct , Chí-Thanh Christopher Nguyễn wrote:
> It may be obvious to you, but it certainly is not obvious to me why
> linux-headers downgrade is so bad. If vapier's unsupported out-of-tree
> software fails to build against old linux-headers, then he has to make
> sure to have the co
Really... it took me less time to chuck the new-videodev.patch from [1] into
src_prepare() and compile-test than it did to read the noise in this
thread... :)
HTH,
malc.
[1] http://patch-tracker.debian.org/package/qutecom/2.2.1+dfsg1-2
Samuli Suominen schrieb:
>>> Poor example to make a case.
>>
>> VIDEO_CARDS is just for user convenience. run "emerge nvidia-drivers" on
>> any system with xorg-server-1.11 installed and it will downgrade, no
>> matter what VIDEO_CARDS is set to.
>
> And your point is?
My point is that packages c
On 10/03/2011 12:37 AM, Chí-Thanh Christopher Nguyễn wrote:
> Samuli Suominen schrieb:
>
>>> And again, downgrade of dependencies it is not against any rule which
>>> would justify mask and removal.
>>>
>>> Another example from the X.org packages, installing the proprietary
>>> ATI/NVidia drivers
Samuli Suominen schrieb:
>> And again, downgrade of dependencies it is not against any rule which
>> would justify mask and removal.
>>
>> Another example from the X.org packages, installing the proprietary
>> ATI/NVidia drivers will cause downgrades for xorg-server on ~arch
>> systems. Nobody in
On 10/02/2011 11:40 PM, Chí-Thanh Christopher Nguyễn wrote:
> Mike Frysinger schrieb:
>> the system is functioning wrongly because you're forcing users to needlessly
>> upgrade/downgrade packages. in addition, packages in the tree aren't the
>> only
>> things to be considered. if the user is b
Mike Frysinger schrieb:
> the system is functioning wrongly because you're forcing users to needlessly
> upgrade/downgrade packages. in addition, packages in the tree aren't the
> only
> things to be considered. if the user is building code that works fine
> against
> the latest stable, but
On Sunday, October 02, 2011 16:00:30 Chí-Thanh Christopher Nguyễn wrote:
> I agree that a downgrade is a bit inconvenient for users. But if another
> package is built later with DEPEND on newer linux-headers or emerge
> --deep option, then it will get upgraded again. As no package runtime
> depends
Mike Frysinger schrieb:
> On Sunday, October 02, 2011 08:58:19 Chí-Thanh Christopher Nguyễn wrote:
>> Samuli Suominen schrieb:
Please point to existing authoritative documentation which says that
downgrades are unacceptable.
> It is NOT gentoo-x86 compatible package in it's curre
On Sunday, October 02, 2011 08:58:19 Chí-Thanh Christopher Nguyễn wrote:
> Samuli Suominen schrieb:
> >> Please point to existing authoritative documentation which says that
> >> downgrades are unacceptable.
> >>
> >>> It is NOT gentoo-x86 compatible package in it's current form.
> >>
> >> It set
Samuli Suominen schrieb:
>> Please point to existing authoritative documentation which says that
>> downgrades are unacceptable.
>>
>>> It is NOT gentoo-x86 compatible package in it's current form.
>>
>> It sets correct dependency on an existing ebuild in tree. The dependency
>> is only build time,
On 10/02/2011 02:44 AM, Chí-Thanh Christopher Nguyễn wrote:
> Samuli Suominen schrieb:
>> On 10/01/2011 08:02 PM, Chi-Thanh Christopher Nguyen (chithanh) wrote:
>>> chithanh11/10/01 17:02:59
>>>
>>> Added:metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
>>> Log:
>>> Bri
Samuli Suominen schrieb:
> On 10/01/2011 08:02 PM, Chi-Thanh Christopher Nguyen (chithanh) wrote:
>> chithanh11/10/01 17:02:59
>>
>> Added:metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
>> Log:
>> Bring back qutecom.
>
> Bringing back version of qutecom, that is forc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10/01/11 19:29, Samuli Suominen wrote:
> On 10/01/2011 08:02 PM, Chi-Thanh Christopher Nguyen (chithanh)
> wrote:
>> chithanh11/10/01 17:02:59
>>
>> Added:metadata.xml ChangeLog
>> qutecom-2.2_p20110210.ebuild Log: Bring back
On 10/01/2011 08:02 PM, Chi-Thanh Christopher Nguyen (chithanh) wrote:
> chithanh11/10/01 17:02:59
>
> Added:metadata.xml ChangeLog qutecom-2.2_p20110210.ebuild
> Log:
> Bring back qutecom.
Bringing back version of qutecom, that is forcing downgrade on
linux-headers, whe
47 matches
Mail list logo
