Mailing List Archive

Matteo Azzali wrote:
> This is just a mine question, but it seems that since gcc-4.1 got it's
> way into portage (~branch) things are getting slower.
>
> Lots of the bugs blocking bug #117482 -
> http://bugs.gentoo.org/show_bug.cgi?id=117482 - have a patch in the report
> or an ebuild for revision bump, tested working.
> They just don't get committed (or, sometimes, closed).
>
> IMHO these bugs should get some kind of "priority", cause actually any
> unstable system having one of these "blocking ebuilds"
> in world tree will have issue emerging,for sure.
> ( for who didn't noticed: gcc-4.1 is actually in portage testing , no
> more unmasked).

Sometimes people get busy, I know I haven't looked at my bugs all week,
been busy at work 12 hours a day. As such if it's a big problem you can
always gcc-config <some-other-compiler-version> and then compile any
problem packages. I know that breaks the whole 'my whole system is
compiled w/gcc-4.1' deal, but if it's that big of a blocker, take
action. Or hell, patch the ebuild yourself.

I think this distro was (or is?) about giving users the ability to do
what they needed. If something is masked, you can unmask it, if it's
not keyworded you can keyword it, if it's not patched, you can patch it

>
> thanks for your time and for listening my 2 cents.
>
> mattepiu

--
gentoo-dev@gentoo.org mailing list

Hum, maybe my little english is not good to explain my thoughts.....

I already have a /usr/local/portage overlay bigger than 500Kb.

What I was asking is if it's a normal behaviour that emerge "stops" for
unstable branch users.
I asked myself this after looking some ebuilds that have more than 4
versions in portage but
still none of these (neither unstable or masked) works with gcc-4.1.x
(for example fox, 11 different versions in portage and the gcc-4.1.x
ebuild (stabled upstream)
still floating in bugreport #132407 of 5-apr-2006 and bug #128917 of
5-may-2006 ,
but fox is just an example, and there could be causes I don't know.......)

No meant to harm anyone, sorry if you get mad, still completely my
personal opinion and
nothing more.

mattepiu




Alec Warner wrote:
> Matteo Azzali wrote:
>> This is just a mine question, but it seems that since gcc-4.1 got it's
>> way into portage (~branch) things are getting slower.
>>
>> Lots of the bugs blocking bug #117482 -
>> http://bugs.gentoo.org/show_bug.cgi?id=117482 - have a patch in the
>> report
>> or an ebuild for revision bump, tested working.
>> They just don't get committed (or, sometimes, closed).
>>
>> IMHO these bugs should get some kind of "priority", cause actually any
>> unstable system having one of these "blocking ebuilds"
>> in world tree will have issue emerging,for sure.
>> ( for who didn't noticed: gcc-4.1 is actually in portage testing , no
>> more unmasked).
>
> Sometimes people get busy, I know I haven't looked at my bugs all
> week, been busy at work 12 hours a day. As such if it's a big problem
> you can always gcc-config <some-other-compiler-version> and then
> compile any problem packages. I know that breaks the whole 'my whole
> system is compiled w/gcc-4.1' deal, but if it's that big of a blocker,
> take action. Or hell, patch the ebuild yourself.
>
> I think this distro was (or is?) about giving users the ability to do
> what they needed. If something is masked, you can unmask it, if it's
> not keyworded you can keyword it, if it's not patched, you can patch it
>
>>
>> thanks for your time and for listening my 2 cents.
>>
>> mattepiu
>

--
gentoo-dev@gentoo.org mailing list

On 08/06/06, Matteo Azzali <matte.az@libero.it> wrote:
> Hum, maybe my little english is not good to explain my thoughts.....
>
> I already have a /usr/local/portage overlay bigger than 500Kb.

I can beat that, try 23MB :-/

Anyway, back to your point - yes, there are lots of bugs with patches
attached that aren't being added to the main tree. And there are lots
of bugs where the ebuild or fix is ending up in an overlay rather than
the main tree. It's getting complicated to keep track - all I can
really advise is that if you'd like to see fixes and ebuilds being
added to the main tree, then become a developer and start doing it
(although it is complex for something like gcc compile fixes which are
spread across packages owned by multiple developers who will get upset
if you touch their package).
--
gentoo-dev@gentoo.org mailing list

On Thu, 2006-06-08 at 13:42 +0100, Chris Bainbridge wrote:
> On 08/06/06, Matteo Azzali <matte.az@libero.it> wrote:
> > Hum, maybe my little english is not good to explain my thoughts.....
> >
> > I already have a /usr/local/portage overlay bigger than 500Kb.
>
> I can beat that, try 23MB :-/
>
> Anyway, back to your point - yes, there are lots of bugs with patches
> attached that aren't being added to the main tree. And there are lots
> of bugs where the ebuild or fix is ending up in an overlay rather than
> the main tree. It's getting complicated to keep track - all I can
> really advise is that if you'd like to see fixes and ebuilds being
> added to the main tree, then become a developer and start doing it
> (although it is complex for something like gcc compile fixes which are
> spread across packages owned by multiple developers who will get upset
> if you touch their package).

Actually, this isn't exactly true. In the case of a compile fix, such
as this, the developer is aware of the issue, and gcc-porting@ is on the
bug, too, as CC, usually. If someone from gcc-porting were to go around
committing patches to my ebuilds, I know I wouldn't mind. It would
reduce my workload greatly, especially as they're the experts on what is
and isn't allowed in gcc 4.1, versus myself, who is a gcc 4.1
amateur. ;]

The truth is that there's tens of thousands of possible patch-providers
(users) and only ~300 people with commit rights. Even fewer when you
consider that the package in question may have a single maintainer, or
only a small team. Most of the packages that are blocking that bug are
games. We're working on them, but there's a small group of us and a
very large number of packages, many of which are very poorly coded and
require a lot of work and testing.

--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

Ehrm, I'm already becomed developer (some days) *,
I'm already the author of lots of patches/comment in those reports,
and as you pointed out I must follow rules and can't "jump" maintainers
(who surely have better understanding of the issue involved than me).

That's the cause of the question,my (little?) brain asked me
"Why there are so much version of a package in portage, and why
following bugs for
version that aren't the latest stable and the latest unstable (for any
arch) instead of
ensuring that those 2/3 versions work fine?" , I mean, because in some
cases a revision
bump is necessary to let unstable work fine, (and these will be
necessary however when
gcc-4.x will become stable) why delaying trying to fix bugs specific of
older versions,
probably resolved upstream with new ones?

(I know, my brain is nasty and doesn't works as others may expect).


Other than this, 23MB of overlay? But you "clean" it or you keep stored
every line
of code you wrote?
If you regularly clean your overlay (keeping no more than 2-3 ebuilds
for package),
then it's really huge and impressive!

mattepiu@gentoo.org

* (I'm not sending mails through gentoo.org account cause
http://www.gentoo.org/proj/en/infrastructure/dev-email.xml
asks me to not use it to send mails "unless absolutely necessary." , and
I have others mean of sending emails....)



Chris Bainbridge wrote:
> On 08/06/06, Matteo Azzali <matte.az@libero.it> wrote:
>> Hum, maybe my little english is not good to explain my thoughts.....
>>
>> I already have a /usr/local/portage overlay bigger than 500Kb.
>
> I can beat that, try 23MB :-/
>
> Anyway, back to your point - yes, there are lots of bugs with patches
> attached that aren't being added to the main tree. And there are lots
> of bugs where the ebuild or fix is ending up in an overlay rather than
> the main tree. It's getting complicated to keep track - all I can
> really advise is that if you'd like to see fixes and ebuilds being
> added to the main tree, then become a developer and start doing it
> (although it is complex for something like gcc compile fixes which are
> spread across packages owned by multiple developers who will get upset
> if you touch their package).

--
gentoo-dev@gentoo.org mailing list

> mattepiu@gentoo.org
>
> * (I'm not sending mails through gentoo.org account cause
> http://www.gentoo.org/proj/en/infrastructure/dev-email.xml
> asks me to not use it to send mails "unless absolutely necessary." , and
> I have others mean of sending emails....)

You should always use it on official gentoo mailing lists.

-Steve
--
gentoo-dev@gentoo.org mailing list

Matteo Azzali <matte.az@libero.it> wrote:
> mattepiu@gentoo.org
>
> * (I'm not sending mails through gentoo.org account cause
> http://www.gentoo.org/proj/en/infrastructure/dev-email.xml asks me to
> not use it to send mails "unless absolutely necessary." , and I have
> others mean of sending emails....)

I just took a look at that. It's asking that you don't relay mail
through dev.gentoo.org unless you can't send mail through your usual
means of sending mail. For example, if your ISP blocks mail if the From:
header indicates something other @myisp.com, then you need to relay
through dev.gentoo.org.

In any case, it's not telling you to avoid using your @gentoo.org
account.

Of course, somebody flame me if I'm wrong.

--
my other signature is witty

On Thu, Jun 08, 2006 at 07:00:33PM -0700, Drake Wyrm wrote:
> I just took a look at that. It's asking that you don't relay mail
> through dev.gentoo.org unless you can't send mail through your usual
> means of sending mail. For example, if your ISP blocks mail if the From:
> header indicates something other @myisp.com, then you need to relay
> through dev.gentoo.org.
>
> In any case, it's not telling you to avoid using your @gentoo.org
> account.

Yupp.

>
> Of course, somebody flame me if I'm wrong.

No flames from me - i send my from: amne@gentoo.org mails via my
university's gateway as well. ;-)

cheers,
Wernfried

--
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

On Thursday 08 June 2006 15:34, Chris Gianelloni wrote:
> Actually, this isn't exactly true. In the case of a compile fix, such
> as this, the developer is aware of the issue, and gcc-porting@ is on the
> bug, too, as CC, usually. If someone from gcc-porting were to go around
> committing patches to my ebuilds, I know I wouldn't mind. It would
> reduce my workload greatly, especially as they're the experts on what is
> and isn't allowed in gcc 4.1, versus myself, who is a gcc 4.1
> amateur. ;]
>
> The truth is that there's tens of thousands of possible patch-providers
> (users) and only ~300 people with commit rights. Even fewer when you
> consider that the package in question may have a single maintainer, or
> only a small team. Most of the packages that are blocking that bug are
> games. We're working on them, but there's a small group of us and a
> very large number of packages, many of which are very poorly coded and
> require a lot of work and testing.

Perhaps we should do something about this problem. There are still many
committers. Take myself for example, I have (of course) my own overlay, and
sometimes I must confess that I just fix these kinds of bugs for myself, add
it to my overlay and forget about it. Perhaps if it were easier to fix these
things in tree, it would be better for gentoo. I do not mean to say that it
should become a free-for-all, but fixing these kinds of issues is beneficial.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

On Thu, 2006-06-15 at 22:36 +0200, Paul de Vrieze wrote:
> On Thursday 08 June 2006 15:34, Chris Gianelloni wrote:
> > Actually, this isn't exactly true. In the case of a compile fix, such
> > as this, the developer is aware of the issue, and gcc-porting@ is on the
> > bug, too, as CC, usually. If someone from gcc-porting were to go around
> > committing patches to my ebuilds, I know I wouldn't mind. It would
> > reduce my workload greatly, especially as they're the experts on what is
> > and isn't allowed in gcc 4.1, versus myself, who is a gcc 4.1
> > amateur. ;]
> >
> > The truth is that there's tens of thousands of possible patch-providers
> > (users) and only ~300 people with commit rights. Even fewer when you
> > consider that the package in question may have a single maintainer, or
> > only a small team. Most of the packages that are blocking that bug are
> > games. We're working on them, but there's a small group of us and a
> > very large number of packages, many of which are very poorly coded and
> > require a lot of work and testing.
>
> Perhaps we should do something about this problem. There are still many
> committers. Take myself for example, I have (of course) my own overlay, and
> sometimes I must confess that I just fix these kinds of bugs for myself, add
> it to my overlay and forget about it. Perhaps if it were easier to fix these
> things in tree, it would be better for gentoo. I do not mean to say that it
> should become a free-for-all, but fixing these kinds of issues is beneficial.

If *any* developer came to us with a patch for GCC 4.1.1 and one of our
games and asks if they can fix it, I know for a fact that I will
definitely say yes. I'm pretty sure none of the other guys would object
to it, either.

--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux