Revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8

Revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8

[Philip Balister]

I'd like to revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8. With 
this commit my build that includes angstrom-task-gnome.bb fails in a 
peculiar way. Basically, my process table is filled with a task. Looks 
like it is trying to run a pkg-config gtk+ operation. This is with 
angstrom-2010.x and a custom machine very similar to an overo.

I realize this is a vague description, but I do not have time to isolate 
better at this time.

Can we go ahead and revert this for now?

Philip


[1] 
http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=c2c8fe4c5629add94bd0b922f5b3446624a9f4d8

Re: Revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8

[Philip Balister]

On 11/19/2010 02:28 PM, Philip Balister wrote:
> I'd like to revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8. With
> this commit my build that includes angstrom-task-gnome.bb fails in a
> peculiar way. Basically, my process table is filled with a task. Looks
> like it is trying to run a pkg-config gtk+ operation. This is with
> angstrom-2010.x and a custom machine very similar to an overo.
>
> I realize this is a vague description, but I do not have time to isolate
> better at this time.
>
> Can we go ahead and revert this for now?

This has been tracked to the xmms package. Anyone have any ideas how we 
can fix the problem?

Philip


>
> Philip
>
>
> [1]
> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=c2c8fe4c5629add94bd0b922f5b3446624a9f4d8
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8

[Yury Bushmelev]

2010/11/21 Philip Balister <philip@balister.org>:
> On 11/19/2010 02:28 PM, Philip Balister wrote:
>>
>> I'd like to revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8. With
>> this commit my build that includes angstrom-task-gnome.bb fails in a
>> peculiar way. Basically, my process table is filled with a task. Looks
>> like it is trying to run a pkg-config gtk+ operation. This is with
>> angstrom-2010.x and a custom machine very similar to an overo.
>>
>> I realize this is a vague description, but I do not have time to isolate
>> better at this time.
>>
>> Can we go ahead and revert this for now?
>
> This has been tracked to the xmms package. Anyone have any ideas how we can
> fix the problem?

I've affected by this problem with angstrom-2008.1 first time when
tried to build angstrom-gnome-image, second time when tried to build
just xmms.

-- 
Yury Bushmelev

Re: Revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8

[Andreas Oberritter]

On 11/19/2010 11:28 PM, Philip Balister wrote:
> I'd like to revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8. With
> this commit my build that includes angstrom-task-gnome.bb fails in a
> peculiar way. Basically, my process table is filled with a task. Looks
> like it is trying to run a pkg-config gtk+ operation. This is with
> angstrom-2010.x and a custom machine very similar to an overo.
> 
> I realize this is a vague description, but I do not have time to isolate
> better at this time.
> 
> Can we go ahead and revert this for now?

No, please don't.

I'm 100% sure that this patch is the only sane way of handling
pkg-config files. I hope you agree that it wasn't possible for me to
test every single package before this got merged.

Still, the solution for problems popping up now is simple: Make sure
that required libraries install their pkg-config files themselves.
Usually, they would already do it, but their install rules are
overridden by custom do_install or do_stage rules in their bitbake recipe.

As you already mentioned, the package causing the problem is gtk+
(gtk+-1.2_1.2.10.bb).

The solution in this case is very likely to
- remove do_stage
- add ${bindir}/gtk-config to FILES_${PN}-dev
- bump PR

The real problem is gtk-config going crazy when gtk's pkg-config file is
not installed.

I'd have already submitted a patch, but testing takes a lot of time,
especially when a recipe takes down the build machine.

Maybe it would be wise for bitbake or OE to set ulimit -u to a sane
value. Is there a way for a process to count the number of its direct
and indirect child processes?

Regards,
Andreas

Re: Revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8

[Khem Raj]

On Sun, Nov 21, 2010 at 6:56 AM, Andreas Oberritter
<obi@opendreambox.org> wrote:
> On 11/19/2010 11:28 PM, Philip Balister wrote:
>> I'd like to revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8. With
>> this commit my build that includes angstrom-task-gnome.bb fails in a
>> peculiar way. Basically, my process table is filled with a task. Looks
>> like it is trying to run a pkg-config gtk+ operation. This is with
>> angstrom-2010.x and a custom machine very similar to an overo.
>>
>> I realize this is a vague description, but I do not have time to isolate
>> better at this time.
>>
>> Can we go ahead and revert this for now?
>
> No, please don't.
>
> I'm 100% sure that this patch is the only sane way of handling
> pkg-config files. I hope you agree that it wasn't possible for me to
> test every single package before this got merged.
>

agreed. but we are soon going to make a release. So it compiled (in
whatever way)
and now it doesnt (looking from 36000 ft above).
So either we fix the known regressions caused or backout because we
can not make release in this state for sure.

> Still, the solution for problems popping up now is simple: Make sure
> that required libraries install their pkg-config files themselves.
> Usually, they would already do it, but their install rules are
> overridden by custom do_install or do_stage rules in their bitbake recipe.
>
> As you already mentioned, the package causing the problem is gtk+
> (gtk+-1.2_1.2.10.bb).
>
> The solution in this case is very likely to
> - remove do_stage
> - add ${bindir}/gtk-config to FILES_${PN}-dev
> - bump PR
>

super can you cook up a patch.

> The real problem is gtk-config going crazy when gtk's pkg-config file is
> not installed.
>
> I'd have already submitted a patch, but testing takes a lot of time,
> especially when a recipe takes down the build machine.
>
> Maybe it would be wise for bitbake or OE to set ulimit -u to a sane
> value. Is there a way for a process to count the number of its direct
> and indirect child processes?
>
> Regards,
> Andreas
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8

[Andreas Oberritter]

On 11/21/2010 05:17 PM, Khem Raj wrote:
> On Sun, Nov 21, 2010 at 6:56 AM, Andreas Oberritter
> <obi@opendreambox.org> wrote:
>> On 11/19/2010 11:28 PM, Philip Balister wrote:
>>> I'd like to revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8. With
>>> this commit my build that includes angstrom-task-gnome.bb fails in a
>>> peculiar way. Basically, my process table is filled with a task. Looks
>>> like it is trying to run a pkg-config gtk+ operation. This is with
>>> angstrom-2010.x and a custom machine very similar to an overo.
>>>
>>> I realize this is a vague description, but I do not have time to isolate
>>> better at this time.
>>>
>>> Can we go ahead and revert this for now?
>>
>> No, please don't.
>>
>> I'm 100% sure that this patch is the only sane way of handling
>> pkg-config files. I hope you agree that it wasn't possible for me to
>> test every single package before this got merged.
>>
> 
> agreed. but we are soon going to make a release. So it compiled (in
> whatever way)
> and now it doesnt (looking from 36000 ft above).
> So either we fix the known regressions caused or backout because we
> can not make release in this state for sure.

Soon means in 10 days AFAIK, and you can still revert the patch in the
release branch if needed. No need to revert it in master just to hide
already existing bugs.

>> Still, the solution for problems popping up now is simple: Make sure
>> that required libraries install their pkg-config files themselves.
>> Usually, they would already do it, but their install rules are
>> overridden by custom do_install or do_stage rules in their bitbake recipe.
>>
>> As you already mentioned, the package causing the problem is gtk+
>> (gtk+-1.2_1.2.10.bb).
>>
>> The solution in this case is very likely to
>> - remove do_stage
>> - add ${bindir}/gtk-config to FILES_${PN}-dev
>> - bump PR
>>
> 
> super can you cook up a patch.

Sure, but only after I either received positive feedback or the build on
my newly set up host finished. That's why I wrote:

>> I'd have already submitted a patch, but testing takes a lot of time,
>> especially when a recipe takes down the build machine.

Regards,
Andreas

Re: Revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8

[Chris Larson]

On Sun, Nov 21, 2010 at 10:23 AM, Andreas Oberritter
<obi@opendreambox.org>wrote:

> > agreed. but we are soon going to make a release. So it compiled (in
> > whatever way)
> > and now it doesnt (looking from 36000 ft above).
> > So either we fix the known regressions caused or backout because we
> > can not make release in this state for sure.
>
> Soon means in 10 days AFAIK, and you can still revert the patch in the
> release branch if needed. No need to revert it in master just to hide
> already existing bugs.


The release branch is being merged back to master after the release is
tagged, FYI.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: Revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8

[Philip Balister]

On 11/21/2010 09:23 AM, Andreas Oberritter wrote:
> On 11/21/2010 05:17 PM, Khem Raj wrote:
>> On Sun, Nov 21, 2010 at 6:56 AM, Andreas Oberritter
>> <obi@opendreambox.org>  wrote:
>>> On 11/19/2010 11:28 PM, Philip Balister wrote:
>>>> I'd like to revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8. With
>>>> this commit my build that includes angstrom-task-gnome.bb fails in a
>>>> peculiar way. Basically, my process table is filled with a task. Looks
>>>> like it is trying to run a pkg-config gtk+ operation. This is with
>>>> angstrom-2010.x and a custom machine very similar to an overo.
>>>>
>>>> I realize this is a vague description, but I do not have time to isolate
>>>> better at this time.
>>>>
>>>> Can we go ahead and revert this for now?
>>>
>>> No, please don't.
>>>
>>> I'm 100% sure that this patch is the only sane way of handling
>>> pkg-config files. I hope you agree that it wasn't possible for me to
>>> test every single package before this got merged.
>>>
>>
>> agreed. but we are soon going to make a release. So it compiled (in
>> whatever way)
>> and now it doesnt (looking from 36000 ft above).
>> So either we fix the known regressions caused or backout because we
>> can not make release in this state for sure.
>
> Soon means in 10 days AFAIK, and you can still revert the patch in the
> release branch if needed. No need to revert it in master just to hide
> already existing bugs.

If we can fix this before the release, I am happy. It looks like several 
people are working on this. I'll be traveling most of the next week, but 
I will try to keep testing .dev to make sure this is OK for the release.

Thanks for working on this issue!

Philip



>
>>> Still, the solution for problems popping up now is simple: Make sure
>>> that required libraries install their pkg-config files themselves.
>>> Usually, they would already do it, but their install rules are
>>> overridden by custom do_install or do_stage rules in their bitbake recipe.
>>>
>>> As you already mentioned, the package causing the problem is gtk+
>>> (gtk+-1.2_1.2.10.bb).
>>>
>>> The solution in this case is very likely to
>>> - remove do_stage
>>> - add ${bindir}/gtk-config to FILES_${PN}-dev
>>> - bump PR
>>>
>>
>> super can you cook up a patch.
>
> Sure, but only after I either received positive feedback or the build on
> my newly set up host finished. That's why I wrote:
>
>>> I'd have already submitted a patch, but testing takes a lot of time,
>>> especially when a recipe takes down the build machine.
>
> Regards,
> Andreas
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8

[Yury Bushmelev]

2010/11/21 Andreas Oberritter <obi@opendreambox.org>:

> Maybe it would be wise for bitbake or OE to set ulimit -u to a sane
> value. Is there a way for a process to count the number of its direct
> and indirect child processes?

Hm.. I'll count # of processes used while building OE with next testbuilder run.
Just for our info and for my fun :)

-- 
Yury Bushmelev

Merging the release branch into master (was: Re: Revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8)

[Andreas Oberritter]

On 11/21/2010 06:55 PM, Chris Larson wrote:
> The release branch is being merged back to master after the release is
> tagged, FYI.

I've been thinking about it, but I'm not really sure what the point is
in that if all fixes should already be in master before entering the
release branch, except for maybe some release-branch specific stuff
(which in turn must not exist, because it would get merged into master
after release has been tagged)? You can't even put some release notes
into the release branch?

Also, a revert can be reverted again, if needed, before a merge, i.e.
revert, tag, release, unrevert, merge, delete.

Re: Merging the release branch into master (was: Re: Revert commit c2c8fe4c5629add94bd0b922f5b3446624a9f4d8)

[Chris Larson]

On Mon, Nov 22, 2010 at 7:29 AM, Andreas Oberritter <obi@opendreambox.org>wrote:

> On 11/21/2010 06:55 PM, Chris Larson wrote:
> > The release branch is being merged back to master after the release is
> > tagged, FYI.
>
> I've been thinking about it, but I'm not really sure what the point is
> in that if all fixes should already be in master before entering the
> release branch, except for maybe some release-branch specific stuff
> (which in turn must not exist, because it would get merged into master
> after release has been tagged)? You can't even put some release notes
> into the release branch?
>

Primarily for clean git logs.  By *marking* it merged, even though the merge
wouldn't actually make any changes to content, we ensure that git knows
there are no commits in the release tag that aren't also in master (git log
master..releasetag would show nothing, rather than every cherry pick).
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics