-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 27/02/13 01:39, Pavlos Ratis wrote:
I would like to announce you a new try to 'revive' the Bugday
event.
I don't have anything to add. I just wanted to express my support. I'm
told that it is useful to be supportive of people and that they like
On 27 February 2013 05:44, Mike Frysinger (vapier) vap...@gentoo.org wrote:
vapier 13/02/27 05:44:01
# patches go here!
epatch ${FILESDIR}/${PN}-1.19.0-bb.patch
- epatch ${FILESDIR}/${P}-*.patch
+ #epatch ${FILESDIR}/${P}-*.patch
cp
On Tuesday 26 of February 2013 22:28:13 Alec Warner wrote:
On Tue, Feb 26, 2013 at 7:14 PM, Michael Palimaka kensing...@gentoo.org
wrote:
On 27/02/2013 11:39, Pavlos Ratis wrote:
Hello everyone,
I would like to announce you a new try to 'revive' the Bugday event.
As most of the open
On 24/02/13 16:17, hasufell wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote:
On 24/02/2013 11:06, Michał Górny wrote:
Then don't put 'autotools' in the name.
+1
That would be multilib-minimal.eclass then?
Sounds good to me.
ABCD
Alexander Berntsen wrote:
I would like to announce you a new try to 'revive' the Bugday
event.
I don't have anything to add. I just wanted to express my support.
Yeah! Me too! :)
//Peter
On Tue, 26 Feb 2013 17:10:56 +0700 (NOVT)
gro...@gentoo.org wrote:
Hello *,
I am stuck and have many questions.
[In the process of becoming a dev, I've generated a gpg key, of course. It
vwas on an old notebook. When I switched to a newer notebook, I forgot to
copy it, because I don't use
Ryan Hill wrote:
I think I see a lot of our upstream bug reports being closed as
invalid/unsupported. I think that if upstreams wanted to use
jemalloc they would just do so. If they don't then obviously
what they have is working fine for them.
It can make sense to try further discussion,
I don't want to start another useless rant here, because I perfectly
understand the issue with ABI specific headers.
The problem is:
a) if you break a provider on purpose, then you should feel
somehow responsible for the consumers and not just dump testing and
fixing on your fellow devs
b) just
On Wed, 27 Feb 2013 18:10:30 +0100
hasufell hasuf...@gentoo.org wrote:
I don't want to start another useless rant here, because I perfectly
understand the issue with ABI specific headers.
The problem is:
a) if you break a provider on purpose, then you should feel
somehow responsible for
On 02/27/2013 06:58 PM, Alexis Ballier wrote:
The other thing is:
We still have the conflict with eclass-solution vs PM-solution
(multilib-portage) and I propose not to convert ANYTHING else until
that conflict is solved, even if it means a council vote (that's what
I actually think makes
On 27/02/2013 18:10, hasufell wrote:
a) if you break a provider on purpose, then you should feel
somehow responsible for the consumers and not just dump testing and
fixing on your fellow devs
I'd say the only real mistake has been not keeping it masked to begin with.
Just so we're clear with
On Wed, 27 Feb 2013 19:14:38 +0100
hasufell hasuf...@gentoo.org wrote:
On 02/27/2013 06:58 PM, Alexis Ballier wrote:
The other thing is:
We still have the conflict with eclass-solution vs PM-solution
(multilib-portage) and I propose not to convert ANYTHING else until
that conflict is
Unfortunately I didn't have much time to 'refresh' the website. As
Theo said, he gave me the code of the site but I think it would be
great to have something new. If anyone wants to join, ping me on irc.
We could create a new repo at our Github and start developing. Also if
you want to add new
Pavlos Ratis wrote:
Unfortunately I didn't have much time to 'refresh' the website. As
Theo said, he gave me the code of the site but I think it would be
great to have something new. If anyone wants to join, ping me on irc.
We could create a new repo at our Github and start developing.
Don't
Thanks for the partial response Luis.
On Wed, Feb 27, 2013 at 04:12:14PM +0100, Luis Ressel wrote:
On Tue, 26 Feb 2013 17:10:56 +0700 (NOVT)
gro...@gentoo.org wrote:
Hello *,
I am stuck and have many questions.
New addition to the instructions:
0. Copy /usr/share/gnupg/gpg-conf.skel to
On 02/27/2013 07:27 PM, Alexis Ballier wrote:
On Wed, 27 Feb 2013 19:14:38 +0100
hasufell hasuf...@gentoo.org wrote:
On 02/27/2013 06:58 PM, Alexis Ballier wrote:
The other thing is:
We still have the conflict with eclass-solution vs PM-solution
(multilib-portage) and I propose not to
On 2013.02.27 00:39, Pavlos Ratis wrote:
Hello everyone,
I would like to announce you a new try to 'revive' the Bugday event.
As most of the open source projects have their own bugday, I thought
it would be great to have this event back. For those who don't know,
its a monthly 24h event
On Wed, 27 Feb 2013 20:05:58 +0100
hasufell hasuf...@gentoo.org wrote:
Afaiu this seems to be mainly a PMS thing. And changing PMS is slow
and painful, so no wonder people rather want to go for eclass based
solutions.
Eh, the only reason it's slow and painful for multilib is that no-one
seems
On Wed, 27 Feb 2013 20:00:44 +0100
Peter Stuge pe...@stuge.se wrote:
Pavlos Ratis wrote:
Unfortunately I didn't have much time to 'refresh' the website. As
Theo said, he gave me the code of the site but I think it would be
great to have something new. If anyone wants to join, ping me on
On Wed, 27 Feb 2013 15:01:51 +0200
Samuli Suominen ssuomi...@gentoo.org wrote:
On 24/02/13 16:17, hasufell wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote:
On 24/02/2013 11:06, Michał Górny wrote:
Then don't put 'autotools' in the
El mié, 27-02-2013 a las 15:01 +0200, Samuli Suominen escribió:
On 24/02/13 16:17, hasufell wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/24/2013 11:11 AM, Diego Elio Pettenò wrote:
On 24/02/2013 11:06, Michał Górny wrote:
Then don't put 'autotools' in the name.
+1
El mié, 27-02-2013 a las 18:10 +0100, hasufell escribió:
I don't want to start another useless rant here, because I perfectly
understand the issue with ABI specific headers.
The problem is:
a) if you break a provider on purpose, then you should feel
somehow responsible for the consumers
El mié, 27-02-2013 a las 19:27 +0100, Alexis Ballier escribió:
[...]
The reason I bring this up again is that there was a strong argument
yesterday in #gentoo-dev, so it seems the situation is NOT clear.
What are these arguments ? The IRC conspiracy is hard to follow :)
I also read that
On Tue, 26 Feb 2013 08:33:44 -0500
Richard Yao r...@gentoo.org wrote:
The Blender project found some fairly remarkable discrepancies between
what their software actually used and what glibc's ptmalloc allocated:
http://www.sintel.org/development/memory-jemalloc/
Results such as these led
On Wed, 27 Feb 2013 21:20:46 +0100
Pacho Ramos pa...@gentoo.org wrote:
About PM-solution... I can't remember how many years we are waiting it
for being approved, and neither remember what was blocking it for
inclusion in eapi5 (as that threads usually end up being fairly long
and ending with
On Wed, Feb 27, 2013 at 11:04 AM, Robin H. Johnson robb...@gentoo.org wrote:
Thanks for the partial response Luis.
On Wed, Feb 27, 2013 at 04:12:14PM +0100, Luis Ressel wrote:
On Tue, 26 Feb 2013 17:10:56 +0700 (NOVT)
gro...@gentoo.org wrote:
Hello *,
I am stuck and have many questions.
El mié, 27-02-2013 a las 18:58 +0100, Alexis Ballier escribió:
On Wed, 27 Feb 2013 18:10:30 +0100
hasufell hasuf...@gentoo.org wrote:
I don't want to start another useless rant here, because I perfectly
understand the issue with ABI specific headers.
The problem is:
a) if you break
Alexis Ballier schrieb:
On Wed, 27 Feb 2013 18:10:30 +0100
hasufell hasuf...@gentoo.org wrote:
The other thing is:
We still have the conflict with eclass-solution vs PM-solution
(multilib-portage) and I propose not to convert ANYTHING else until
that conflict is solved, even if it means a
Pacho Ramos schrieb:
El mié, 27-02-2013 a las 19:27 +0100, Alexis Ballier escribió:
[...]
The reason I bring this up again is that there was a strong argument
yesterday in #gentoo-dev, so it seems the situation is NOT clear.
What are these arguments ? The IRC conspiracy is hard to follow :)
On Wed, 27 Feb 2013 22:08:45 +0100
Thomas Sachau to...@gentoo.org wrote:
Alexis Ballier schrieb:
On Wed, 27 Feb 2013 18:10:30 +0100
hasufell hasuf...@gentoo.org wrote:
The other thing is:
We still have the conflict with eclass-solution vs PM-solution
(multilib-portage) and I propose
Tom Wijsman wrote:
We could create a new repo at our Github and start developing.
Don't start developing, plz work on bugs instead.
Then who will develop useful tools to handle bugs more efficiently?
Don't get me wrong: I am not hating on useful tools!
I am saying that working on
Hello,
Recently python-r1 and multilib-build started to share a few bits
of code related to running the build process for multiple 'variants'
of the same package. Over time, the code extended and it is a bit
cumbersome to maintain the two copies and keep them in sync.
Therefore, I'd like to
Based on the code from python-r1.
---
gx86/eclass/multibuild.eclass | 172 ++
1 file changed, 172 insertions(+)
create mode 100644 gx86/eclass/multibuild.eclass
diff --git a/gx86/eclass/multibuild.eclass b/gx86/eclass/multibuild.eclass
new file mode
---
gx86/eclass/multibuild.eclass | 4
1 file changed, 4 insertions(+)
diff --git a/gx86/eclass/multibuild.eclass b/gx86/eclass/multibuild.eclass
index d42b8a7..a4d5d11 100644
--- a/gx86/eclass/multibuild.eclass
+++ b/gx86/eclass/multibuild.eclass
@@ -99,6 +99,10 @@ multibuild_foreach() {
---
gx86/eclass/multilib-build.eclass | 45 ++-
1 file changed, 21 insertions(+), 24 deletions(-)
diff --git a/gx86/eclass/multilib-build.eclass
b/gx86/eclass/multilib-build.eclass
index b1afd85..4321e45 100644
--- a/gx86/eclass/multilib-build.eclass
+++
This allows us to spawn 'tee' as separate process while keeping
the function code executed in the main shell.
---
gx86/eclass/multibuild.eclass | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/gx86/eclass/multibuild.eclass b/gx86/eclass/multibuild.eclass
---
gx86/eclass/python-r1.eclass | 61 +++-
1 file changed, 37 insertions(+), 24 deletions(-)
diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
index 310859e..a1d9228 100644
--- a/gx86/eclass/python-r1.eclass
+++
---
gx86/eclass/python-r1.eclass | 74 +---
1 file changed, 21 insertions(+), 53 deletions(-)
diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
index a1d9228..fb9032e 100644
--- a/gx86/eclass/python-r1.eclass
+++
---
gx86/eclass/multibuild.eclass | 19 +++
gx86/eclass/python-r1.eclass | 19 ---
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/gx86/eclass/multibuild.eclass b/gx86/eclass/multibuild.eclass
index a4d5d11..e15b74e 100644
---
Just a quick, dirty example. Not even tested thoroughly ;).
---
gx86/sci-libs/fftw/fftw-3.3.3-r1.ebuild | 38 +
1 file changed, 15 insertions(+), 23 deletions(-)
diff --git a/gx86/sci-libs/fftw/fftw-3.3.3-r1.ebuild
b/gx86/sci-libs/fftw/fftw-3.3.3-r1.ebuild
index
On Wed, 27 Feb 2013 22:30:38 +0100
Peter Stuge pe...@stuge.se wrote:
Tom Wijsman wrote:
We could create a new repo at our Github and start developing.
Don't start developing, plz work on bugs instead.
Then who will develop useful tools to handle bugs more efficiently?
Don't
Tom Wijsman wrote:
I am saying that working on tools that help you work on open bugs is
not orthogonal to fixing open bugs, it helps you fix them efficiently.
Sure, but on the bugday itself it sounds on the name like the idea is
to work on bugs with currently available tools, rather than work
On 02/24/2013 11:39 PM, Samuli Suominen wrote:
On 24/02/13 02:34, hasufell wrote:
Some people seem to feel uncomfortable with autotools-multilib, because
it depends on autotools-utils.
Instead of arguing whether it makes sense or not I'd propose a similar
autotools related eclass.
I also
On Thu, 28 Feb 2013 01:20:01 +0100
Peter Stuge pe...@stuge.se wrote:
Sure, but on the bugday itself it sounds on the name like the idea is
to work on bugs with currently available tools, rather than work on
tools to work on bugs .. some other time.
Neither of us did suggest such thing.
@neddyseagoon: Yeah it would be great to have it back, I think the day
should remain as is. Every first Saturday of every month. Thanks.
@TomWij and Peter: Well guys, I think you should not expand the topic
so much, lets stay to the bugday. As I said in my first post, bugday's
goal is to close as
45 matches
Mail list logo