* [PATCH 1/3] allarch.bbclass: disable shlib and debug symbol processing
From: Paul Eggleton @ 2011-11-04 17:52 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1320429060.git.paul.eggleton@linux.intel.com>
all-arch packages should not contain any binaries that need processing,
so disable the shared library dependency processing and debug symbol
splitting/stripping to save some time during packaging.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
meta/classes/allarch.bbclass | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index a2f8179..18c9ae2 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -15,3 +15,8 @@ TARGET_CC_ARCH = "none"
TARGET_LD_ARCH = "none"
TARGET_AS_ARCH = "none"
PACKAGE_EXTRA_ARCHS = ""
+
+# No need to do shared library processing or debug symbol handling
+EXCLUDE_FROM_SHLIBS = "1"
+INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
+INHIBIT_PACKAGE_STRIP = "1"
--
1.7.5.4
^ permalink raw reply related
* [PATCH 0/3] Misc fixes
From: Paul Eggleton @ 2011-11-04 17:52 UTC (permalink / raw)
To: openembedded-core
The following changes since commit f01fbc17b5d9bf9a227d64fe858014376cd19432:
avahi: fix useradd race condition (2011-11-03 14:48:42 +0000)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib paule/fixes8
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/fixes8
Paul Eggleton (3):
allarch.bbclass: disable shlib and debug symbol processing
core-image-minimal-initramfs: force IMAGE_FSTYPES
qemugl: switch to new git repo
meta/classes/allarch.bbclass | 5 +++++
.../images/core-image-minimal-initramfs.bb | 1 +
meta/recipes-graphics/mesa/qemugl_git.bb | 2 +-
3 files changed, 7 insertions(+), 1 deletions(-)
--
1.7.5.4
^ permalink raw reply
* OpenEmbedded General Assembly, 28 November 2011, Prague, CZ
From: Jeff Osier-Mixon @ 2011-11-04 17:28 UTC (permalink / raw)
To: openembedded-devel, openembedded-core, openembedded-members, tsc
[-- Attachment #1: Type: text/plain, Size: 28863 bytes --]
OpenEmbedded General Assembly, 28 November 2011, 6pm-9pm CET
Clarion Congress Hotel, Prague, CZ
Proceedings taken by Jeff Osier-Mixon, apologies for any misspellings
_____________________________________________________________________
Members present:
Board:
Philip Balister
Florian Boer
Membership:
Robert Schuster
Richard Purdie
Paul Eggleton
Marcin Juszkiewicz
Martin Jansa
Dirk Hohndel
Anden Darrander
David Stewart
Saul Wold
Frans Meulenbroeks
Esben Haabendal
Sean Hudson
Koen Kooi
Jeff Osier-Mixon
Total membership is 54, of which 32 were represented, including proxies
Proxy representation:
in person proxy 1 proxy 2
Phlip Balister Steve Sakoman Denys Dmytriyenko
Florian Boer
Robert Schuster
Richard Purdie Phil Blundell Joshua Lock
Paul Eggleton Andrea Adami Dmitry Eremin-Solenikov
Marcin Juszkiewicz
Martin Jansa Tom King Simon Busch
Dirk Hohndel
Anden Darrander
David Stewart Scott Garman Marco Cavallino
Saul Wold Yu Ke Mark Hatle
Frans Meulenbroeks Andreas Oberitter Michael Lauer
Esben Haabendal
Sean Hudson
Koen Kooi Khem Raj Graeme Gregory
Jeff Osier-Mixon
Meeting chair: Philip Balister
_____________________________________________________________________
Agenda
- Financial status (Florian)
- Budget plan (Philip)
also discuss conferences
- Discussion on Phil Blundell's proposed voting procedure changes
if on members list, look over voting changes
- Discussion of relaxing 2-proxy rule
Richard: 2 to 4, proxy easy to change
superseded by Phil's proposal
on wiki under Organization
- Secretary
- Discuss future GA in the US
_____________________________________________________________________
Proceedings
Note: initials are used to indicate speakers
FB: financial status
not too bad
currently have 2000 euros left, mostly from a few donations from TI
& 2 other people to paypal acct
at least 1 requested anonymity
bank account: €2098.84 (local acct sprachasz ziegen), paypal: €141.28 (2
donations of €100 minus fees)
request 2 members present take look at written summaries
volunteers to check that paperwork is correct - Dirk & Sean
SH: dont see ti donation
FB: took a year to find out what forms to sign
DH: balance of paypal missing, otherwise books ok - SH concurs
expenses:
travel reimbursement 2010 for oedem in 2009 €200
€1086.33 = US$1500 plus €50 fees for hosting to OSUOSL
written donation receipt not exact amount due to entropy
bank in Germany takes some fees, US bank takes some fees
wire transfer, shared cost
not enough time to hunt down best way of tranferring mone
paypal is relatively expensive
donation of US$100, fees of 4.20%
to do: take whole amount of paypal & transfer to bank acct, stories of
frozen paypal accounts
bank acct already tied to paypal acct
question: need to spend money donated in 1/2 year?
FB: no, supposed to spend money we have at the time
can think about useful things to spend it on
PB: need to carry some money in case of emergency
DH: can not use eV to park money, e.g. if had 180k and would make money
on interest
for a group with 50 members, €2000 is reasonable & not a problem
FB: will solve that problem when we hit it
PB: no one inside TI noticed, accounting bouncing, took a long time to
figure out
now have correct form
KK: if in EU, read website of banking on how to transfer between EU
countries
PB: EU to US$ is a pain (EU countries specifically, not Europe in general)
PB: Budget plan
coming expenses:
€500 for an event box, can put together before FOSDEM (4-5 February,
Brussels)
cannot ship to FOSDEM, someone needs to take - collect dev boards,
cables, etc
not planning to ship video wall - only something a human can carry
plan is for human portable and not 9 monitors, not talking about Koen's
wall
PB: problem with budget planning is no steady income
DH: talk about reimburse travel for events, e.g. Florian made special
trip to come here
some go to FOSDEM
PB: people make trips to events to present OE stuff
KK: written down conditions to reimburse? no, basically using for
emergency or case by case
PB: not spinning enough cash to sponsor for travel
PB:
need to provide financial support to OSUOSL
our machines live in rack run by NAS admin, predate a lot of OSU people
there now
attended talk at LinuxCon Vancouver about history of OSUOSL
Leslie Hawthorn now working there
they are hiring sysadmins
spending money, project brings prestige to WORST university
(university used to be Western ORegon STate == WORST)
not a fly-by-night university operation
any help we can get for admin team would be helpful
right now admins are volunteers with day jobs
Tom King logs in from mountaintops
part of budget planning, basically incur costs from OSU for bandwidth &
occasional kick machine
KK: hardware from LF, yocto, ? if company donates large sum to yocto, do
we see anything coming out?
PB:
donation receipt for 1 machine - donations to yocto internal to yocto,
encourage donations to OSUOSL instead of yocto
if feeling generous and dont want to donate to ev, osu has web form
put down "for OE" on donation form
want OE to remain as a sponsor for the lab
significant costs to move money around, so donate to OSU and put on form
"for OE"
they can aggregate contribs as OE, sponsor levels - over US$2000 is
bronze sponsor
need to encourage people to support OSU
let us know if donate
we have paypal which is not great but better than not having money
given no stable income, welcome comments on generating stable income, if
so what should we do with it?
KK: list of companies using OE? with contacts?
PB: could do that, but without spending plan hard to ask for money
DH: would membership think a funded travel fund important?
solicit money, finding in relatively small quantities not that hard
has to be a plan what to do with it, needs to make sense to membership
within ethical boundaries of what companies find acceptable
giving presentations at events, infrastructure
FB: mostly a communication problem
1 - need better communcation, website, what spending money on
going forward, what to spend
2 - need to define target, say 5000 10000 etc. to spend on this, that, or
some other thing
makes communication with ev much easier for companies donating money
KK: legally have to say what money is spent on
DH: can specify donation for travel fund e.g.
legal consequences for not following guidance
can't say "travel fund only for TI employees", e.g., but can say this is
for travel fund
PB: safest is unrestricted gifts
what about PR material, banners, etc
FB: mostly for tables e.g. FOSDEM, don't look good
why donate travel money if people coming [sponsored by companies] anyway
SH: need to clarify
perhaps offer training? lots of smart people on IRC willing to help
people out for free
but might be opportunity to set up training for companies, private
individuals
DH: dangerous, risking status as eV - can't provide services for a fee
PB: if came up, encourage individuals to do it on their own and remember
us fondly
KK: used to refer to third parties on wiki
PB: don't want to be service provider or compete with OE users
KK: do we have a list of companies using OE?
PB: not really, but you are close to being volunteered to create one
RP: such a list would be very useful
PB: to all, please talk with KK to develop such a list
conflict because KK works for TI?
>> take action item offline - some companies may not want to be listed
PB: can send to list, ask people to self-report on wiki
can send info to PB if want to be privately listed
eg Eric Bernard would love to put Eutria on the list
perhaps someone like x company may not want to be on website
SH: no problem helping to sponsor travel
KK: LF said they can help out too
DH: ...but only to lf events
what would membership like? is interest in membership in specific
sponsorships?
then board needs to put draconian caps & rules, travel is expensive
for those of us working for big companies, sponsorship should not apply
if need, how much money needed? then start fundraising
PB: for one OEDEM a company gave some money to spend, we said anyone who
wanted
could ask for fixed amount to help reduce pain, which works
prevents hostel guys from staying in hilton, or Holder's place
FB: set up basic rules
DH: rules define travel on OE business
PB: good presentation at FOSDEM & LinuxTag
FB: dont have to pay for it, stands/tables at conferences quite expensive
certain amount of stands for projects, register & submit info
DH: LinuxTag is EU's largest free software conference, 14 yrs
now permanently in Berlin, part sponsored by German govt, part German
part English
very German centric, density of English speaking instuctors very
frustrating
15000 people attend
mostly community people attending
PB: good exposure
FB: useful to have some German speaking people attend, some English is
still ok
good thing in Berlin, easy to go there
MJ: had 3 German OE people at LinuxTag last year
FB: this year better
KK: plan to join embedded projects in a corner, join booths so larger
space (FB's idea)
requires coordination with other embedded projects
can't pay for larger booth, overly expensive
PB: LinuxTag worthwhile event, trouble getting people to go without
travel grants?
make sense to sponsor?
FB: last year very few people, mostly only one, this year better
DH: other projects at LinuxTag provide travel sponsorship in return for
spending 50% of time in booth
in booth for 4 hrs/day, pay part of travel
I went to OE booth and found no one, possibly coincidence? having
people in booth very important
FB: half organized by LinuxTag ev, half by Berlin gov, sometimes
complicated
they realize "embedded" is interesting catchword
idea of having larger embedded area will go through
KK: video people already share an area
PB: worthwhile sponsoring, try to arrange reimbursements for LinuxTag,
high impact
DS: value in having joint booth with yocto project
PB: always open to more sponsorship
DH: LinuxTag giving me hard sell on sponsoring - using Intel booth as
joint OE/yocto could be a lot of fun
maybe bribe Niels into putting OE community both adjacent
KK: video wall comes with me in the box
DH: if OE willing to make sure people there to answer questions,
we can figure financial part of getting a nice space, all show more
presence
PB: other embedded projects in corner?
KK: free booths small, video wall big
Niels' idea
DH: competing projects next to each other?
FB: T2 directly competing with OE, several embedded projects
one doing open hardware bicycle computing
some from embedded area in the past
was quite interesting, not only ones with big collection of funky
hardware
MJ: someone had wall of suported mainboards
DH: will ask Niels if we can do adjacent booth & share space
PB: can show up with claptrap?
DH: yocto booth, can show anything
PB: no objections noted
EH: if TI allow to show video wall, problems if OE allows sponsorship for
demo OE supported boards on stand
could look like paying for product to be there
FB: smells fishy
EH: eaiser waty to get fundint
PB: if want to give money stand in booth great, only requirement is that
something looks cool & personally stand around to show poeple
EH: more selling hardware than OE
opportunity, gives value to those wanting to sell boards
DH: careful from media perspective, can't "sell" but tell people
donations welcome
invite people present with hardware & talk about it
EH: also have hardware not paid
DH & PB: all toys welcome
PB: we're here to talk about toys
EH: just not a cheap way to showcase hardwaere
PB: spend some money to have community people there, meets goals of ev
problem is not too little hardware, too much
EH: have not had too much money - ask for donations from showcased boards
DH: sales job, should not be doing
KK: donate money want marketing materials there
DH: need someone on OE side - yocto booth will have intel swag
keep tasteful & low key
KK: don't expect problem, but don't always know expectations
PB: if have to pay price to go, don't be annyoing
SH: ratify to go ahead & sponsor?
DH & PB: board decision, though no one objects
PB: think about other events
RS: .. CEBIT?
RP: problem FOSDEM? not many people there
trying to see if have plan to do things, then money - extra money
spend on FOSDEM
look for alternate events, arrange people to present
MJ: easier to find for linuxtag
need to clone myself into 10 copies, meet 500 people/hr
[7:30 - break]
(continued: other events)
PB: other European events, how about Tdose? KK can report back
ELCE? no community stand - looking for shows where we can get in for
nothing
possibly partner with other group like yocto
KK: for LF event, yocto better as LF project
MJ: session by toolchain group at Linaro Connect, dont know what about,
possibly using yocto as daily builds?
will report back, minutes will be available
PB: under travel - ask OE person to go to Linaro Connect? havent had much
followup due to sched conflicts, etc
MJ: next Linaro Connect is the week before ELC, right after FOSDEM
PB: good thing to have an OE person not related to Linaro there
MJ: each time decision made to represent, irc channel, audio feed - can
listen & ask questions on irc
will report on how
may be possible to move to more EU friendly time
FB: Embedded World
no deal yet, more or less perfect enviroment for us, commercial fair,
fairly big
surrounded by potential users, customers, etc
lots of companies using OE there
DH: events frustrating as open source person
value opinion surrounded by potential customers, pain involved in
being there
complete lack of understanding of 90%
PB: some us small guys have to deal with that environment
work out if we can expand our reach
FB: EW usually in march near CEBIT
RS: CEBIT, consumer electronics show, in Hanover, famous, international
DH: largest show in world
RS: no focus on open source software, this year & few years ago have open
source corner
free stands to community projects
had an OE stand, tv & show devices
nice way to display oe
lots of traffic, asked about Embedded World a week before, lots of
people say using OE
PB: real staffing problem, RS only, 7 day event
FB: used to be 8, several people died (laughter)
DH: actually only 5 days now, 800k true unique visitors
22 large fair halls, multiple stories
takes a week to see everything
keep stopping & starting open source booths
need to solve staffing
FB: useful even to sponsor people
staying in Hanover very expensive or involves driving
DH: cheaper to stay in berlin
will not find another event with 1/10 of people, free booth there
extremely useful
disagree that Embedded World is more useful
lot of biz people go there to figure out next thing
FB: most important thing, mechanism for projects to get in, EW doesn't
have
PB: one thing is to look at minutes [for GA], come up wtih proposed
travel budget for next year
take to potential sponsors
RS doing advocacy stuff, show stuff, continue? if get money to sponsor
people?
RS: have day job too
>>PB: look at minutes, propose travel budget: PB, RS - use GSA per diem
schedules
>>DH: note that normal travel budget does ont apploy to CEBIT/Hanover, will
help with this specific issue
US events:
PB: SCaLE (Tom & Khem went last year)
also big shows, not os friendly
DH: Open Bridge in Portland, very open-source friendly
PB: low OE density in US
KK: if show & present at a conference, sometimes petition for travel,
possibly ELC?
DH: for us, no value in commercial events, not visible & not right people
RP: better to start talking now, need multiple people
lots of regionals
DH: OSCON waste of time for embedded, audience 80% web devs
PB: in US, there is SCaLE (should help with money), open bridge,
regionals
on mailing list, say lots of events to have OE booths to see if
worthwhile,
dont want to put lots of money in without good plan
do events where we cant staff a booth?
DH: only sign up for booth if know have staff to cover, otherwise looks
like dead project
PB: conclusion, need large travel budget, come up wth estimated needs
if get funding then do, if not then only do free stuff
reasonably good chance to improve LinuxTag & do CEBIT
LinuxTag 23-26 May, CEBIT 6-10 March
[8:00]
proxy rule
PB:
problem is that to stay active in eV, need to attend GA in person or
submit proxy
proposal to raise proxy from 2 to 3, could be worthwhile - very full up
with current rule
Phil Blundell has made proposals for voting procedure like voting for 1
candidate
anyone had chance to review elec voting proc?
RP: did read, radical changes
currently all votes anonymous from vote manager, just decision back
if internet voting, need list of people covering who voted
other complaint never get feedback on percentage voting - was it
close?
or even how many people voted
Phil's proposals open up voting radically, results have list of
voters,
summary of stats, how many people voted yes or abstained
actual vote still confidential
FM: one concern - list of members who partcipate
personally prefer that if the vote is about things ok to disclose, if
people then not
don't want to give people a bad feeling if they just won with small
margin
then their contribution not appreciated
been in other groups with rule like this
anon in terms of metrics
RP: in voting instructions, lots of classifications listed
new members, groups of people, generic decision making process
FM: not only new members, but also TSC, board - personal feeling
RP: just stating what proposals represents
could take both ways
one tech question - if we change internet voting procedure, can we
hold an internet vote on changing procedure or must decide at GA?
Phil's proposal late in cycle
question to all: read out proposal?
EH: also proxies, no one with proxies
RP: ok to change procedure because it is not part of statutes
can now agree to hold the vote on that using internet system
PB: Phil wrote it up late & people need to read it, use existing internet
voting procedure
agree ok under statues
collected proxy representation from 30 of 50 people who may want to
put end to this
can read carefully, anyone vote on tonight?
SW: need amendment
PB: need to know & not to spend 30 minutes agreeing with each other
FB: continue process
PB: do internet vote now, anything else?
RP: this about internet voting procedure can change
only other question is on proxy. 16 people here, 16 proxies
concern is that org needs to adapt; lots of bureaucratic steps
espescially when issue concerns statutes
need 3/4 vote, hard to get
EH: could get more people to hand in proxy
KK: if extend to 3 or 4 proxies per attendee, can hold GAs with 25 or 20%
of complete
membership & make majority decision? that's icky
SW: were there still people looking for proxies?
all: yes
KK: question of trust - many members don't know each other
EH: do proposals have to be available in advance? proxy can instruct on
specific votes
DH: have to be specific based on German laws
RP: given instructions on specific instructions e.g. phil's proposal
KK: met in person, discussed things on agenda, so knew what thinking
RP: do worry about currenty proxy levels tying up organization
EH: law states that a proxy is not general proxy; less problem with
specific proxies
FB: exactly specified degree of function of proxy in German law
if specified somehow, rules on how to do it
person proxying says vote x on y, but there is no secure way to check
whether they voted that way
PB: had discussing on mailing list, but people wont fill out agenda
got a concrete voting proposal 1 hr before voting starts
frustration
RP: is proposal on changing statute about # proxies
KK: proposal to change or change to specified number?
RP: to change to 3 or 4
FB: suggest reducing pressure behind needing to have proxies, see how to
attend remotely
so people not attending could vote
RP: what are rules, do we have to hold a physical GA?
FB: law doesnt know about anything not physical
have to announce location & time
EH: similar in denmark
can have all virtual
RP: much fairer way to get the organization together
KK: only need 12 people to get 2/3 currently
PB: 2/3 only for changing statutes
KK: for those who don't exercise vote, they are demoted?
RP: memership classes need to reflect the fact that it is a virtual
organization effectively
PB: one thing that requires 3/4 is to disband org
SH: there are 16 people here, 33 represented with proxies
all rest are potentially going to next level of membership?
RP: only if they miss two GAs
PB: they automatically go into extraordinary membership, but can petition
board to be put back
>> I will examine attendances to see who needs to change status
SH: concerned about effectiveness at having people show up & vote
RP: if changes required, today is a moot point to try to change statutes,
not enough voters
SH: reasonable approach to try to have people attend remotely
RP: propose to board that needs investigation, English translation is
unclear
PB: our statutes very similar to KDE ones
SH: adding ways for people to attend is extremely valuable
if can do that then [Mentor Graphics] could help with logistics
PB: can't change proxies if not enough people (and no proposal)
other one didn't come in soon enough but can change with internet vote
FB: changing statutes requires 3/4 majority of complete membership?
or of votes in meeting? but at least half of active members
EH: if we have remote attendance, obviates issue
RP: need German speakers to decipher rules
FB: if fine with german law then ok
SH: consult german attorney?
JO: possibly FSFE legal help?
>>PB: hold internet vote, discussion on list to make sure everyone is happy
with Phil's proposal,
can proceed with existing procedure
trying to solve problem of people downgrading to extraordinary
may be non-problem; reapplying costs nothing
PB: personal distaste for conference phone
RP: IRC meeting would be fairer
PB: still encourage people to physically attend
KK: language in statutes for phoning? e.g. "show of hands"?
RP: secret ballot using cards
PB: who will take & run with? changing statutes potentially with proxies
for timeout, changing internet voting procedure
hoping that Phil ok with turning into internet vote so people can
read before voting
KK: avoid deadlock
PB: anyone going to run this through if Phil doesn't?
KK: then no one cares and dont need to do it
PB: agree in principle
will hope Phil finishes
>>RP: general consensues in room? yes. if phil doesn't, RP will bring it
up.
KK: if possible to do remotely & we agree, then likely won't need to
extend proxy rule
also need to find out about secret ballot & physical requirement
PE: proposal not to keep votes
KK: might need to verify to proxies
RP: people not willing to step forward to handle voting, need people to
step up
PB: problem trying to solve is timing out & deadlock issues
statutes relatively sound now, only real concern is saturated for
proxies
KK: or remote stuff works out [obviating need for proxies]
PB: up to members to develop current proposal, has to be voted at GA or
extraordinary GA
KK: if proposal to address timeout issue, articulate better then get rid
of one problem?
PB: reserve right for board to make decision
KK: non problem
PB: regarding the extraordinary list, if you are on this list and dont
want to be there, contact board
EH: not deadlocked today anyway
PB: if group wants to make proposal - don't want to hear on and on with
no reasonable proposals
PB: anyone want to change statutes today? no, move on
New Secretary
PB: Graeme resigned mid GA, had internet vote to elect, Denys voted to
board
statutes state that has to be revoted
DS: nominates denys
Denys keeps minutes for board meetings, very important
PB: has been a huge help
all in favor for 3 year term
or step into remaining time?
PB: my interpretation, use internet vote to carry to GA, then vote to new
term
next year and 1 yr from now, other board members terms expire, then 3
peoples terms stagger
natural process for letting it become staggered
normally these things are staggered from start, ours wasn't
PB: read statutes, 3 year term, then next year can replace him
all in favor of electing denys to 3 yrs term? [all hands]
DH: request for compliance with German law to ask if anyone voting for
self or proxy against proposal
is anyone voting against proposal for self or proxy? no hands
RESULT: Denys elected
GA in US
PB: several people based in US asked to have a GA there because they
heard about how fun they are
KK: what are the rules for timing of GA?
PB: required to have one per year, says nothing about having another one
KK: must be 6 weeks between? so there is a maximum per year
PB: is there anyone who doesn't think we can have 2 GA in a year? (none)
RP: first one is GA, next is extraordinary GA
PB: partly helps (or RP says makes works) timing
EH: dumb idea, should have one, not two
PB: good to have a get together
SH: doesn't have to be a GA
MJ: how about a US OEDEM
PB: enough attendance to do a developers meeting?
KK: what was proposal put fwd?
RP: representatives from members who would like to be able to attend GA
but not travel to EU
DS: perhaps this is wrong group to ask?
KK: one solution is 2012 GA can be held in US if go through <vote>?
then the next in europe? one way to address
keep with one GA per year & alternating so not two GA in same area
twice
helps issue with people timing out & becoming extraordinary members
PB: would be convenent to have at ELC in Feb (San Francisco bay area)
board requires an announcement 6 weeks in advance
could hold one every 8 weeks?
EH: always have very specific time
FM: purpose is to get results on financials etc, member declare all well
& board ok
FB: can have GA for any puprose if 20% membership ok
is that extraoridnary?
PB: helpful as board member
RP: helpful to have meeting, not necessarily a GA which is business
makes sense to condense business portion
move to discuss on mailing list, keep GA as a formality and do rest
through online voting
fine next year to hold formality of GA in US rather than here
encourage more developer meetings
KK: takes away problem of interacting with proxies
PB: have heard people say they want more developer meetings
SH: admin overhead
EH: need purpose for GA, no purpose is not a purpose
other issues dont even talk about
KK: could have at ELC
EH: not really that interested in discussing voting procedures
>>result:
hold virtually if can happen
keep as small as possible
face to face developer type meeting
GA short
discuss beforehand, make GA a formality
make concrete proposals on list well in advance
Conclusion
PB: anything else?
RS: next ga?
PB: board will announce 6 weeks in adavance, may discuss ELC on list
if good corporate sponsorship, have in good diving location
meeting adjourned 9:04
--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
[-- Attachment #2: Type: text/html, Size: 37432 bytes --]
^ permalink raw reply
* Minutes: OE-TSC Meeting, 3 November 2011
From: Jeff Osier-Mixon @ 2011-11-04 16:31 UTC (permalink / raw)
To: openembedded-devel, openembedded-core, tsc, openembedded-members
[-- Attachment #1: Type: text/plain, Size: 18532 bytes --]
Minutes: OE-TSC Meeting, 3 November 2011
_____________________________________________________________________
Attended: Richard, Tom, Koen, Mark
Apologies: Khem
Minutes: Jefro
_____________________________________________________________________
Agenda & action items:
- OE GA at ELCE
overall very positive, though long, meeting
* publish GA proceedings before Friday (jefro)
- bitbake release
* 1.14.0 ready to go when servers return (RP)
- oe-lite
general agreement to investigate collaboration
* continue discussion on bitbake mailing list (RP)
- oe-core with selinux, other security
start in a layer, with implementation sufficient that if it were folded
into oe-core it would be acceptable
* summarize process to wiki (fray)
- other
major issue with opkg, libbb issue
Noted for future discussion:
- review tools (khem)
- "OE classic read only" thing (koen)
- TSC responsible for setting up OEDEM?
Noted for future TSC meetings: meeting time is based on European time, not
UTC
_____________________________________________________________________
Raw Transcript:
[19:51] <+fray> I remember we had this discussion last year and decided
that TSC meetings were based on European time..
[19:51] <+fray> (note sure we said -which- european time though) ;)
[19:51] <+Jefro> that's crazy talk
[19:51] <+koen> like I said, DST :)
[19:51] <+Jefro> I thought they were based on UTC?
[19:51] * fray doesn't care personally
[19:52] <+fray> ...as long as we meet at the same time.. ;)
[19:52] <+koen> I'm here anyway
[19:52] <+Jefro> actually makes no dif to me either, today
[19:52] <+Jefro> I'll send a note to Khem & Tom
[19:54] == Tartarus [trini@pixelshelf.com] has joined #oe-tsc
[19:54] == mode/#oe-tsc [+v Tartarus] by ChanServ
[19:54] <+Tartarus> I'm, uh, as ready as I'll ever be
[19:54] <+Tartarus> So if RP and koen want out sooner, that's fine
[19:55] <+fray> ready now or later..
[19:58] <+koen> I'm ready
[19:58] * RP__ is here
[19:59] <+Jefro> I have not heard from Khem, but everyone else seems to be
present & ok to meet
[19:59] <+RP__> We did say Europe time which is an hour from now
[19:59] <+RP__> but I'm here
[20:00] <+fray> khem the only one missing?
[20:00] <+Jefro> fray: yes, I believe so
[20:00] <+RP__> Isn't Khem out anyway?
[20:00] <+koen> ISTR he is on a multiweek holiday
[20:00] <+fray> I seem tor embmer something about that
[20:01] * RP__ too
[20:01] * RP__ suggests we have the meeting
[20:01] <+fray> ok, I'm up for a meeting
[20:01] * koen 2
[20:01] <+RP__> So - chairperson
[20:02] <+RP__> I can volunteer
[20:02] <+RP__> agenda?
[20:02] * Jefro notes RP__ = chair
[20:02] <+Jefro> agenda: 1. any new agenda items?
[20:03] <+Jefro> agenda: 2. status on regular items
[20:03] <+RP__> touch on OE e.V. meeting
[20:03] <+RP__> bitbake release
[20:03] <+RP__> infrastructure update will be hard without khem
[20:03] <+fray> postponed item from last meeting.....
[20:03] <+RP__> We should perhaps talk about oe-lite
[20:03] <+fray> (which I don't remember suddenly)
[20:04] * Jefro is checking minutes from last meeting - we had a few
deferred items
[20:04] <+RP__> While Jefro is doing that let me take the e.V meeting
[20:04] <+fray> thanx
[20:04] <+RP__> Basic summary is the meeting ran on a lot, 3 hours
[20:05] <+RP__> we didn't get to touch on the tsc as planned
[20:05] <+RP__> so if we want feedback I'd suggest we go for the mailing
list
[20:05] <+fray> sounds like a good idea to me..
[20:05] <+RP__> Jefro will publish minutes of that meeting
[20:05] <+RP__> In general ELC-E was very positive IMO
[20:05] * koen proposes to rename everything to 'yocto' to avoid confusion
to the outside world
[20:05] * Jefro notes: proceedings from GA are nearly ready to post
[20:06] <+RP__> koen: I'm not giving up on this naming business yet ;-)
[20:06] * fray regrets not being able to attend.. but with the bum leg, I
gave up trying to get their own my own
[20:06] <+RP__> Let me talk about oe-lite for a minute
[20:07] <+RP__> I guess people all know the history?
[20:07] <+Jefro> before going on - I found two items from last meeting that
are now on the agenda
[20:07] <+Jefro> from fray: oe-core with selinux, other security
[20:07] <+RP__> Esben didn't like certain things in OE and created OE-Lite
[20:07] <+fray> ahh yes....
[20:07] <+RP__> Jefro: what was the last topic last week that ran on?
[20:07] <+RP__> ah PR stuff
[20:08] <+RP__> Esben has continued development of OE-Lite and is doing
some rather nice stuff there by the sounds of it
[20:08] <+Jefro> reading - PR bumps
[20:08] <+fray> fewer packages? smaller stuff or?
[20:08] <+fray> how is it different?
[20:08] <+RP__> The trouble is he is breaking compatibility since he
doesn't need that
[20:08] <+RP__> fray: sysroot per recipe
[20:08] <+fray> 'k
[20:08] <+RP__> fray: and all package based dependencies
[20:09] <+RP__> so he rewrote the dependency code in bitbake
[20:09] <+RP__> but he's now also been looking at the parser and has
rewritten that
[20:09] <+RP__> and found inconsistencies in our current syntax
[20:09] <+RP__> He also handles checksums differently
[20:10] <+RP__> and many other details, its very different now
[20:10] <+RP__> The question is whether we'd want to try and see them move
closer together again and whether we can get back to a more common code base
[20:10] <+fray> between that and build-root.. is sounds like it would be a
good idea to identify the different implementation (and feature) details
and understand if any of it looks like a "better" way then what we
currently have -- or something that can fill a gap
[20:11] <+fray> I'm always in favor of trying to come together with other
projects..
[20:11] <+RP__> fray: The other big difference Esben is proud of is that
its simpler and easier to use
[20:11] <+RP__> e.g. he removed package management
[20:11] <+fray> At the least, I think we need to understand what was
removed and what it fixed.. then most likely if we can duplicate that --
we may be able to solve some issues..
[20:12] <+RP__> I feel as a TSC we need to look at why he's done things
differently and see if there are ways we can collaborate
[20:12] <+fray> I agree
[20:13] <+RP__> I should also note Esben has no resources so would be
looking for others to help
[20:13] <+fray> (I'm going to inject buildroot for a second based on the
email to the members list.. the idea of the common upstream patch set,
etc... is something we should help explore w/ buildroot.. that was part of
the goal for the Yocto Project..)
[20:13] <+koen> we had the common patch thing happen a few years ago as well
[20:14] <+RP__> It keeps coming up
[20:14] <+koen> that quickly degenerated into "you OE guys need to do all
the work, we'll steal your patches"
[20:14] <+fray> syncing up projects, common patch repositories, etc all
require people to work together..
[20:14] <+RP__> We've tried to push directly upstream in general
[20:14] <+fray> koen (speaking for Yocto and not OE for a second).. I don't
know that the Yocto people would be against that.. "hey you do all of the
work and we steal your patches"..
[20:14] <+RP__> The trouble is that those other projects value their
"simplicity"
[20:14] <+RP__> That is the biggest difference that comes up now
[20:15] <+RP__> and I can't fault them for that
[20:15] <+fray> In general terms, I like things that simplify packages,
building and configurations for more embedded usage.. we just need people
to take ownership of the item and say, hey I think we have a better way...
[20:15] <+koen> fray: just giving historical perspective
[20:15] <+fray> but when it comes down to it in the end, it often doesn't
work well because the changes can interfer w/ the full functionality version
[20:16] <+RP__> I'm still hoping we can make a fully featured and easy to
use OE
[20:16] <+fray> ...the other thing (in my experience) is then when this
works it's very good.. when it doesn't work, people have to be willing to
step back and decide it's not going to work.. ;)
[20:16] <+fray> RP__ agreed
[20:17] <+RP__> Also, Esben thought things like the parser changes might
not be acceptable to us
[20:17] <+fray> still worth looking into IMHO
[20:17] <+RP__> I've said that they are providing it doesn't change the
world
[20:17] <+RP__> i.e. we should at least talk about them
[20:18] <+RP__> I know the specific way he's implemented recipe specific
sysroots isn't appropriate but that feature is still on the yocto feature
list of possible enhancements too
[20:18] <+koen> so for parser stuff: tsc ml, oe-core ml, bitbakeml?
[20:18] <+RP__> koen: I'd say bitbake list
[20:18] <+fray> ya, int he end bitbake list..
[20:19] <+RP__> but oe-lite's bitbake is very different now I'm told :/
[20:20] <+RP__> So, summary, thinking of the overall architecture there is
some discussions we should have
[20:20] <+RP__> Also its worth noting buildroot have decided not to add
package management support to buildroot
[20:20] <+RP__> too invasive (and hence complex) thereby changing one of
their main advantages
[20:21] <+RP__> so - next topic
[20:21] <+RP__> bitbake release
[20:21] <+RP__> 1.14.0 should roll when the servers come back
[20:22] * RP__ doesn't have anything to add on that topic
[20:22] <+koen> and oe-core gets a req bump?
[20:22] <+RP__> koen: doesn't need one at this point
[20:22] <+koen> ok, just checking
[20:22] * RP__ will propose removing fetch v1 from 1.15 though
[20:22] <+RP__> which means 1.15 will no longer work with oe-classic
[20:22] <+RP__> any objections?
[20:23] <+fray> Unless there are any planned changes to bitbake to enhance
oe-classic.. I have no objections..
[20:23] <+koen> not from me
[20:23] <+Tartarus> sounds good
[20:23] * koen doesn't use OE classic anymore, only copies stuff from the
git tree
[20:23] <+RP__> It seems like a natural step to take at this point
[20:24] <+RP__> other general status updates?
[20:24] <+koen> I guess we'll need to discuss the "OE classic read only"
thing soon
[20:24] <+RP__> We've having issues with the useradd class but I think
we've got them mostly under control
[20:24] <+koen> (not today)
[20:24] <+RP__> Jefro: note as a future topic for discussion?
[20:24] * Jefro notes future discussion on oe-classic read only
[20:24] <+RP__> we do have a major issue with opkg
[20:24] <+fray> RP__ ya the useradd stuff is getting better from what I can
tell
[20:25] <+RP__> and likely need to hack the ancient libbb code in there :(
[20:25] <+fray> the issue w/ the opkg is that it's relying on actual
uid/gid and not uname/gname.. deb and rpm work on the names..
[20:25] <+fray> (assuming I have the summary right, RP?)
[20:25] <+RP__> fray: correct
[20:26] <+RP__> fray: and the quick look I took at the code shows the
problem to be in libbb
[20:26] <+RP__> (at least)
[20:26] <+koen> RP__: have you mailed the opkg-devel list about it?
[20:27] <+RP__> I pushed the gettext changes which are worth about an 8%
speedup on a quadcore
[20:27] <+RP__> koen: not yet
[20:27] <+koen> r627 is also problematic for use, we'll need to pass
--force-postinstall in the classes
[20:27] <+RP__> koen: that isn't very active is it?
[20:27] <+koen> RP__: fews mails per month
[20:27] <+fray> the PSEUDO_UNLOAD stuff is ready to go in.. just an FYI,
found an issue w/ clone(2) may not have been wrapped properly in pseudo..
but we've never seen a failure in practice..
[20:28] <+RP__> fray: great, that should be worth a couple more percent :)
[20:28] <+fray> PSEUDO_UNLOAD (w/ change to bitbake) will eliminate some of
the LD_PRELOAD penalty
[20:28] <+RP__> ok, any other general status updates?
[20:28] <+koen> RP__: http://groups.google.com/group/opkg-devel/topics
[20:28] <+fray> (I find it interesting it's faster to have pseudo loaded in
memory, then load it only when needed.. and faster yet to -unload- it when
we know its not needed)
[20:29] <+RP__> btw, for the bitbake release, I'm pushing the files onto
yocto's downloads directory
[20:29] <+RP__> I'm more than happy for that to be on OE servers but until
we figure out the infrastructure I'm putting them *somewhere*
[20:29] <+RP__> berlios is going away in 7 weeks
[20:30] <+koen> rapidshare
[20:30] <+RP__> fray: given the exec penalty I'm not so surprised ;-)
[20:30] * koen hides
[20:30] <+fray> hey there would be no exec penalty if it wasn't for you.. ;)
[20:30] <+RP__> fray: ?
[20:31] <+fray> (we implemented the exec loading in pseudo to have the
PSEUDO_DISABLED case) ;)
[20:31] <+fray> (I'm kidding BTW)
[20:31] <+RP__> fray: right ;-)
[20:31] <+RP__> ok, any other general status updates?
[20:31] <+Tartarus> not here
[20:31] <+koen> nope
[20:32] <+RP__> Tartarus: you're very quiet ;-)
[20:32] <+Jefro> still to discuss: (1) oe-core with selinux, other
security, (2) review tools
[20:32] <+fray> ready on (1)?
[20:32] <+RP__> Jefro: I was just searching for that
[20:32] <+RP__> fray: go for it
[20:33] <+fray> Ok, so this is more of a philisophical question then "hey
what do you think about selinux"
[20:33] <+Tartarus> reading and multitasking atm
[20:33] <+RP__> fray: My take is that "it depends"
[20:33] <+fray> Basically the issue is, as security frameworks (and other
system wide frameworks) come into being.. Do we have a policy for reviewing
them and deciding if they belong in "meta"?
[20:33] <+RP__> fray: How big is this patch set and what maintenance burden
does it entail?
[20:33] <+fray> or is it something we tell people to implement in a layer
(via bbappend preferrably?) and then if it's popular we include it.. or?
[20:34] <+RP__> fray: If we're talking two small patches its a no brainer.
If it involved 500kb of patches per recipe, I'm not happy
[20:34] <+fray> security frameworks happen to be the issue of the week for
me... but I can see it for other things as we move forward as well.. what
I'm looking for is simply guidance to give to people..
[20:34] <+koen> start as a layer, go from there :)
[20:34] <+RP__> fray: I suspect its somewhere in the middle ;-)
[20:35] <+RP__> and yes, my gut reaction is "what does this look like in a
layer" would be a good initial approach
[20:35] <+fray> ok, so best practice for (more then one or two patches) is
a layer.. would that layer be accepted back into oe-core?
[20:35] <+RP__> fray: who would be maintaining it?
[20:35] <+RP__> fray: would someone step up and keep the layer in sync with
the core as it changed?
[20:35] <+fray> I think that is part of the question.. if it's a layer,
then "someone" has to maintain that layer.. if it goes back to meta.. then
it would be merged and existing maintainers used..
[20:35] <+koen> does it need to be in oe-core?
[20:36] <+fray> RP__ that is one of my concerns with the layer approach for
a security layer at least
[20:36] <+Tartarus> Well, here's how I see it
[20:36] <+fray> koen, that is another question... especially for something
like seliux
[20:36] <+Tartarus> These are big new "features" in a way
[20:36] <+Tartarus> So do it in a layer
[20:36] <+RP__> fray: I'd like to understand how big/invasive these patches
are
[20:36] <+Tartarus> Get it working and clean
[20:36] <+Tartarus> Then it can be evaluated
[20:36] <+RP__> fray: maybe start with the minimal images?
[20:36] <+fray> RP__ some of them can be large, others are simply just
adding --enable-selinux to a configure line..
[20:36] <+Tartarus> No "foot in the door" of 5 patches
[20:36] <+RP__> this is what we did with x32 for example
[20:36] <+Tartarus> Then a big explosion later to make it useful, etc
[20:37] <+fray> but we need a way to continue (even with a layer) to
control this stuff via the feature/distribution flags.. (the selinux
example IMHO is a distro flag item
[20:37] <+RP__> fray: you can have a distro feature flag in a layer
[20:37] <+Tartarus> Sure, but that's independent
[20:37] <+koen> oe-core is too big already, adding more layers needs to be
considered very carefully
[20:37] <+fray> ok.. let me sumerize.. something like a new major feature
-- i.e. a security layer -- should be initially implemented and maintained
in a layer..
[20:38] <+fray> it's implementation should be sufficient that if it were
folded into oe-core it would be acceptable..
[20:38] <+fray> over time, the usage and demands of the oe members (and
users) will guide if the feature remains in a layer or if it gets folded
in..
[20:38] <+koen> and appropriate
[20:38] <+fray> the above reasonable?
[20:38] <+RP__> fray: I think so
[20:38] <+Tartarus> with as koen said, yes
[20:39] <+fray> ok, good enough..
[20:39] <+Jefro> fray: that summary seems like it should be on a wiki page
[20:39] <+fray> Jefro, ya..
[20:40] <+fray> you can add an AI for me to do that.. I just need to know
"where"
[20:40] <+Jefro> fray that is the question ... :)
[20:41] <+Jefro> let's discuss offline
[20:41] <+RP__> So any other business?
[20:41] <+fray> 'k
[20:41] <+Jefro> time-check: 19 minutes to go, one remaining agenda item
from last meeting: review tools
[20:41] <+RP__> which tools?
[20:41] <+RP__> koen: any objection to replacing gconf-dbus with gconf btw?
[20:41] <+koen> I heard someone mention that organizing OEDEM "is TSC
business"
[20:41] <+Jefro> I don't know, that was the agenda item
[20:41] <+koen> RP__: gconf-bus is blacklisted in angstrom
[20:42] <+koen> RP__: Josh has been keeping me up to date with his
intentions
[20:42] <+Jefro> "review tools" was from khem, perhaps we can wait on that
one
[20:42] <+RP__> koen: ok, good
[20:42] <+RP__> Jefro: I don't understand which tools so yes, better wait
[20:42] <+fray> fine w/ me
[20:42] <+Jefro> ok - then I believe agenda is clear
[20:42] <+RP__> koen: FWIW Yocto is looking at whether we can tag a day
onto ELC
[20:43] <+koen> RP__: josh discovered that his planned rework of gnome
bbclasses was already done in meta-oe
[20:43] <+RP__> Yocto/OE developer day/summit kind of thing
[20:43] <+Tartarus> Ug, sorry, I need to step away for a bit now
[20:43] <+RP__> Tartarus: I think we're about done
[20:43] <+Jefro> Tartarus - adios
[20:44] <+RP__> Any other requests before we close?
[20:44] <+koen> not from me
[20:44] * RP__ closes the meeting
--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
[-- Attachment #2: Type: text/html, Size: 60079 bytes --]
^ permalink raw reply
* Re: [Patch v3] rootfs_ipk bbclass: special-case base-passwd preinst to run first
From: Mark Hatle @ 2011-11-04 16:23 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <9EE60FF1-8F0B-4F49-B807-3CC198A4F24A@dominion.thruhere.net>
One way to possibly address this is to create a distribution image creation
policy. (That is how most of the distributions I'm aware of do it..
desktop/server and embedded.)
The policy is generally:
install passwd/group files
install filesystem hierarchy (it's second because it needs uid/gids)
install "everything else"
Something needs to set down the base set of components so the filesystem is sane
before we do the actual package installs and pre/post install scripts for each.
We could make this generic by defining "critical" or "base" or whatever name you
want packages and setting a specific order for these packages. (The list needs
to kept small, there generally are one or two items that need to be done very
early.)
--Mark
On 11/4/11 11:09 AM, Koen Kooi wrote:
>
> Op 4 nov. 2011, om 16:45 heeft Richard Purdie het volgende geschreven:
>
>> On Fri, 2011-11-04 at 12:44 +0100, Koen Kooi wrote:
>>> Preinst are run alphabetically which breaks when e.g. avahi-daemon needs /etc/passwd present.
>>>
>>> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
>>> ---
>>> meta/classes/rootfs_ipk.bbclass | 6 ++++++
>>> 1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> I've merged this to master. I'm not particularly happy about it but
>> right now I can't see a good way to fix this short/medium term.
>
> RP and discussed this and we're both not happy with it, but no viable other options short/medium term. The idea is to see if we can have opkg run all the preinsts since opkg does dependency resolving nowadays.
>
> regards,
>
> Koen
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [Patch v3] rootfs_ipk bbclass: special-case base-passwd preinst to run first
From: Koen Kooi @ 2011-11-04 16:09 UTC (permalink / raw)
To: Richard Purdie; +Cc: saul.wold, Patches and discussions about the oe-core layer
In-Reply-To: <1320421523.20107.118.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
Op 4 nov. 2011, om 16:45 heeft Richard Purdie het volgende geschreven:
> On Fri, 2011-11-04 at 12:44 +0100, Koen Kooi wrote:
>> Preinst are run alphabetically which breaks when e.g. avahi-daemon needs /etc/passwd present.
>>
>> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
>> ---
>> meta/classes/rootfs_ipk.bbclass | 6 ++++++
>> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> I've merged this to master. I'm not particularly happy about it but
> right now I can't see a good way to fix this short/medium term.
RP and discussed this and we're both not happy with it, but no viable other options short/medium term. The idea is to see if we can have opkg run all the preinsts since opkg does dependency resolving nowadays.
regards,
Koen
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]
^ permalink raw reply
* Re: [Patch v3] rootfs_ipk bbclass: special-case base-passwd preinst to run first
From: Richard Purdie @ 2011-11-04 15:45 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi, saul.wold
In-Reply-To: <1320407079-24810-1-git-send-email-koen@dominion.thruhere.net>
On Fri, 2011-11-04 at 12:44 +0100, Koen Kooi wrote:
> Preinst are run alphabetically which breaks when e.g. avahi-daemon needs /etc/passwd present.
>
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> ---
> meta/classes/rootfs_ipk.bbclass | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
I've merged this to master. I'm not particularly happy about it but
right now I can't see a good way to fix this short/medium term.
Saul: We'd better check if the rpm rootfs class needs this help
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH] rt-tests: update to 0.83
From: Richard Purdie @ 2011-11-04 15:44 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi
In-Reply-To: <1320312113-2492-1-git-send-email-koen@dominion.thruhere.net>
On Thu, 2011-11-03 at 10:21 +0100, Koen Kooi wrote:
> Fetch from github, kernel.org uri is gone
>
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> ---
> .../{rt-tests_0.73.bb => rt-tests_0.83.bb} | 16 ++++++++++------
> 1 files changed, 10 insertions(+), 6 deletions(-)
> rename meta/recipes-rt/rt-tests/{rt-tests_0.73.bb => rt-tests_0.83.bb} (68%)
Merged to master, thanks.
Richard
^ permalink raw reply
* [PATCH] lighttpd 1.4.29: rename index.html to avoid clashes with DL_DIR
From: Koen Kooi @ 2011-11-04 14:26 UTC (permalink / raw)
To: openembedded-core; +Cc: Koen Kooi
As Martin Jansa pointed out before, bitbake will silently peek in DL_DIR before FILESPATH and use files from there if found.
The failure mode for lighttpd involves a 404 redirect placing index.html into DL_DIR, which will end up in the lighttpd packages. In my specific case iproute2 hit the linuxfoundation 404 redirect so lighttpd.ipk now serves the linuxfoundation frontpage :)
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
meta/recipes-extended/lighttpd/files/index.html | 1 -
.../lighttpd/files/index.html.lighttpd | 1 +
meta/recipes-extended/lighttpd/lighttpd_1.4.29.bb | 6 +++---
3 files changed, 4 insertions(+), 4 deletions(-)
delete mode 100644 meta/recipes-extended/lighttpd/files/index.html
create mode 100644 meta/recipes-extended/lighttpd/files/index.html.lighttpd
diff --git a/meta/recipes-extended/lighttpd/files/index.html b/meta/recipes-extended/lighttpd/files/index.html
deleted file mode 100644
index cd25bf1..0000000
--- a/meta/recipes-extended/lighttpd/files/index.html
+++ /dev/null
@@ -1 +0,0 @@
-<html><body><h1>It works!</h1></body></html>
\ No newline at end of file
diff --git a/meta/recipes-extended/lighttpd/files/index.html.lighttpd b/meta/recipes-extended/lighttpd/files/index.html.lighttpd
new file mode 100644
index 0000000..cd25bf1
--- /dev/null
+++ b/meta/recipes-extended/lighttpd/files/index.html.lighttpd
@@ -0,0 +1 @@
+<html><body><h1>It works!</h1></body></html>
\ No newline at end of file
diff --git a/meta/recipes-extended/lighttpd/lighttpd_1.4.29.bb b/meta/recipes-extended/lighttpd/lighttpd_1.4.29.bb
index c1d5f81..9fdb5f6 100644
--- a/meta/recipes-extended/lighttpd/lighttpd_1.4.29.bb
+++ b/meta/recipes-extended/lighttpd/lighttpd_1.4.29.bb
@@ -16,10 +16,10 @@ RDEPENDS_${PN} += " \
lighttpd-module-staticfile \
"
-PR = "r0"
+PR = "r1"
SRC_URI = "http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-${PV}.tar.bz2 \
- file://index.html \
+ file://index.html.lighttpd \
file://lighttpd.conf \
file://lighttpd \
"
@@ -48,7 +48,7 @@ do_install_append() {
install -d ${D}${sysconfdir}/init.d ${D}/www/logs ${D}/www/pages/dav ${D}/www/var
install -m 0755 ${WORKDIR}/lighttpd ${D}${sysconfdir}/init.d
install -m 0755 ${WORKDIR}/lighttpd.conf ${D}${sysconfdir}
- install -m 0644 ${WORKDIR}/index.html ${D}/www/pages/
+ install -m 0644 ${WORKDIR}/index.html.lighttpd ${D}/www/pages/index.html
}
FILES_${PN} += "${sysconfdir} /www"
--
1.7.2.5
^ permalink raw reply related
* Re: Bitbake 1.14.0 released!
From: Richard Purdie @ 2011-11-04 14:25 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: bitbake-devel
In-Reply-To: <CAFu+nvG9gLNyCOEcE9ZdCwCe8wtzn=4vxdd3fGz2mP_zBtAM_Q@mail.gmail.com>
On Fri, 2011-11-04 at 10:05 -0400, George C. Huntington, III wrote:
> can the new bitbake be used on oe-classic, 2011.03-maintenance branch?
It should work there, yes.
Cheers,
Richard
^ permalink raw reply
* Re: Bitbake 1.14.0 released!
From: George C. Huntington, III @ 2011-11-04 14:05 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: bitbake-devel
In-Reply-To: <1320361692.20107.103.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 28341 bytes --]
can the new bitbake be used on oe-classic, 2011.03-maintenance branch?
On Thu, Nov 3, 2011 at 7:08 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:
> Bitbake 1.14.0 has been released.
>
> http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.14.0.tar.gz
>
> [I've placed the bitbake tarballs onto Yocto infrastructure until OE
> infrastructure gets sorted out. Berlios goes away in 7 weeks so I wanted
> a backup of them somewhere and I didn't want to hold the release any
> further]
>
> This release contains many bugfixes and improvements over 1.12 and
> includes hob, a graphical interface to running builds and image
> construction. A git log of the differences between 1.12 and 1.14
> follows.
>
> Bernhard Reutner-Fischer (1):
> manual: fix typo
>
> Brandon Stafford (1):
> doc/usermanual.xml: Tweaks for the manual
>
> Chris Larson (50):
> cooker: simplify self.configuration.data vs data usage
> cooker: use BBHandler.inherit for INHERIT
> build: switch to old cwd handling
> build: add missing newline
> bitbake-layers: drop 2.6 from #!, per Joshua Lock
> server: use local fixed _bootstrap when appropriate
> goggle: exit quietly on ^C
> hob: adjust for master's eventHandler API
> lockfile: ask for forgiveness, not permission
> utils: fix typo in lockfile
> bb.siggen: import os
> codeparser: fix ShellSyntaxError usage
> codeparser: use ==, not 'is' to compare strings
> Fix more incorrect usages of 'is'
> More 'is' fixups
> Initial work on getting bitbake working under pypy
> build: add missing bit necessary for mhatle's fakeroot fix
> runqueue: simplify fakeroot environment handling
> build: in exec_func, mkdirhier ${T}
> build: fix dir removal traceback
> build: don't choke if olddir no longer exists
> event: register event handler functions, not code objects
> event: improve output when eventhandler exec fails
> event: improve output for syntax errors in handlers
> cooker: fix -b with BBCLASSEXTEND
> persist_data: raise KeyError on missing elements
> persist_data: add has_key
> persist_data: don't allow non-string keys/values
> persist_data: make SQLTable a context manager
> persist_data: implement comparison, same as dict
> build: run fakeroot if FAKEROOT is set
> bb.namedtuple_with_abc: add useful util from activestate
> bb.exceptions: add code to create pickleable traceback entries
> bb.exceptions: add to_string convenience function
> bb.exceptions: handle tb entries without context
> bb.exceptions: don't show a repr of 'self'
> cooker: show a useful message for ParsingFailure
> cooker: pass traceback back from parsing thread
> cooker: use logger.exception for config file parse errors
> cooker: don't show a useless traceback for SyntaxError
> cooker: don't show a traceback for ParseError
> Shift exception formatting into the UI
> Merge remote branch 'github/exceptions'
> event: don't catch systemexit from handler execution
> cooker: handle ExpansionError the same way we do ParseError
> parse: pass a useful (if mangled) key to bb.data.expand for :=
> siggen: don't choke with traceback when data is None
> bb.exceptions: don't choke on frames without arguments
> Revert the unintentionally pushed msg.py change
> event: fix the event display order when exiting early
>
> Christopher Larson (6):
> fetch.git: fix a remnant wrt persist + keyerror
> msg: use a simpler enumeration for the domains
> msg: fix domain enum use
> cache: fix remnant broken 'info' reference from recent cache changes
> taskdata: fix string formatting of an error message
> codeparser: make var_expands actually hold useful information
>
> Cliff Brake (1):
> Linefeed to test commits
>
> Darren Hart (4):
> correct typo in ??= documentation
> bitbake docs: use dblatex to build the pdf bitbake manual
> fetch2/git: use logging.debug() and clarify messages
> fetch2/git: ensure network check log matches actual command
>
> Denys Dmytriyenko (1):
> lib/bb/providers: make "checking PREFERRED_PROVIDER_%s" a debug
> message
>
> Dexuan Cui (1):
> bitbake/cooker, bitbake-layers: show the .bbappend files that matches
> no existing .bb recipe
>
> Dmitry Eremin-Solenikov (1):
> lib/bb/siggen.py: return a string from noop get_taskhash
>
> Dongxiao Xu (3):
> Introduce stamp-extra-info task flag into stamp filenames
> fix parameter order for flaglist()
> data_smart.py: make use of expand cache in getVar()
>
> Holger Hans Peter Freyther (1):
> fetch2/git: Allow to specify the name of the checkout directory
>
> Jessica Zhang (3):
> ui/crumbs/tasklistmodel: fix loading a saved recipe
> ui/crumbs/hobprefs: trigger reparse when package format changed
> bb/ui/hob: Restore toolchain relevant preference settings for build
>
> Joshua Lock (155):
> bitbake/cache: store a list of inherited files in the cache
> implement command to get all possible targets and their dependencies
> implement command to find configuration files for a config variable
> bitbake/cooker: add generateTargetsTree method
> bitbake/cooker: reduce code duplication
> bitbake/[cooker|cache]: cache summary, license and group. Add to
> targets tree
> introduce crumbs.TaskListModel a gtk.ListStore subclass
> bitbake/event: fix some whitespace issues
> bitbake/crumbs: update documentation header
> bitbake/progress: add method to pulse the progress bar
> bitbake/cooker: don't drop possible_world ref count
> Add new UI hob, a prototype Gtk+ GUI for creating images
> bitbake/progress: make progress dialog modal for parent window
> bitbake/cache: bump cache version after recent changes
> bitbake/ui: Fix Gtk+ GUI's after recent cache changes
> uievent: fix queueing of events for xmlrpc before UI has loaded
> server: add updated/fixed xmlrpc server from Poky
> bitbake/cooker: don't error in prepareTreeData for unbuildable targets
> bitbake/hob: only show one progress dialog when changing machine
> bitbake/depexp: closing progress dialog kills gui
> bitbake/goggle: closing the progress dialog kills the UI
> bitbake/hob: fix cancel button
> command|cooker: allow generating targets tree for specified pkgs
> cooker: add generic method to locate configuration files
> command|cooker|event: add findConfigFilePath command
> cooker|command|event: add new command findFilesMatchingInDir
> cooker: remove code duplication in non trivial functions
> cooker: switch to new universe target rather than world
> bitbake: add -R option for loading configuration files after
> bitbake.conf
> hob: re-designed interaction and implementation
> ui/crumbs/tasklistmodel: fix reset method
> lib/bb/hob: fix changing base image
> lib/bb/ui/hob: don't error when dismissing save as dialog
> ui/crumbs/tasklistmodel: update brought in by column when possible
> ui/crumbs/tasklistmodel: fix automatic removal of orphaned items
> cooker: only return *Found events if something was actually found
> ui/crumbs/hobprefs: add missing import
> ui/crumbs/tasklistmodel: fix saving recipes
> ui/hob: add more guidance to the stop dialog
> ui/crumbs/configurator: write new lines after new entries
> ui/hob: don't crash if PARALLEL_MAKE doesn't include a space
> ui/crumbs/tasklistmodel: ignore tasks and images when marking
> dependencies
> hob: refer to tasks as Package Collections
> ui/crumbs/tasklistmodel: don't show native and cross recipes
> ui/hob: clear the search entry when resetting
> ui/hob: if the user clicks Stop a second time only offer 'Force Stop'
> hob: only add new layer's to the UI
> ui/crumbs/hobprefs: set higher arbitrary limit on threads &
> parallelism
> ui/crumbs/hobprefs: tweak the package format tooltip
> hob: rework image output type setting
> bitbake|cooker: save a copy of the environment when BitBake is started
> data|cooker: use saved environment variables when calling
> inheritFromOS
> bitbake-layers: adapt to cooker change for saved environment
> command|cooker: Add reparseFiles command
> cooker: only append files once
> ui/hob: replace the ugly static command map
> ui/crumbs/hobeventhandler: reparse files before running other commands
> ui/hob: switch from buildFile to buildTargets for custom image builds
> ui/hob: don't offer to show built output if build fails
> ui/hob: change wording in build complete dialog
> ui/hob: Force the 'Base image combo' to be drawn correctly
> ui/hob: enable building an image with minimal contents
> ui/crumbs/tasklistmodel: handle items added in by base image being
> removed
> ui/crumbs/tasklistmodel: don't iterate whole model in
> find_alt_dependency()
> ui/crumbs/tasklistmodel: work around overly aggressive package removal
> hob: fix loading customised image recipe
> cooker: populate rdepends-pkg in generatePkgDepTreeData
> hob: more reliable disabling of GPLv3 packages
> hob: fix save/restore of toolchain preferences
> ui/crumbs/hobeventhandler: remove unused code
> hob: unset busy cursor on exit
> ui/crumbs/hobeventhandler: emit a signal when there's a fatal-error
> ui/hob: show error and exit if we receive the fatal-error signal
> ui/crumbs/hobeventhandler: emit a signal when a command fails
> ui/crumbs/configurator: tweak addLayerConf return values
> ui/crumbs/layereditor: if layer adding fails show an explanatory
> dialog
> hob: remove temporary directory on program shutdown
> bb/ui/hob: save changes to bblayers.conf when using Add Layer menu
> item
> bb/ui/crumbs/runningbuild: optionally create list entries sequentially
> bb/ui/hob: show build messages are displayed in the order they're
> received
> ui/crumbs/runningbuild: add optional readonly mode, default off
> bb/ui/hob: disable editing in the build messages tree view
> bb/ui/crumbs/runningbuild: emit signal when command fails with exit
> signal
> bb/ui/hob: fix detection of whether GPLv3 is disabled
> bb/ui/crumbs/tasklistmodel: fix regex used for loading image recipes
> bb/ui/hob: prevent label on progress bar from changing rapidly when
> loading
> bb/ui/crumbs/hobeventhandler: use generic loading message once cache
> loaded
> bb/ui/hob: only connect to the changed signal of image_combo once
> bb/ui/hob: be clear that the image contents are an estimate
> bb/ui/hob: reset event handler once build complete
> bb/cooker: mark parsed conf files as potential cache invalidators
> bb/ui/crumbs/tasklistmodel: prevent hang when removing item
> bb/ui/hob: move some code around to avert a race
> bb/cooker: only emit ConfigFilePathFound for files which were parsed
> bb/ui/crumbs/tasklistmodel: fix some typos and add comments to mark()
> bb/ui/crumbs/tasklistmodel: correctly uniquify dependency list
> bb/ui/crumbs/tasklistmodel: don't include an item in its own depends
> bb/cache: rename confusing variable
> bb/command|cooker: refactor the reparseFiles logic
> bb/ui/crumbs/hobeventhandler: adapt to reset -> reparse change
> bb/ui/crumbs/configurator: introduce writeConfFile method for all
> writes
> lib/bb/ui/crumbs/hobprefs: fix erroneous save/reparse
> bb/crumbs/tasklistmodel: filter nativesdk packages out of views
> bb/ui/crumbs/tasklistmodel: include package level information
> bb/ui/crumbs/tasklistmodel: optimise find_path_for_item
> bb/ui/crumbs/tasklistmodel: make package_model_filter a little safer
> bb/ui/crumbs/tasklistmodel: simplify conditional in include_item
> Ensure only the filtered environment variables are inherited from the
> OS
> bb/ui/crumbs/runningbuild: reduce number of messages after recent msg
> change
> bb/ui/crumbs/runningbuild: hide the progress bar on cache load
> complete
> bb/ui/crumbs/tasklistmodel: more robust checking for substrings
> bb/ui/crumbs/tasklistmodel: remove useless items from dependency list
> bb/ui/crumbs/tasklistmodel: store all binb, not just the first
> hob: don't try and build if user selects Bake with no selections made
> bb/ui/crumbs/tasklistmodel: track the PN for each entry in the model
> bb/ui/hob: fix package only build
> bb/ui/crumbs/hobeventhandler: fix return values of *_image_output_type
> bb/ui/crumbs/hobprefs: fix setting IMAGE_FSYTPES
> bb/ui/hob: warn and prevent image build if no IMAGE_FSTYPE is set
> bb/fetch2/git: add checkstatus command
> hob: don't set PARALLEL_MAKE and BB_NUMBER_THREADS based on cpu count
> bb/ui/crumbs/tasklistmodel: fix find_reverse_depends method
> hob: disable some menu entries whilst build is in progress
> ui/crumbs/tasklistmodel: don't add same item to binb column more than
> once
> ui/crumbs/runningbuild: add a 'Copy' item to the messages right-click
> menu
> ui/crumbs/tasklistmodel: don't add same item to binb column more than
> once
> ui/crumbs/tasklistmodel: prevent packages depending on each other
> ui/crumbs/tasklistmodel: optimise find_path_for_item()
> ui/crumbs/tasklistmodel: remove unnecessary check
> ui/crumbs/tasklistmodel: loop optimisation in include_item()
> ui/crumbs/tasklistmodel: don't add empty entries to COL_BINB
> hob: use both pre and post files for hob configuration
> hob: reflect defaultsetup being default distro
> hob: add a test to ensure hob is run with the required pre and post
> files
> ui/crumbs/hobprefs: disable 'build toolchain with headers'
> ui/crumbs/runningbuild: mask run_buildstats failure
> hob: disable removal of packages
> ui/crumbs/hobeventhandler: fix test for BBFILES
> ui/crumbs/hobeventhandler: don't check BBPATH and BBFILES each build
> hob: correctly handle an exception
> hob: correctly set the selected image when loading a recipe
> fetch2/wget: make checkstatus() quieter
> ui/crumbs/hobprefs: re-enable reloading of data after prefs changes
> hob: fix build again when building packages only
> hob: enable package only builds even if an image has been built
> ui/crumbs/runningbuild: fix log messages right-click menu
> hob: fix opening of image output dir on image build completion
> ui/crumbs/hobeventhandler: move remaining getVariable calls to init
> ui/crumbs/hobeventhandler: fix variable name typo
> hob: fix building with current selections after reparse
> hob: store recipe path at load time
> hob: fix backtrace when dismissing open dialog
> fetch2: improve usability of checksums
> fetch2: enable checksum definition as SRC_URI parameter
> doc: update manual for checksum changes
>
> Julian Pidancet (1):
> Fix mercurial fetcher in fetch2
>
> Kevin Tian (1):
> siggen.py: better print for task hash comparison
>
> Khem Raj (1):
> fetch, fetch2: Get rid of DeprecationWarning notice
>
> Lianhao Lu (3):
> Add PR service deamon to bitbake
> ui/hob: Fixed the "build again" hang.
> bitbake cooker/ui: handle cmd line parsing result by individual UI.
>
> Liping Ke (6):
> cache.py: Refactory Current Cache implementation
> cache: Introduce extra cache class for image creator
> cache: Introduce new param caches_array into Cache impl.
> cache: Implement multiple extra cache fields request support
> bitbake: Make bitbake server type configurable.
> Remove unused target tree data for Hob
>
> Mark Hatle (4):
> fetch2: unpack revision
> runqueue.py: Enable PSEUDO (fakeroot) before the fork
> build.py: Merge fakeroot changes from Poky
> runqueue.py: Add umask task control
>
> Martin Jansa (4):
> setup.py: also install bitbake-{layers,diffsigs} scripts
> setup.py: install fetch2 module
> fetch2/git: fix logger.debug
> fetch2/git: be more carefull in _contains_ref when checking git log
> output
>
> Matthew McClintock (2):
> fetch2/git: Make git fetch run with -f so rebased branches don't fail
> fetch2: Export additional variables to the fetchers
>
> Otavio Salvador (2):
> codeparser.py: fix syntax error in exception handling
> codeparser.py: fix syntax error in exception handling
>
> Paul Eggleton (31):
> bitbake: use layer priority when applying bbappends
> bitbake/runqueue: fix clash when setscene & real tasks done in same
> build
> bitbake/runqueue: show correct task name for setscene task failure
> track skipped packages
> bitbake-layers: handle skipped recipes
> bitbake: track 'overlayed' recipes
> bitbake-layers: add show_overlayed action
> bitbake/cooker: implement layer dependencies, make priority optional
> bitbake-layers: add command to flatten layers into one
> bitbake-layers: fix sorting of show_appends output
> bitbake-layers: fix sorting by package name for cooker change
> bitbake-layers: fix error on startup caused by recent cooker change
> bitbake/ast: include class name when arguments given in variant
> bitbake/cache: allow class names with arguments to be specified
> add note to -b option indicating no dependency handling
> bitbake/cooker: show a warning when -b is specified
> adjust comments/messages for default server change
> bitbake-layers: check for errors before parsing
> bitbake-layers: add command help
> bitbake-layers: remove unneeded do_EOF
> bitbake: show more information for NoProvider errors
> bitbake/taskdata: fix incorrect usage of rdependees instead of
> dependees
> bitbake/providers: list PREFERRED_VERSION candidates when unavailable
> bitbake-layers: improve default command help
> bitbake-layers: show help with no command specified
> bitbake-layers: use logger.plain instead of info
> bitbake-layers: extend show_layers
> hob: clear out temporary file list after deleting
> hob: fix segfault on second build
> fetch2/git: fix subpath destination directory
> bitbake/lib/bb/msg.py: fix setting debug and verbosity levels
>
> Richard Purdie (112):
> Increment version for development version
> bitbake/siggen.py: Fix whitelisted variable handling
> bitbake/build.py: Rename message field to avoid DeprecationWarning:
> BaseException.message warning
> bitbake/utils.py: Add option of holding shared lockfiles
> bitbake/utils.py: Teach unlockfile about shared mode lockfiles
> bitbake/providers.py: Fix runtime providers problems
> bitbake/utils: Ignore OSError in unlockfile
> bitbake/unlockfile: Fix exception handling
> bitbake/build.py: When looking up extra stamp info for setscene
> tasks, use the real taskname
> process.py: Avoid deprecation warning
> bitbake/fetch2: Fix message about md5 checksums when sha256 is
> incorrect
> bitbake/fetch2: Pass over malformatted (empty) mirror url lines
> bitbake/fetch2: Correctly handle git mirror tarball fetching
> bitbake/fetch2: Ensure failed fetch attempts are logged in the debug
> logs
> bitbake/fetch2/wget: Fix missing string parameter reference
> bitbake/fetch2: Ensure network access status is reset for each loop
> iteration in download()
> bitbake/fetch2: Add some debug output so its clear when PREMIRRORS,
> upstream and MIRRORS are being used
> bitbake/fetch2: Fix patch merge error
> bitbake/fetch2: Add explict network access exception and handling to
> give users usable error messages
> bitbake/fetch2: Revert part of the unpack change until the issues
> with it are resolved
> bitbake/fecth2: Ensure BB_FETCH_PREMIRRORONLY being set as false is
> handled correctly
> bitbake/cooker: Fix parsing failure zombie problem
> bitbake/fetch2: Ensure SRCREV_pn-PN is checked for a revision when
> the SRC_URI is unnamed
> bitbake/data_smart: Improve the way lazyassignment works
> bitbake/data_smart: Improve Variable expansion error handling
> build.py: Improve exec_task standalone usage
> build.py: Operate logfile handling at the task level
> bitbake/utils.py: Allow join_deps to return a list that isn't comman
> separated
> bitbake/ast.py: Only run finalise() for the specified variant
> bitbake/cooker/codeparser: Ensure the code parser cache is saved for
> each parsing process
> bitbake/cache.py: Ensure skipped recipes make it into the cache to
> avoid reparsing
> bitbake/codeparser: Correctly handle a missing/empty cache file
> build.py: Fix ordering bug introduced in
> 7a29ab534388c0095f7f826b16c5cff343927d10
> bitbake/fetch2/git: Fix a bug where AUTOREV and the git fetcher
> interact badly
> bitbake/fetch2: Fix the problems introduced by the git fetcher
> AUTOREV fix
> bitbake/fetch2: Allow local file:// urls to be found on mirrors
> bitbake/fetch2/local: Fix inverted update required logic
> bitbake/utils.py: Only try and add read access to a file if we don't
> have it
> codeparser.py: Ignore incomplete cache files
> codeparser.py: Ignore incomplete cache files
> build/siggen: Ensure a task signature file is generated for each task
> that is executed
> cooker.py: Don't show spurious warnings for collections of .bbappend
> files
> bitbake/cooker.py: Fix -b option regexp handling
> bitbake/cooker.py: Ensure BBFILES is processed in order
> bitbake/utils.py: Add option to lockfiles to return immediately
> rather than wait
> bitbake/runqueue.py: Ensure existing setscene stamp files are taken
> into account
> runqueue.py: Set BB_WORKERCONTEXT in task execution context
> bitbake/codeparser: Improve cache handling
> providers.py: Correct PREFERRED_VERSION handling
> data_smart: Adding overrides of zero length is pointless so lets not
> cache.py: Sync what amounts to whitespace with bitbake in poky,
> pending merge of cache patches
> cooker/process.py: Move profiling code to a place it can be reused by
> different server mechanisms
> bitbake/runqueue: When we successfully fork off a task and there are
> more processes we can start do so immediately
> bitbake/runqueue: When we have successfully collected a pid value
> return True to ensure we don't sleep in the main loop
> bitbake/cooker: Ensure delays are accurately transfered to the idle
> loops from runqueue
> bitbake/cooker.py: Fix debug message arguments
> bitbake/server/process: Move implementation knowledge of event queue
> into the server
> bitbake/server: Move server specific code into the server backend and
> create a server API
> bitbake/server: Add the none server back for now
> xmlrpc/event: Add ability to send pickled events to UI if requested
> hob/crumbs/hobeventhandler: Remove server specific implementation
> details missed in the precious cleanup
> knotty: If any error messages are seen, set our exit code accordingly
> data.py: Ensure vardeps flags get expanded
> runqueue.py: Export further hash information into the task environment
> bitbake-layers: Add comment header
> build/runqueue: Pass quieterrors flag around to supress errors at
> task execution time
> cooker.py: Drop duplicate parseCommandLine call
> Drop psyco support
> persist_data: Add back code to retry in the case of locked database
> errors
> bitbake/data_smart: Change overrides behaviour to remove expanded
> variables from the datastore
> bitbake/parse/ast: We always need to finalize the default data since
> otherwise overrides to BBCLASSEXTEND may not be applied
> bitbake/event/ast: Add RecipePreFinalise event
> Update version to 1.13.1
> bitbake/cooker: Fix -b option by ensuring the empty cache structure
> is present
> bitbake/fetch2: When replacing URLs in mirror handling mask out empty
> entries
> codeparser: When loading the cache, ignore ValueError
> process.py: Fix issue where early errors weren't making it to the
> console
> bitbake/data_smart: Optimise the data store iterator
> bitbake/data_smart: Don't export deleted/empty entries in the list of
> keys
> bitbake/data_smart: Don't track overrides in deleted variable names
> bitbake/ast: Call expandkeys after the RecipePreFinalise event
> bitbake/ast: Add optional argument for BBCLASSEXTEND
> Update version to 1.13.2
> bitbake/ast: Fix ??= vs. ?= handling
> ui/depexp: If we're parsing zero files we need to ensure the cache
> progress bar gets hidden
> cache.py: Ensure additional .bbappend files are accounted for
> bitbake/process.py: Ensure queued UI events are queued right before
> we add our own handler
> fetch2/git: Tweak git fetcher to handling repo updates correctly
> parse/ConfHandler: Fix multiline variable corruption
> Merge remote-tracking branch 'origin/master'
> bitbake/utils: Add contains helper function from lib.oe.utils
> Update version to 1.13.3
> bitbake/utils: 'Fix' bb.utils.contains() behaviour
> bitbake/ui/knotty: Ensure 'No Provider' errors set an exit code
> bitbake/ui/knotty: Ensure previous failures aren't masked by a final
> successful command
> bitbake: Fix -e when used with -b option
> bitbake/usermanual: Update to be more in sync with bitbake codebase
> bitbake/logging: Overhaul internal logging process
> bitbake/msg.py: Drop manually created domain lists
> build.py: Fix cut and paste error
> Fixup remaining bb.msg.domain users
> fetch2/git: Add rsync as a valid git protocol
> usermanual: The git fetcher defaults to the git protocol (or file)
> bitbake: Correctly handle multiline comments including whitespace
> bitbake/fetch2/git: Ensure .gitconfig file is ignored
> bitbake/event: Allow event handlers to quietly raise SkipPackage
> events
> runqueue: Ensure task environment is correct
> runqueue.py: Ensure fakeroot variables are reflected in the datastore
> git.py: Fix logging vs logger typo
> cooker.py: Fix key expansion issues in showVersions
> Merge branch 'master' of git.openembedded.org:bitbake
> Release 1.14.0
>
> Robert Yang (1):
> bitbake: Add task specific stamp file support
>
> Saul Wold (1):
> universe target: add a new target to collect all recipe targets
>
> Scott Garman (3):
> cache.py: fix bitbake -s command
> make exception handling syntax consistent
> fetch2/git.py: improve error reporting when an invalid protocol is
> used
>
> Yu Ke (8):
> git fetcher: make tag back to work, fix Yocto bug 972
> git fetcher: add support for rebaseable git repo
> fetch2/git: change default protocol from rsync to git
> fetch2/git: unify the nocheckout option format
> fetch2/git: add document for git fetcher supported options
> fetch2/git: enhance the unpack by using "git checkout"
> fetcher2: retry mirror if upstream checksum mismatch
> fetcher2: show warning message when checksum is mismatch
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 31609 bytes --]
^ permalink raw reply
* [Patch v3] rootfs_ipk bbclass: special-case base-passwd preinst to run first
From: Koen Kooi @ 2011-11-04 11:44 UTC (permalink / raw)
To: openembedded-core; +Cc: Koen Kooi
Preinst are run alphabetically which breaks when e.g. avahi-daemon needs /etc/passwd present.
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
meta/classes/rootfs_ipk.bbclass | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index e02b816..3094c1a 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta/classes/rootfs_ipk.bbclass
@@ -77,6 +77,12 @@ fakeroot rootfs_ipk_do_rootfs () {
${ROOTFS_POSTINSTALL_COMMAND}
runtime_script_required=0
+
+ # Base-passwd needs to run first to install /etc/passwd and friends
+ if [ -e ${IMAGE_ROOTFS}${opkglibdir}/info/base-passwd.preinst ] ; then
+ sh ${IMAGE_ROOTFS}${opkglibdir}/info/base-passwd.preinst
+ fi
+
for i in ${IMAGE_ROOTFS}${opkglibdir}/info/*.preinst; do
if [ -f $i ] && ! sh $i; then
runtime_script_required=1
--
1.7.2.5
^ permalink raw reply related
* Re: about the qemu net interface name
From: Phil Blundell @ 2011-11-04 11:31 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1320400712.1504.29.camel@localhost.localdomain>
On Fri, 2011-11-04 at 17:58 +0800, Ni Qingliang wrote:
> I have checked the version of ifconfig, it blongs to package
> "net-tools".
>
> only the latest version 1.60.20110819cvs-1 have the ":" after Interface
> name. In this version, the output format of ifconfig has changed.
Parsing the output of ifconfig isn't a very good way to get a list of
devices (not least because ifconfig isn't guaranteed to be available).
It would be better to read /proc/net/dev directly since this file is
intended to be machine-readable.
p.
^ permalink raw reply
* Re: Clean of qt4-embedded don't cleanup sysroot and deploy
From: Richard Purdie @ 2011-11-04 10:52 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: openembedded-devel
In-Reply-To: <0C757E680E33864AB113392C7E83F910BE522C@GSX300A.mxchg.m.corp>
On Fri, 2011-11-04 at 10:18 +0100, Hauser, Wolfgang (external) wrote:
> if I do a bitbake -c clean for qt4-embedded or qt4-native all libraries
> and binaries of QT are left in the sysroots and all created packages are
> left in deploy. This is an result of splitting qt into several sub
> packages and install them.
When you clean a package, everything it installed into the sysroot
should get removed. If this doesn't happen there is a bug somewhere and
we need to fix that bug...
Cheers,
Richard
^ permalink raw reply
* Re: about the qemu net interface name
From: Ni Qingliang @ 2011-11-04 9:58 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org
In-Reply-To: <1320375012.1504.22.camel@localhost.localdomain>
I have checked the version of ifconfig, it blongs to package
"net-tools".
only the latest version 1.60.20110819cvs-1 have the ":" after Interface
name. In this version, the output format of ifconfig has changed.
On Fri, 2011-11-04 at 10:50 +0800, 倪庆亮 wrote:
> file: scripts/runqemu-internal
> line153: POSSIBLE=`$IFCONFIG -a|grep '^tap' | awk `{print $1}'`
>
> on archlinux, I got that:
> tap0:
> tap1:
>
> maybe it should be:
> tap0
> tap1
>
> Is it right?
>
> so I change it to
> POSSIBLE=`$IFCONFIG -a|grep '^tap' | awk `{print $1}' | sed 's/:$//'`
>
> --
> Yi Qingliang
> niqingliang@insigma.com.cn
> https://niqingliang2003.wordpress.com
>
--
Yi Qingliang
niqingliang@insigma.com.cn
https://niqingliang2003.wordpress.com
^ permalink raw reply
* Re: Error building any image
From: Martin Jansa @ 2011-11-04 9:59 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111104094559.GS9949@jama.jama.net>
[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]
On Fri, Nov 04, 2011 at 10:45:59AM +0100, Martin Jansa wrote:
> On Fri, Nov 04, 2011 at 10:23:44AM +0100, Peter Lohmer wrote:
> > Hi all,
> > after last oecore update building fails with the following error message:
> >
> > peter@p-lohmer-linux:~/oe-core$ bitbake -k xfce-nm-image
> > Loading cache: 100%
> > |##########################################################################################################|
> > ETA: 00:00:00
> > Loaded 1826 entries from dependency cache.
> > Parsing recipes: 100%
> > |########################################################################################################|
> > Time: 00:00:00
> > Parsing of 1418 .bb files complete (1414 cached, 4 parsed). 1825
> > targets, 72 skipped, 0 masked, 0 errors.
> > ERROR: No recipes available for:
> > /home/peter/oe-core/sources/meta-smartphone/meta-openmoko/recipes-multimedia/mplayer/mplayer2_git.bbappend
> > ERROR: Command execution failed: Exited with 1
> >
> > I believe it's caused by meta-smartphone, does anyone face the same problem ?
>
> Hi,
>
> yes it is, I'm sorry about that.
>
> yes it is, I've updated README to be more clear about dependencies
> http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=543e9ccc533677f25146f5ab59fbb019907e3548
> http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=bc7051e466f3d48b70ed62df8fffef23a9329bf0
>
> and for now you can revert
> http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=38d81585f57c3df86771dc39f7408291798601a4
> or apply
> http://patches.openembedded.org/patch/14259/
I've also pushed without_shr branch to meta-smartphone which is master
without this 3 patches and I'll merge master branch to it sometimes when
I'll feel that currently we don't need anything critical from
oe-core-contrib/shr or meta-oe-contrib/shr
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: Error building any image
From: Martin Jansa @ 2011-11-04 9:45 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAE1-YAGuD3+ccvJ0kFgEFuJCpew_T0VX85YH3sMuNYdyu729CA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]
On Fri, Nov 04, 2011 at 10:23:44AM +0100, Peter Lohmer wrote:
> Hi all,
> after last oecore update building fails with the following error message:
>
> peter@p-lohmer-linux:~/oe-core$ bitbake -k xfce-nm-image
> Loading cache: 100%
> |##########################################################################################################|
> ETA: 00:00:00
> Loaded 1826 entries from dependency cache.
> Parsing recipes: 100%
> |########################################################################################################|
> Time: 00:00:00
> Parsing of 1418 .bb files complete (1414 cached, 4 parsed). 1825
> targets, 72 skipped, 0 masked, 0 errors.
> ERROR: No recipes available for:
> /home/peter/oe-core/sources/meta-smartphone/meta-openmoko/recipes-multimedia/mplayer/mplayer2_git.bbappend
> ERROR: Command execution failed: Exited with 1
>
> I believe it's caused by meta-smartphone, does anyone face the same problem ?
Hi,
yes it is, I'm sorry about that.
yes it is, I've updated README to be more clear about dependencies
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=543e9ccc533677f25146f5ab59fbb019907e3548
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=bc7051e466f3d48b70ed62df8fffef23a9329bf0
and for now you can revert
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=38d81585f57c3df86771dc39f7408291798601a4
or apply
http://patches.openembedded.org/patch/14259/
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* [Patch v2] rootfs_ipk bbclass: special-case base-passwd preinst to run first
From: Koen Kooi @ 2011-11-04 9:38 UTC (permalink / raw)
To: openembedded-core; +Cc: Koen Kooi
Preinst are run alphabetically which breaks when e.g. avahi-daemon needs /etc/passwd present.
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
meta/classes/rootfs_ipk.bbclass | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index e02b816..47c4f94 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta/classes/rootfs_ipk.bbclass
@@ -77,6 +77,12 @@ fakeroot rootfs_ipk_do_rootfs () {
${ROOTFS_POSTINSTALL_COMMAND}
runtime_script_required=0
+
+ # Base-passwd needs to run first to install /etc/passwd and friends
+ if [ -e ${IMAGE_ROOTFS}${opkglibdir}/info/base-passwd.preinst ] ; then
+ sh ${IMAGE_ROOTFS}${opkglibdir}/info/base-passwd.preinst; then
+ fi
+
for i in ${IMAGE_ROOTFS}${opkglibdir}/info/*.preinst; do
if [ -f $i ] && ! sh $i; then
runtime_script_required=1
--
1.7.2.5
^ permalink raw reply related
* Re: sstate.bbclass: Ensure machine specific stamps are only wiped for the current task
From: Martin Jansa @ 2011-11-04 9:32 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111103220837.GO9949@jama.jama.net>
[-- Attachment #1: Type: text/plain, Size: 27566 bytes --]
On Thu, Nov 03, 2011 at 11:08:37PM +0100, Martin Jansa wrote:
> On Thu, Nov 03, 2011 at 05:33:28PM +0100, Martin Jansa wrote:
> > Hi,
> >
> > to recap what we have talked about on ELCE;
> >
> > Currently it doesn't seem to change sstate checksums after switching
> > MACHINE, but still it rebuilds everything at least once after switch.
> >
> > Today I've tried to wipe tmp and rebuild from sstate-cache and I've
> > noticed interesting thing:
> >
> > All recipes are starting with
> > do_populate_lic_setscene
> > not
> > do_populate_sysroot_setscene
> > like ie koen's build does
> >
> > NOTE: Resolving any missing task queue dependencies
> > NOTE: Preparing runqueue
> > NOTE: Executing SetScene Tasks
> > NOTE: package quilt-native-0.48-r0: task do_populate_lic_setscene: Started
> > NOTE: package shr-image-2.0-r18: task do_populate_lic_setscene: Started
> > NOTE: package quilt-native-0.48-r0: task do_populate_lic_setscene: Succeeded
> > NOTE: package shr-image-2.0-r18: task do_populate_lic_setscene: Succeeded
> >
> > Does do_populate_lic_setscene wipe all stamps after do_populate_lic so it
> > causes the rebuild instead of population of sysroot from sstate?
> >
> > IIRC I had similar issue when I was starting to use oe-core and it was
> > in the end caused by inheriting package_ipk (once directly from distro config
> > and once through sane-feed-ipk.inc) and it was fixed 6 months ago by:
> > http://git.shr-project.org/git/?p=meta-shr.git;a=commit;h=00623b3c6dd01c4a227008f7cfdb0801cb06f49a
> > And IIRC we've talked about some ways to make sstate less error-prone
> > for such things.
> >
> > Now I have similar symptoms but only after switching MACHINE.
> >
> > Any hint?
>
> With few more hours of debuging this.. I can say that sometimes it works,
> but sometimes it's too strict to be usefull anyway.
This is also related to older thread about sstate
http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/003308.html
I'm going to try
BB_SIGNATURE_HANDLER = "basichash"
as it's supposed to become default anyway IIRC.
Regards,
>
> Whole logs are here:
> http://build.shr-project.org/tests/jama/sstate.test
> here I'll try to shorten as much as possible.
>
> OE @shr ~/shr-core $ export MACHINE=qemuarm
> OE qemuarm@shr ~/shr-core $ bitbake -k core-image-core
> .....
> NOTE: package core-image-core-1.0-r0: task do_rm_work_all: Succeeded
> NOTE: Tasks Summary: Attempted 5306 tasks of which 5250 didn't need to be rerun and 0 failed.
> OE qemuarm@shr ~/shr-core $ bitbake -k expat
> Parsing of 1436 .bb files complete (1423 cached, 13 parsed). 1837 targets, 56 skipped, 0 masked, 0 errors.
>
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> NOTE: Running task 2428 of 2428 (ID: 11, /OE/shr-core/openembedded-core/meta/recipes-core/expat/expat_2.0.1.bb, do_rm_work_all)
> NOTE: package expat-2.0.1-r1: task do_rm_work_all: Started
> NOTE: package expat-2.0.1-r1: task do_rm_work_all: Succeeded
> NOTE: Tasks Summary: Attempted 2428 tasks of which 2427 didn't need to be rerun and 0 failed.
>
> All done
>
> OE qemuarmB@shr ~/shr-core $ cp openembedded-core/meta/conf/machine/qemuarm.conf openembedded-core/meta/conf/machine/qemuarmcopy.conf
> OE qemuarmB@shr ~/shr-core $ export MACHINE=qemuarmcopy
> OE qemuarmcopy@shr ~/shr-core $ bitbake -k expat
> Parsing of 1436 .bb files complete (0 cached, 1436 parsed). 1837 targets, 56 skipped, 0 masked, 0 errors.
>
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing SetScene Tasks
> ..
> libproxy fail (around task 2232)
> fix
>
> OE qemuarmcopy@shr ~/shr-core $ bitbake -k expat
> libproxy built
> NOTE: Tasks Summary: Attempted 2428 tasks of which 2232 didn't need to be rerun and 0 failed.
>
> So after 3 hours we have qemuarm and qemuarmcopy (identical machine) with expat built! hurray
> But seems like nothing was reused from qemuarm build.
>
> once again for check
>
> OE qemuarmcopy@shr ~/shr-core $ export MACHINE=qemuarm
> OE qemuarm@shr ~/shr-core $ bitbake -k expat
> Parsing of 1436 .bb files complete (1423 cached, 13 parsed). 1837 targets, 56 skipped, 0 masked, 0 errors.
> ...
> NOTE: Tasks Summary: Attempted 2428 tasks of which 2428 didn't need to be rerun and 0 failed.
>
> OE qemuarm@shr ~/shr-core $ export MACHINE=qemuarmcopy
> OE qemuarmcopy@shr ~/shr-core $ bitbake -k expat
> Parsing of 1436 .bb files complete (1423 cached, 13 parsed). 1837 targets, 56 skipped, 0 masked, 0 errors.
> ...
> NOTE: Tasks Summary: Attempted 2428 tasks of which 2428 didn't need to be rerun and 0 failed.
>
> great
>
> OE qemuarmcopy@shr ~/shr-core/tmp/sstate-control $ ls -lah manifest-qemuarm*expat* manifest-spitz-*expat* | sed 's/.*bitbake//g'
> 460 Oct 30 00:54 manifest-qemuarm-expat.deploy-ipk
> 1.2K Oct 30 00:54 manifest-qemuarm-expat.package
> 138 Oct 30 00:34 manifest-qemuarm-expat.populate-lic
> 732 Oct 30 00:54 manifest-qemuarm-expat.populate-sysroot
> 460 Nov 3 19:50 manifest-qemuarmcopy-expat.deploy-ipk
> 1.2K Nov 3 19:50 manifest-qemuarmcopy-expat.package
> 138 Nov 3 19:17 manifest-qemuarmcopy-expat.populate-lic
> 788 Nov 3 19:50 manifest-qemuarmcopy-expat.populate-sysroot
> 460 Oct 25 15:35 manifest-spitz-expat.deploy-ipk
> 1.2K Oct 25 15:35 manifest-spitz-expat.package
> 138 Oct 25 15:35 manifest-spitz-expat.populate-lic
> 704 Oct 25 15:35 manifest-spitz-expat.populate-sysroot
>
> OE qemuarmcopy@shr ~/shr-core/sstate-cache $ ls -la1 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-* | sort | sed 's/.*bitbake//g'
> 926 Nov 3 19:17 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-b198883dcffdb3af1a2c669f97d379ca_populate-lic.tgz
> 8444 Nov 3 19:17 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-b198883dcffdb3af1a2c669f97d379ca_populate-lic.tgz.siginfo
> 12409 Nov 3 19:50 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-62f6df13c2e883d59f8e73e5eb24fdab_deploy-ipk.tgz.siginfo
> 12419 Oct 25 15:35 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-757ebe15c6afc27935bb3f3b823f1a12_deploy-ipk.tgz.siginfo
> 12419 Oct 30 00:54 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-e2d316a9a054855d4433a3734e343db8_deploy-ipk.tgz.siginfo
> 21852 Nov 3 19:50 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-1a807cb22931fac0fbd848d258cafecd_populate-sysroot.tgz.siginfo
> 21920 Oct 25 15:35 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-d813b67ed935225757b90d014f631652_populate-sysroot.tgz.siginfo
> 21927 Oct 30 00:54 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-e90bb07db6e100f14ee8f8eed99a7d7e_populate-sysroot.tgz.siginfo
> 91310 Oct 25 15:35 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-f22b72a744d826703a553960f3402bc9_package.tgz.siginfo
> 91317 Oct 30 00:54 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-634056338ea09623cd84437f710e04d5_package.tgz.siginfo
> 91826 Nov 3 19:50 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-0bd093f2a681edc159eff0dc784022f9_package.tgz.siginfo
> 339323 Oct 25 15:35 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-d813b67ed935225757b90d014f631652_populate-sysroot.tgz
> 339468 Oct 30 00:54 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-e90bb07db6e100f14ee8f8eed99a7d7e_populate-sysroot.tgz
> 339470 Nov 3 19:50 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-1a807cb22931fac0fbd848d258cafecd_populate-sysroot.tgz
> 437319 Oct 25 15:35 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-757ebe15c6afc27935bb3f3b823f1a12_deploy-ipk.tgz
> 437805 Nov 3 19:50 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-62f6df13c2e883d59f8e73e5eb24fdab_deploy-ipk.tgz
> 437864 Oct 30 00:54 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-e2d316a9a054855d4433a3734e343db8_deploy-ipk.tgz
> 882262 Oct 25 15:35 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-f22b72a744d826703a553960f3402bc9_package.tgz
> 882411 Nov 3 19:50 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-0bd093f2a681edc159eff0dc784022f9_package.tgz
> 882415 Oct 30 00:54 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-634056338ea09623cd84437f710e04d5_package.tgz
>
> So it seems we have the same populate-lic.tgz.siginfo for all 3 machines but remaining tasks are 1 for each machine.
>
> so lets check deploy-ipk for qemuarm and qemuarmcopy..
>
> OE qemuarmcopy@shr ~/shr-core/sstate-cache $ bitbake-diffsigs sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-e2d316a9a054855d4433a3734e343db8_deploy-ipk.tgz.siginfo sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-62f6df13c2e883d59f8e73e5eb24fdab_deploy-ipk.tgz.siginfo
> basehash changed from 1d549bac0c3a8e400f1b56b7df9cf79e to 7558b2191b73c3ef5d99e608c2701215
> Variable OPKGBUILDCMD value changed from opkg-build -o 0 -g 0 to opkg-build
> Hash for dependent task virtual:native:/OE/shr-core/openembedded-core/meta/recipes-devtools/opkg-utils/opkg-utils_svn.bb.do_populate_sysroot changed from ed94400e8710f5a838f362f1ce67fb78 to 23c7d629ee4bf98f81cb85af901e7396
> Hash for dependent task /OE/shr-core/openembedded-core/meta/recipes-core/expat/expat_2.0.1.bb.do_package changed from 634056338ea09623cd84437f710e04d5 to 0bd093f2a681edc159eff0dc784022f9
> Hash for dependent task virtual:native:/OE/shr-core/openembedded-core/meta/recipes-devtools/pseudo/pseudo_1.1.1.bb.do_populate_sysroot changed from dde1a4ad1e7479005c272dda013d87ef to fca554e63de71499466d62d6c6d0f38c
>
> ahh lots of changes.. but wait!
> So MACHINE=qemuarm first said
> NOTE: Tasks Summary: Attempted 2428 tasks of which 2427 didn't need to be rerun and 0 failed.
> but sstate checksums were invalid already for qemuarm (ie due to OPKGBUILDCMD change)
>
> So let's retry with clean sstate:
>
> OE qemuarmcopy@shr ~/shr-core $ bitbake -c cleansstate -b openembedded-core/meta/recipes-core/expat/expat_2.0.1.bb
> ..
> OE qemuarmcopy@shr ~/shr-core/sstate-cache $ ls -la1 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-* | sort | sed 's/.*bitbake//g'
> ls: cannot access sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-*: No such file or directory
>
> OK no sstate tgz for all 3 armv5t machines
>
> OE qemuarmcopy@shr ~/shr-core/tmp/sstate-control $ ls -lah manifest-qemuarm*expat* manifest-spitz-*expat* | sed 's/.*bitbake//g'
> 460 Oct 30 00:54 manifest-qemuarm-expat.deploy-ipk
> 1.2K Oct 30 00:54 manifest-qemuarm-expat.package
> 138 Oct 30 00:34 manifest-qemuarm-expat.populate-lic
> 732 Oct 30 00:54 manifest-qemuarm-expat.populate-sysroot
> 460 Oct 25 15:35 manifest-spitz-expat.deploy-ipk
> 1.2K Oct 25 15:35 manifest-spitz-expat.package
> 138 Oct 25 15:35 manifest-spitz-expat.populate-lic
> 704 Oct 25 15:35 manifest-spitz-expat.populate-sysroot
>
> Remaining 2 armv5t machines still have their manifests, lets clean them too.
>
> OE qemuarmcopy@shr ~/shr-core $ export MACHINE=qemuarm
> OE qemuarm@shr ~/shr-core $ bitbake -c cleansstate -b openembedded-core/meta/recipes-core/expat/expat_2.0.1.bb
> ....
>
> OE qemuarm@shr ~/shr-core $ export MACHINE=spitz
> OE spitz@shr ~/shr-core $ bitbake -c cleansstate -b openembedded-core/meta/recipes-core/expat/expat_2.0.1.bb
> ...
>
> OE qemuarm@shr ~/shr-core/tmp/sstate-control $ ls -lah manifest-qemuarm*expat* | sed 's/.*bitbake//g'
> ls: cannot access manifest-qemuarm*expat*: No such file or directory
>
> OK good, clean start
>
> OE qemuarm@shr ~/shr-core $ bitbake expat
> Parsing of 1436 .bb files complete (1423 cached, 13 parsed). 1837 targets, 56 skipped, 0 masked, 0 errors.
> ...
> NOTE: Tasks Summary: Attempted 2428 tasks of which 2414 didn't need to be rerun and 0 failed.
>
> OE qemuarm@shr ~/shr-core $ export MACHINE=qemuarmcopy
> OE qemuarmcopy@shr ~/shr-core/sstate-cache $ ls -la1 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-* | sort | sed 's/.*bitbake//g'
> 926 Nov 3 21:50 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-b198883dcffdb3af1a2c669f97d379ca_populate-lic.tgz
> 8444 Nov 3 21:50 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-b198883dcffdb3af1a2c669f97d379ca_populate-lic.tgz.siginfo
> 12409 Nov 3 21:51 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-62f6df13c2e883d59f8e73e5eb24fdab_deploy-ipk.tgz.siginfo
> 21852 Nov 3 21:50 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-1a807cb22931fac0fbd848d258cafecd_populate-sysroot.tgz.siginfo
> 91826 Nov 3 21:51 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-0bd093f2a681edc159eff0dc784022f9_package.tgz.siginfo
> 339474 Nov 3 21:50 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-1a807cb22931fac0fbd848d258cafecd_populate-sysroot.tgz
> 437687 Nov 3 21:51 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-62f6df13c2e883d59f8e73e5eb24fdab_deploy-ipk.tgz
> 882413 Nov 3 21:51 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-0bd093f2a681edc159eff0dc784022f9_package.tgz
>
> OE qemuarmcopy@shr ~/shr-core/tmp/sstate-control $ ls -lah manifest-qemuarm*expat* | sed 's/.*bitbake//g'
> 460 Nov 3 21:51 manifest-qemuarm-expat.deploy-ipk
> 1.2K Nov 3 21:51 manifest-qemuarm-expat.package
> 138 Nov 3 21:50 manifest-qemuarm-expat.populate-lic
> 732 Nov 3 21:50 manifest-qemuarm-expat.populate-sysroot
>
> sofar good
>
> OE qemuarmcopy@shr ~/shr-core $ bitbake expat
> Parsing of 1436 .bb files complete (1423 cached, 13 parsed). 1837 targets, 56 skipped, 0 masked, 0 errors.
>
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing SetScene Tasks
> NOTE: package expat-2.0.1-r1: task do_package_write_ipk_setscene: Started
> NOTE: package expat-2.0.1-r1: task do_populate_sysroot_setscene: Started
> NOTE: package expat-2.0.1-r1: task do_package_write_ipk_setscene: Succeeded
> NOTE: package expat-2.0.1-r1: task do_populate_sysroot_setscene: Succeeded
> NOTE: package expat-2.0.1-r1: task do_package_setscene: Started
> NOTE: package expat-2.0.1-r1: task do_package_setscene: Succeeded
> NOTE: Executing RunQueue Tasks
> NOTE: Tasks Summary: Attempted 2428 tasks of which 2428 didn't need to be rerun and 0 failed.
>
> OE spitz@shr ~/shr-core/tmp/sstate-control $ ls -lah manifest-qemuarm*expat* | sed 's/.*bitbake//g'
> 460 Nov 3 21:51 manifest-qemuarm-expat.deploy-ipk
> 1.2K Nov 3 21:51 manifest-qemuarm-expat.package
> 138 Nov 3 21:50 manifest-qemuarm-expat.populate-lic
> 732 Nov 3 21:50 manifest-qemuarm-expat.populate-sysroot
> 460 Nov 3 21:54 manifest-qemuarmcopy-expat.deploy-ipk
> 1.2K Nov 3 21:54 manifest-qemuarmcopy-expat.package
> 788 Nov 3 21:54 manifest-qemuarmcopy-expat.populate-sysroot
>
> nice! everything reused! lets try spitz..
>
> OE spitz@shr ~/shr-core $ bitbake expat
> NOTE: Out of date cache found, rebuilding...
> NOTE: shr DOES NOT support sysvinit because use systemd now | ETA: 0:01:26
> NOTE: shr DOES NOT support external-poky-toolchain because use internal toolchain | ETA: 0:01:29
> NOTE: shr DOES NOT support external-csl-toolchain because use internal toolchain
> NOTE: shr DOES NOT support console-tools because use kbd now
> NOTE: shr DOES NOT support libiconv because libiconv is provided by LIBC | ETA: 0:01:30
> NOTE: shr DOES NOT support libiconv because libiconv is provided by LIBC
> NOTE: shr DOES NOT support gconf-dbus because gconf-dbus is provided by gconf | ETA: 0:01:32
> NOTE: shr DOES NOT support xserver-common because use x11-common now########################################### | ETA: 0:00:35
> Parsing recipes: 100% |########################################################################################################################| Time: 0:04:23
> Parsing of 1436 .bb files complete (0 cached, 1436 parsed). 1837 targets, 52 skipped, 0 masked, 0 errors.
>
> OE Build Configuration:
> BB_VERSION = "1.13.3"
> TARGET_ARCH = "arm"
> TARGET_OS = "linux-gnueabi"
> MACHINE = "spitz"
> DISTRO = "shr"
> DISTRO_VERSION = "20111103"
> TUNE_FEATURES = "armv5 dsp thumb xscale"
> TARGET_FPU = "soft"
> meta-jama = "master:f699df1c7aa69f669cf0e6f0e1fe5cc1e7f3e29e"
> meta-shr
> meta-aurora
> meta-fso = "jama:b159c41f87b6349a1b3963b77a696e3414012fc9"
> meta-efl
> meta-oe
> meta-gnome
> meta-gpe = "shr:b4ef7ac3f70ef15c45ef01af87a665d2a4135890"
> meta-nokia
> meta-htc
> meta-palm
> meta-openmoko
> meta-samsung = "jama:b159c41f87b6349a1b3963b77a696e3414012fc9"
> meta-handheld = "jansa/spitz:b228c7de95d49afc31866523c1c542a53f6229a7"
> meta = "jansa/test:9f46daa3b656ccd83ac3322ab8c8a027eb09b260"
>
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> NOTE: Running task 1961 of 2428 (ID: 4, /OE/shr-core/openembedded-core/meta/recipes-core/expat/expat_2.0.1.bb, do_fetch)
> NOTE: Running task 2142 of 2428 (ID: 1248, virtual:native:/OE/shr-core/meta-openembedded/meta-gnome/recipes-gnome/gobject-introspection/gobject-introspection_
> git.bb, do_fetch)
> NOTE: package expat-2.0.1-r1: task do_fetch: Started
> NOTE: package expat-2.0.1-r1: task do_fetch: Succeeded
> NOTE: Running task 2143 of 2428 (ID: 0, /OE/shr-core/openembedded-core/meta/recipes-core/expat/expat_2.0.1.bb, do_unpack)
> NOTE: package expat-2.0.1-r1: task do_unpack: Started
> NOTE: package gobject-introspection-native-1.29.0+gitr3+8d64bc23d2b837421ecf9c7b0e4b8d5d95ca0d21-r0: task do_fetch: Started
> ...
> NOTE: package gobject-introspection-native-1.29.0+gitr3+8d64bc23d2b837421ecf9c7b0e4b8d5d95ca0d21-r0: task do_rm_work: Succeeded
> NOTE: package libproxy-0.4.7-r1: task do_fetch: Started
> ...
> NOTE: package expat-2.0.1-r1: task do_rm_work: Succeeded
> NOTE: package libproxy-0.4.7-r1: task do_rm_work: Started
> NOTE: package libproxy-0.4.7-r1: task do_rm_work: Succeeded
> NOTE: Running task 2428 of 2428 (ID: 11, /OE/shr-core/openembedded-core/meta/recipes-core/expat/expat_2.0.1.bb, do_rm_work_all)
> NOTE: package expat-2.0.1-r1: task do_rm_work_all: Started
> NOTE: package expat-2.0.1-r1: task do_rm_work_all: Succeeded
> NOTE: Tasks Summary: Attempted 2428 tasks of which 2388 didn't need to be rerun and 0 failed.
>
> libproxy was built because I had to cleansstate it in first qemuarmcopy build - remember?
> gobject-introspection-native was rebuilt for some reason, but probably not important
>
> but why did it build expat again?
>
> OE spitz@shr ~/shr-core/sstate-cache $ ls -la1 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-* | sort | sed 's/.*bitbake//g'
> 924 Nov 3 22:02 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-b198883dcffdb3af1a2c669f97d379ca_populate-lic.tgz
> 8444 Nov 3 22:02 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-b198883dcffdb3af1a2c669f97d379ca_populate-lic.tgz.siginfo
> 12409 Nov 3 21:51 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-62f6df13c2e883d59f8e73e5eb24fdab_deploy-ipk.tgz.siginfo
> 12409 Nov 3 22:04 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-8ddf3a5ca6b77e09cb0c64fcc7ff5279_deploy-ipk.tgz.siginfo
> 21845 Nov 3 22:03 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-20b5b1202729ee864303af147d64958d_populate-sysroot.tgz.siginfo
> 21852 Nov 3 21:50 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-1a807cb22931fac0fbd848d258cafecd_populate-sysroot.tgz.siginfo
> 91819 Nov 3 22:04 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-cab79e114cc993bf250b13dfa8a93624_package.tgz.siginfo
> 91826 Nov 3 21:51 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-0bd093f2a681edc159eff0dc784022f9_package.tgz.siginfo
> 339330 Nov 3 22:03 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-20b5b1202729ee864303af147d64958d_populate-sysroot.tgz
> 339474 Nov 3 21:50 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-1a807cb22931fac0fbd848d258cafecd_populate-sysroot.tgz
> 437571 Nov 3 22:04 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-8ddf3a5ca6b77e09cb0c64fcc7ff5279_deploy-ipk.tgz
> 437687 Nov 3 21:51 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-62f6df13c2e883d59f8e73e5eb24fdab_deploy-ipk.tgz
> 882277 Nov 3 22:04 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-cab79e114cc993bf250b13dfa8a93624_package.tgz
> 882413 Nov 3 21:51 sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-0bd093f2a681edc159eff0dc784022f9_package.tgz
>
> OE spitz@shr ~/shr-core/tmp/sstate-control $ ls -lah manifest-qemuarm*expat* manifest-spitz-*expat* | sed 's/.*bitbake//g'
> 460 Nov 3 21:51 manifest-qemuarm-expat.deploy-ipk
> 1.2K Nov 3 21:51 manifest-qemuarm-expat.package
> 138 Nov 3 21:50 manifest-qemuarm-expat.populate-lic
> 732 Nov 3 21:50 manifest-qemuarm-expat.populate-sysroot
> 460 Nov 3 21:54 manifest-qemuarmcopy-expat.deploy-ipk
> 1.2K Nov 3 21:54 manifest-qemuarmcopy-expat.package
> 788 Nov 3 21:54 manifest-qemuarmcopy-expat.populate-sysroot
> 460 Nov 3 22:04 manifest-spitz-expat.deploy-ipk
> 1.2K Nov 3 22:04 manifest-spitz-expat.package
> 138 Nov 3 22:02 manifest-spitz-expat.populate-lic
> 704 Nov 3 22:03 manifest-spitz-expat.populate-sysroot
>
> OE qemuarm@shr ~/shr-core/sstate-cache $ bitbake-diffsigs sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-cab79e114cc993bf250b13dfa8a93624_package.tgz.siginfo sstate-expat-armv5te-oe-linux-gnueabi-2.0.1-r1-armv5te-2-0bd093f2a681edc159eff0dc784022f9_package.tgz.siginfo
> basehash changed from 46af1626aaa837363f75be1feb68a887 to 538e0e2d40c961a31a4347625af0b0f2
> Variable TUNE_CCARGS value changed from ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)} to ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)} ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)} ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)} ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)} ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)} ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)}
> Hash for dependent task /OE/shr-core/openembedded-core/meta/recipes-core/expat/expat_2.0.1.bb.do_install changed from caca792bd48071654a7061388de25373 to 18e1dbc2128e23f65b5a8d8fc418a38d
> Hash for dependent task /OE/shr-core/openembedded-core/meta/recipes-devtools/gcc/gcc-cross_4.6.bb.do_package changed from dd50ecd95cc6795a9dd0cd2bf46f402d to b781ef14e88af52bab8e86f18fd44e8a
> Hash for dependent task /OE/shr-core/openembedded-core/meta/recipes-core/eglibc/eglibc_2.14.bb.do_package changed from 585a01290d2062f02ec6618a9b4b661d to 27699293b72b7b12aa2662b9a1a66a53
> Hash for dependent task /OE/shr-core/openembedded-core/meta/recipes-devtools/desktop-file-utils/desktop-file-utils-native_0.15.bb.do_populate_sysroot changed from 67753340d7173dcf7d0a50f750b322b1 to 9d6d5166a23472faa5b66c8ab86a9448
> Hash for dependent task /OE/shr-core/openembedded-core/meta/recipes-devtools/gcc/gcc-runtime_4.6.bb.do_package changed from 66c434a5afcb5895d45e5f78a5375240 to de96ebfb46addf8e7a945a56da436af5
> Hash for dependent task /OE/shr-core/openembedded-core/meta/recipes-devtools/libtool/libtool-cross_2.4.bb.do_package changed from c2e9e854f6c13ae537f6d6edc6b6ed54 to 34ccdc741d85abba60afe3ce93676e77
>
> aaah so they're compatible only as far as they have completely the same TUNE_CCARGS?
>
> few more white-spaces to see the diff:
> Variable TUNE_CCARGS value changed from
> ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}
> ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}
> ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)}
> ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}
> ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}
> ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}
> to
> ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}
> ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}
> ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)}
> ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}
> ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}
> ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)}
>
> That's pity as they are overwritting the same files in feeds:
>
> OE qemuarm@shr ~/shr-core $ ls -lah tmp/deploy/ipk/armv5te/libexpat*
> -rw-r--r-- 1 bitbake bitbake 8.3K Nov 3 22:04 tmp/deploy/ipk/armv5te/libexpat-bin_2.0.1-r1_armv5te.ipk
> -rw-r--r-- 1 bitbake bitbake 191K Nov 3 22:04 tmp/deploy/ipk/armv5te/libexpat-dbg_2.0.1-r1_armv5te.ipk
> -rw-r--r-- 1 bitbake bitbake 13K Nov 3 22:04 tmp/deploy/ipk/armv5te/libexpat-dev_2.0.1-r1_armv5te.ipk
> -rw-r--r-- 1 bitbake bitbake 4.4K Nov 3 22:04 tmp/deploy/ipk/armv5te/libexpat-doc_2.0.1-r1_armv5te.ipk
> -rw-r--r-- 1 bitbake bitbake 171K Nov 3 22:04 tmp/deploy/ipk/armv5te/libexpat-staticdev_2.0.1-r1_armv5te.ipk
> -rw-r--r-- 1 bitbake bitbake 48K Nov 3 22:04 tmp/deploy/ipk/armv5te/libexpat1_2.0.1-r1_armv5te.ipk
>
> So user won't know if the package he downloads was built as qemuarm or qemuarmcopy or spitz..
> all he will notice is that md5 sums for ipk files are changing alot.
>
> Cheers,
> --
> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* [PATCH] rootfs_ipk bbclass: special-case base-passwd preinst to run first
From: Koen Kooi @ 2011-11-04 9:25 UTC (permalink / raw)
To: openembedded-core; +Cc: Koen Kooi
Preinst are run alphabetically which breaks when e.g. avahi-daemon needs /etc/passwd present.
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
meta/classes/rootfs_ipk.bbclass | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index e02b816..3ae0529 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta/classes/rootfs_ipk.bbclass
@@ -77,6 +77,15 @@ fakeroot rootfs_ipk_do_rootfs () {
${ROOTFS_POSTINSTALL_COMMAND}
runtime_script_required=0
+
+ # Base-passwd needs to run first to install /etc/passwd and friends
+ if [ -e ${IMAGE_ROOTFS}${opkglibdir}/info/base-passwd.preinst ] ; then
+ if ! sh ${IMAGE_ROOTFS}${opkglibdir}/info/base-passwd.preinst; then
+ runtime_script_required=1
+ opkg-cl ${IPKG_ARGS} flag unpacked base-passwd
+ fi
+ fi
+
for i in ${IMAGE_ROOTFS}${opkglibdir}/info/*.preinst; do
if [ -f $i ] && ! sh $i; then
runtime_script_required=1
--
1.7.2.5
^ permalink raw reply related
* Error building any image
From: Peter Lohmer @ 2011-11-04 9:23 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <CAE1-YAFQW1LXHfND8on-KBp-4fid32EAh5N12DD_hdmhc_54Qw@mail.gmail.com>
Hi all,
after last oecore update building fails with the following error message:
peter@p-lohmer-linux:~/oe-core$ bitbake -k xfce-nm-image
Loading cache: 100%
|##########################################################################################################|
ETA: 00:00:00
Loaded 1826 entries from dependency cache.
Parsing recipes: 100%
|########################################################################################################|
Time: 00:00:00
Parsing of 1418 .bb files complete (1414 cached, 4 parsed). 1825
targets, 72 skipped, 0 masked, 0 errors.
ERROR: No recipes available for:
/home/peter/oe-core/sources/meta-smartphone/meta-openmoko/recipes-multimedia/mplayer/mplayer2_git.bbappend
ERROR: Command execution failed: Exited with 1
I believe it's caused by meta-smartphone, does anyone face the same problem ?
Regards Peter
^ permalink raw reply
* Clean of qt4-embedded don't cleanup sysroot and deploy
From: Hauser, Wolfgang (external) @ 2011-11-04 9:18 UTC (permalink / raw)
To: openembedded-devel; +Cc: openembedded-core
I didn't get an answer, so I ask it again.
Hello,
if I do a bitbake -c clean for qt4-embedded or qt4-native all libraries
and binaries of QT are left in the sysroots and all created packages are
left in deploy. This is an result of splitting qt into several sub
packages and install them.
This behavior makes problems if I change the used QT Version of the
distro.
If qt recipe builds, it first searches for the libraries in sysroot
(standard library path of OE) and then it search in its working
directory. While the sysroots contain libraries of a different QT
version now, the build will fail.
Is there a way to clean all sub packages of qt if I clean the
qt4-embedded or qt4-native package ?
An other solution may be to switch the order of the library paths in the
linker command (-L) to search libraries in the package working path
first. But how to do this in a proper way?
Regards
Wolfgang Hauser
^ permalink raw reply
* Re: [PATCH] avahi: fix useradd race condition
From: Koen Kooi @ 2011-11-04 9:00 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4EB301E5.9050809@intel.com>
[-- Attachment #1: Type: text/plain, Size: 3769 bytes --]
Op 3 nov. 2011, om 22:04 heeft Scott Garman het volgende geschreven:
> On 11/03/2011 07:39 AM, Richard Purdie wrote:
>> On Thu, 2011-11-03 at 14:04 +0100, Koen Kooi wrote:
>>> Op 3 nov. 2011, om 13:57 heeft Koen Kooi het volgende geschreven:
>>>
>>>> Avahi doesn't work at boot because of:
>>>>
>>>> + sh /OE/../rootfs/var/lib/opkg/info/avahi-daemon.preinst
>>>> Running useradd commands...
>>>> grep: /OE/../rootfs/etc/passwd: No such file or directory
>>>>
>>>> That is due to:
>>>>
>>>> Package: avahi-daemon
>>>> Version: 0.6.30-r9.0
>>>> [..]
>>>> Depends: libavahi-core7 (>= 0.6.30), libdaemon0 (>= 0.14), libcap2 (>= 2.22), libavahi-common3 (>= 0.6.30), libdbus-1-3 (>= 1.4.12), sysvinit-pidof, libc6 (>= 2.12), libexpat1 (>= 2.0.1)
>>>>
>>>> After this patch:
>>>>
>>>> Package: avahi-daemon
>>>> Version: 0.6.30-r10.0
>>>> [..]
>>>> Depends: libavahi-core7 (>= 0.6.30), libdaemon0 (>= 0.14), libcap2 (>= 2.22), libavahi-common3 (>= 0.6.30), libdbus-1-3 (>= 1.4.12), sysvinit-pidof, libc6 (>= 2.12), shadow, libexpat1 (>= 2.0.1), base-passwd
>>>>
>>>> This also changes ${PN}-daemon to avahi-daemon to be consistent with the PACKAGES/FILES lines below
>>>>
>>>> Signed-off-by: Koen Kooi<koen@dominion.thruhere.net>
>>>> ---
>>>> meta/recipes-connectivity/avahi/avahi.inc | 7 ++++---
>>>> 1 files changed, 4 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc
>>>> index 79cfd73..728c38f 100644
>>>> --- a/meta/recipes-connectivity/avahi/avahi.inc
>>>> +++ b/meta/recipes-connectivity/avahi/avahi.inc
>>>> @@ -14,7 +14,7 @@ SECTION = "network"
>>>> # python scripts are under GPLv2+
>>>> LICENSE = "GPLv2+& LGPLv2.1+"
>>>>
>>>> -INC_PR = "r9"
>>>> +INC_PR = "r10"
>>>>
>>>> DEPENDS = "expat libcap libdaemon dbus glib-2.0"
>>>>
>>>> @@ -23,8 +23,9 @@ SRC_URI = "http://avahi.org/download/avahi-${PV}.tar.gz \
>>>> file://99avahi-autoipd \
>>>> file://initscript.patch"
>>>>
>>>> -USERADD_PACKAGES = "${PN}-daemon"
>>>> -USERADD_PARAM_${PN}-daemon = "--system --home /var/run/avahi-daemon \
>>>> +USERADDPN = "avahi-daemon"
>>>
>>> My gut feeling is that useradd.bbclass should add the RDEPENDS in its
>>> pythoncode instead of relying on people to set both USERADD_PACKAGES
>>> and USERADDPN to the same value.
>>
>> Agreed, looking at the code I think we can make this easier on the user.
>> I'll take the fix to solve the short term issues but we could do with
>> improving this.
>
> I've filed a bug and will work on a fix for this:
>
> http://bugzilla.pokylinux.org/show_bug.cgi?id=1727
>
> Thank you for uncovering the source of the problem.
Some more digging reveals a second bug:
+ for i in '/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/beaglebone-angstrom-linux-gnueabi/cloud9-image-1.0-r0/rootfs/var/lib/opkg/info/*.preinst'
That will go alphabetically, with 'avahi-daemon' going before 'base-passwd' :(
I'm going to test this patch:
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index e02b816..9a8edb1 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta/classes/rootfs_ipk.bbclass
@@ -77,6 +77,15 @@ fakeroot rootfs_ipk_do_rootfs () {
${ROOTFS_POSTINSTALL_COMMAND}
runtime_script_required=0
+
+ # Base-passwd needs to run first to install /etc/passwd and friends
+ if [ -e ${IMAGE_ROOTFS}${opkglibdir}/info/base-passwd.preinst ] ; then
+ if ! sh $i; then
+ runtime_script_required=1
+ opkg-cl ${IPKG_ARGS} flag unpacked base-passwd
+ fi
+ fi
+
regards,
Koen
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]
^ permalink raw reply related
* Re: [PATCH] rt-tests: update to 0.83
From: Koen Kooi @ 2011-11-04 8:14 UTC (permalink / raw)
To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CA+T6QPkZ5NNbtVES40=AuJ=X-Wc17ZNhhtQRzMS8=FGYtT3rTw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
Op 3 nov. 2011, om 13:22 heeft Jason Kridner het volgende geschreven:
> On Thu, Nov 3, 2011 at 5:21 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> Fetch from github, kernel.org uri is gone
>>
>> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
>
> Acked-by: Jason Kridner <jdk@ti.com>
Since rt-tests is unfetchable currently can this patch get merged quickly?
regards,
Koen
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]
^ permalink raw reply
* about the qemu net interface name
From: Ni Qingliang @ 2011-11-04 2:50 UTC (permalink / raw)
To: openembedded-core
file: scripts/runqemu-internal
line153: POSSIBLE=`$IFCONFIG -a|grep '^tap' | awk `{print $1}'`
on archlinux, I got that:
tap0:
tap1:
maybe it should be:
tap0
tap1
Is it right?
so I change it to
POSSIBLE=`$IFCONFIG -a|grep '^tap' | awk `{print $1}' | sed 's/:$//'`
--
Yi Qingliang
niqingliang@insigma.com.cn
https://niqingliang2003.wordpress.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox