* Re: [PATCH 3/8] pulseaudio-0.9.23: force ARM mode
From: Martin Jansa @ 2011-10-21 16:16 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1soRAhf065VCJqZsQMUct1a0Ob5S2rJzN9QpE0A0R0SZ6g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
On Fri, Oct 21, 2011 at 08:40:20AM -0700, Khem Raj wrote:
> On Fri, Oct 21, 2011 at 1:17 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > ---
> > .../pulseaudio/pulseaudio_0.9.23.bb | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > index 4ac2418..2f872b8 100644
> > --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > @@ -23,3 +23,4 @@ do_compile_prepend() {
> > cp ${STAGING_LIBDIR}/libltdl* ${S}/libltdl
> > }
> >
> > +ARM_INSTRUCTION_SET = "arm"
>
> not averse to patch but it would be nice to know what fails in thumb mode.
selected processor does not support Thumb mode `swp r1,r2,[r3]'
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* Re: [PATCH] squashfs-tools: add recipe (2nd try)
From: Saul Wold @ 2011-10-21 16:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Cliff Brake
In-Reply-To: <20111019212659.GA30050@sakrah.homelinux.org>
On 10/19/2011 02:26 PM, Khem Raj wrote:
> On (19/10/11 08:43), Cliff Brake wrote:
>> From: Cliff Brake<cbrake@bec-systems.com>
>>
>> added xz compression option, general cleanup
>> ---
>> .../squashfs-tools/squashfs-tools_4.2.bb | 38 ++++++++++++++++++++
>> 1 files changed, 38 insertions(+), 0 deletions(-)
>> create mode 100644 meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb
>>
>
> IIRC they did not work with thumb mode so you might have to add option
> to always build for arm mode when building for arm architectures.
> Add ARM_INSTRUCTION_SET = "arm" to the recipe
>
>> diff --git a/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb b/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb
>> new file mode 100644
>> index 0000000..3a9f12a
>> --- /dev/null
>> +++ b/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb
>> @@ -0,0 +1,38 @@
>> +# Note, we can probably remove the lzma option as it has be replaced with xz,
>> +# and I don't think the kernel supports it any more.
>> +DESCRIPTION = "Squashfs is a highly compressed read-only filesystem for Linux."
>
> I think this description is for the filesystem but the recipe is for
> tools. So probably saying something like "Tools for manipulate squashfs,
> ..." would be nice.
>
>> +SECTION = "base"
>> +LICENSE = "GPLv2& Public Domain"
>> +LIC_FILES_CHKSUM = "file://../COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
>> + file://../../7zC.txt;beginline=12;endline=16;md5=2056cd6d919ebc3807602143c7449a7c \
>> + "
>> +DEPENDS = "attr zlib xz"
>> +PR = "0"
>> +
>> +SRC_URI = "${SOURCEFORGE_MIRROR}/squashfs/squashfs${PV}.tar.gz;name=squashfs \
>> + http://downloads.sourceforge.net/sevenzip/lzma465.tar.bz2;name=lzma \
>> + "
>> +SRC_URI[squashfs.md5sum] = "1b7a781fb4cf8938842279bd3e8ee852"
>> +SRC_URI[squashfs.sha256sum] = "d9e0195aa922dbb665ed322b9aaa96e04a476ee650f39bbeadb0d00b24022e96"
>> +SRC_URI[lzma.md5sum] = "29d5ffd03a5a3e51aef6a74e9eafb759"
>> +SRC_URI[lzma.sha256sum] = "c935fd04dd8e0e8c688a3078f3675d699679a90be81c12686837e0880aa0fa1e"
>> +
>> +S = "${WORKDIR}/squashfs${PV}/squashfs-tools"
>> +
>> +# EXTRA_OEMAKE is typically: -e MAKEFLAGS=
>> +# the -e causes problems as CFLAGS is modified in the Makefile, so
>> +# we redefine EXTRA_OEMAKE here
>> +EXTRA_OEMAKE = "MAKEFLAGS= LZMA_SUPPORT=1 LZMA_DIR=../.. XZ_SUPPORT=1"
>> +
>> +do_compile() {
>> + oe_runmake mksquashfs
>> +}
>> +do_install () {
>> + install -d ${D}${sbindir}
>> + install -m 0755 mksquashfs ${D}${sbindir}/
>> +}
>> +
>> +# required to share same place with -lzma specific packages
>> +FILESPATHPKG =. "squashfs-tools-${PV}:"
>> +
>> +BBCLASSEXTEND = "native"
>> --
>> 1.7.1
>>
>>
This one is on hold pending an update from Cliff based on Khem's comments.
Sau!
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
^ permalink raw reply
* MINUTES: OE-TSC meeting 20-Oct-2011
From: Jeff Osier-Mixon @ 2011-10-21 16:19 UTC (permalink / raw)
To: openembedded-core, openembedded-devel, tsc
[-- Attachment #1: Type: text/plain, Size: 27063 bytes --]
MINUTES: OE-TSC meeting 20-Oct-2011
Attending: Mark, Richard, Khem, Koen, Tom
Notes: Jefro
________________________________________________________
Agenda & Results
(0) GA
- discussion about candidacy, maintainership & what to bring up & answer
at GA
- ACTION: tsc introspection in next meeting
(1) distro fields
- Saul planning to think about it & write proposal
(2) bugzilla
- ACTION: Khem to shut down bugzilla, create a landing page
(4) oe-core status
- ACTION: Khem & RP to drive tarball release to github
- ACTION: Koen to look into git push hooks for mirroring
(6) PR stuff
- ACTION: RP to refresh discussion on ML
(7) infrastructure status
- server changes in process, no ETA on completion
Agendized but not discussed:
(3) oe-core with selinux, other security
(5) review tools
________________________________________________________
Raw Transcript:
(1:04:49 PM) Jefro: I think everyone is here
(1:05:54 PM) khem: topics I would like to bring up two things. Distro fields
and bring down bugzilla
(1:06:01 PM) RP__: Jefro: I think so
(1:06:02 PM) fray: ok.. so I have a potential agenda item.. oe-core with
things like selinux support... or other "security" infrastructure changes..
(1:06:15 PM) fray: (I'm happy to table that to the future as well)
(1:06:21 PM) RP__: OE-Core release (and Bitbake)
(1:06:45 PM) khem: review tools
(1:06:56 PM) RP__: There are also calls for the TSC to talk about the PR
stuff
(1:08:06 PM) Jefro: topics: (1) distro fields (2) bugzilla (3) oe-core with
selinux, other security (4) oe-core status (5) review tools (6) PR stuff
(1:09:27 PM) khem: RP__: oh lastly some infra updates too
(1:09:50 PM) Jefro: topics contd (7) infrastructure status
(1:11:20 PM) RP__: As a group is there anything we want to represent the GA?
(1:11:52 PM) khem: RP__: a short update I guess
(1:11:52 PM) fray: RP__ I have the opposite.. is there anything we want to
ask of the members at the GA?
(1:11:55 PM) khem: would be nice
(1:12:15 PM) RP__: fray: indeed, that is where I was going next :)
(1:12:33 PM) RP__: We've seen some feedback from Frans and he has some valid
questions
(1:12:50 PM) Jefro: topics (0) GA
(1:13:03 PM) RP__: Jefro: sorry ;-)
(1:13:11 PM) Jefro: :) no prob
(1:13:41 PM) RP__: So anything specific to take to the GA other than general
updates and what was said on the members list?
(1:14:04 PM) RP__: Did anyone disagree with anything said on the members
list re: the TSC?
(1:14:24 PM) Tartarus: nope
(1:14:37 PM) fray: RP__ are your eferring to the call for candidates?
(1:14:39 PM) khem: was ok. I think
(1:14:47 PM) RP__: fray: the discussion that followed, yes
(1:15:10 PM) koen: RP__: I disagree, fwiw
(1:15:20 PM) RP__: I think the summary was that there are things we are
doing well, there are some things that are less well. We're only human but
its useful to keep people's feedback in mind
(1:15:20 PM) fray: yup.. ok..
(1:15:35 PM) fray: I think many of the points there are valid..
(1:15:49 PM) koen: I still think the TSC should *NOT* have taken away
maintainership of meta-oe
(1:15:56 PM) RP__: Some things are inevitable even with the resources Yocto
brings etc, we can't do everything
(1:16:55 PM) fray: I always come back to.. maintainership of any OE project
is up to the member(s) contributing to it..
(1:17:19 PM) fray: if people want to be maintainers they need to step up and
say that.. otherwise the TSC needs to do whatever is necessary to further
the layers..
(1:17:34 PM) khem: I think we should do a TSC introspection in next meeting
(1:17:47 PM) khem: where we talk about where we lack and where we are ok
(1:17:51 PM) RP__: I think there will be further discussion at the GA - I
agree we should revisit the topic after the GA
(1:19:16 PM) RP__: Jefro: Might I suggest topic 1 unless there is more
discussion?
(1:20:34 PM) khem: I think pb's point on incubating new developers was what
stuck with me
(1:23:03 PM) RP__: khem: agreed, I think we do need to incubate new
developers
(1:30:52 PM) Jefro: ok to move to next topic? 6 to go
(1:31:19 PM) RP__: I'd suggest we do
(1:32:01 PM) RP__: For distro fields, I don't think its clear cut. I think
Saul is going to think about it and give a proposal
(1:32:19 PM) RP__: and since he uses those most heavily I'd like to hear
that feedback before we go further on that
(1:32:39 PM) RP__: so its probably fine to continue on the mailing list for
now unless anyone has any pressing comments to add?
(1:32:43 PM) koen: I have no strong opinion on the fields except that
monolithic files suck in general
(1:32:52 PM) RP__: I agree with that and I hear you
(1:33:30 PM) fray: are we talking the maintainer fields or?
(1:33:44 PM) khem: distro tracking fields file
(1:34:09 PM) RP__: fray: that and the other distro tracking data (manual
update data, other distro equivalence fields etc.)
(1:34:11 PM) fray: ok.. ya, agree.. I prefer them in the recipes (or at
least the recipes directory...) but that can get messy
(1:34:17 PM) RP__: For bugzilla, I thought we'd agreed to shut it down?
(1:34:35 PM) fray: (oe bugzilla right?) and yes, we had.. since it was more
or less abandoned
(1:34:58 PM) RP__: yes
(1:34:58 PM) koen: the question is about killing the instance
(1:35:05 PM) koen: it has been RO for months now
(1:35:27 PM) fray: do we have any analytics that show if people are using it
(in a RO capability) still?
(1:35:30 PM) Tartarus: Time for a little more ngix redirect magic?
(1:35:50 PM) ***koen needs to finish the ngix recipe
(1:36:04 PM) RP__: So the con of taking it down is the lack of the data
being public anymore?
(1:36:08 PM) RP__: Is anyone using it?
(1:36:22 PM) khem: RP__: there are links on mails and if people use them
then we should have a page where it gives the information
(1:36:24 PM) RP__: Is any of the data there still relevant? Are people
accessing it?
(1:36:29 PM) fray: ya.. if nobody is using it.. then I'm not concerned.. if
it's still getting used.. is it relevant?
(1:36:48 PM) khem: RP__: I have no idea, no one adds data to it but access
wise I dont know if people do
(1:37:00 PM) fray: I'm not against removing it entirely.. I just hate
historical items disappearing. especially if there may be useful data in it
to explain why something happened in the past
(1:37:29 PM) RP__: is keeping it alive read only a problem?
(1:37:35 PM) khem: fray: there are links that people used in mails and if
someone searches such mails thats the only thing that we should care since
we can not edit those links
(1:37:43 PM) khem: RP__: that server is going away
(1:37:58 PM) khem: and we need to set it up again on new server
(1:37:58 PM) RP__: khem: hard to migrate?
(1:38:07 PM) khem: RP__: I guess not
(1:38:09 PM) khem: but its work
(1:38:19 PM) RP__: khem: it might be worth the effort and easier than a
landing page for the email links?
(1:38:24 PM) khem: I personally would not want to do it
(1:38:33 PM) khem: RP__: yes a landing page
(1:38:35 PM) khem: is good
(1:38:51 PM) RP__: what I mean is its probably just as much work to
transition the data?
(1:38:57 PM) RP__: The data should be saved anyway?
(1:39:08 PM) khem: yes its there
(1:39:09 PM) fray: ya, at a minimum we should have a landing page explaining
it went away... but I do prefer saving the data
(1:40:00 PM) khem: the databases are saved
(1:40:07 PM) khem: so it will be there
(1:40:14 PM) khem: just not visible
(1:40:27 PM) RP__: Perhaps ask on the mailing lists, see if anyone has
strong views?
(1:40:35 PM) khem: I already did
(1:40:42 PM) RP__: any response?
(1:40:53 PM) khem: most of responders were ok with it going away
(1:41:03 PM) khem: provided we have a landing page
(1:41:12 PM) fray: I'd say bring this up at the GA... but assuming we have a
landing page.. it'll go away
(1:41:27 PM) RP__: fray: not really a GA topic tbh
(1:41:43 PM) fray: I would have thought the members would be the ones to
care if it exists (or not)
(1:41:52 PM) fray: I'm not asking for a vote, just feedback
(1:42:02 PM) RP__: khem: I'm marginally in favour of setting up bugzilla to
share the data but only just if you see what I mean
(1:42:09 PM) khem: bugzilla was used by new user more often than seasoned
developes in my experience
(1:42:27 PM) khem: RP__: ok.
(1:42:40 PM) ***RP__ notes a timecheck
(1:42:55 PM) koen: I'd say a landing page is good enough
(1:43:02 PM) RP__: 5 items to go, 15 mins
(1:43:09 PM) koen: either we have a bugzilla or we don't, halfway sucks
(1:43:16 PM) ***Jefro notes the data can always be resurrected if the
complaints are loud
(1:43:38 PM) khem: I agree with koen
(1:44:03 PM) khem: and maintaining it is also some work plus the internet
traffic that comes from web crawlers
(1:44:21 PM) Jefro: if there is general agreement /me notes action item:
landing page, bugzilla removed
(1:44:32 PM) fray: no objection
(1:44:41 PM) Tartarus: no objection
(1:44:57 PM) RP__: (3) oe-core with selinux, other security (4) oe-core
status (5) review tools (6) PR stuff (7) infrastructure status
(1:45:14 PM) koen: can we move 6 up?
(1:45:17 PM) fray: we can table the discussion and move on or I can briefly
explain
(1:45:24 PM) fray: (and I'm happy to move it to the end)
(1:45:32 PM) RP__: We need to touch on 4 and 6 IMO
(1:45:53 PM) Tartarus: With 15min? maybe just 4 and 7?
(1:46:01 PM) RP__: Do we want to release OE-Core/Bitbake? Assuming the
answer is yes, who is going to which pieces of it?
(1:46:03 PM) Tartarus: Lets start 4 tho :)
(1:46:28 PM) khem: yes release is needed
(1:46:34 PM) RP__: I have the trees in a position we could do it
(1:46:58 PM) RP__: I'd kind of like to do it in their current states since
that was was was heavily tested for Yocto 1.1
(1:47:21 PM) RP__: but I have no place to put the tarballs and I think the
release annoucement would look better coming from someone other than me?
(1:47:41 PM) khem: I think both release at same time but other layers
(1:48:06 PM) khem: RP__: I have opened the ticket to get
downloads.openembedded.org back
(1:48:12 PM) fray: yes release
(1:48:13 PM) khem: but its still pending
(1:48:19 PM) RP__: khem: ETA?
(1:48:25 PM) khem: no
(1:48:25 PM) koen: we can start with a tag in the repo
(1:48:28 PM) khem: I will ask
(1:48:30 PM) fray: can we tag now, prepare the release.. and sit on it?
(1:48:36 PM) fray: (until downloads.... is ready?)
(1:48:38 PM) koen: and put tarballs on github temporary
(1:48:41 PM) fray: what about github?
(1:48:46 PM) RP__: Call this bitbake 1.14.0 ?
(1:48:48 PM) fray: koen, ya..
(1:48:53 PM) fray: RP__ I would think so
(1:48:58 PM) khem: yes tars can be put any time
(1:48:59 PM) RP__: Its probably more than a point release at this point
(1:49:19 PM) koen: no opinion on bitbake versioning here
(1:49:28 PM) RP__: it sucks to have to use github for tarballs :/
(1:49:38 PM) RP__: khem: the problem is the DNS?
(1:49:49 PM) koen: at least github is fast
(1:50:04 PM) khem: I think yes. I thought Tom K will figure it
(1:50:19 PM) RP__: khem: Can you take the AR to drive that?
(1:50:25 PM) khem: ok
(1:50:32 PM) khem: however I am gone for next 3 weeks
(1:50:37 PM) khem: starting sunday
(1:50:53 PM) RP__: khem: hmm, will you have time before you go to ping him?
(1:51:10 PM) khem: yes surely
(1:51:20 PM) khem: hopefully we can set it us as well
(1:51:32 PM) RP__: So given no other volunteers, I guess I'll have to drive
the announcement and work through this?
(1:51:32 PM) ***Jefro notes action item for khem to drive tarball release to
github this week
(1:51:55 PM) koen: with a oe-core tag in place I can drive the meta-oe part
(1:52:05 PM) RP__: koen: ok, thanks
(1:52:09 PM) koen: (and meta-angstrom, meta-ti, setup-scripts, etc, but
that's not OE)
(1:52:31 PM) khem: RP__: I can help with announcement if you need and if its
planned before I leave
(1:53:00 PM) RP__: khem: with me moving atm, I'm not sure when/how i'm going
ot manage this :/
(1:53:10 PM) khem: sure ok
(1:53:11 PM) RP__: but I know our users are not happy and it needs to get
done
(1:53:31 PM) RP__: so, probably best to cover 7
(1:53:42 PM) koen: infra status
(1:53:43 PM) RP__: particularly if khem is missing
(1:53:50 PM) fray: I'm happy to help with the release... tell me what needs
to be done (announcements, wiki, etc).. but I don't have the git perms to do
the actual release work
(1:54:34 PM) RP__: Is the TSC happy for me to handle the announcement, I
guess that is the question. I'd not like to presume :)
(1:54:40 PM) koen: I am
(1:54:55 PM) fray: i am
(1:55:00 PM) khem: on 7 we have moved all services to new VM
(1:55:03 PM) khem: I am ok
(1:55:03 PM) RP__: fray: I'll see how we can work this out and pull you in
if/as needed
(1:55:07 PM) fray: ok
(1:55:29 PM) RP__: khem: cool, thanks for the work you/Tom and anyone else
involved have put in!
(1:55:40 PM) ***Jefro 5 minute warning
(1:55:59 PM) khem: Tom also has build box installed and we should have
access to it soon
(1:56:05 PM) khem: but no ETA
(1:56:29 PM) RP__: khem: ok, cool :)
(1:56:51 PM) RP__: Do we want to extend the meeting to cover some of the
other topics?
(1:56:53 PM) khem: on old VM we have github mirroring crob tasks
(1:56:55 PM) RP__: or leave until next time?
(1:57:01 PM) Tartarus: next time for me
(1:57:04 PM) khem: that pb runs should move to new VM
(1:57:08 PM) khem: when he has time
(1:57:39 PM) koen: s/crob/cron/
(1:57:49 PM) koen: we should make them git push hooks
(1:58:07 PM) Jefro: any other high-priority items to discuss before GA next
week?
(1:58:07 PM) khem: yes its possible to make them hooks
(1:58:08 PM) koen: (I can look into that after ELC-E, we're going to do that
for meta-ti)
(1:58:25 PM) khem: I looked into them briefly
(1:58:50 PM) RP__: The push hooks would delay people's pushes though
wouldn't they?
(1:59:19 PM) koen: no idea, but I can look into that
(1:59:29 PM) khem: RP__: yes a bit
(1:59:33 PM) koen: Jefro: can you make that an AR for me?
(1:59:46 PM) ***Jefro notes action item for koen to look into push hooks
(2:00:03 PM) RP__: It is annoying if you have a raft of things to push out
and each one has time lag :/
(2:00:43 PM) koen: you'll be one of the 2 people affected, the other one is
me for meta-oe
(2:00:53 PM) khem: you mean multiple push ?
(2:00:57 PM) koen: and our bus factor reducers, saul, khem, etc
(2:01:06 PM) RP__: koen: right
(2:01:26 PM) RP__: It was "fun" watching the patchwork hooks slow things
down today
(2:03:04 PM) RP__: So that brings us past time :/
(2:03:05 PM) Jefro: remaining issues? I remember that Tartarus had to flee
at 2pm
(2:03:20 PM) koen: ironically the pw hooks refused to update the patch khem
sent :)
(2:03:46 PM) khem: koen: what was error ?
(2:04:02 PM) khem: was it generic error
(2:04:03 PM) koen: it couldn't correlate the patch I pushed with the one in
pw
(2:04:13 PM) khem: hmmm
(2:04:25 PM) khem: did it happen only for 1 patch or others too
(2:04:37 PM) RP__: The PR issues probably does need addressing and is a TSC
centric issue
(2:04:53 PM) RP__: We need to do that when we're all here thoug
(2:05:37 PM) khem: RP__: PR = problem report ?
(2:05:45 PM) khem: or the publicity
(2:05:55 PM) fray: package release
(2:06:06 PM) RP__: khem: The PR bumping discussion on the mailing list
(2:06:10 PM) koen: Package Revision
(2:06:12 PM) khem: oh I see
(2:07:40 PM) RP__: Are we closing the meeting?
(2:07:48 PM) koen: I still have time
(2:07:54 PM) fray: we can.. or we can discuss other things.. I have time
(2:08:07 PM) khem: I can spend some more mins
(2:08:28 PM) ***Jefro can stick around
(2:09:04 PM) fray: ok, next topic then? PR (or is Tartarus gone?)
(2:09:24 PM) koen: I bet Tartarus is screaming at uboot
(2:09:34 PM) Tartarus: I'm semi here still
(2:09:36 PM) ***fray does that every now and then
(2:09:40 PM) Tartarus: Need to put Daughter down for a nap then run errands
(2:10:44 PM) RP__: So I think our future direction from an architecture
point of view needsto be to automate the PR bumps
(2:11:11 PM) RP__: Why? Currently its unclear which bumps are needed to
which packages and when. It also totally breaks down with layers
(2:11:28 PM) khem: RP__: I agree
(2:11:34 PM) RP__: The values would be better maintained alongside the
distro feeds that contain the used values
(2:11:38 PM) khem: so do we maintain a database or how
(2:11:44 PM) khem: ah
(2:12:00 PM) RP__: The trouble is this change will be a bit painful
(2:12:13 PM) RP__: We've put off enabling the BasicHash handler for a long
time now
(2:12:56 PM) RP__: I'd really like to see people thinking and working
towards addressing these issues. As such I refused a patch to OE core adding
manual PR increment functionality
(2:13:00 PM) khem: RP__: so if I dont have any feeds where do the initial
values come from
(2:13:19 PM) RP__: khem: We need some tools to handle some of these things
(2:13:26 PM) Tartarus: I think day 1 after a release is about when we need
to turn on the solution, or at least the current proposal
(2:13:33 PM) RP__: khem: they'd default to starting at 0
(2:13:34 PM) koen: the issue otavio raised is that the kernel.bbclass line
RP draws is arbitrary
(2:13:42 PM) Tartarus: So if basic hash should be able to get us most of the
way, time to switch
(2:13:49 PM) khem: RP__: so distro's then cant share feeds ?
(2:13:51 PM) RP__: Tartarus: I'd love to throw the BasicHash switch now
(2:13:54 PM) fray: ya.. this is something that is going to take time for
people to ome to terms with -- or object so strongly we revert..
(2:14:01 PM) Tartarus: I vote now, and am mostly afk, now
(2:14:04 PM) fray: the hash thing needs to be done ASAP.. the PR thing is
what may or may not work
(2:14:05 PM) koen: Tartarus: you will kill rebuilding from (old) tags
(2:14:08 PM) RP__: khem: only if they sync up PR data
(2:14:11 PM) fray: but I vote as soon as we tag and release
(2:14:36 PM) koen: this auto-pr things needs to be done in a branch and
merged when it works good enough
(2:14:38 PM) RP__: We do have the network PR service that we created a while
back
(2:14:57 PM) fray: I assume the auto-pr stuff is the network PR service, w/o
the network
(2:15:05 PM) koen: I think I've already shown that that network PR thingy is
worthless for any real work?
(2:15:08 PM) RP__: I think that with some not so difficult improvements to
save the data to metadata and back we can address the reproducibility issues
(2:15:28 PM) RP__: koen: Its not worthless, you've just found a usecase it
doesn't cover
(2:15:35 PM) RP__: koen: the world isn't black/white
(2:15:42 PM) RP__: fray: yes
(2:16:07 PM) koen: I'm trying to make it more black and white so that it
will go in a branch first
(2:16:09 PM) fray: ya, in that case, I'm fairly comfortable with it.. enough
to explain to the world the possible pain and to turn it on
(2:16:33 PM) RP__: fray: I do understand this will cause koen and anyone
else with distro feeds some problems
(2:16:34 PM) fray: but geting the updated hashing first is key IMHO..
(2:16:44 PM) koen: if the changes are really "not so diffucult" the branch
will be short lived
(2:16:53 PM) fray: we SHOULD be able to seed the data though with the feed
info, right?
(2:17:09 PM) RP__: fray: the feed info is the current set of PR values
(2:17:21 PM) RP__: which I guess we need to "export" to an include
(2:17:26 PM) khem: I see
(2:17:28 PM) fray: ya, current PR's which can be tied back to specific hash
values right?
(2:17:41 PM) RP__: once we can import/export the data from the PR service to
an include we should be good to go IMO
(2:17:53 PM) fray: that was my thought as well..
(2:17:54 PM) RP__: fray: hash value is distro specific
(2:18:20 PM) khem: RP__: do I assume its going to be a file or some such
that will be updated after build ?
(2:18:21 PM) RP__: So my vote is not for now instantly but very soon
(2:18:22 PM) koen: I still say it should live in a branch at first
(2:18:28 PM) RP__: once we have the import/export script
(2:18:46 PM) koen: I've seen the eglibc fallout from a recent experiment
(2:18:49 PM) RP__: and since this will happen soon, we shouldn't be taking
PR bump type features into OE-Core at this point
(2:18:55 PM) fray: koen, my only problem with "branches" is getting people
to use them
(2:19:19 PM) koen: my problem is with people knowingly breaking master using
that excuse
(2:19:50 PM) fray: well, the goal is to not knowingly break master with this
change.. but to expect (and react) to the unknown issues
(2:20:04 PM) koen: I know I'm not going to live test it in master, I'll roll
back to the release
(2:20:30 PM) koen: testing a branch is no problem
(2:20:38 PM) koen: since this will be messy
(2:20:44 PM) khem: put it in master-next
(2:20:56 PM) khem: and we can test it out
(2:20:58 PM) ***RP__ will make no comment about how long the feedback for
the network PR service took
(2:21:31 PM) koen: it was too hard to test for me, being based on poky and
all
(2:21:39 PM) koen: </lame excuse>
(2:21:56 PM) ***RP__ tries not to choke ;-)
(2:22:25 PM) RP__: So, I'm suggesting that we so look to do this stuff soon
once we have the import/export scripting working and hopefully once koen is
happy we have some kind of solution in place than can work for his usecases
(2:22:42 PM) fray: seems reasonable
(2:22:45 PM) RP__: this will rely on some mailing list discussions, testing
and some help
(2:22:53 PM) koen: and in the meantime can we apply that kernel.bbclass
path?
(2:22:57 PM) RP__: and it will be with some of the Yocto PRC team doing some
of this
(2:23:00 PM) RP__: koen: no
(2:23:02 PM) koen: I really want to remove it from meta-oe
(2:23:44 PM) koen: OTOH, I can ignore any hatemail about meta-oe overrides
now
(2:24:29 PM) RP__: koen: How many more patches will I get if I take that
one?
(2:24:58 PM) koen: to sync meta-oe classes involving PR? none
(2:25:08 PM) RP__: koen: For PR in general
(2:25:25 PM) koen: you're saying any patch touching PR will get
rejected??!?!
(2:25:53 PM) RP__: For bulk PR handling with new variables I'll reject
(2:26:07 PM) koen: there's only INC_PR and MACHINE_KERNEL_PR
(2:26:11 PM) RP__: I'll continue to grudgingly tolerate the PR bumps for now
(2:26:15 PM) koen: in classic OE
(2:26:23 PM) RP__: koen: but people want to add more
(2:26:36 PM) koen: since only otavio and I could be arsed to 'fix' PR
problems there
(2:26:58 PM) koen: RP__: 'people' don't get PR anyway
(2:27:12 PM) koen: so I wouldn't worry about magic PR helpers appearing
(2:27:30 PM) RP__: koen: so we need to start educating them and the
MACHINE_KERNEL_PR sends totally the wrong message :/
(2:27:45 PM) RP__: I know you understand the issue, others will not
(2:27:48 PM) koen: it does, but it will remove a bbclass overlay
(2:27:49 PM) khem: RP__: take it for now and then drop it when Auto PR is in
(2:28:05 PM) RP__: Then I'll be accused of breaking existing functionality
(2:28:08 PM) koen: I'm getting too much crap about it being overlayed
(2:28:31 PM) koen: (which I can now say is not my fault, pesky OE core
maintainer ;)
(2:28:38 PM) ***RP__ gets too much crap about PR values in general
(2:29:09 PM) RP__: koen: you can blame me for now, this isn't going to be
for long
(2:29:13 PM) fray: PR is one of those things you need a distribution
maintainer and policy for.. otherwise inconsistencies easily creep in.. :(
(2:29:14 PM) koen: RP__: consider that I silently 'repair' feeds a few times
a week due to oe-core messing up upgrade paths
(2:29:35 PM) RP__: koen: I have really tried to help with this
(2:29:39 PM) koen: I know
(2:29:48 PM) koen: that's why I don't report every incident
(2:29:51 PM) RP__: koen: This is also why I want to get something automated
(2:29:57 PM) khem: RP__: OK so the network PR stuff is what we want to use
here
(2:30:30 PM) koen: but please realize that in general oe-core is a huge pain
for people with a binary distro feed
(2:30:39 PM) koen: we all try hard, but we are failing
(2:30:57 PM) RP__: koen: This is why we need a change in approach
(2:31:00 PM) koen: exactly
(2:31:22 PM) khem: koen: I think having PR controlled by distro's is sane I
guess ?
(2:31:36 PM) koen: doesn't really matter where
(2:32:08 PM) fray: PR is a distribution "issue".. and we need to provide the
tools (and data) to make it easier to manager
(2:32:08 PM) koen: ideally a recipe maintainer knows best
(2:32:20 PM) koen: e.g. xorg changed abi
(2:32:32 PM) koen: so things like xf86-video-fbdev need rebuilding
(2:32:48 PM) koen: (I 'repaired' the feeds for that yesterday)
(2:33:11 PM) fray: yup these are the things that hashing and auto PR should
help with
(2:33:14 PM) fray: (I hope)
(2:33:14 PM) koen: the fs-perms.txt change in angstrom is another
(2:33:20 PM) RP__: koen: Are false positives a problem?
(2:33:26 PM) koen: RP__: not for me
(2:33:38 PM) khem: koen: I think if we rebuild more its suboptimal but ok I
think
(2:33:44 PM) RP__: koen: ok
(2:34:03 PM) koen: PR is really a "better safe than sorry" type of thing
(2:34:04 PM) RP__: We'll obviously look to not rebuild more than we need but
its going to take a little experimentation
(2:34:18 PM) khem: agree
(2:34:28 PM) RP__: the checksum code does er on the side of false positives
(2:34:54 PM) khem: RP__: why not send a proposal
(2:34:55 PM) khem: to ml
(2:35:34 PM) RP__: khem: It has been discussed before, just a while ago.
Refreshing people's memory is probably good I guess
(2:35:39 PM) RP__: but release takes priority
(2:36:04 PM) khem: ok yes I think release should happen before this change
for sure
(2:36:27 PM) koen: I'd still like it to sit in master-next for a while
(2:36:55 PM) RP__: koen: Lets see how this goes
(2:37:10 PM) ***RP__ next needs to explain what the problem is to the Yocto
PRC people
(2:37:18 PM) khem: koen: RP__ yes master-next should have it for a while so
distro maintainers can adapt to it in background
(2:37:21 PM) ***RP__ might as well give up on a day off tomorrow
(2:37:32 PM) RP__: and the house moving thing
(2:37:48 PM) khem: RP__: you need 25th hour
(2:37:58 PM) RP__: khem: and the rest :/
(2:38:18 PM) khem: thats what it is for sleep 1 hr :)
(2:38:23 PM) khem: and work 24
(2:38:55 PM) khem: I need to make a move
(2:39:12 PM) khem: bye see u in 3 weeks
(2:39:25 PM) RP__: khem: safe travels!
(2:39:31 PM) fray: sounds good! have a good time
(2:39:40 PM) khem: I will
(2:39:55 PM) khem: watch out me flying over eu on 26th :)
(2:40:07 PM) khem: I will wave when I am over Germany :)
(2:40:30 PM) Jefro: safe travels khem
(2:40:37 PM) khem: thx
(2:40:44 PM) khem left the room.
(2:41:02 PM) ***koen also needs to zzz soon
(2:41:36 PM) Jefro: meeting adjourned?
(2:43:12 PM) RP__: Jefro: yes! :)
--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
[-- Attachment #2: Type: text/html, Size: 31599 bytes --]
^ permalink raw reply
* Re: [PATCH 2/8] libatomics-ops: force ARM mode
From: Martin Jansa @ 2011-10-21 16:21 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1soEYSZvnDKPTT+63r759mKV753wgXY2PuYU2rtii8KZLg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]
On Fri, Oct 21, 2011 at 09:06:34AM -0700, Khem Raj wrote:
> On Fri, Oct 21, 2011 at 1:48 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Fri, Oct 21, 2011 at 10:43:46AM +0200, Henning Heinold wrote:
> >> Hi,
> >>
> >> hm we should think of reworking this recipe now. Because since gcc 4.5
> >> pulseaudio for arm can use the gcc internal atomicstuff and in oe-core
> >> and meta-oe we have 4.5 or 4.6 only. The lib is
> >> only needed for mips and it is still the old release, on cvs
> >> is a much better version, which supports thumb too, if
> >> remember correctly.
> >
> > Agreed, I've added this only because pulseaudio is now needed for
> > gst-plugins and I wasn't able to build any armv[45]t images.
> >
> > But because I don't know much about pulseaudio or libatomics-ops I was
> > hoping that someone who maintains them will fix it properly and this
> > work around will be needed only temporary.
>
> Would you have cycles to create a git recipe for it the git tree is here
> https://github.com/ivmai/libatomic_ops/
Sorry, I'm not going to spend more of my free time on stuff I've never
used on my phones at least as long as we have broken stuff which we're
using almost daily.
But I can keep this work around or .bbappend dropping whole pulseaudio
in SHR until someone fixes it properly or until I fix all other issues
we have.
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* [PATCHv3] squashfs-tools: add recipe
From: Cliff Brake @ 2011-10-21 16:39 UTC (permalink / raw)
To: openembedded-core; +Cc: Cliff Brake
In-Reply-To: <20111019212659.GA30050@sakrah.homelinux.org>
From: Cliff Brake <cbrake@bec-systems.com>
added xz compression option, general cleanup
---
.../squashfs-tools/squashfs-tools_4.2.bb | 40 ++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
create mode 100644 meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb
diff --git a/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb b/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb
new file mode 100644
index 0000000..6691797
--- /dev/null
+++ b/meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb
@@ -0,0 +1,40 @@
+# Note, we can probably remove the lzma option as it has be replaced with xz,
+# and I don't think the kernel supports it any more.
+DESCRIPTION = "Tools to manipulate Squashfs filesystems."
+SECTION = "base"
+LICENSE = "GPLv2 & Public Domain"
+LIC_FILES_CHKSUM = "file://../COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
+ file://../../7zC.txt;beginline=12;endline=16;md5=2056cd6d919ebc3807602143c7449a7c \
+ "
+DEPENDS = "attr zlib xz"
+PR = "0"
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/squashfs/squashfs${PV}.tar.gz;name=squashfs \
+ http://downloads.sourceforge.net/sevenzip/lzma465.tar.bz2;name=lzma \
+ "
+SRC_URI[squashfs.md5sum] = "1b7a781fb4cf8938842279bd3e8ee852"
+SRC_URI[squashfs.sha256sum] = "d9e0195aa922dbb665ed322b9aaa96e04a476ee650f39bbeadb0d00b24022e96"
+SRC_URI[lzma.md5sum] = "29d5ffd03a5a3e51aef6a74e9eafb759"
+SRC_URI[lzma.sha256sum] = "c935fd04dd8e0e8c688a3078f3675d699679a90be81c12686837e0880aa0fa1e"
+
+S = "${WORKDIR}/squashfs${PV}/squashfs-tools"
+
+# EXTRA_OEMAKE is typically: -e MAKEFLAGS=
+# the -e causes problems as CFLAGS is modified in the Makefile, so
+# we redefine EXTRA_OEMAKE here
+EXTRA_OEMAKE = "MAKEFLAGS= LZMA_SUPPORT=1 LZMA_DIR=../.. XZ_SUPPORT=1"
+
+do_compile() {
+ oe_runmake mksquashfs
+}
+do_install () {
+ install -d ${D}${sbindir}
+ install -m 0755 mksquashfs ${D}${sbindir}/
+}
+
+# required to share same place with -lzma specific packages
+FILESPATHPKG =. "squashfs-tools-${PV}:"
+
+ARM_INSTRUCTION_SET = "arm"
+
+BBCLASSEXTEND = "native"
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/6] gmp: also generate the libgmpcxx library
From: Kamble, Nitin A @ 2011-10-21 16:54 UTC (permalink / raw)
To: Wold, Saul; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <4EA12540.9020002@intel.com>
> -----Original Message-----
> From: Saul Wold [mailto:saul.wold@intel.com]
> Sent: Friday, October 21, 2011 12:55 AM
> To: Kamble, Nitin A
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 2/6] gmp: also generate the libgmpcxx
> library
>
> On 10/20/2011 11:04 PM, Kamble, Nitin A wrote:
> >
> >
> >> -----Original Message-----
> >> From: Saul Wold [mailto:saul.wold@intel.com]
> >> Sent: Thursday, October 20, 2011 12:50 AM
> >> To: Patches and discussions about the oe-core layer
> >> Cc: Kamble, Nitin A
> >> Subject: Re: [OE-core] [PATCH 2/6] gmp: also generate the libgmpcxx
> >> library
> >>
> >> On 10/18/2011 05:30 PM, nitin.a.kamble@intel.com wrote:
> >>> From: Nitin A Kamble<nitin.a.kamble@intel.com>
> >>>
> >>> configure runs few checks to make sure c++ compiler and runtime are
> >> working as expected
> >>> with the --enable-cxx=detect option.
> >>>
> >> Somehow this change has also changed what the gmp package provides,
> >> before this change the package provided libgmp10 via PKG_gmp:
> libgmp10,
> >> after this change, the libgmp10 is no longer provided and causes
> other
> >> breakage.
> >>
> >> The example case I found was a coreutils package that was built
> prior
> >> to
> >> this change failed to fulfill it's dependencies after this change
> when
> >> creating an image. If I rebuild coreutils with the newer gmp build,
> >> then all is well, I think we need to understand this better before
> >> making this change.
> >>
> >> Did something else change in the packaging that would cause use to
> look
> >> the mapping above?
> >>
> > Saul,
> > In my testing I did not get any of these issues you mentioned
> above.
> >
> > Also I tried to reproduce the issue with coreutils as mentioned
> above, and I can not reproduce the issue for creations of an image. Can
> you verify the issue one more time?
> >
> Just to confirm, did you have a build of coreutils prior to your gmp
> changes? Which image did you build? Be sure you build an image that
> includes coreutils, such at an -sdk image.
>
> I can easily reproduce this issue.
>
> Sau!
>
I am able to reproduce the issue with sdk image, The packages(rpms) generated are different in r0 vs r1 version of gmp. Hence you are seeing that issue. Earlier libgmp.so.10 was the only library need packaging, so I guest package name was chosen aslibgmp10. now libgmpxx.so is also part of the package, hence recipe name which is gmp is chosen as the package name.
$ ls gmp-5.0.2-r0/deploy-rpms/i586/
libgmp10-5.0.2-r0.i586.rpm libgmp-dev-5.0.2-r0.i586.rpm libgmp-staticdev-5.0.2-r0.i586.rpm
libgmp-dbg-5.0.2-r0.i586.rpm libgmp-doc-5.0.2-r0.i586.rpm
$ ls gmp-5.0.2-r1/deploy-rpms/i586/
gmp-5.0.2-r1.i586.rpm gmp-dev-5.0.2-r1.i586.rpm gmp-staticdev-5.0.2-r1.i586.rpm
gmp-dbg-5.0.2-r1.i586.rpm gmp-doc-5.0.2-r1.i586.rpm
Thanks,
Nitin
> > Thanks,
> > Nitin
> >
> >>
> >> Sau!
> >>
> >>
> >>> Signed-off-by: Nitin A Kamble<nitin.a.kamble@intel.com>
> >>> ---
> >>> meta/recipes-support/gmp/gmp.inc | 2 ++
> >>> meta/recipes-support/gmp/gmp_4.2.1.bb | 2 +-
> >>> meta/recipes-support/gmp/gmp_5.0.2.bb | 2 +-
> >>> 3 files changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/meta/recipes-support/gmp/gmp.inc b/meta/recipes-
> >> support/gmp/gmp.inc
> >>> index 66349e6..3c662a0 100644
> >>> --- a/meta/recipes-support/gmp/gmp.inc
> >>> +++ b/meta/recipes-support/gmp/gmp.inc
> >>> @@ -14,3 +14,5 @@ ARM_INSTRUCTION_SET = "arm"
> >>> acpaths = ""
> >>>
> >>> BBCLASSEXTEND = "native nativesdk"
> >>> +
> >>> +EXTRA_OECONF += " --enable-cxx=detect"
> >>> diff --git a/meta/recipes-support/gmp/gmp_4.2.1.bb b/meta/recipes-
> >> support/gmp/gmp_4.2.1.bb
> >>> index 74da6b8..97ac4b2 100644
> >>> --- a/meta/recipes-support/gmp/gmp_4.2.1.bb
> >>> +++ b/meta/recipes-support/gmp/gmp_4.2.1.bb
> >>> @@ -6,7 +6,7 @@ LICENSE = "LGPLv2.1+"
> >>> LIC_FILES_CHKSUM =
> >> "file://COPYING;md5=892f569a555ba9c07a568a7c0c4fa63a \
> >>>
> >> file://COPYING.LIB;md5=fbc093901857fcd118f065f900982c24 \
> >>> file://gmp-
> >> h.in;startline=6;endline=21;md5=5e25ffd16996faba8c1cd27b04b16099"
> >>> -PR = "r0"
> >>> +PR = "r1"
> >>>
> >>> SRC_URI = "${GNU_MIRROR}/gmp/${BP}.tar.bz2 \
> >>> file://disable-stdc.patch"
> >>> diff --git a/meta/recipes-support/gmp/gmp_5.0.2.bb b/meta/recipes-
> >> support/gmp/gmp_5.0.2.bb
> >>> index 03fef45..f80971e 100644
> >>> --- a/meta/recipes-support/gmp/gmp_5.0.2.bb
> >>> +++ b/meta/recipes-support/gmp/gmp_5.0.2.bb
> >>> @@ -2,7 +2,7 @@ require gmp.inc
> >>> LICENSE="LGPLv3&GPLv3"
> >>> LIC_FILES_CHKSUM =
> >> "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
> >>>
> >> file://version.c;endline=18;md5=d8c56b52b9092346b9f93b4da65ef790"
> >>> -PR = "r0"
> >>> +PR = "r1"
> >>>
> >>> SRC_URI_append += "file://sh4-asmfix.patch \
> >>> file://use-includedir.patch "
> >
^ permalink raw reply
* Re: [PATCH 4/4] dbus: use useradd class to allow use in read-only filesystems
From: Saul Wold @ 2011-10-21 17:03 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <889826463264f3a2aeb5062afb5b2f24b5dc75a0.1319206126.git.otavio@ossystems.com.br>
On 10/21/2011 07:10 AM, Otavio Salvador wrote:
> Move creation of required user/groups to useradd class thus allowing
> use with read-only filesystems and booting the initial boot.
>
> Signed-off-by: Otavio Salvador<otavio@ossystems.com.br>
> ---
> meta/recipes-core/dbus/dbus.inc | 48 +++++++++++++++++----------------------
> 1 files changed, 21 insertions(+), 27 deletions(-)
>
> diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
> index a8ecda8..2a97c02 100644
> --- a/meta/recipes-core/dbus/dbus.inc
> +++ b/meta/recipes-core/dbus/dbus.inc
> @@ -10,15 +10,22 @@ DEPENDS = "expat virtual/libintl ${@base_contains('DISTRO_FEATURES', 'x11', '${X
> DEPENDS_virtclass-native = "expat-native virtual/libintl-native"
> DEPENDS_virtclass-nativesdk = "expat-nativesdk virtual/libintl-nativesdk virtual/libx11"
>
> +PR = "r1"
> +
> SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
> file://tmpdir.patch; \
> file://dbus-1.init"
>
> -inherit autotools pkgconfig gettext update-rc.d
> +inherit useradd autotools pkgconfig gettext update-rc.d
>
> INITSCRIPT_NAME = "dbus-1"
> INITSCRIPT_PARAMS = "start 02 5 3 2 . stop 20 0 1 6 ."
>
> +USERADD_PACKAGES = "${PN}"
> +GROUPADD_PARAM_${PN} = "-r netdev"
I thought netdev was going to be removed from this recipe?
Sau!
> +USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \
> + --no-create-home --user-group messagebus"
> +
> CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf ${sysconfdir}/dbus-1/session.conf"
>
> DEBIANNAME_${PN} = "dbus-1"
> @@ -44,32 +51,7 @@ RRECOMMENDS_${PN}-lib = "${PN}"
> FILES_${PN}-dev += "${libdir}/dbus-1.0/include ${bindir}/dbus-glib-tool"
>
> pkg_postinst_dbus() {
> - # can't do adduser stuff offline
> - if [ "x$D" != "x" ]; then
> - exit 1
> - fi
> -
> - MESSAGEUSER=messagebus
> - MESSAGEHOME=/var/run/dbus
> - UUIDDIR=/var/lib/dbus
> -
> - mkdir -p $MESSAGEHOME
> - mkdir -p $UUIDDIR
> - chgrp "$MESSAGEUSER" "$MESSAGEHOME" 2>/dev/null || addgroup "$MESSAGEUSER"
> - chown "$MESSAGEUSER":"$MESSAGEUSER" "$MESSAGEHOME" 2>/dev/null || \
> - adduser --system --home "$MESSAGEHOME" --no-create-home --disabled-password \
> - --ingroup "$MESSAGEUSER" "$MESSAGEUSER"
> -
> - chown "$MESSAGEUSER":"$MESSAGEUSER" "$UUIDDIR"
> -
> - grep -q netdev: /etc/group || addgroup netdev
> -
> - chown root:"$MESSAGEUSER" /usr/libexec/dbus-daemon-launch-helper
> - chmod 4754 /usr/libexec/dbus-daemon-launch-helper
> -
> - # add volatile after new user/grp are created
> - echo "d messagebus messagebus 0755 /var/run/dbus none"> /etc/default/volatiles/99_dbus
> - if [ -e /etc/init.d/populate-volatile.sh ] ; then
> + if [ -z "${D}" ]&& [ -e /etc/init.d/populate-volatile.sh ] ; then
> /etc/init.d/populate-volatile.sh update
> fi
> }
> @@ -92,6 +74,18 @@ do_install() {
> install -d ${D}${sysconfdir}/init.d
> install -m 0755 ${WORKDIR}/dbus-1.init ${D}${sysconfdir}/init.d/dbus-1
>
> + install -d ${D}${sysconfdir}/default/volatiles
> + echo "d messagebus messagebus 0755 ${localstatedir}/run/dbus none" \
> + > ${D}${sysconfdir}/default/volatiles/99_dbus
> +
> +
> + mkdir -p ${D}${localstatedir}/run/dbus ${D}${localstatedir}/lib/dbus
> +
> + chown messagebus:messagebus ${D}${localstatedir}/run/dbus ${D}${localstatedir}/lib/dbus
> +
> + chown root:messagebus ${D}${libexecdir}/dbus-daemon-launch-helper
> + chmod 4754 ${D}${libexecdir}/dbus-daemon-launch-helper
> +
> # disable dbus-1 sysv script on systemd installs
> # nearly all distros call the initscript plain 'dbus', but OE-core is different
> ln -sf /dev/null ${D}/${base_libdir}/systemd/system/dbus-1.service
^ permalink raw reply
* Re: [PATCH 4/4] dbus: use useradd class to allow use in read-only filesystems
From: Koen Kooi @ 2011-10-21 17:07 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4EA1A5E1.8080508@intel.com>
Op 21 okt. 2011, om 19:03 heeft Saul Wold het volgende geschreven:
> On 10/21/2011 07:10 AM, Otavio Salvador wrote:
>> Move creation of required user/groups to useradd class thus allowing
>> use with read-only filesystems and booting the initial boot.
>>
>> Signed-off-by: Otavio Salvador<otavio@ossystems.com.br>
>> ---
>> meta/recipes-core/dbus/dbus.inc | 48 +++++++++++++++++----------------------
>> 1 files changed, 21 insertions(+), 27 deletions(-)
>>
>> diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
>> index a8ecda8..2a97c02 100644
>> --- a/meta/recipes-core/dbus/dbus.inc
>> +++ b/meta/recipes-core/dbus/dbus.inc
>> @@ -10,15 +10,22 @@ DEPENDS = "expat virtual/libintl ${@base_contains('DISTRO_FEATURES', 'x11', '${X
>> DEPENDS_virtclass-native = "expat-native virtual/libintl-native"
>> DEPENDS_virtclass-nativesdk = "expat-nativesdk virtual/libintl-nativesdk virtual/libx11"
>>
>> +PR = "r1"
>> +
>> SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
>> file://tmpdir.patch; \
>> file://dbus-1.init"
>>
>> -inherit autotools pkgconfig gettext update-rc.d
>> +inherit useradd autotools pkgconfig gettext update-rc.d
>>
>> INITSCRIPT_NAME = "dbus-1"
>> INITSCRIPT_PARAMS = "start 02 5 3 2 . stop 20 0 1 6 ."
>>
>> +USERADD_PACKAGES = "${PN}"
>> +GROUPADD_PARAM_${PN} = "-r netdev"
>
> I thought netdev was going to be removed from this recipe?
let's do that as follow up so it bisects cleanly. Changing 2 things at once never works for me :)
regards,
Koen
^ permalink raw reply
* Re: [PATCH 3/8] pulseaudio-0.9.23: force ARM mode
From: Saul Wold @ 2011-10-21 17:13 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Martin Jansa
In-Reply-To: <20111021161620.GS3522@jama.jama.net>
On 10/21/2011 09:16 AM, Martin Jansa wrote:
> On Fri, Oct 21, 2011 at 08:40:20AM -0700, Khem Raj wrote:
>> On Fri, Oct 21, 2011 at 1:17 AM, Martin Jansa<martin.jansa@gmail.com> wrote:
>>> Signed-off-by: Martin Jansa<Martin.Jansa@gmail.com>
>>> ---
>>> .../pulseaudio/pulseaudio_0.9.23.bb | 1 +
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
>>> index 4ac2418..2f872b8 100644
>>> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
>>> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
>>> @@ -23,3 +23,4 @@ do_compile_prepend() {
>>> cp ${STAGING_LIBDIR}/libltdl* ${S}/libltdl
>>> }
>>>
>>> +ARM_INSTRUCTION_SET = "arm"
>>
>> not averse to patch but it would be nice to know what fails in thumb mode.
>
> selected processor does not support Thumb mode `swp r1,r2,[r3]'
>
As already asked, can you upgrade to 1.1 and verify if this problem
still exists. Also if it does, it would be good to have this info in
the commit message.
Thanks
Sau!
> Regards,
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Keeping patch status uptodate in patchwork
From: Khem Raj @ 2011-10-21 17:20 UTC (permalink / raw)
To: openembeded-devel,
Patches and discussions about the oe-core layer
Hi
I would like to request the patch submitter to change the status of
patches appropriately particularly case where manual intervention will
be needed
1. When you send pull request the cover letter is not marked accepted
automatically so when pull request is merged please mark it so.
2. When multiple versions of patches V1, V2, V3 are sent then the
versions that don't get applied should be marked as superseded.
It will greatly help in keeping the patchwork clean and layer
maintainers and the data it represents will be lot more relevant.
Thanks for you help
-Khem
^ permalink raw reply
* Re: [PATCH 3/8] pulseaudio-0.9.23: force ARM mode
From: Phil Blundell @ 2011-10-22 12:33 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111021161620.GS3522@jama.jama.net>
On Fri, 2011-10-21 at 18:16 +0200, Martin Jansa wrote:
> On Fri, Oct 21, 2011 at 08:40:20AM -0700, Khem Raj wrote:
> > On Fri, Oct 21, 2011 at 1:17 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > > ---
> > > .../pulseaudio/pulseaudio_0.9.23.bb | 1 +
> > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > index 4ac2418..2f872b8 100644
> > > --- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
> > > @@ -23,3 +23,4 @@ do_compile_prepend() {
> > > cp ${STAGING_LIBDIR}/libltdl* ${S}/libltdl
> > > }
> > >
> > > +ARM_INSTRUCTION_SET = "arm"
> >
> > not averse to patch but it would be nice to know what fails in thumb mode.
>
> selected processor does not support Thumb mode `swp r1,r2,[r3]'
If it's only that one error (presumably some kind of home-grown atomic
operation) then let's just fix the code in question rather than forcing
the whole thing to build in ARM-state. Or if the code is hard to fix,
patch the makefile so that only the particular source files with the
assembly in are built for ARM and let the rest stay as Thumb. Making
the whole package be ARM is a bit of a heavyweight fix for that issue.
p.
^ permalink raw reply
* Re: [PATCH] base.bbclass: add subversion-native to DEPENDS if there is svn:// in SRC_URI
From: Saul Wold @ 2011-10-22 17:24 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Martin Jansa
In-Reply-To: <1319190483-5637-1-git-send-email-Martin.Jansa@gmail.com>
On 10/21/2011 02:48 AM, Martin Jansa wrote:
> Signed-off-by: Martin Jansa<Martin.Jansa@gmail.com>
> ---
> meta/classes/base.bbclass | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index f539744..bced226 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -401,6 +401,13 @@ python () {
> bb.note("SKIPPING %s because it's %s" % (pn, this_license))
> raise bb.parse.SkipPackage("incompatible with license %s" % this_license)
>
> + # Svn packages should DEPEND on subversion-native
> + srcuri = bb.data.getVar('SRC_URI', d, 1)
> + if "svn://" in srcuri:
> + depends = bb.data.getVarFlag('do_fetch', 'depends', d) or ""
> + depends = depends + " subversion-native:do_populate_sysroot"
> + bb.data.setVarFlag('do_fetch', 'depends', depends, d)
> +
> # Git packages should DEPEND on git-native
> srcuri = bb.data.getVar('SRC_URI', d, 1)
> if "git://" in srcuri:
This change introduces a circular dependency when I tried to build.
Sau!
^ permalink raw reply
* Re: [PATCH] squashfs-tools: add recipe (2nd try)
From: Cliff Brake @ 2011-10-22 17:42 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <4EA19B3E.2020302@intel.com>
On Fri, Oct 21, 2011 at 12:18 PM, Saul Wold <saul.wold@intel.com> wrote:
> This one is on hold pending an update from Cliff based on Khem's comments.
v3 posted. Thanks for all the feedback.
Cliff
^ permalink raw reply
* Re: [review/test 3/5] python, python-native: upgrade from 2.6.6 to 2.7.2
From: Kamble, Nitin A @ 2011-10-22 23:54 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111014091136.GE3542@jama.jama.net>
Hi Martin,
I have kept my python work at nitin/python branch on poky contrib. the 2.7.2 python is working for all arches except arm. And I am going on vacation for few days, and I could not finish the python arm issue arm, so if you get a chance you can look into the arm issue, if you have not resolved it already then I will look into it again once I am back from my vacation on 13th Nov.
Thanks & Regards,
Nitin
> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Martin Jansa
> Sent: Friday, October 14, 2011 2:12 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [review/test 3/5] python, python-native: upgrade
> from 2.6.6 to 2.7.2
>
> On Fri, Oct 14, 2011 at 10:19:39AM +0200, Martin Jansa wrote:
> > On Thu, Oct 13, 2011 at 04:06:13PM -0700, nitin.a.kamble@intel.com
> wrote:
> > > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> > >
> >
> > This patch does not apply after
> > 9f9612d15acc6ee3b71f52bdb3f1ec4cb56b1a17
> >
> > can you rebase on top of oe-core?
> >
> > Also please drop
> > DEFAULT_PREFERENCE = "-27"
> >
> > we have only one python version so I guess it's not usefull at all
> > anymore
> >
> > I'll apply it manually, test it here.. and report if those modules
> are
> > build later..
>
> seems the same as with previous version..
>
> log.do_compile full of
> /OE/shr-core/tmp/sysroots/x86_64-linux/usr/lib/libpython2.7.so: file
> not recognized: File format not recognized
> collect2: ld returned 1 exit status
>
> and only built module is sqlite
> OE @ ~/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.7.2-r0.0 $ ls
> Python-2.7.2/build/lib.linux-x86_64-2.7/
> _sqlite3.so
>
> while with 2.6 we had a lot of modules
> $ ls Python-2.6.6/build/lib.linux-x86_64-2.6/
> _bisect.so _codecs_jp.so _ctypes.so _fileio.so
> _json.so _random.so _testcapi.so bz2.so
> datetime.so itertools.so parser.so spwd.so
> unicodedata.so
> _bytesio.so _codecs_kr.so _ctypes_test.so _functools.so
> _locale.so _socket.so _weakref.so cPickle.so fcntl.so
> math.so pyexpat.so strop.so zlib.so
> _codecs_cn.so _codecs_tw.so _curses.so _hashlib.so
> _lsprof.so _sqlite3.so array.so cStringIO.so
> future_builtins.so mmap.so readline.so syslog.so
> _codecs_hk.so _collections.so _curses_panel.so _heapq.so
> _multibytecodec.so _ssl.so audioop.so cmath.so gdbm.so
> nis.so resource.so termios.so
> _codecs_iso2022.so _csv.so _elementtree.so _hotshot.so
> _multiprocessing.so _struct.so binascii.so crypt.so grp.so
> operator.so select.so time.so
>
> Can you please test that you have non-empty python-syslog python-
> resource python-elementtree python-fcntl python-zlib?
> And test build for qemuarm, because I guess that it links to -native
> libpython2.7 when you're building qemux86 on x86 host.
>
> But it seems that python runtime works now, thanks!
>
> Regards,
> --
> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
^ permalink raw reply
* Re: [review/test 3/5] python, python-native: upgrade from 2.6.6 to 2.7.2
From: Martin Jansa @ 2011-10-23 6:28 UTC (permalink / raw)
To: Kamble, Nitin A; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <9DA5872FEF993D41B7173F58FCF6BE94E33A6D8D@orsmsx504.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3746 bytes --]
On Sat, Oct 22, 2011 at 04:54:00PM -0700, Kamble, Nitin A wrote:
> Hi Martin,
> I have kept my python work at nitin/python branch on poky contrib. the 2.7.2 python is working for all arches except arm. And I am going on vacation for few days, and I could not finish the python arm issue arm, so if you get a chance you can look into the arm issue, if you have not resolved it already then I will look into it again once I am back from my vacation on 13th Nov.
Hi Nitin,
I've tried already and failed, but I'll try again and I guess qemux86-64
(linking to host libc and failing if it's not same version as the one in
sysroot) is also still broken and should be taken care of too, right?
Regards,
> > -----Original Message-----
> > From: openembedded-core-bounces@lists.openembedded.org
> > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> > Martin Jansa
> > Sent: Friday, October 14, 2011 2:12 AM
> > To: Patches and discussions about the oe-core layer
> > Subject: Re: [OE-core] [review/test 3/5] python, python-native: upgrade
> > from 2.6.6 to 2.7.2
> >
> > On Fri, Oct 14, 2011 at 10:19:39AM +0200, Martin Jansa wrote:
> > > On Thu, Oct 13, 2011 at 04:06:13PM -0700, nitin.a.kamble@intel.com
> > wrote:
> > > > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> > > >
> > >
> > > This patch does not apply after
> > > 9f9612d15acc6ee3b71f52bdb3f1ec4cb56b1a17
> > >
> > > can you rebase on top of oe-core?
> > >
> > > Also please drop
> > > DEFAULT_PREFERENCE = "-27"
> > >
> > > we have only one python version so I guess it's not usefull at all
> > > anymore
> > >
> > > I'll apply it manually, test it here.. and report if those modules
> > are
> > > build later..
> >
> > seems the same as with previous version..
> >
> > log.do_compile full of
> > /OE/shr-core/tmp/sysroots/x86_64-linux/usr/lib/libpython2.7.so: file
> > not recognized: File format not recognized
> > collect2: ld returned 1 exit status
> >
> > and only built module is sqlite
> > OE @ ~/shr-core/tmp/work/armv4t-oe-linux-gnueabi/python-2.7.2-r0.0 $ ls
> > Python-2.7.2/build/lib.linux-x86_64-2.7/
> > _sqlite3.so
> >
> > while with 2.6 we had a lot of modules
> > $ ls Python-2.6.6/build/lib.linux-x86_64-2.6/
> > _bisect.so _codecs_jp.so _ctypes.so _fileio.so
> > _json.so _random.so _testcapi.so bz2.so
> > datetime.so itertools.so parser.so spwd.so
> > unicodedata.so
> > _bytesio.so _codecs_kr.so _ctypes_test.so _functools.so
> > _locale.so _socket.so _weakref.so cPickle.so fcntl.so
> > math.so pyexpat.so strop.so zlib.so
> > _codecs_cn.so _codecs_tw.so _curses.so _hashlib.so
> > _lsprof.so _sqlite3.so array.so cStringIO.so
> > future_builtins.so mmap.so readline.so syslog.so
> > _codecs_hk.so _collections.so _curses_panel.so _heapq.so
> > _multibytecodec.so _ssl.so audioop.so cmath.so gdbm.so
> > nis.so resource.so termios.so
> > _codecs_iso2022.so _csv.so _elementtree.so _hotshot.so
> > _multiprocessing.so _struct.so binascii.so crypt.so grp.so
> > operator.so select.so time.so
> >
> > Can you please test that you have non-empty python-syslog python-
> > resource python-elementtree python-fcntl python-zlib?
> > And test build for qemuarm, because I guess that it links to -native
> > libpython2.7 when you're building qemux86 on x86 host.
> >
> > But it seems that python runtime works now, thanks!
> >
> > Regards,
> > --
> > 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
* Re: [review/test 3/5] python, python-native: upgrade from 2.6.6 to 2.7.2
From: Koen Kooi @ 2011-10-23 6:53 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <9DA5872FEF993D41B7173F58FCF6BE94E33A6D8D@orsmsx504.amr.corp.intel.com>
Op 23 okt. 2011, om 01:54 heeft Kamble, Nitin A het volgende geschreven:
> Hi Martin,
> I have kept my python work at nitin/python branch on poky contrib.
Do you have a branch against oe-core?
^ permalink raw reply
* bitbake eating more than 6GB ram while parsing recipes
From: Martin Jansa @ 2011-10-23 7:57 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]
Hi,
I know this was reported a while ago and I had this issue for few days
with 4 GB RAM on my workstation it was hard to do anything when bitbake
was parsing and today I've "resolved" it by removing cache.
first I've tried to remove
#PARALLEL_MAKE="-j3"
#BB_NUMBER_THREADS = "2"
from my local.conf and it didn't help I still had 6 bitbake processes
4 eating ~ 1GB ad 2 with ~ 512MB. So I've removed tmp/cache except
bb_persist_data.sqlite3:
OE om-gta02@shr ~/shr-core $ du -hs tmp/cache/*
35M tmp/cache/bb_codeparser.dat
0 tmp/cache/bb_codeparser.dat.lock.13293
0 tmp/cache/bb_codeparser.dat.lock.13294
0 tmp/cache/bb_codeparser.dat.lock.13295
0 tmp/cache/bb_codeparser.dat.lock.15708
0 tmp/cache/bb_codeparser.dat.lock.16878
0 tmp/cache/bb_codeparser.dat.lock.16879
0 tmp/cache/bb_codeparser.dat.lock.16880
0 tmp/cache/bb_codeparser.dat.lock.25605
68K tmp/cache/bb_persist_data.sqlite3
87M tmp/cache/default-eglibc
OE om-gta02@shr ~/shr-core $ rm -rf tmp/cache/bb_codeparser.dat*
OE om-gta02@shr ~/shr-core $ du -hs tmp/cache/default-eglibc/*
13M tmp/cache/default-eglibc/nokia900
13M tmp/cache/default-eglibc/om-gta02
13M tmp/cache/default-eglibc/palmpre
13M tmp/cache/default-eglibc/qemuarm
13M tmp/cache/default-eglibc/qemux86
13M tmp/cache/default-eglibc/qemux86-64
13M tmp/cache/default-eglibc/spitz
OE om-gta02@shr ~/shr-core $ rm -rf tmp/cache/default-eglibc/
and now it's sane again and memory used is < 2GB.
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply
* [PATCH 1/2] matchbox-stroke: Fix linking error with gold
From: Khem Raj @ 2011-10-23 14:31 UTC (permalink / raw)
To: openembedded-core
Gold defaults to no-add-needed thetefore
it does not link with librtaries that are not on cmdline
it needs libXrender but is not on the linker cmdline
so add it.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
.../matchbox-stroke/files/ldadd_libXrender.patch | 25 ++++++++++++++++++++
.../matchbox-stroke/matchbox-stroke_git.bb | 6 +++-
2 files changed, 29 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-sato/matchbox-stroke/files/ldadd_libXrender.patch
diff --git a/meta/recipes-sato/matchbox-stroke/files/ldadd_libXrender.patch b/meta/recipes-sato/matchbox-stroke/files/ldadd_libXrender.patch
new file mode 100644
index 0000000..90d2057
--- /dev/null
+++ b/meta/recipes-sato/matchbox-stroke/files/ldadd_libXrender.patch
@@ -0,0 +1,25 @@
+with GNU binutils-gold the
+important difference is that --no-add-needed is the default behavior of GNU
+binutils-gold. Please provide all needed libraries to the linker when building
+your executables.
+
+Otherwise we get link errors like
+
+/home/kraj/work/angstrom/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/libexec/armv5te-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/4.6.2/ld: matchbox-stroke-ui.o: in function mb_stroke_ui_resources_create:matchbox-stroke-ui.c:223: error: undefined reference to 'XRenderCreatePicture'collect2: ld returned 1 exit statusmake[2]: *** [matchbox-stroke] Error 1
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+
+Upstream-Status: Pending
+Index: git/src/Makefile.am
+===================================================================
+--- git.orig/src/Makefile.am 2011-10-22 19:25:52.000000000 -0700
++++ git/src/Makefile.am 2011-10-22 19:27:07.746428946 -0700
+@@ -6,7 +6,7 @@
+
+ bin_PROGRAMS = matchbox-stroke
+
+-matchbox_stroke_LDADD = $(MBSTROKE_LIBS) $(EXPAT_LIBS) -lm
++matchbox_stroke_LDADD = $(MBSTROKE_LIBS) $(EXPAT_LIBS) -lm -lXrender
+
+ matchbox_stroke_SOURCES = \
+ matchbox-stroke.h \
diff --git a/meta/recipes-sato/matchbox-stroke/matchbox-stroke_git.bb b/meta/recipes-sato/matchbox-stroke/matchbox-stroke_git.bb
index 44b316d..2c2e940 100644
--- a/meta/recipes-sato/matchbox-stroke/matchbox-stroke_git.bb
+++ b/meta/recipes-sato/matchbox-stroke/matchbox-stroke_git.bb
@@ -9,11 +9,13 @@ DEPENDS = "libfakekey expat libxft"
SECTION = "x11/wm"
SRCREV = "8edfd9a2bf1f0d6b28d4afee4bda9d3635f26a0b"
PV = "0.0+git${SRCPV}"
-PR = "r0"
+PR = "r1"
SRC_URI = "git://git.yoctoproject.org/${BPN};protocol=git \
file://single-instance.patch \
- file://configure_fix.patch;maxrev=1819"
+ file://configure_fix.patch;maxrev=1819 \
+ file://ldadd_libXrender.patch \
+ "
S = "${WORKDIR}/git"
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/2] pulseaudio: inherit perlnative
From: Khem Raj @ 2011-10-23 14:31 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1319380267-29794-1-git-send-email-raj.khem@gmail.com>
manpage generatition uses xmltoman utility
which inturn uses xml-parser. So we add
libxml-parser-perl-native to DEPENDS and also
inherit perlnative so it does not use the one
from build host
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
.../pulseaudio/pulseaudio_0.9.23.bb | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
index 33f5e15..9521ab0 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
@@ -1,10 +1,10 @@
require pulseaudio.inc
-PR = "r5"
+PR = "r6"
-DEPENDS += "gdbm speex"
+DEPENDS += "gdbm speex libxml-parser-perl-native"
-inherit gettext
+inherit gettext perlnative
SRC_URI = "http://freedesktop.org/software/pulseaudio/releases/pulseaudio-${PV}.tar.gz \
file://buildfix.patch \
--
1.7.5.4
^ permalink raw reply related
* Re: bitbake eating more than 6GB ram while parsing recipes
From: Khem Raj @ 2011-10-23 14:39 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111023075715.GD3497@jama.jama.net>
On Sun, Oct 23, 2011 at 12:57 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> Hi,
>
> I know this was reported a while ago and I had this issue for few days
> with 4 GB RAM on my workstation it was hard to do anything when bitbake
> was parsing and today I've "resolved" it by removing cache.
yes I have exact same problem. As you add more machines to same tmpdir
build. It keeps becoming s bigger pig. And so far I have been removing
cache dir too since s parse from scratch is way faster in this case.
I think we have to profile bitbake and find the memory wastage even after
parse right now it keeps like 600M through out the build process which
could be reduced too.
>
> first I've tried to remove
> #PARALLEL_MAKE="-j3"
> #BB_NUMBER_THREADS = "2"
> from my local.conf and it didn't help I still had 6 bitbake processes
> 4 eating ~ 1GB ad 2 with ~ 512MB. So I've removed tmp/cache except
> bb_persist_data.sqlite3:
>
> OE om-gta02@shr ~/shr-core $ du -hs tmp/cache/*
> 35M tmp/cache/bb_codeparser.dat
> 0 tmp/cache/bb_codeparser.dat.lock.13293
> 0 tmp/cache/bb_codeparser.dat.lock.13294
> 0 tmp/cache/bb_codeparser.dat.lock.13295
> 0 tmp/cache/bb_codeparser.dat.lock.15708
> 0 tmp/cache/bb_codeparser.dat.lock.16878
> 0 tmp/cache/bb_codeparser.dat.lock.16879
> 0 tmp/cache/bb_codeparser.dat.lock.16880
> 0 tmp/cache/bb_codeparser.dat.lock.25605
> 68K tmp/cache/bb_persist_data.sqlite3
> 87M tmp/cache/default-eglibc
> OE om-gta02@shr ~/shr-core $ rm -rf tmp/cache/bb_codeparser.dat*
>
> OE om-gta02@shr ~/shr-core $ du -hs tmp/cache/default-eglibc/*
> 13M tmp/cache/default-eglibc/nokia900
> 13M tmp/cache/default-eglibc/om-gta02
> 13M tmp/cache/default-eglibc/palmpre
> 13M tmp/cache/default-eglibc/qemuarm
> 13M tmp/cache/default-eglibc/qemux86
> 13M tmp/cache/default-eglibc/qemux86-64
> 13M tmp/cache/default-eglibc/spitz
> OE om-gta02@shr ~/shr-core $ rm -rf tmp/cache/default-eglibc/
>
> and now it's sane again and memory used is < 2GB.
>
> Regards,
> --
> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
^ permalink raw reply
* [PATCH 0/3] Misc metadata fixes
From: Paul Eggleton @ 2011-10-23 15:07 UTC (permalink / raw)
To: openembedded-core
The following changes since commit 99da9a4e65f9dffb04efc3ad60125194c476d6b3:
distro-tracking-fields: update fields for tzdata and gst-plugins-good (2011-10-20 13:07:16 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib paule/fixes7
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/fixes7
Paul Eggleton (3):
dbus: remove unused initscript
util-linux: split out mkfs into its own package
e2fsprogs: move mke2fs.conf to e2fsprogs-mke2fs package
meta/recipes-core/dbus/dbus.inc | 3 +++
meta/recipes-core/dbus/dbus_1.4.12.bb | 3 +++
meta/recipes-core/util-linux/util-linux.inc | 6 ++++--
meta/recipes-core/util-linux/util-linux_2.19.1.bb | 2 +-
.../e2fsprogs/e2fsprogs_1.41.14.bb | 4 ++--
5 files changed, 13 insertions(+), 5 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH 1/3] dbus: remove unused initscript
From: Paul Eggleton @ 2011-10-23 15:07 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1319382376.git.paul.eggleton@linux.intel.com>
We already install an appropriate init script to /etc/init.d, we do not
need an additional one in /etc/init.d/rc.d as well.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
meta/recipes-core/dbus/dbus.inc | 3 +++
meta/recipes-core/dbus/dbus_1.4.12.bb | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-core/dbus/dbus.inc b/meta/recipes-core/dbus/dbus.inc
index a8ecda8..339bedf 100644
--- a/meta/recipes-core/dbus/dbus.inc
+++ b/meta/recipes-core/dbus/dbus.inc
@@ -92,6 +92,9 @@ do_install() {
install -d ${D}${sysconfdir}/init.d
install -m 0755 ${WORKDIR}/dbus-1.init ${D}${sysconfdir}/init.d/dbus-1
+ # Remove Red Hat initscript
+ rm -rf ${D}${sysconfdir}/rc.d
+
# disable dbus-1 sysv script on systemd installs
# nearly all distros call the initscript plain 'dbus', but OE-core is different
ln -sf /dev/null ${D}/${base_libdir}/systemd/system/dbus-1.service
diff --git a/meta/recipes-core/dbus/dbus_1.4.12.bb b/meta/recipes-core/dbus/dbus_1.4.12.bb
index ada53c9..9324af7 100644
--- a/meta/recipes-core/dbus/dbus_1.4.12.bb
+++ b/meta/recipes-core/dbus/dbus_1.4.12.bb
@@ -1,4 +1,7 @@
include dbus.inc
+
+PR = "r1"
+
SRC_URI[md5sum] = "104f2ea94c10a896dfb1edecb5714cb1"
SRC_URI[sha256sum] = "da3c97fd546610558d588799e27c4fa81101e754acbcd34747a42c131f30dbe7"
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/3] util-linux: split out mkfs into its own package
From: Paul Eggleton @ 2011-10-23 15:07 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1319382376.git.paul.eggleton@linux.intel.com>
For those external tools such as Webmin that call mkfs to do formatting
operations, it is useful to have it in its own package to avoid dragging
in the rest of util-linux.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
meta/recipes-core/util-linux/util-linux.inc | 6 ++++--
meta/recipes-core/util-linux/util-linux_2.19.1.bb | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-linux/util-linux.inc
index 67d81b9..d10bafb 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -29,7 +29,8 @@ PACKAGES =+ "util-linux-agetty util-linux-fdisk util-linux-cfdisk util-linux-sfd
util-linux-swaponoff util-linux-losetup util-linux-umount \
util-linux-mount util-linux-readprofile util-linux-libblkid \
util-linux-libblkid-dev util-linux-libuuid util-linux-libuuid-dev \
- util-linux-uuidgen util-linux-lscpu util-linux-fsck util-linux-blkid"
+ util-linux-uuidgen util-linux-lscpu util-linux-fsck util-linux-blkid \
+ util-linux-mkfs"
EXTRA_OECONF = "--disable-use-tty-group --disable-makeinstall-chown --enable-elvtune --enable-init --enable-kill --enable-last \
--enable-mesg --enable-partx --enable-raw --enable-rdev --enable-reset \
@@ -55,13 +56,14 @@ FILES_util-linux-libuuid-dev = "${libdir}/libuuid.so ${libdir}/libuuid.a ${libdi
FILES_util-linux-lscpu = "${bindir}/lscpu"
FILES_util-linux-fsck = "${base_sbindir}/fsck*"
+FILES_util-linux-mkfs = "${sbindir}/mkfs"
# Util-linux' blkid replaces the e2fsprogs one
FILES_util-linux-blkid = "${base_sbindir}/blkid*"
RCONFLICTS_util-linux-blkid = "e2fsprogs-blkid"
RREPLACES_util-linux-blkid = "e2fsprogs-blkid"
-RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk util-linux-mount util-linux-readprofile "
+RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk util-linux-mount util-linux-readprofile util-linux-mkfs "
RDEPENDS_${PN} = "util-linux-umount util-linux-swaponoff util-linux-losetup perl"
RRECOMMENDS_${PN}_virtclass-native = ""
diff --git a/meta/recipes-core/util-linux/util-linux_2.19.1.bb b/meta/recipes-core/util-linux/util-linux_2.19.1.bb
index 04f4457..fb5637e 100644
--- a/meta/recipes-core/util-linux/util-linux_2.19.1.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.19.1.bb
@@ -1,5 +1,5 @@
MAJOR_VERSION = "2.19"
-PR = "r8"
+PR = "r9"
require util-linux.inc
# note that `lscpu' is under GPLv3+
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/3] e2fsprogs: move mke2fs.conf to e2fsprogs-mke2fs package
From: Paul Eggleton @ 2011-10-23 15:07 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1319382376.git.paul.eggleton@linux.intel.com>
mke2fs.conf, which contains defaults for filesystem formatting options,
ought to be shipped along with mke2fs itself.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
.../e2fsprogs/e2fsprogs_1.41.14.bb | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.41.14.bb b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.41.14.bb
index 1fca7b9..c6c1f0d 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.41.14.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.41.14.bb
@@ -1,6 +1,6 @@
require e2fsprogs.inc
-PR = "r2"
+PR = "r3"
SRC_URI += "file://quotefix.patch \
file://acinclude.m4"
@@ -44,7 +44,7 @@ PACKAGES =+ "libcomerr libss libe2p libext2fs"
FILES_e2fsprogs-blkid = "${base_sbindir}/blkid"
FILES_e2fsprogs-fsck = "${base_sbindir}/fsck"
FILES_e2fsprogs-e2fsck = "${base_sbindir}/e2fsck ${base_sbindir}/fsck.ext*"
-FILES_e2fsprogs-mke2fs = "${base_sbindir}/mke2fs ${base_sbindir}/mkfs.ext*"
+FILES_e2fsprogs-mke2fs = "${base_sbindir}/mke2fs ${base_sbindir}/mkfs.ext* ${sysconfdir}/mke2fs.conf"
FILES_e2fsprogs-tune2fs = "${base_sbindir}/tune2fs ${base_sbindir}/e2label ${base_sbindir}/findfs"
FILES_e2fsprogs-badblocks = "${base_sbindir}/badblocks"
FILES_libcomerr = "${libdir}/libcom_err.so.*"
--
1.7.4.1
^ permalink raw reply related
* [CONSOLIDATED PULL 00/27] Various Updates and fixes
From: Saul Wold @ 2011-10-23 18:26 UTC (permalink / raw)
To: openembedded-core
Richard,
This pull requests adds some new recipes for supporting building
oe-core with oe-core, also various patches and updates.
I also included the MACHINE_KERNEL_PR change from Dmitry per my
reading of the TSC Notes.
Please review and commit
Thanks
Sau!
The following changes since commit 53f37ed45fe7286eae76fa237ee2b86061b6a021:
Merge branch 'master-next' of git://git.openembedded.org/openembedded-core into oe-core (2011-10-23 11:15:07 -0700)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/stage
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
Cliff Brake (1):
squashfs-tools: add recipe
Dmitry Eremin-Solenikov (1):
kernel.bbclass: respect MACHINE_KERNEL_PR
Khem Raj (7):
tcmode-default.inc: Add TRANSLATED_TARGET_ARCH suffix to
binutils-cross-canadian
binutils-cross-canadian: Point sysroot to correct location
gcc-configure-sdk: Point sysroot to correct location
xserver-xorg: Add mesa-dri to depends instead of virtual/libgl
gcc-4.6: Backport fix for PR32219
coreutils: Upgrade recipe 8.12 -> 8.14
libtool: Upgrade from 2.4 -> 2.4.2
Martin Jansa (7):
pulseaudio-0.9.23: inherit perlnative to work around build on host
without XML/Parser.pm
apr: add native support
neon: add native support
apr-util: add native support
subversion: add 1.7.0 with native support and negative D_P for now
subversion-1.6.15: add native support too
default-providers: switch virtual/libgl from mesa-xlib to mesa-dri
Nitin A Kamble (2):
tcl: upgrade from 8.5.9 to 8.5.10
perl: upgrade from 5.12.3 to 5.14.2
Otavio Salvador (4):
bootimg.bbclass: add support to disable HDD image building
useradd.bbclass: check if a group already exists manually
base-passwd: move initial criation of group and passwd to preinst
dbus: use useradd class to allow use in read-only filesystems
Saul Wold (5):
wget: Add recipe from OE
texi2html: Added recipe from OE
oprofile: Update to 0.9.7 and convert cvs->git
abiword: convert to svn
perl: remove debug set -x; pwd
meta-demoapps/recipes-gnome/abiword/abiword.inc | 4 +-
meta-demoapps/recipes-gnome/abiword/abiword_cvs.bb | 10 -
meta-demoapps/recipes-gnome/abiword/abiword_svn.bb | 10 +
meta/classes/bootimg.bbclass | 44 +-
meta/classes/kernel.bbclass | 5 +
meta/classes/useradd.bbclass | 8 +-
meta/conf/distro/include/default-providers.inc | 2 +-
meta/conf/distro/include/tcmode-default.inc | 2 +-
.../recipes-core/base-passwd/base-passwd_3.5.22.bb | 19 +-
.../remove-usr-local-lib-from-m4.patch | 18 +-
.../{coreutils_8.12.bb => coreutils_8.14.bb} | 11 +-
meta/recipes-core/dbus/dbus.inc | 48 +-
.../binutils/binutils-cross-canadian.inc | 2 +-
.../binutils/binutils-cross-canadian_2.21.1a.bb | 2 +-
meta/recipes-devtools/gcc/gcc-4.6.inc | 3 +-
meta/recipes-devtools/gcc/gcc-4.6/pr32219.patch | 71 +
meta/recipes-devtools/gcc/gcc-configure-sdk.inc | 4 +-
.../libtool/{libtool.inc => libtool-2.4.2.inc} | 26 +-
meta/recipes-devtools/libtool/libtool-2.4.inc | 13 -
...libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} | 2 +-
...btool-native_2.4.bb => libtool-native_2.4.2.bb} | 2 +-
...nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} | 2 +-
meta/recipes-devtools/libtool/libtool/prefix.patch | 46 +-
.../libtool/libtool/resolve-sysroot.patch | 42 -
.../libtool/{libtool_2.4.bb => libtool_2.4.2.bb} | 2 +-
.../perl/files/Configure-multilib.patch | 17 -
.../perl/perl-5.12.3/cross-generate_uudmap.patch | 15 -
.../perl/perl-5.12.3/debian/arm_optim.diff | 34 -
.../perl/perl-5.12.3/debian/cpan_config_path.diff | 24 -
.../perl-5.12.3/debian/deprecate-with-apt.diff | 61 -
.../debian/devel-ppport-ia64-optim.diff | 34 -
.../perl/perl-5.12.3/debian/extutils_hacks.diff | 315 -
.../perl-5.12.3/debian/fixes/autodie-flock.diff | 100 -
.../debian/fixes/concat-stack-corruption.diff | 39 -
.../debian/fixes/cpanplus-without-home.diff | 32 -
.../perl-5.12.3/debian/fixes/h2ph-gcc-4.5.diff | 108 -
.../perl-5.12.3/debian/fixes/lc-numeric-docs.diff | 97 -
.../debian/fixes/lc-numeric-sprintf.diff | 31 -
.../perl/perl-5.12.3/debian/fixes/processPL.diff | 45 -
.../perl/perl-5.12.3/debian/patchlevel | 45 -
.../perl/perl-5.12.3/debian/series | 34 -
.../perl/perl-5.12.3/parallel_build_fix_1.patch | 27 -
.../perl/perl-5.12.3/parallel_build_fix_2.patch | 24 -
.../perl/perl-5.12.3/parallel_build_fix_3.patch | 6585 --------------------
.../perl/perl-5.12.3/parallel_build_fix_4.patch | 57 -
.../perl/perl-5.12.3/parallel_build_fix_5.patch | 430 --
.../perl/perl-5.12.3/parallel_build_fix_6.patch | 158 -
.../09_fix_installperl.patch | 0
.../Configure-multilib.patch | 0
.../{perl-5.12.3 => perl-5.14.2}/MM_Unix.pm.patch | 0
.../{perl-5.12.3 => perl-5.14.2}/Makefile.SH.patch | 122 +-
.../{perl-5.12.3 => perl-5.14.2}/Makefile.patch | 17 +-
.../asm-pageh-fix.patch | 0
.../perl/{perl-5.12.3 => perl-5.14.2}/config.sh | 65 +-
.../perl/{perl-5.12.3 => perl-5.14.2}/config.sh-32 | 0
.../{perl-5.12.3 => perl-5.14.2}/config.sh-32-be | 0
.../{perl-5.12.3 => perl-5.14.2}/config.sh-32-le | 0
.../perl/{perl-5.12.3 => perl-5.14.2}/config.sh-64 | 0
.../{perl-5.12.3 => perl-5.14.2}/config.sh-64-be | 0
.../{perl-5.12.3 => perl-5.14.2}/config.sh-64-le | 0
.../perl/perl-5.14.2/cross-generate_uudmap.patch | 15 +
.../debian/arm_thread_stress_timeout.diff | 13 +-
.../debian/cpan_definstalldirs.diff | 18 +-
.../debian/cpanplus_config_path.diff | 19 +-
.../debian/cpanplus_definstalldirs.diff | 13 +-
.../debian/db_file_ver.diff | 12 +-
.../perl-5.14.2/debian/deprecate-with-apt.diff | 406 ++
.../debian/disable-zlib-bundling.diff | 7 +-
.../debian/doc_info.diff | 16 +-
.../debian/enc2xs_inc.diff | 9 +-
.../debian/errno_ver.diff | 23 +-
.../debian/extutils_set_libperl_path.diff | 23 +
.../debian/fakeroot.diff | 15 +-
.../perl/perl-5.14.2/debian/find_html2text.diff | 35 +
.../debian/fixes/document_makemaker_ccflags.diff | 31 +
.../debian/fixes/extutils-cbuilder-cflags.diff | 86 +
.../perl-5.14.2/debian/fixes/h2ph-multiarch.diff | 69 +
.../debian/fixes/hurd-ccflags.diff | 12 +-
.../perl/perl-5.14.2/debian/fixes/hurd-hints.diff | 48 +
.../perl-5.14.2/debian/fixes/index-tainting.diff | 73 +
.../debian/fixes/module-build-home-directory.diff | 37 +
.../debian/fixes/net_smtp_docs.diff | 10 +-
.../perl/perl-5.14.2/debian/fixes/pod_fixes.diff | 145 +
.../perl-5.14.2/debian/fixes/respect_umask.diff | 153 +
.../fixes/sys-syslog-socket-timeout-kfreebsd.patch | 36 +
.../debian/instmodsh_doc.diff | 9 +-
.../debian/ld_run_path.diff | 15 +-
.../debian/libnet_config_path.diff | 12 +-
.../perl/perl-5.14.2/debian/libperl_embed_doc.diff | 26 +
.../debian/m68k_thread_stress.diff | 15 +-
.../debian/mod_paths.diff | 15 +-
.../debian/module_build_man_extensions.diff | 16 +-
.../perl-5.14.2/debian/no_packlist_perllocal.diff | 88 +
.../perl/perl-5.14.2/debian/patchlevel.diff | 30 +
.../debian/perlivp.diff | 19 +-
.../perl/perl-5.14.2/debian/prefix_changes.diff | 118 +
.../debian/prune_libs.diff | 16 +-
.../perl/perl-5.14.2/debian/series | 40 +
.../perl-5.14.2/debian/skip-kfreebsd-crash.diff | 39 +
.../debian/skip-upstream-git-tests.diff | 59 +
.../debian/squelch-locale-warnings.diff | 14 +-
.../perl-5.14.2/debian/writable_site_dirs.diff | 36 +
.../fix_bad_rpath.patch | 13 +-
.../{perl-5.12.3 => perl-5.14.2}/generate-sh.patch | 0
.../{perl-5.12.3 => perl-5.14.2}/installperl.patch | 0
.../letgcc-find-errno.patch | 0
.../native-nopacklist.patch | 0
.../native-perlinc.patch | 0
.../perl-configpm-switch.patch | 18 +-
.../{perl-5.12.3 => perl-5.14.2}/perl-configure.sh | 0
.../perl-dynloader.patch | 21 +-
.../perl-enable-gdbm.patch | 0
.../perl-moreconfig.patch | 0
...perl-native_5.12.3.bb => perl-native_5.14.2.bb} | 32 +-
...depends_5.12.3.inc => perl-rdepends_5.14.2.inc} | 54 +-
...ovides_5.12.3.inc => perl-rprovides_5.14.2.inc} | 0
.../perl/{perl_5.12.3.bb => perl_5.14.2.bb} | 47 +-
.../squashfs-tools/squashfs-tools_4.2.bb | 40 +
.../subversion/subversion-1.7.0/libtool2.patch | 15 +
.../subversion/subversion_1.6.15.bb | 2 +
.../subversion/subversion_1.7.0.bb | 37 +
.../tcltk/tcl/fix_non_native_build_issue.patch | 16 +-
.../tcltk/tcl/tcl-add-soname.patch | 26 +-
.../tcltk/{tcl_8.5.9.bb => tcl_8.5.10.bb} | 6 +-
meta/recipes-extended/texi2html/texi2html_1.82.bb | 14 +
.../wget/wget-1.12/fix_makefile.patch | 59 +
.../wget/wget-1.12/gnutls.bzr.patch | 266 +
meta/recipes-extended/wget/wget.inc | 40 +
meta/recipes-extended/wget/wget_1.12.bb | 11 +
.../recipes-graphics/xorg-xserver/xserver-xorg.inc | 2 +-
.../oprofile/{oprofile_0.9.6.bb => oprofile.inc} | 13 +-
meta/recipes-kernel/oprofile/oprofile_0.9.7.bb | 11 +
meta/recipes-kernel/oprofile/oprofile_cvs.bb | 28 -
meta/recipes-kernel/oprofile/oprofile_git.bb | 11 +
.../pulseaudio/pulseaudio_0.9.23.bb | 2 +-
meta/recipes-support/apr/apr-util_1.3.12.bb | 8 +
meta/recipes-support/apr/apr_1.4.5.bb | 2 +
meta/recipes-support/neon/neon_0.29.5.bb | 3 +
meta/site/common-linux | 3 +
139 files changed, 2724 insertions(+), 8881 deletions(-)
delete mode 100644 meta-demoapps/recipes-gnome/abiword/abiword_cvs.bb
create mode 100644 meta-demoapps/recipes-gnome/abiword/abiword_svn.bb
rename meta/recipes-core/coreutils/{coreutils-8.12 => coreutils-8.14}/remove-usr-local-lib-from-m4.patch (65%)
rename meta/recipes-core/coreutils/{coreutils_8.12.bb => coreutils_8.14.bb} (90%)
create mode 100644 meta/recipes-devtools/gcc/gcc-4.6/pr32219.patch
rename meta/recipes-devtools/libtool/{libtool.inc => libtool-2.4.2.inc} (57%)
delete mode 100644 meta/recipes-devtools/libtool/libtool-2.4.inc
rename meta/recipes-devtools/libtool/{libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} (98%)
rename meta/recipes-devtools/libtool/{libtool-native_2.4.bb => libtool-native_2.4.2.bb} (96%)
rename meta/recipes-devtools/libtool/{libtool-nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} (97%)
delete mode 100644 meta/recipes-devtools/libtool/libtool/resolve-sysroot.patch
rename meta/recipes-devtools/libtool/{libtool_2.4.bb => libtool_2.4.2.bb} (94%)
delete mode 100644 meta/recipes-devtools/perl/files/Configure-multilib.patch
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/cross-generate_uudmap.patch
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/debian/arm_optim.diff
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/debian/cpan_config_path.diff
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/debian/deprecate-with-apt.diff
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/debian/devel-ppport-ia64-optim.diff
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/debian/extutils_hacks.diff
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/debian/fixes/autodie-flock.diff
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/debian/fixes/concat-stack-corruption.diff
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/debian/fixes/cpanplus-without-home.diff
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/debian/fixes/h2ph-gcc-4.5.diff
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/debian/fixes/lc-numeric-docs.diff
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/debian/fixes/lc-numeric-sprintf.diff
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/debian/fixes/processPL.diff
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/debian/patchlevel
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/debian/series
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/parallel_build_fix_1.patch
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/parallel_build_fix_2.patch
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/parallel_build_fix_3.patch
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/parallel_build_fix_4.patch
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/parallel_build_fix_5.patch
delete mode 100644 meta/recipes-devtools/perl/perl-5.12.3/parallel_build_fix_6.patch
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/09_fix_installperl.patch (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/Configure-multilib.patch (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/MM_Unix.pm.patch (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/Makefile.SH.patch (75%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/Makefile.patch (87%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/asm-pageh-fix.patch (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/config.sh (94%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/config.sh-32 (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/config.sh-32-be (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/config.sh-32-le (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/config.sh-64 (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/config.sh-64-be (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/config.sh-64-le (100%)
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/cross-generate_uudmap.patch
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/arm_thread_stress_timeout.diff (66%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/cpan_definstalldirs.diff (80%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/cpanplus_config_path.diff (83%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/cpanplus_definstalldirs.diff (84%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/db_file_ver.diff (83%)
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/deprecate-with-apt.diff
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/disable-zlib-bundling.diff (83%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/doc_info.diff (78%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/enc2xs_inc.diff (90%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/errno_ver.diff (70%)
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/extutils_set_libperl_path.diff
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/fakeroot.diff (79%)
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/find_html2text.diff
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/fixes/document_makemaker_ccflags.diff
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/fixes/extutils-cbuilder-cflags.diff
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/fixes/h2ph-multiarch.diff
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/fixes/hurd-ccflags.diff (67%)
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/fixes/hurd-hints.diff
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/fixes/index-tainting.diff
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/fixes/module-build-home-directory.diff
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/fixes/net_smtp_docs.diff (76%)
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/fixes/pod_fixes.diff
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/fixes/respect_umask.diff
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/fixes/sys-syslog-socket-timeout-kfreebsd.patch
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/instmodsh_doc.diff (81%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/ld_run_path.diff (68%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/libnet_config_path.diff (85%)
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/libperl_embed_doc.diff
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/m68k_thread_stress.diff (78%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/mod_paths.diff (89%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/module_build_man_extensions.diff (81%)
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/no_packlist_perllocal.diff
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/patchlevel.diff
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/perlivp.diff (77%)
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/prefix_changes.diff
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/prune_libs.diff (81%)
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/series
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/skip-kfreebsd-crash.diff
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/skip-upstream-git-tests.diff
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/debian/squelch-locale-warnings.diff (86%)
create mode 100644 meta/recipes-devtools/perl/perl-5.14.2/debian/writable_site_dirs.diff
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/fix_bad_rpath.patch (70%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/generate-sh.patch (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/installperl.patch (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/letgcc-find-errno.patch (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/native-nopacklist.patch (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/native-perlinc.patch (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/perl-configpm-switch.patch (76%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/perl-configure.sh (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/perl-dynloader.patch (69%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/perl-enable-gdbm.patch (100%)
rename meta/recipes-devtools/perl/{perl-5.12.3 => perl-5.14.2}/perl-moreconfig.patch (100%)
rename meta/recipes-devtools/perl/{perl-native_5.12.3.bb => perl-native_5.14.2.bb} (74%)
rename meta/recipes-devtools/perl/{perl-rdepends_5.12.3.inc => perl-rdepends_5.14.2.inc} (90%)
rename meta/recipes-devtools/perl/{perl-rprovides_5.12.3.inc => perl-rprovides_5.14.2.inc} (100%)
rename meta/recipes-devtools/perl/{perl_5.12.3.bb => perl_5.14.2.bb} (92%)
create mode 100644 meta/recipes-devtools/squashfs-tools/squashfs-tools_4.2.bb
create mode 100644 meta/recipes-devtools/subversion/subversion-1.7.0/libtool2.patch
create mode 100644 meta/recipes-devtools/subversion/subversion_1.7.0.bb
rename meta/recipes-devtools/tcltk/{tcl_8.5.9.bb => tcl_8.5.10.bb} (91%)
create mode 100644 meta/recipes-extended/texi2html/texi2html_1.82.bb
create mode 100644 meta/recipes-extended/wget/wget-1.12/fix_makefile.patch
create mode 100644 meta/recipes-extended/wget/wget-1.12/gnutls.bzr.patch
create mode 100644 meta/recipes-extended/wget/wget.inc
create mode 100644 meta/recipes-extended/wget/wget_1.12.bb
rename meta/recipes-kernel/oprofile/{oprofile_0.9.6.bb => oprofile.inc} (70%)
create mode 100644 meta/recipes-kernel/oprofile/oprofile_0.9.7.bb
delete mode 100644 meta/recipes-kernel/oprofile/oprofile_cvs.bb
create mode 100644 meta/recipes-kernel/oprofile/oprofile_git.bb
--
1.7.6.4
^ 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