@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
On Thu, 28 Feb 2013 01:20:01 +0100
Peter Stuge 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.
> > Yes, one shal
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.
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 Wed, 27 Feb 2013 22:30:38 +0100
Peter Stuge 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
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 1
---
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
--- a/gx86/eclass/multibu
---
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
+++ b/gx86/eclass/python-
---
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
+++ b/gx86/eclass/python-
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
ind
---
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
+++ b/gx8
---
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() {
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 100644
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 propo
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 Wed, 27 Feb 2013 22:08:45 +0100
Thomas Sachau wrote:
> Alexis Ballier schrieb:
> > On Wed, 27 Feb 2013 18:10:30 +0100
> > hasufell wrote:
> >
> >> The other thing is:
> >> We still have the conflict with eclass-solution vs PM-solution
> >> (multilib-portage) and I propose not to convert ANYT
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
Alexis Ballier schrieb:
> On Wed, 27 Feb 2013 18:10:30 +0100
> hasufell 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 v
El mié, 27-02-2013 a las 18:58 +0100, Alexis Ballier escribió:
> On Wed, 27 Feb 2013 18:10:30 +0100
> hasufell 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 provi
On Wed, Feb 27, 2013 at 11:04 AM, Robin H. Johnson 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.
>
>
On Wed, 27 Feb 2013 21:20:46 +0100
Pacho Ramos 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 blockers like
On Tue, 26 Feb 2013 08:33:44 -0500
Richard Yao 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 Blender an
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
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 consume
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
On Wed, 27 Feb 2013 15:01:51 +0200
Samuli Suominen 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 name
On Wed, 27 Feb 2013 20:00:44 +0100
Peter Stuge 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
> > irc.
On Wed, 27 Feb 2013 20:05:58 +0100
hasufell 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 to know what's ac
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 eve
On 02/27/2013 07:27 PM, Alexis Ballier wrote:
> On Wed, 27 Feb 2013 19:14:38 +0100
> hasufell 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 con
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.ske
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.
Do
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 ide
On Wed, 27 Feb 2013 19:14:38 +0100
hasufell 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 solve
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 wi
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 thi
On Wed, 27 Feb 2013 18:10:30 +0100
hasufell 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 the consumers a
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 t
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,
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
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 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 al
On Tuesday 26 of February 2013 22:28:13 Alec Warner wrote:
> On Tue, Feb 26, 2013 at 7:14 PM, Michael Palimaka
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 source p
On 27 February 2013 05:44, Mike Frysinger (vapier) 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 "${FILESDIR}"/ginit.c
-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 lik
45 matches
Mail list logo
