Helo Paul,
Do you know, if and how »PATCH« got stripped in the subject? Without it,
Patchwork will not pick it up, I think.
It got stripped because of your recommendation to use
--subject-prefix="v2". The "How to submit a patch to OpenEmbedded" wiki
page at
<http://wiki.openembedded.net/index.php/How_to_submit_a_patch_to_OpenEmbedded#Create_and_Commit_your_patch>
recommends the same.
Anyway, the patch got picked up by patchwork.
From: t.fromm<t.fr...@ba11ecae-741b-462f-8724-1218f99f5906>
Where does that line come from. Did you send this patch from the same
system and did you configure git correctly?
git config user.name Thilo Fromm
git config user.email [email protected]
It is just a cosmetic error, but this line will be shown in the commit
history and used for the weekly changelog generation.
I have these two config fields set up exactly like this. Git, however,
chooses to generate a mail with two From: header lines.
If wvstreams is configured with DBus support enabled (by not providing
--without-dbus) the the build fails at link time as libdbus cannot be
found:
| ./CXX -c dbus/wvdbusconn
| ./CXX -c dbus/wvdbusmarshal
| ./CXX -c dbus/wvdbusmsg
[...]
+PR = "r2"
+
I think `PR` starts at 0 by default.
Well, I though this recipe was already *there* before I started, so it's
not a "r0". But all right, I'll reset this ro "r0" in [v3].
SRC_URI = "http://wvstreams.googlecode.com/files/${PN}-${PV}.tar.gz \
"
@@ -10,7 +12,8 @@ inherit autotools pkgconfig
LDFLAGS_append = " -Wl,-rpath-link,${TOOLCHAIN_PATH}/${TARGET_SYS}/lib"
-EXTRA_OECONF = " --without-tcl --without-qt --without-pam"
+# dbus detection currently broken in configure.ac; remember to add "dbus (>=
1.2.14)" to DEPENDS when fixed
+EXTRA_OECONF = " --without-tcl --without-qt --without-pam --without-dbus"
PACKAGES_prepend = "libuniconf libuniconf-dbg "
PACKAGES_prepend = "uniconfd uniconfd-dbg "
Just a question. Do you know if the other version of wvstreams suffer
from the same problem?
Nope, no idea. I am merely trying to get one single build from start to
finish, but OpenEmbeddded keeps breaking all the time. I've been doing
this for about a week now without success.
Given the current (in)stability of the build framework I think I'm far,
far away from a system state reliable enough to even think about the
cross-versioning build tests you're suggesting.
Regards, Thilo
--
Dipl.-Ing (FH) Thilo Fromm, MSc., Embedded Systems Developer
DResearch Digital Media Systems GmbH
Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
Tel: +49 (30) 515 932 228 mailto:[email protected]
Fax: +49 (30) 515 932 77 http://www.dresearch.de
Amtsgericht: Berlin Charlottenburg, HRB:54412
Ust.-IDNr. DE169013825; WEEE Reg.-Nr. DE 85995642
Geschäftsführer: Dr. M. Weber, W. Mögle
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
