**** BEGIN LOGGING AT Tue Jan 28 02:59:59 2014
Jan 28 08:22:58 good morning
Jan 28 08:38:14 hi i try to build yocto toolchain by using this command bitbake meta-toolchain-qte it shows me this error http://pastebin.com/qrxNv2Cd can you help me
Jan 28 08:43:55 linu1: you need to figure out why libqt-embeddedscripttools4-dev wasn't created or when it should have been created
Jan 28 08:45:43 linu1: you'd better use branch dora
Jan 28 08:50:05 mckoan, ya but i have been used dylan for a set up, there is ipk for libqt-embeddedscripttools4-dev in deploy-ipks, dont know exact reason
Jan 28 08:50:22 mckoan, ya but i have been used dylan for a set up, there is no ipk for libqt-embeddedscripttools4-dev in deploy-ipks, dont know exact reason
Jan 28 08:53:15 morning all
Jan 28 09:02:23 bluelightning do you have any idea
Jan 28 09:07:42 linu1: what files are you looking for specifically that should be in that package?
Jan 28 09:18:50 bluelightning: his paste was here: http://pastebin.com/qrxNv2Cd
Jan 28 09:43:54 hello
Jan 28 09:48:45 I have a question, I am trying to build pg_journal witch is a module of postgresql. When I build it on my workstation by executing make it works just fine. When i try to build it with bitbake this http://pastebin.com/4AfhAy7U error comes up. I dont understand what that means. because i have systemd in the build dependencies of my recipe.
Jan 28 09:50:07 wfailla: is there a systemd/sd-journal.h in /usr/src/disk/wfailla/tplino-core/build-tposs-vmware/tmp/sysroots/x86_64-linux/usr/include ?
Jan 28 09:50:43 I see it is complaining it can't find the pc file as well
Jan 28 09:51:50 no there is no file in that dir
Jan 28 09:52:01 yes but i don't know why
Jan 28 09:52:21 i assumed that it should be installed by the systemd pkg
Jan 28 09:53:32 wfailla: I'd suggest verifying that it is
Jan 28 09:54:37 linu1: I just did a build with dylan here and that package isn't empty
Jan 28 09:58:05 bluelightning, I grebed fore libsystemd-journal over all my metalayer and i got no result
Jan 28 09:59:28 linu1: does log.do_configure say whether the QtScriptTools module was enabled or not?
Jan 28 09:59:59 bluelightning, is there an easy way to find out what pkg is provided by what recipe?
Jan 28 10:03:12 bluelightning, libsystemd-journal.pc is lokated tmp/sysroots/vmware/usr/lib/pkgconfig/libsystemd-journal.pc
Jan 28 10:03:29 why can't bitbake find that
Jan 28 10:04:41 wfailla: it's not bitbake at all, it's the build process of the software you're building
Jan 28 10:05:07 wfailla: i suspect the build script is broken
Jan 28 10:07:31 it is a module for postgresql, so it might be better to build it directly on the machien it will be deployed on ... is that a good idear? have the .ipk include the src code and a post install script that will build the module ?
Jan 28 10:09:59 wfailla: that definitely should not be necessary
Jan 28 10:10:12 bluelightning, ok
Jan 28 10:10:29 wfailla: this should be a fairly simple problem to fix - find out where it's looking for the .pc file and tell it to look in the right place
Jan 28 10:13:19 bluelightning, i think the problem is that the makefile of pg_journal https://github.com/intgr/pg_journal/blob/master/Makefile includes the pgxs.mk of postgresql and that confuses bitbake
Jan 28 10:15:55 wfailla: well that has to be put into the sysroot so the pg_journal build process can find it there
Jan 28 10:16:39 bluelightning, how do i find out where bitbake looks for stuff ?
Jan 28 10:16:58 wfailla: bitbake isn't doing the looking; it's the build process of the software itself
Jan 28 10:17:41 wfailla: so check log.do_configure, config.log (if applicable), the configure script code, etc. in the WORKDIR of postgres / pg_journal
Jan 28 10:18:19 wfailla: do "bitbake pg_journal -c devshell", and in the resulting termal "pkg-config —cflags libsystemd-journal"
Jan 28 10:22:18 rburton, --cflags returns nothing and --libs returns -lsystemd-journal -lsystemd-id128
Jan 28 10:22:54 so it does work, and its entirely the makefile
Jan 28 10:25:49 ok then i have to find a good tutorial about make files XD
Jan 28 10:27:11 hm, did that just pick up your *host* systemd?
Jan 28 10:28:31 i dont think so i am running ubuntu 11.10 as host
Jan 28 10:28:37 fair enough :)
Jan 28 10:58:42 hi again th files i am looking for are just in ./tmp/work/x86_64-tposs-linux/postgresql/9.3.1-r0.0.0/image/usr/bin/pg_config but not in /usr/src/disk/wfailla/tplino-core/build-tposs-vmware/tmp/sysroots/vmware/usr/bin/pf_config whitch is the staging dir
Jan 28 10:59:12 is there a way to get them in to the staging dir ?
Jan 28 10:59:39 and or ld bitbake look in the package
Jan 28 11:00:15 * and/or led bitbake look in the package specific dir ?
Jan 28 13:02:46 I do not understand the why md5sum does not match if I use a tarball for SRC_URI or a git link
Jan 28 13:02:50 got a clue ?
Jan 28 13:02:57 090eb3dae0f520f7770f85193e931ad3 /home/lpapp/Downloads/linux-3.2.1.tar.bz2
Jan 28 13:03:07 492f7bde295d7b401ac4061852ea9e59 source-tree.tar.bz2
Jan 28 13:03:33 SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v3.0/linux-${PV}.tar.bz2;name=kernel
Jan 28 13:03:34 vs.
Jan 28 13:03:34 um... because a git tree is not a tarball?
Jan 28 13:03:40 SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;protocol=git;branch=${KBRANCH}
Jan 28 13:03:46 LetoThe2nd: surely, it is with git archive.
Jan 28 13:04:13 lpapp: no, it surely isn't... the files will have different dates, owners, etc.
Jan 28 13:04:36 bluelightning: so?
Jan 28 13:04:45 bluelightning: the binary content should be the same.
Jan 28 13:04:50 since it is the same release...
Jan 28 13:04:50 anyways, i don't think that an md5sum is of much use for git. git itself shall take care of integrity, all it shall depend on is the sha of the commit.
Jan 28 13:05:04 lpapp: so, the tarball will end up different, the checksum is of the archive file not the contents
Jan 28 13:05:08 md5sum has not much to do with git
Jan 28 13:05:18 once you get an archive from git, you can forget git.
Jan 28 13:05:43 bluelightning: I do not follow.
Jan 28 13:05:57 try it outside of the build system and see
Jan 28 13:06:26 even the size is very different fwiw.
Jan 28 13:06:34 75 M and 88 M
Jan 28 13:06:39 they should be exactly the same
Jan 28 13:06:44 why?
Jan 28 13:06:46 since they should represent exactly the same release.
Jan 28 13:06:50 why what?
Jan 28 13:07:14 well, I am getting a kernel panic, and it is clearly due to the move to git.
Jan 28 13:07:23 why should two archives from two sources be in anyways identical?
Jan 28 13:07:23 and I really do not know how to get the right release from git.
Jan 28 13:07:33 it should be the *same* source.
Jan 28 13:07:38 that is the whole point. :-)
Jan 28 13:07:48 then why do you go through git-archive?
Jan 28 13:09:02 OE can pull a specific git tag.
Jan 28 13:09:02 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux/linux-yocto-dev.bb
Jan 28 13:09:03 pardon ?
Jan 28 13:09:20 how else would you verify they are the same sources, without git archive?
Jan 28 13:09:26 no need for archive -> pack -> md5sum -> unpack
Jan 28 13:09:36 err... no, not at all.
Jan 28 13:09:47 the tarball downloaded from tarball is a tarball, surprisingly. :)
Jan 28 13:09:53 it does not have .git, etc, what-so-ever.
Jan 28 13:10:10 what I want is the contrary, I want to compare the real sources without VCS information.
Jan 28 13:10:23 since the git version clearly causes a kernel panic, and I have reached a point that I do not know why.
Jan 28 13:10:27 then the tarball is just not identic, and your process of getting the sources is whacked. same result.
Jan 28 13:10:33 this is the only last hope of mine that where the problem may lay down.
Jan 28 13:11:33 and comparing a *tarball* to any git checkout/archive is always pointless, because the export from git will give you other metadata than that in the tarball.
Jan 28 13:11:55 you can only compare net data, like diffing or such
Jan 28 13:12:37 is there anyone here understanding how the linux kernel recipe is supposed to work?
Jan 28 13:13:29 http://pastebin.kde.org/pabfmh8lq -> These are the changes I made to mine from denzil era.
Jan 28 13:13:34 Is there anything wrong in there?
Jan 28 13:13:55 no no
Jan 28 13:14:06 git archive is heavily used for actually generating the release tarball
Jan 28 13:14:13 that is the whole point of it, in fact. :)
Jan 28 13:15:33 i still think you are going wrong, but i cannot lay my fingers on the point.
Jan 28 13:17:25 right, "I do not know" is more fruitful than "You are doing it wrong, but I do not know what". :-)
Jan 28 13:18:19 so, does anyone know if there is any scary modification in that recipe which would cause the kernel to run panic?
Jan 28 13:18:37 i think they both told you that you can't compare md5 for 2 tarballs generated independently. even on 2 different linux machine you might get 2 different tarball for the same content.
Jan 28 13:19:04 you should diff the files inside the tarball if you want the differences in the source code
Jan 28 13:19:26 no, 10-20% size difference is pretty indicative.
Jan 28 13:19:56 either way, does anyone know why that recipe modification would cause kernel panic?
Jan 28 13:20:24 I have been trying to debug it for half a day now, but my kernel code is just good (TM)
Jan 28 13:20:28 so it must be about the recipe.
Jan 28 13:20:47 well, kernel recipes deal with additional patches and defconfig. are you sure you are using the same patches and same defconfig?
Jan 28 13:21:19 yes, of course.
Jan 28 13:21:45 are you compiling with the same gcc in both cases?
Jan 28 13:22:30 http://pastebin.kde.org/pmkqcodvv -> this is the .inc kernel recipe modification fwiw.
Jan 28 13:22:37 I cannot figure out for my life while it is panicing.
Jan 28 13:22:50 ndec: yes, everything is exactly the same except the recipes.
Jan 28 13:25:14 then you should study the run_do.configure and run_do.compile of the kernel recipes, that will tell precisely how it's built.
Jan 28 13:25:58 well, I was coming here to get advice from people who know this stuff.... ;-)
Jan 28 13:26:04 (Otherwise, yes, I would have done it myself).
Jan 28 13:41:07 http://patches.openembedded.org/patch/49683/
Jan 28 13:41:09 is this really good?
Jan 28 13:41:16 root home should be /root rather than /home/root, no?
Jan 28 13:41:54 or is there a better way than ROOT_HOME to actually get /root?
Jan 28 13:48:26 https://gitorious.org/shr/openembedded-core/commit/a78cd0b
Jan 28 13:48:41 I have never really seen any /home/root on any Linux yet. Is this really a reasonable thing?
Jan 28 13:56:22 https://bugzilla.yoctoproject.org/show_bug.cgi?id=5762
Jan 28 13:56:23 Bug 5762: normal, Undecided, ---, scott.m.rifenbark, NEW , Document the usage of the ROOT_HOME variable
Jan 28 13:58:04 so if it is modified in the local.conf the home root will be that one globally, and if in a layer, then only for that layer?
Jan 28 13:58:48 is there even a use case when it should not be set "globally"? I cannot imagine two separate home folders for the root, or perhaps this is not the same as the /root folder? I am kindle puzzled....
Jan 28 14:01:40 is it ok to have a meta-foo/recipes-core/base-files/*.bbappend and then an fstab within the base-files folder of that parent folder?
Jan 28 14:01:53 so we would like to have the same base files except some fstab customization for our board and distro?
Jan 28 14:24:25 hi, I'm using a very basic classic recipe for kernel (no yocto-kernel). Is it possible to have multiple defconfigs for multiple machines?
Jan 28 14:26:15 ccaione: perhaps with fragments? I do not know to be honest
Jan 28 14:29:19 lpapp: yeah probably
Jan 28 14:31:09 I was hoping in something like SRC_URI_machine
Jan 28 14:31:26 yep, that's works
Jan 28 14:31:51 _machine ("overrides") work on any variable
Jan 28 14:32:04 :D lol, great
Jan 28 14:32:10 thanks rburton
Jan 28 14:32:41 looks like another documentation bugreport...
Jan 28 14:32:52 overrides are documented
Jan 28 14:33:41 ccaione: ./meta/recipes-kernel/sysprof/sysprof_git.bb:15:SRC_URI_append_mips = " file://rmb-mips.patch"
Jan 28 14:33:44 ./meta/recipes-kernel/sysprof/sysprof_git.bb:16:SRC_URI_append_mips64 = " file://rmb-mips.patch"
Jan 28 14:34:06 rburton: I am not talking about override, but the arch...
Jan 28 14:34:41 lpapp: now I have to check if I'm forced to call the file "defconfig"
Jan 28 14:34:52 ccaione: http://www.yoctoproject.org/docs/1.4.2/ref-manual/ref-manual.html#var-MACHINEOVERRIDES
Jan 28 14:35:06 ccaione: I do not know, but I would really not call it otherwise.
Jan 28 14:35:40 the problem is that I want to use two different kernel configurations for my machines
Jan 28 14:36:19 (two boards with different on-board SDRAM)
Jan 28 14:36:54 ah, right.
Jan 28 14:37:07 files are searched in machine-specific directories
Jan 28 14:37:09 I would grep for "defconfig" then.
Jan 28 14:37:32 but in general, it is better to have a device tree IMHO.
Jan 28 14:37:49 so you'd have my-kernel/[machine]/defconfig
Jan 28 14:37:55 again, see what oe-core does
Jan 28 14:38:34 lpapp: device tree != kernel config :)
Jan 28 14:38:38 rburton: I'll do, thanks
Jan 28 14:38:45 ccaione: it is
Jan 28 14:38:59 ccaione: you can have subfolders for different archs, like the linux kernel device tree
Jan 28 14:39:24 lpapp: oooh, got it
Jan 28 14:39:36 rburton: what do you mean by oe-core?
Jan 28 14:39:59 meta does not have defconfigs except busybox
Jan 28 14:40:40 looking up per-architecture files isn't in any way specific to the kernel
Jan 28 14:41:07 well, even busybox does not have it.
Jan 28 14:41:13 it has only one "main" defconfig.
Jan 28 14:41:28 probably better to pick a recipe that varies per machine
Jan 28 14:41:36 like formfactor
Jan 28 14:42:50 I am not sure what became wrong about the "Propriate" license entry in the bb recipes?
Jan 28 14:42:53 I am getting a warning...
Jan 28 14:44:15 "CLOSED" is the idiomatic way to avoid license warnings for closed source pieces
Jan 28 14:44:43 but I was suggested to use Propriate before...
Jan 28 14:44:47 (in here)
Jan 28 14:44:56 are you spelling it correctly?
Jan 28 14:45:29 < bluelightning> lpapp: "Proprietary" or "CLOSED"
Jan 28 14:45:43 yep, so i see in the code
Jan 28 14:45:45 < bluelightning> lpapp: note that CLOSED will completely disable LIC_FILES_CHKSUM
Jan 28 14:45:54 indeed
Jan 28 14:46:22 well, I feel pretty strange
Jan 28 14:46:28 bluelightning told me this long ago, and we still have Propriate
Jan 28 14:46:35 I wonder why I would not have fixed it right away...
Jan 28 14:49:51 rburton: so have you seen my question above about fstab?
Jan 28 14:49:58 is it ok to have a base-files bbappend with a custom fstab?
Jan 28 14:50:20 sure
Jan 28 14:50:35 oh, right, I fixed the Proprietary stuff only in new recipes added
Jan 28 14:50:38 and did not for old.
Jan 28 14:50:49 rburton: ok, thanks, so how about busybox patches?
Jan 28 14:50:55 one of the patches in meta does not fit us...
Jan 28 14:51:04 we had to make a one liner modification to it.
Jan 28 14:51:26 bbappend with a custom modified patch will let meta know to ignore the same patch in there if the names are the same or what?
Jan 28 14:51:35 yeah
Jan 28 15:11:32 -> /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/meta/files/common-licenses/Proprietary could not be copied for some reason. It may not exist. WARN for now.
Jan 28 15:11:47 even though the file does exist, and has the following content: Proprietary license.
Jan 28 15:15:28 guys, I have bbappend for packagegroup-core-buildessential.bbappend that contains: RDEPENDS_packagegroup-core-buildessential_libc-uclibc = "\
Jan 28 15:15:39 is it correct variable name? I want that to trigger only for uclibc
Jan 28 15:15:59 yes
Jan 28 15:16:12 (unfortunatelly default packagegroup-core-buildessential depends on stuff that does not build for uclibc)
Jan 28 15:16:14 that will override entirely what the recipe says
Jan 28 15:16:18 ah
Jan 28 15:16:29 I do not understand why we need dummy bbappend files
Jan 28 15:16:31 in that case file a bug so the recipe in oe-core uses libc-glibc??
Jan 28 15:16:33 like in meta-yocto-bsp
Jan 28 15:16:34 can I do substraction in bbappend for uclibc only?
Jan 28 15:16:39 the content is always something like FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
Jan 28 15:16:42 P/PN/PV
Jan 28 15:16:50 could it just not scan through by default?
Jan 28 15:17:06 lpapp: because then it will be looking *everywhere* for files
Jan 28 15:17:26 Xz: yes, use _remove_libc-uclibc
Jan 28 15:17:55 rburton: RDEPENDS_packagegroup-core-buildessential_remove_libc-uclibc = "pkgconfig"
Jan 28 15:17:59 rburton: does that look correct? :)
Jan 28 15:18:31 Xz: i *think* so :)
Jan 28 15:18:32 rburton: yes, that is what I want.
Jan 28 15:18:42 rburton: so we do not need to write boilerplate.
Jan 28 15:19:06 rburton: ok, will test it and maybe that would be good enough solution to upstream? just to add this line into original recipe
Jan 28 15:19:28 lpapp: so for every file it looks for, it should iterate though every directory in every layer just in case the file is there?
Jan 28 15:19:58 rburton: no
Jan 28 15:20:12 rburton: the default could be the THISDIR/{PV,PN,P}
Jan 28 15:21:03 i guess you mean the default is extended automatically every time there's a bbappend
Jan 28 15:21:09 as what you've said is the default
Jan 28 15:21:49 if that is the default, why do bbappends write dummy stuff?
Jan 28 15:22:14 why don't we just have empty files?
Jan 28 15:22:48 because the default comes from the .bb
Jan 28 15:23:08 as i said, you want the default to be extended for every bbappend
Jan 28 15:23:35 yes.
Jan 28 15:23:50 although it feels a bit fuzzy to touch empty files.
Jan 28 15:23:59 sure there is no other useful content to put into a bbappend?
Jan 28 15:28:19 RP: Last commit on master only partially reverts the CC 2.5 to 3.0 change. The link still says 3.0 but the text now says 2.5...
Jan 28 15:28:52 Saur: well spotted, thanks
Jan 28 15:30:33 rburton: so what is the difference between overriding ROOT_HOME in the layer stuff or the local config?
Jan 28 15:30:40 (also, which one would you suggest?)
Jan 28 15:31:06 I guess we prefer the root home as on any Linux I have seen so far which is /root.
Jan 28 15:32:50 lpapp: none. one is a local choice, one is a layer choice.
Jan 28 15:33:40 rburton: well, it should be the same for everyone.
Jan 28 15:33:57 rburton: but since we check in the conf/ folder in the build/ folder, I do not see the difference for us.
Jan 28 15:34:06 cause everyone has the same local conf.
Jan 28 15:34:56 so if I need to provide a custom defconfig for busybox, what is the best way for it?
Jan 28 15:35:12 fragments or simple a bbappend with a defconfig file in busybox-1.20.2?
Jan 28 15:35:38 meta-yocto is doing this: ../meta-yocto/recipes-core/busybox/busybox-1.20.2/poky-tiny/defconfig
Jan 28 15:35:48 but is this the right way or it is obsolete and it is better to use fragments?
Jan 28 15:39:58 why does meta-yocto have that "poky-tiny" in-between folder? What is wrong about putting the defconfig right in busybox-1.20.2?
Jan 28 15:40:39 argh, why after kernel compiling the uImage I get is totally wrong? it seems that kernel is correctly compiled (I see the correct uImage in the temp dir) but in deploy/images I have a wrong uImage taken from packages-split
Jan 28 15:41:49 ccaione: are you having some custom kernel recipes?
Jan 28 15:41:54 lpapp: yes I do
Jan 28 15:42:13 then probably people cannot know without seeing it. :-)
Jan 28 15:42:34 lpapp: http://pastebin.com/tzv5JUi9
Jan 28 15:42:44 nothing special
Jan 28 15:43:08 well, IMHO, the kernel recipe is quite special. :)
Jan 28 15:43:17 compared to the other recipes, it is somewhat complex.
Jan 28 15:43:22 why so? :D
Jan 28 15:44:10 Is there a way to automatically force recompilation of certain packages if DISTRO_TYPE is changed?
Jan 28 15:44:55 the real question is: what is the uImage I got in packages-split/kernel-image/boot? and why it isn't the real uImage copied in deploy/images?
Jan 28 15:44:58 user1314241: -c compile -f
Jan 28 15:47:31 that might work but I don't see how to automate that.
Jan 28 15:48:38 automate what?
Jan 28 15:48:44 you want to avoid typing that? Make an alias!
Jan 28 15:48:55 it is also possible by configuration, sec...
Jan 28 15:49:00 the system will automatically rerun tasks if variables they use change. so if changing that affects the vars that flow into a task, that task will be rerun, regardless of what the var is
Jan 28 15:49:38 I think RP told me a config solution for it back then, but I cannot find it in my log right now...
Jan 28 15:49:55 it is possible it is in my home log.
Jan 28 15:50:25