On Saturday, September 11, 2010 22:51:23 Ryan Hill wrote:
> On Sun, 12 Sep 2010 20:59:25 +1200 Alistair Bush wrote:
> > There should be nothing stopping a user from running a mixed arch/~arch
> > system. Those problems just point to our dependency information not
> > being recorded correctly. I
On Saturday, September 11, 2010 15:04:45 Ciaran McCreesh wrote:
> On Sat, 11 Sep 2010 20:51:56 +0200 justin wrote:
> > is the following comment an adequate way to close bugs with
> > RESOLVED/INVALID? If so, I will change the way I handle bugs and use
> > it too.
> >
> > ""
> > virtual/os-headers:
On Sun, 12 Sep 2010 20:59:25 +1200
Alistair Bush wrote:
> There should be nothing stopping a user from running a mixed arch/~arch
> system. Those problems just point to our dependency information not being
> recorded correctly. It might be understandable that this info can be
> incredibly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/11/2010 02:03 PM, Jonathan Callen wrote:
> On 09/08/2010 03:03 PM, MichaB Górny wrote:
>> If called with a single arg, it would assume val1=use1.
>
> Just as a proof-of-concept, here's one implementation of such a
> function, allowing for an a
Petteri Räty posted on Sat, 11 Sep 2010 23:18:32 +0300 as excerpted:
> On 09/11/2010 11:14 PM, Ryan Hill wrote:
>> On Sat, 11 Sep 2010 22:10:51 +0300
>> Petteri Räty wrote:
>>
+
+*hachoir-parser-1.3.4 (10 Sep 2010)
+
+ 10 Sep 2010; Arfrever Frehtes Taifersar Arahesis
On Fri, 10 Sep 2010 18:32:38 +0200
Jeroen Roovers wrote:
> On Tue, 7 Sep 2010 21:30:34 +
> "Robin H. Johnson" wrote:
>
> > On Tue, Sep 07, 2010 at 10:47:27PM +0200, Róbert Čerňanský wrote:
> > > 2.3. Upstream issues
> > >Do not close a bug (as RESOLVED/UPSTREAM) until it is fixed by
> >
> On 09/11/2010 03:04 PM, Ciaran McCreesh wrote:
> > Or does the problem only occur if you mix keywords and ignore
> > dependencies?
>
> I think that if a package doesn't work in a mixed environment, that
> points to a likely dependency problem. Sooner or later there is a good
> chance it will bi
2010-09-11 21:17:19 Petteri Räty napisał(a):
> On 09/11/2010 12:50 AM, Arfrever Frehtes Taifersar Arahesis (arfrever)
> wrote:
> >
> > +PYTHON_CFLAGS=("2.* + -fno-strict-aliasing")
> > +
>
> Shouldn't this rather be a patch to the build system that can be sent
> upstream?
It's a bug in Python 2
On 09/11/2010 11:20 PM, Maciej Mrozowski wrote:
> On Saturday 11 of September 2010 22:18:32 Petteri Räty wrote:
>> On 09/11/2010 11:14 PM, Ryan Hill wrote:
>>> On Sat, 11 Sep 2010 22:10:51 +0300
>>>
>>> Petteri Räty wrote:
> +
> +*hachoir-parser-1.3.4 (10 Sep 2010)
> +
> + 10 Sep
On Saturday 11 of September 2010 22:18:32 Petteri Räty wrote:
> On 09/11/2010 11:14 PM, Ryan Hill wrote:
> > On Sat, 11 Sep 2010 22:10:51 +0300
> >
> > Petteri Räty wrote:
> >>> +
> >>> +*hachoir-parser-1.3.4 (10 Sep 2010)
> >>> +
> >>> + 10 Sep 2010; Arfrever Frehtes Taifersar Arahesis
> >>> +
On 09/11/2010 11:14 PM, Ryan Hill wrote:
> On Sat, 11 Sep 2010 22:10:51 +0300
> Petteri Räty wrote:
>
>>> +
>>> +*hachoir-parser-1.3.4 (10 Sep 2010)
>>> +
>>> + 10 Sep 2010; Arfrever Frehtes Taifersar Arahesis
>>> + -hachoir-parser-1.3.3.ebuild, +hachoir-parser-1.3.4.ebuild:
>>> + Version bum
On Sat, 11 Sep 2010 22:10:51 +0300
Petteri Räty wrote:
> > +
> > +*hachoir-parser-1.3.4 (10 Sep 2010)
> > +
> > + 10 Sep 2010; Arfrever Frehtes Taifersar Arahesis
> > + -hachoir-parser-1.3.3.ebuild, +hachoir-parser-1.3.4.ebuild:
> > + Version bump.
> >
>
> Deleting an older version is rele
On 09/11/2010 10:31 PM, Fabian Groffen wrote:
> On 11-09-2010 21:29:22 +0200, Ulrich Mueller wrote:
>>> On Sat, 11 Sep 2010, Petteri Räty wrote:
>>
Update EAPI. Fix dependencies.
>>
>>> This message does not tell why the EPREFIX stuff was removed.
>>
>> Come on. EAPI was updated to 3, and
On 11-09-2010 21:29:22 +0200, Ulrich Mueller wrote:
> > On Sat, 11 Sep 2010, Petteri Räty wrote:
>
> >> Update EAPI. Fix dependencies.
>
> > This message does not tell why the EPREFIX stuff was removed.
>
> Come on. EAPI was updated to 3, and removal of the EPREFIX assignments
> are part of
> On Sat, 11 Sep 2010, Petteri Räty wrote:
>> Update EAPI. Fix dependencies.
> This message does not tell why the EPREFIX stuff was removed.
Come on. EAPI was updated to 3, and removal of the EPREFIX assignments
are part of that.
Ulrich
On 09/11/2010 03:04 PM, Ciaran McCreesh wrote:
Or does the problem only occur if you mix keywords and ignore
dependencies?
I think that if a package doesn't work in a mixed environment, that
points to a likely dependency problem. Sooner or later there is a good
chance it will bite somebody.
On 09/11/2010 12:50 AM, Arfrever Frehtes Taifersar Arahesis (arfrever)
wrote:
>
> +PYTHON_CFLAGS=("2.* + -fno-strict-aliasing")
> +
Shouldn't this rather be a patch to the build system that can be sent
upstream?
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
On 09/11/2010 01:02 AM, Arfrever Frehtes Taifersar Arahesis (arfrever)
wrote:
> arfrever10/09/10 22:02:28
>
> Modified: PyQt4-4.7.6.ebuild ChangeLog
> Log:
> Update EAPI. Fix dependencies.
>
This message does not tell why the EPREFIX stuff was removed.
> (Portage versi
On Saturday 11 of September 2010 20:51:56 justin wrote:
> Hi all,
>
> is the following comment an adequate way to close bugs with
> RESOLVED/INVALID? If so, I will change the way I handle bugs and use it
> too.
>
> ""
> virtual/os-headers: 2.6.35 (sys-kernel/linux-headers)
> ACCEPT_KEYWORDS="amd
On 09/11/2010 01:39 AM, Arfrever Frehtes Taifersar Arahesis (arfrever)
wrote:
> arfrever10/09/10 22:39:27
>
> Modified: ChangeLog
> Added:hachoir-parser-1.3.4.ebuild
> Log:
> Version bump.
>
> (Portage version: 2.2_rc79_p5/cvs/Linux x86_64)
>
> Revisio
On Sat, 11 Sep 2010 20:51:56 +0200
justin wrote:
> is the following comment an adequate way to close bugs with
> RESOLVED/INVALID? If so, I will change the way I handle bugs and use
> it too.
>
> ""
> virtual/os-headers: 2.6.35 (sys-kernel/linux-headers)
> ACCEPT_KEYWORDS="amd64"
>
> you mix st
On 09/11/2010 09:51 PM, justin wrote:
> Hi all,
>
> is the following comment an adequate way to close bugs with
> RESOLVED/INVALID? If so, I will change the way I handle bugs and use it too.
>
> ""
> virtual/os-headers: 2.6.35 (sys-kernel/linux-headers)
> ACCEPT_KEYWORDS="amd64"
>
> you mix sta
On 9/11/10 11:51 AM, justin wrote:
> is the following comment an adequate way to close bugs with
> RESOLVED/INVALID? If so, I will change the way I handle bugs and use it too.
>
> ""
> virtual/os-headers: 2.6.35 (sys-kernel/linux-headers)
> ACCEPT_KEYWORDS="amd64"
>
> you mix stable & unstable -
Hi all,
is the following comment an adequate way to close bugs with
RESOLVED/INVALID? If so, I will change the way I handle bugs and use it too.
""
virtual/os-headers: 2.6.35 (sys-kernel/linux-headers)
ACCEPT_KEYWORDS="amd64"
you mix stable & unstable -> your problem
""
Cheers Justin
signat
On 09/11/2010 09:44 PM, Michał Górny wrote:
> On Sat, 11 Sep 2010 20:26:17 +0200
> Francesco R wrote:
>
>> echo $(use_case useA,echoA useB,echoB ,echoC)
>
> I would personally rather use:
> echo $(use_case useA,echoA useB,echoB echoC)
>
> but AFAICS your implementation should support both.
>
>
On Sat, 11 Sep 2010 20:26:17 +0200
Francesco R wrote:
> echo $(use_case useA,echoA useB,echoB ,echoC)
I would personally rather use:
echo $(use_case useA,echoA useB,echoB echoC)
but AFAICS your implementation should support both.
PS I suggest using [[ -z ${u} ]] instead.
--
Best regards,
Mic
2010/9/11 "Paweł Hajdan, Jr."
> On 9/11/10 11:03 AM, Jonathan Callen wrote:
> > Just as a proof-of-concept, here's one implementation of such a
> > function, allowing for an arbitrary number of arguments:
> >
> > use_echo() {
> > while [[ $# -gt 1 ]]; do
> > if use "$1"; then
On 9/11/10 11:03 AM, Jonathan Callen wrote:
> Just as a proof-of-concept, here's one implementation of such a
> function, allowing for an arbitrary number of arguments:
>
> use_echo() {
> while [[ $# -gt 1 ]]; do
> if use "$1"; then
> echo "$2"
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/08/2010 03:03 PM, Michał Górny wrote:
> Hello,
>
> We already have a variety of use_*() functions with their specific
> uses. But what I miss is a single, simple and universal use_echo()
> function, behaving similarly to ?: operator in C. In o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
W dniu 11.09.2010 15:38, Jeroen Roovers pisze:
> 1) OK, we have someone anonymously using bugs.gentoo.org in an official
> capacity? I don't think this is a good idea.
>
> 2) This bug was RESOLVED/FIXED 4 years ago. There is absolutely no
> reason to
On Sat, 11 Sep 2010 07:17:01 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> Jeroen Roovers posted on Fri, 10 Sep 2010 18:32:38 +0200 as excerpted:
>
> > If the reason you propose this is visibility, then maybe we should
> > make the quicksearch option include more than just open bugs. I've
>
On Fri, 10 Sep 2010 19:00:50 + (UTC)
bugzilla-dae...@gentoo.org wrote:
> DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the person
> whose email is mentioned below. To comment on this bug, please visit:
>
> Clear-Text: http://bugs.gentoo.org/show_bug.cgi?id=142517
> Secure: https
2010/9/11 Tomáš Chvátal :
> Since you guys again talk about stabling something, i added -r1 again.
> This time with really trimmed patches that fixes only build time issues
> or some issue i experienced localy.
>
> Feel free to rework that patches before stabling it :)
Thanks, I've just added anot
Jeroen Roovers posted on Fri, 10 Sep 2010 18:32:38 +0200 as excerpted:
> If the reason you propose this is visibility, then maybe we should make
> the quicksearch option include more than just open bugs. I've thought
> about having UPSTREAM/DUPLICATE/INVALID added so that bugzilla users can
> more
34 matches
Mail list logo
