On 02/12/10 02:45, Zac Medico wrote:
> sci-chemistry/mopac7-1.10-r1 =sys-devel/automake-1.8*
> sci-chemistry/mopac7-1.13 =sys-devel/automake-1.8*
> sci-chemistry/mopac7-1.13-r1 =sys-devel/automake-1.8*
This can be also considered to be fixed. Only ppc needs to be stabled.
signature.asc
De
On 02/12/10 02:45, Zac Medico wrote:
> I've attached a list of packages, and script to generate it.
>
sci-chemistry/ccp4-apps-6.1.3-r1=sys-devel/automake-1.6*
sci-chemistry/ccp4-apps-6.1.3-r2=sys-devel/automake-1.6*
sci-chemistry/ccp4-apps-6.1.3-r4=sys-devel/automake-1.6*
And just to add another reason, automake 1.8 already starts triggering
warnings with Perl 5.12. How soon do you fare that a Perl update will
make older automake fail altogether?
--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/
If you found a .asc file in this mail and know not what
I've attached a list of packages, and script to generate it.
--
Thanks,
Zac
#!/usr/bin/env python
import os
import sys
import portage
if len(sys.argv) != 2 or not portage.isvalidatom(sys.argv[1]):
sys.stderr.write("usage: %s \n" % os.path.basename(sys.argv[0]))
sys.exit(1)
input_atom = porta
Hi all,
Not sure if you know but we're currently experiencing a spur of build
failures related to eautoreconf (in particular, eaclocal) and
libtool-2.4 The new libtool release only works with automake 1.9 and
later. [1]
In this situation, the proper way to tackle the issue is to make sure
the bui
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01-12-2010 19:13, Alec Warner wrote:
> On Tue, Nov 30, 2010 at 8:02 PM, Jorge Manuel B. S. Vicetto
> wrote:
> On 29-11-2010 10:34, Sebastian Pipping wrote:
On 11/29/10 09:35, Arfrever Frehtes Taifersar Arahesis wrote:
> There will probably
On Wed, 01 Dec 2010 22:47:45 +0100
Diego Elio Pettenò wrote:
> x86-64/amd64 (which Intel called IA32e or EM64T iirc).
I think I've seen them calling it 'Intel 64' too which introduces even
more confusion.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Il giorno mer, 01/12/2010 alle 22.51 +0100, Michał Górny ha scritto:
>
>
> Pure GnuTLS.
>
That's good, so what about this?
jabber? ( ssl? ( !gnutls ( openssl ) gnutls? ( gnutls ) )
irc? ( ssl? ( openssl ) )
Use a couple of variables to avoid repeating the three-way (all-off ssl
on, ssl-and-gnu
On Wed, 01 Dec 2010 22:44:45 +0100
Diego Elio Pettenò wrote:
> Il giorno mer, 01/12/2010 alle 22.30 +0100, Michał Górny ha scritto:
> >
> > In other words, the preferred complete build of ekg2 requires both
> > gnutls and openssl. However, all of the features should work fine
> > with openssl it
Il giorno gio, 02/12/2010 alle 00.44 +0300, Alexey Shvetsov ha scritto:
>
> i call it ia32 since its original name of this arch however it can be
> better called x86 (x86_32 and x86_64)
It is by far not the original name of the architecture… it was retconned
after IA-64 was released. And it only
Il giorno mer, 01/12/2010 alle 22.30 +0100, Michał Górny ha scritto:
>
> In other words, the preferred complete build of ekg2 requires both
> gnutls and openssl. However, all of the features should work fine with
> openssl itself as well.
>
There is a simple first question to ask here. Does it us
Well ok =)
i call it ia32 since its original name of this arch however it can be
better called x86 (x86_32 and x86_64)
PS seems many users were confused with ia64 since they associate it
with core2 and nahalem
2010/12/1 Diego Elio Pettenò :
> Il giorno mer, 01/12/2010 alle 22.11 +0300, Alexey Sh
Hello,
I'd like to ask for an advice related to net-im/ekg2 ebuild. I would
like to switch the ebuilds there to use the primary autotools build
system for the package, and the last thing on my to-do list is adding
a 'ssl' flag to the package.
The package consists of a core application and a set o
On Wed, 01 Dec 2010 21:58:20 +0100
"Paweł Hajdan, Jr." wrote:
> So we have some automatic reporting. Can we have a webpage for
> that, or a mailing list that people can subscribe to?
Mailing list: http://bugs.gentoo.org/329165
I have no idea how to go about doing an automated webpage or other
in
On Wed, 01 Dec 2010 21:58:20 +0100, Paweł Hajdan, Jr. wrote:
On 12/1/10 9:34 PM, Joshua Saddler wrote:
Catalyst sends automated emails to rel...@gentoo.org from the
various build boxes: dolphin, poseidon, other dev.g.o machines.
So we have some automatic reporting. Can we have a webpage for th
On 12/1/10 9:34 PM, Joshua Saddler wrote:
> Catalyst sends automated emails to rel...@gentoo.org from the
> various build boxes: dolphin, poseidon, other dev.g.o machines.
So we have some automatic reporting. Can we have a webpage for that, or
a mailing list that people can subscribe to?
Idea: ma
On 12/1/10 9:13 PM, Alec Warner wrote:
>> How does a developer know when the stage generation is broken? Is
>> there a dashboard? At work we have a guy who is basically a build cop
>> and checks our build dashboard once a day or so and if it is broken he
>> goes and finds the guy who broke it and
On Wed, 1 Dec 2010 12:13:03 -0800
Alec Warner wrote:
> On Tue, Nov 30, 2010 at 8:02 PM, Jorge Manuel B. S. Vicetto
> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 29-11-2010 10:34, Sebastian Pipping wrote:
> >> On 11/29/10 09:35, Arfrever Frehtes Taifersar Arahesis wrot
On 12/01/2010 01:16 PM, Diego Elio Pettenò wrote:
> Il giorno mer, 01/12/2010 alle 19.05 +0100, Thomas Kahle ha scritto:
>>
>>
>> I agree, comments within the ebuild are practically invisible to
>> archteams (at least to me for x86). But also running repoman is
>> usually
>> the final step, right
Il giorno mer, 01/12/2010 alle 22.11 +0300, Alexey Shvetsov ha scritto:
>
> PS also with this feature seems amd64 and x86 can be merged in one
> arch (like it was done in kernel) since its only abis of ia32
>
I would suggest against that.
For the kernel it's somewhat easier, but for userland, x8
Am 01.12.2010 20:11, schrieb Alexey Shvetsov:
> Well =)
>
> This will be killer feature in gentoo =P
> Also what about more complex arhes than ia32? like mips of ppc?
I cant speak in detail about the other arches, since i dont know them that
much. Basicly, if you can
crosscompile for a different
Am 01.12.2010 20:05, schrieb Fabian Groffen:
> Hi Thomas,
>
> On 01-12-2010 19:57:46 +0100, Thomas Sachau wrote:
>> The current implementation uses a USE-dep like way internally to
>> satisfy the needed dependencies, so that e.g. 32bit libs on a 64bit
>> platform get their required dependencies bu
On Tue, Nov 30, 2010 at 8:02 PM, Jorge Manuel B. S. Vicetto
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 29-11-2010 10:34, Sebastian Pipping wrote:
>> On 11/29/10 09:35, Arfrever Frehtes Taifersar Arahesis wrote:
>>> There will probably be no active version of Python set.
>>
>>
Hello,
the proposed changes have been applied to all ebuilds of dev-lang/python
in Gentoo's main tree as of now.
So it's in CVS now, mirrors take longer.
If you stumble upon problems with it please
- file bugs with details
- reply here, pointing to the bug
NOTE: If you plan to explicitly unm
Well =)
This will be killer feature in gentoo =P
Also what about more complex arhes than ia32? like mips of ppc?
PS also with this feature seems amd64 and x86 can be merged in one
arch (like it was done in kernel) since its only abis of ia32
2010/12/1 Thomas Sachau :
> Hi,
>
> i have already wri
Hi Thomas,
On 01-12-2010 19:57:46 +0100, Thomas Sachau wrote:
> The current implementation uses a USE-dep like way internally to
> satisfy the needed dependencies, so that e.g. 32bit libs on a 64bit
> platform get their required dependencies built with 32bit libs
> installed.
This just means that
Hi,
i have already written about this some months ago and updated the code in
relation to the comments
especially from vapier.
Basicly, it does now first set abi-specific vars (like CC, CFLAGS and others
(setup_abi_env function
in bin/auto-multilib.sh contains the full list), then does build th
Hello!
I have done a bit more testing now. To do so I have isolated the
eselect-python-update behavior into testing ebuilds (package
"virtual/debug-eselect-python") reduced to just that problem (no
compilation and the like, see attachment, also in sping overlay).
The test scenario is made of tw
Il giorno mer, 01/12/2010 alle 19.05 +0100, Thomas Kahle ha scritto:
>
>
> I agree, comments within the ebuild are practically invisible to
> archteams (at least to me for x86). But also running repoman is
> usually
> the final step, right before committing. The place for comments that
> need t
On 17:35 Wed 01 Dec , Diego Elio Pettenò wrote:
> > Comments inside are better suited for this task - you see/update notes
> > as you edit ebuild.
> >
> How many ATs/arch maintainers will look _within_ the ebuild when testing
> an ebuild for stable?
I agree, comments within the ebuild are pra
On 12/01/10 05:02, Jorge Manuel B. S. Vicetto wrote:
> As Arfrever noted, this is likely the cause of the broken automated
> weekly stages for this past week. By not having a python symlink /
> wrapper, stages generation failed on stage2 run.
Yes, a fellow dev already reported that issue to me.
I
Il giorno mer, 01/12/2010 alle 17.02 +0300, Peter Volkov ha scritto:
>
> Comments inside are better suited for this task - you see/update notes
> as you edit ebuild.
>
How many ATs/arch maintainers will look _within_ the ebuild when testing
an ebuild for stable?
--
Diego Elio Pettenò — “Flameey
Il giorno mer, 01/12/2010 alle 07.25 +0530, Nirbheek Chauhan ha scritto:
>
>
> That's just the DTD not getting validated. We can just change the DTD
> and repoman won't complain about the XML being invalid.
>
What Matt was saying is that I actually asked for something that was
explicitly printed
В Срд, 01/12/2010 в 02:00 +0100, Diego Elio Pettenò пишет:
> I was wondering if we have space already, or if others would feel
> strongly about making space for, maintainer notes in packages'
> metadata.xml.
Comments inside are better suited for this task - you see/update notes
as you edit ebuild.
Our bug queue has 102 bugs!
If you have some spare time, please help assign/sort a few bugs.
To view the bug queue, click one of the following links:
http: http://bit.ly/bsHeJt
https: http://bit.ly/8Z4xUU
Thanks!
35 matches
Mail list logo
