On Thu 27 Mar 2014 00:41:47 Alexandre Rostovtsev wrote:
On Wed, 2014-03-26 at 22:41 -0400, Mike Frysinger wrote:
On Wed 26 Mar 2014 12:23:53 Ian Stakenvicius wrote:
On 26/03/14 12:12 PM, Mike Frysinger wrote:
that's bs. people install crossdev to get a cross-compile
environment, not
On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
(2) use tuples with loaded vendor fields to reduce the chance of collisions.
e.g. having an ABI=amd64 system use i686-gentoo%multilib-linux-gnu instead
of i686-pc-linux-gnu would defeat any automatic path searches.
this patch keeps the status
On Thu, 2014-03-27 at 02:07 -0400, Mike Frysinger wrote:
An amd64 multilib system *is* expected to build x86
binaries that would be hosted on itself. So i686-pc-linux-gnu-ar is
expected to be not a part of any cross-compile toolchain, but a part of
the native toolchain for the machine's
On Thu 27 Mar 2014 02:31:01 Alexandre Rostovtsev wrote:
On Thu, 2014-03-27 at 02:07 -0400, Mike Frysinger wrote:
An amd64 multilib system *is* expected to build x86
binaries that would be hosted on itself. So i686-pc-linux-gnu-ar is
expected to be not a part of any cross-compile
Dnia 2014-03-27, o godz. 02:41:21
Mike Frysinger vap...@gentoo.org napisał(a):
On Thu 27 Mar 2014 02:31:01 Alexandre Rostovtsev wrote:
On Thu, 2014-03-27 at 02:07 -0400, Mike Frysinger wrote:
An amd64 multilib system *is* expected to build x86
binaries that would be hosted on itself.
Dnia 2014-03-27, o godz. 02:13:52
Mike Frysinger vap...@gentoo.org napisał(a):
On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
(2) use tuples with loaded vendor fields to reduce the chance of collisions.
e.g. having an ABI=amd64 system use i686-gentoo%multilib-linux-gnu instead
of
On 27/03/14 08:41, Mike Frysinger wrote:
On Thu 27 Mar 2014 02:31:01 Alexandre Rostovtsev wrote:
On Thu, 2014-03-27 at 02:07 -0400, Mike Frysinger wrote:
An amd64 multilib system *is* expected to build x86
binaries that would be hosted on itself. So i686-pc-linux-gnu-ar is
expected to be not
On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
(2) use tuples with loaded vendor fields to reduce the chance of
collisions. e.g. having an ABI=amd64 system use
really have no idea what you're ranting about. doesn't look discussion worthy
though.
-mike
signature.asc
Description: This is a digitally signed message part.
Hello,
Currently there are four open bugs (see comment 2 in bug 490457) about
imagemagick tools causing access violations while trying to open GPU. There
is working solution:
Mike Frysinger wrote:
Steven J. Long wrote:
Mike Frysinger wrote:
if they're in $PATH, then the exact location is irrelevant.
they need not be in /usr/bin to cause a problem.
if they're not in $PATH, then you're breaking the cross-compilers
and that is unacceptable.
There's a sandbox.d configuration directory on purpose; imagemagick[opencl]
should probably install its own exception.
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
On 27 March 2014 07:29, Maxim Koltsov maksbo...@gentoo.org wrote:
Hello,
Currently there
btw, this is http://bugs.gentoo.org/472766
i'll look into adding a sandbox.d file...
On 27/03/14 10:54, Diego Elio Pettenò wrote:
There's a sandbox.d configuration directory on purpose;
imagemagick[opencl] should probably install its own exception.
Diego Elio Pettenò — Flameeyes
Dnia 2014-03-27, o godz. 03:18:31
Mike Frysinger vap...@gentoo.org napisał(a):
On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
(2) use tuples with loaded vendor fields to
Pacho Ramos dixit:
Due to nirbheek's lack of time the following packages are now up for
grabs:
x11-themes/gtk-engines-murrine
I'm using it, but don't know how to maintain a package yet. Just letting
you know, before you have to throw it out of the tree, I'll take it.
Greetings, Alex
Hello,
Currently there are four open bugs (see comment 2 in bug 490457) about
imagemagick tools causing access violations while trying to open GPU. There
is working solution:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-themes/tango-ico
Tom Wijsman wrote:
If we were to take this example to its extreme; then we would have to
create an inventory of which INSTALL_MASK entries are good and bad for
each ebuild, in which we cover all the files installed by that ebuild.
Why are you directing this at me? Please don't cc me off-list.
Dnia 2014-03-27, o godz. 10:23:30
Mike Frysinger vap...@gentoo.org napisał(a):
On Thu 27 Mar 2014 10:10:07 Michał Górny wrote:
Dnia 2014-03-27, o godz. 03:18:31 Mike Frysinger napisał(a):
On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger
On Thu 27 Mar 2014 10:10:07 Michał Górny wrote:
Dnia 2014-03-27, o godz. 03:18:31 Mike Frysinger napisał(a):
On Thu 27 Mar 2014 07:51:32 Michał Górny wrote:
Dnia 2014-03-27, o godz. 02:13:52 Mike Frysinger napisał(a):
On Wed 26 Mar 2014 01:17:14 Mike Frysinger wrote:
(2) use tuples
On Thu, 27 Mar 2014 13:43:24 +
Steven J. Long wrote:
Tom Wijsman wrote:
It's evidently meant for a few packages which would break, to avoid
obvious breakage, and not as a blanket mechanism.
Yes, it is; but a package consists of multiple ebuilds, and thus, the
individual files of the
On Thu, 27 Mar 2014 12:46:11 +0100
Alexander Hof gentoo...@cosmofox.net wrote:
Pacho Ramos dixit:
Due to nirbheek's lack of time the following packages are now up for
grabs:
x11-themes/gtk-engines-murrine
I'm using it, but don't know how to maintain a package yet. Just
letting you
The current test for MERGE_TYPE in check-reqs_pkg_setup suppresses
also the CHECKREQS_DISK_{USR,VAR} checks which are relevant for binary
installs. Move the test to check-reqs_run().
Also, don't check install disk space requirements if building a binpkg
without installing it.
---
Don't try to display atoms that are None when in debug mode.
---
Can I get an ACK on this please? Do share your ideas for refactoring,
if any. But even if this is not how we want it to work in the end, I
still think we should commit it to fix the bug.
pym/_emerge/depgraph.py | 13 +++--
The first two patches here are not interesting. The first one makes
DEVELOPING cap at the same width as README. The second adds a duh
paragraph on commits. They are only bundled with what I really wanna
talk about because I need ACKs to push them anyway. (Please ACK them,
someone.)
So what I
---
Nothing to see here, move along.
DEVELOPING | 71 +-
1 file changed, 38 insertions(+), 33 deletions(-)
diff --git a/DEVELOPING b/DEVELOPING
index 40b4ca2..1f5087a 100644
--- a/DEVELOPING
+++ b/DEVELOPING
@@ -1,37 +1,39 @@
Code
---
DEVELOPING | 20
1 file changed, 20 insertions(+)
diff --git a/DEVELOPING b/DEVELOPING
index c6004ec..a34dda5 100644
--- a/DEVELOPING
+++ b/DEVELOPING
@@ -175,6 +175,26 @@ change a lot of unrelated things. This makes it easier to
see what
parts of the system have
On Thu, 27 Mar 2014 13:48:40 +0100
Alexander Berntsen berna...@gentoo.org wrote:
---
DEVELOPING | 20
1 file changed, 20 insertions(+)
diff --git a/DEVELOPING b/DEVELOPING
index c6004ec..a34dda5 100644
--- a/DEVELOPING
+++ b/DEVELOPING
@@ -175,6 +175,26 @@ change a
On Thu, 27 Mar 2014 13:48:38 +0100
Alexander Berntsen berna...@gentoo.org wrote:
---
Nothing to see here, move along.
do it.
--
Brian Dolbec dolsen
On Thu, 27 Mar 2014 13:48:39 +0100
Alexander Berntsen berna...@gentoo.org wrote:
---
Boilerplate text, nothing to see here either.
DEVELOPING | 7 +++
1 file changed, 7 insertions(+)
diff --git a/DEVELOPING b/DEVELOPING
index 1f5087a..c6004ec 100644
--- a/DEVELOPING
+++
29 matches
Mail list logo
