**** 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 <@RP> lpapp: you could add do_compile[nostamp] = "1" to your kernel recipe, then it will rebuild every time Jan 28 15:50:39 user1314241: ^ Jan 28 15:53:05 kergoth: what constitutes using a variable? if define a variable that is conditional on DISTRO_TYPE in a recipe, and that variable in turn is passed to a make file. But I find that no rebuild is taking place for a changed DISTRO_TYPE. Jan 28 15:54:28 bitbake tracks variable references. 90% of the time it successfully does so. once in a blue moon it fails to do so Jan 28 15:54:43 in which case they can be added explicitly via the vardeps flag Jan 28 15:55:17 is there a way to change a owner:group of a directory ? I tried to do it in my image in ROOTFS_POSTPROCESS_COMMAND += "chown -R 1001:1001 ${IMAGE_ROOTFS}/directory but when I login in the image, I get owner:group 114:124 any trick to solve this ? Jan 28 15:58:48 rburton: I guess it is ok to add a patch to ../meta/recipes-core/init-ifupdown/init-ifupdown-1.0/init in our layer with a bbappend? Jan 28 16:00:24 kergoth: did you have any thoughts on -S? Jan 28 16:01:04 YPTM: IonutC is on Jan 28 16:01:20 sjolley: YPTM: Richard is on the call Jan 28 16:01:31 YPTM: Matthew is on the call Jan 28 16:01:40 YPTM: ross joined Jan 28 16:01:50 Cristiana from Ro-dev team is on the call Jan 28 16:01:52 YPTM: Scott Rifenbark is on the call. Jan 28 16:01:55 sjolley, YPTM: Michael on the call. Jan 28 16:01:55 YPTM: AlexG is on the call. Jan 28 16:01:57 The Yocto Project Tech Meeting Con-Call will be starting at the top of the hour Jan 28 16:01:57 Dial-in number: 1.972.995.7777 / Participant passcode: 42001078 Jan 28 16:01:57 This call is open to all and the channel remains open to discuss any topic Jan 28 16:02:01 RP: not offhand, though i do think an optional argument to an option is a bad idea, as you say, results in vague/unclear behavior Jan 28 16:02:04 YPTM: Paul Eggleton is on Jan 28 16:02:12 YPTM: Denys is here Jan 28 16:02:32 YPTM: Tom Z on Jan 28 16:02:40 YPTM: Polk is on Jan 28 16:02:43 kergoth: am torn over it, I think a mandatory parameter is going to be the least bad solution Jan 28 16:02:47 sjolley: Scott Rifenbark is on the call. Jan 28 16:02:47 YPTM: Saul is On finally Jan 28 16:03:08 YPTM: Tom Z on Jan 28 16:03:50 RP: fwiw, i think adding a mandatory option to -S is least bad too. optional is horrible. there's sufficiently few people using -S that breakage is managable i'd say. Jan 28 16:03:52 YPTM: Nitin is on the call Jan 28 16:05:03 sjolley TPTM: is here Jan 28 16:05:14 sjolley: Cristiana from Ro-dev team is on the call Jan 28 16:05:15 sjolley YTPTM Jan 28 16:06:59 pidge Jan 28 16:09:11 sjolley: FRI2 = FishRiverIsland 2 Jan 28 16:09:41 I thought it meant FRIed Twice Jan 28 16:10:04 sjolley: ionut Jan 28 16:12:53 YPTM: the current QA status: https://wiki.yoctoproject.org/wiki/1.6_QA_Status Jan 28 16:13:09 rburton: have you idea of what is the uImage I find in packages-split/kernel-image/boot and why it is different from uImage I get in the working directory? Jan 28 16:13:30 ccaione: none at all, sorry Jan 28 16:13:50 ccaione: do you have the same issue with the meta kernel? Jan 28 16:14:00 lpapp: I cannot use the meta-kernel atm Jan 28 16:14:05 rburton: Hey, long time no see :) Jan 28 16:14:11 yes, I mean for testing... to boil down whether it is a recipe issue. Jan 28 16:14:48 ok, let's see if i can convert my recipe to meta-kernel Jan 28 16:15:09 nah, just build the meta kernel. Jan 28 16:15:15 with uImage (custom mod) Jan 28 16:17:24 * fray is on IRC for a few.. the -16F weather is trying ot kill me Jan 28 16:17:33 me Jan 28 16:17:40 sjolley: it's me Jan 28 16:17:48 sjolley: https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Jan 28 16:19:24 rburton: RDEPENDS_packagegroup-core-buildessential_remove_libc-uclibc = "pkgconfig" does not remove pkgconfig :| Jan 28 16:19:52 Xz: hm :( Jan 28 16:20:09 fray: sounds rather cold... Jan 28 16:20:19 -45F when you consider wind chill Jan 28 16:20:26 rburton: does order of appending and evaluating variables matter here? Jan 28 16:20:41 -16F is -27C BTW Jan 28 16:20:50 -27C is usual in Finland. :-) Jan 28 16:20:52 Xz: _remove will happen alongside _append, i.e. last Jan 28 16:22:17 remove should happen last Jan 28 16:22:34 rburton: can I print that variable somehowe? bitbake -e does not give me access to it Jan 28 16:23:52 Xz: try bitbake packagegroup-core-buildessential -e Jan 28 16:24:00 Xz: it certainly should if you do bitbake -e packagegroup-core-buildessential Jan 28 16:24:12 YPTM: yes my question was answered, thank you. Jan 28 16:25:20 RP: rburton: so that shows pkgconfig not being removed Jan 28 16:25:49 maybe variable name should be RDEPENDS_remove_libc-uclibc_packagegroup-core-buildessential ? Jan 28 16:26:10 Xz: your bitbake supports remove, right? sure the bbappend is being parsed? Jan 28 16:26:12 don't know the logic of parsing names - that name is anyway pretty complex ^_^ Jan 28 16:26:32 rburton: I'm on dylan - was remove introduced in dora? Jan 28 16:26:32 Xz: Try RDEPENDS_${PN}_remove_libc-uclibc_pn-packagegroup-core-buildessential = "pkgconfig" Jan 28 16:26:45 RP: oh god, explain that? Jan 28 16:26:52 heh, thats what i was thinking. one would hope expandKeys would have run before the _remoe processing, but.. Jan 28 16:26:57 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/base-passwd/base-passwd/nobash.patch#n6 Jan 28 16:26:59 Xz: ah, you might not have that in dylan Jan 28 16:27:04 why is that? It breaks stuff for us. :-/ Jan 28 16:27:14 "remove "*" for root since we don't have a /etc/shadow so far." Jan 28 16:27:15 Xz: ah, yeah, dylan doesn't have _remove Jan 28 16:27:15 gotta love use of multiple overrides for a single variable ;) Jan 28 16:27:24 no way :| Jan 28 16:27:33 * fray is Mark Hatle Jan 28 16:27:54 What does it mean "we do not have /etc/shadow so far"? Jan 28 16:28:51 isn't it shipped by ../meta/recipes-core/base-files/base-files/filesystems? Jan 28 16:29:05 or something similar. :-) Jan 28 16:30:02 FYI pseudo, Seebs (peter seebach) has found a couple of cases where the wrong modes are saved.. this is what Saul is referring to. He'll hopefully have fixes for Dora and master soon.. Jan 28 16:30:42 FOSDEM Jan 28 16:30:47 conference is FOSDEM Jan 28 16:31:04 fray: Is that Jama's issue? Jan 28 16:31:14 https://fosdem.org/2014/ Jan 28 16:31:38 I don't know.. the issue we were tracking was found by a customer who was trying to set a directory as 500 and it kep getting set to 0700 Jan 28 16:32:01 sjolley: thanks! Jan 28 16:33:19 RP: rburton: for dylan this will do: RDEPENDS_${PN}_libc-uclibc_pn-packagegroup-core-buildessential = "\ Jan 28 16:33:49 RP: rburton: I know it's not perfect, but better than nothing and it lets build dylan uclibc image with 'tools-sdk' and few others enabled Jan 28 16:34:20 RP: rburton: will double-check with eglibc, but there is big chance it will work correctly Jan 28 16:35:26 Xz: any idea why pkgconfig doesn't work with uclibc? Jan 28 16:36:16 Xz: or you could use a bbappend with := and oe_filter_out() Jan 28 16:37:40 Xz: you'll have dora soon, right? ;-) Jan 28 16:37:46 hehe Jan 28 16:38:11 rburton: first question: Jan 28 16:38:11 | Collected errors: Jan 28 16:38:11 | * satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-core-sdk: Jan 28 16:38:14 | * pkgconfig * Jan 28 16:38:16 | * opkg_install_cmd: Cannot install package packagegroup-core-sdk. Jan 28 16:38:27 rburton: I have no idea why it happens + I can live without pkgconfig :) Jan 28 16:39:15 jackmitchell: are you around by any chance? Jan 28 16:39:26 Xz: what happens if you bitbake pkgconfig? Jan 28 16:39:30 kergoth: any documentation about 'oe_filter_out()' ? yoctoproject.org/.../mega-manual does not cover that one Jan 28 16:39:44 grep :) Jan 28 16:39:56 should be lots of examples to use Jan 28 16:40:13 rburton: NOTE: Tasks Summary: Attempted 0 tasks of which 0 didn't need to be rerun and all succeeded. Jan 28 16:40:17 rburton: nothing happens Jan 28 16:40:21 rburton: actually interesting :) Jan 28 16:41:09 RP: yeah, dora is target for I guess feb 2014 Jan 28 16:41:21 RP: maybe march 2014... :) Jan 28 16:44:42 Xz: so its already built.. so why didn't it find it when building the packagegroup? :/ Jan 28 16:45:25 rburton: it's not built. When I do 'bitbake pkgconfig -c cleanall' and then try to make it again - the same thing happens, 0 tasks Jan 28 16:45:53 rburton: and it's not present under tmp/work/i586-uclibc.../pkgconfig Jan 28 16:48:25 huh Jan 28 16:48:41 is anyone working on this issue? https://bugzilla.yoctoproject.org/show_bug.cgi?id=5675 Jan 28 16:48:42 Bug 5675: enhancement, Medium, 1.6, Qi.Chen, NEW , Add a ROOT_PASSWD feature for images Jan 28 16:48:57 Xz: crazy hunch: do you have pkgconfig in an ASSUME_PROVIDED by any chance? Jan 28 16:49:55 rburton: yeah, I do Jan 28 16:50:04 Xz: you probably meant pkgconfig-native Jan 28 16:50:11 (that's why this is failing) Jan 28 16:50:43 we should sanity check that ASSUME_PROVIDED only contains -native recipes Jan 28 16:50:45 rburton: meta-yocto/conf/distro/poky-tiny.conf:ASSUME_PROVIDED += "pkgconfig$" Jan 28 16:50:53 rburton: why poky-tiny.conf does that? Jan 28 16:50:57 huh Jan 28 16:51:10 rburton: I'm inheriting poky-tiny Jan 28 16:51:29 that sounds really broken/bad, unless it just is impossible to build in those circumstances, but even then it'd be better to append it and raise SkipPackage Jan 28 16:51:31 that is a horrible hack Jan 28 16:51:47 well that's impressively vile Jan 28 16:52:02 should I git-blame it? ^_^ Jan 28 16:52:05 that dependency doesn;t exist anymore Jan 28 16:52:17 pretty sure i removed that anyway Jan 28 16:52:54 rburton: its still in the tiny config Jan 28 16:53:09 RP: i meant -dev depending on pkgconfig Jan 28 16:53:18 rburton: right, yes Jan 28 16:53:43 a54932dc373ec130f7a166d144f4d5744ec52097 - that's git commit of that ASSUME_PROVIDED Jan 28 16:53:51 bcc73d26ddff01f0e4bb38eab23c57ef9bf76b04 Jan 28 16:54:05 " pkgconfig: Drop automatic pkgconfig RDEPENDS" Jan 28 16:54:22 thus, we can delete that line from poky-tiny Jan 28 16:55:30 * zeddii missed the meeting, but has a good excuse. xrays on my wrist. typing sucks today. Jan 28 16:55:37 hm maybe not. Jan 28 16:55:57 Xz: if you have a moment, can you try commenting out that line and bitbakeing pkgconfig? Jan 28 16:56:05 rburton: yeah Jan 28 16:56:17 rburton: do you use git-revert to revert such changes? Jan 28 16:56:33 Xz: that's one option, certainly Jan 28 16:56:54 we *could* change pkgconfig to use the integrated libraries in tiny distros, that stops it linking to glib Jan 28 16:57:54 zeddii: radioactive wrists? surely that means super-fast typing or something. Jan 28 16:58:02 SUPERTYPOMAN Jan 28 16:58:35 * zeddii wishes. maybe it's fractured. sports injury. Jan 28 16:59:11 rburton: pkgconfig built fine on dylan Jan 28 16:59:22 rburton: with ASSUME_PROVIDED commented out Jan 28 16:59:37 rburton: will boot the board to make sure it didn't fck up anything Jan 28 17:00:40 Xz: the comment says glib->dbus, which isn't a linkage that exists anymore Jan 28 17:01:26 rburton: fair enough Jan 28 17:01:29 Xz: patch welcome to remove that line from poky-tiny :) Jan 28 17:01:36 I want to do a chown while creating the image. But my user does not have privilege to chown file. What could be the strategy to do this ? Jan 28 17:01:40 rburton: alright, sending Jan 28 17:03:57 rburton: which repos is it in? certainly not git://git.openembedded.org/openembedded-core Jan 28 17:04:56 Xz: meta-yocto (although a patch from the poky repo would be fine). mail to poky@ Jan 28 17:14:19 what are these notes about ? http://pastebin.kde.org/ptf3k0sxj Jan 28 17:14:24 is it safe to ignore them? Jan 28 17:19:06 foo to bar is normally produced by buildhistory, but i've never seen them as notes. git master? maybe someone left in a debugging statement. Jan 28 17:19:25 no, dylan. Jan 28 17:20:50 never seen them. what's the context, i.e. what bit of the build produced them. Jan 28 17:23:18 rburton: bitbake foo-core-image Jan 28 17:25:31 zeddii: :/ Jan 28 17:25:54 force the minions to push 3.13 Jan 28 17:28:51 lpapp: they're accidentally left in debug in the bbappend parsing code in bitbake iirc Jan 28 17:29:11 lpapp: very safe to ignore Jan 28 17:29:42 RP: ok, thanks. :) Jan 28 17:31:45 lpapp: http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake?id=b5255bb34d17017e38d264e4360b1b560b1fa5d2 Jan 28 17:31:59 bluelightning: might be something to backport? Jan 28 17:32:31 seems like a strange thing to even keep as a debug message. bitbake -e will show you what appends were loaded anyway Jan 28 17:32:34 :) Jan 28 17:33:08 RP: are you working on the PASSWD_ROOT feature request? IMHO, it would be useful. Jan 28 17:34:09 lpapp: Since I don't know offhand what that is, I guess not Jan 28 17:35:18 RP: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5675 Jan 28 17:35:19 Bug 5675: enhancement, Medium, 1.6, Qi.Chen, NEW , Add a ROOT_PASSWD feature for images Jan 28 17:35:47 I am somewhat surprised that Yocto does not still have such a basic feature Jan 28 17:35:54 it is part of any Linux installation these days. Jan 28 17:36:36 lpapp: didn't someone add something like that (extra params for plaintext to the commands)? Jan 28 17:36:53 lpapp: Its not assigned to me so I'm not sure why I'd be working on it? Jan 28 17:37:01 rburton: packagegroup-core-sdk tries to pull in ldd, but it 'does not exist' for uclibc (poky-tiny) Jan 28 17:37:37 RP: well, you need to execute raw commands Jan 28 17:37:44 rburton: however this guy: meta/recipes-core/uclibc/uclibc-package.inc says PACKAGES = "ldd ..." Jan 28 17:38:13 Xz: hm, can't actually get any files in then Jan 28 17:38:24 rburton: so it looks like there is ldd somewhere but not exported as 'ldd' name Jan 28 17:39:08 rburton: the thing is that if I add 'tools-sdk' into IMAGE_FEATURES build breaks Jan 28 17:39:33 rburton: outcome of addint 'tools-sdk' is packagegroup-core-sdk pulling in ldd Jan 28 17:39:40 rburton: well, trying to pull in ldd Jan 28 17:39:56 RP: it was you, btw, http://cgit.openembedded.org/openembedded-core/commit/?id=31dee7946340bf0f1e94e4e714191d3d6ca3bf6a Jan 28 17:40:20 RP: because the thing is, you still need to have some raw stuff like this, EXTRA_USERS_PARAMS = "\ Jan 28 17:40:23 useradd -p '' -u 1200 -d /home/user1 -r -s /bin/bash user1; \ Jan 28 17:40:40 IMHO, that is still too complex for setting a password for the root user. Jan 28 17:40:52 lpapp: author: Chen Qi Jan 28 17:40:57 lpapp: I am not Chen Jan 28 17:41:14 oh, I see. Jan 28 17:44:42 lpapp: personally I don't think this is something we should be making easier Jan 28 17:44:44 RP: well, I guess, it would not be too hard to implement this feature in bitbake. Jan 28 17:45:04 lpapp: at worst, it encourages poor security practices Jan 28 17:45:21 since variables are already parsed, so I could take a look at how other variables are parsed, and then I know how to use passwd or chpasswd in the end. Jan 28 17:45:49 bluelightning: no, it does not. Jan 28 17:46:06 1) the discussion was also about ROOT_PASSWD_type Jan 28 17:46:13 2) Moreover, the current way already "encourages" that. Jan 28 17:46:25 since the implemented feature by Chen is basically to add support cleartext. Jan 28 17:46:32 for* Jan 28 17:46:32 setting the same default root password for every device you ship is not a security problem? Jan 28 17:47:19 correct. Jan 28 17:47:28 * rburton loves how raumfeld handles root access Jan 28 17:47:31 (not in our case anyhow where ssh is disabled) Jan 28 17:47:55 plug in a usb device with a file with basically a md5sum in and it enables ssh Jan 28 17:48:02 but then again, you have a generic complain which does not apply to the case. Jan 28 17:48:09 1) We already have this issue already today Jan 28 17:48:18 2) You already have the tools to make it better Jan 28 17:48:35 lpapp: so if this affects you perhaps you can come up with the patch to add the feature? Jan 28 17:48:53 rburton: eh? Jan 28 17:49:07 rburton: if there is no ssh server running, how will you enable the ssh? Jan 28 17:49:53 bluelightning: not at the moment, I am afraid... I have plenty on my plate. Jan 28 17:50:09 don't we all... Jan 28 17:50:21 how should I know? :) Jan 28 17:50:26 I am not busy all the time in my life. :-) Jan 28 17:50:45 lpapp: we have a lot going on. Now you know Jan 28 17:51:03 yeah, well, either way, this is a basic feature IMHO. Jan 28 17:51:17 rburton: huh, thats an interesting approach. requires local access Jan 28 17:51:27 lpapp: so basic we've managed without it for years Jan 28 17:51:55 RP: the two are orthogonal Jan 28 17:52:05 look around how it has been managed .... :) Jan 28 17:52:37 not the way how distributions have handled this the last 5-10 years. Jan 28 17:53:44 bluelightning: also, one problem with implementing it on my own is that it is possible that the Linux Foundation and Intel would not like the feature itself, so I would rather not risk my time. Jan 28 17:55:39 bluelightning: for instance I am still having a simple pending change for december, and such things demotivate me. Jan 28 17:55:45 from* Jan 28 17:56:44 currently, it feels a bit like if it is not important for the Linux Foundation and/or Intel, it will not get any attention. Jan 28 17:56:55 anybody know anything about pseudo environment vars? Jan 28 17:57:40 built it on a 64bit multilib setup but still no worky... Jan 28 18:21:37 guys, uclibc-package.inc says: PACKAGES = "ldd ...", however my built image does not have ldd Jan 28 18:21:40 what's wrong? Jan 28 18:21:57 Xz: do you have a recipe in your image that pulls in ldd? Jan 28 18:22:13 Question about ar: In my recipe I have an $AR variable set to i586-poky-linux-ar, but I don't have have i586-poky-linux-ar in my PATH Jan 28 18:22:30 Garibaldi|work: packagegroup-core-sdk pulls ldd in Jan 28 18:22:47 Garibaldi|work: in my image recipe I pull in 'tools-sdk' which pulls in packagegroup-core-sdk :) Jan 28 18:23:05 Garibaldi|work: it breaks my uclibc build Jan 28 18:23:09 I see tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.8.1/i586-poky-linux-ar, but that directory isn't in my PATH Jan 28 18:23:28 Garibaldi|work: and now I proved that ldd is not present on uclibc build (it is present on eglibc image) Jan 28 18:24:17 Xz: does uclibc actually put anything into an ldd package? Jan 28 18:24:18 Xz: ok... I'm not sure what you're asking Jan 28 18:24:47 bluelightning: I don't know that Jan 28 18:25:17 Xz: I'd suggest checking - just having it in PACKAGES is not enough, it needs to actually install the appropriate files and have FILES_ldd somewhere Jan 28 18:25:21 bluelightning: but if it doesn't it would be strange to put 'PACKAGES = "ldd into uclbic-packages.inc, wouldn't it? Jan 28 18:25:33 Xz: it would yes Jan 28 18:25:48 bluelightning: there is FILES_ldd = "${bindir}/ldd" Jan 28 18:26:10 bluelightning: in uclibc-package.inc Jan 28 18:27:26 bluelightning: maybe it should be FILES_ucblic-ldd? Jan 28 18:28:12 if ldd is in packages, FILES_ldd is what it should be defining Jan 28 18:28:14 any have any idea about my $AR not being in the $PATH? Jan 28 18:28:28 bluelightning: SUMMARY_ldd and DESCRIPTION_ldd are missing, maybe that's the case? Jan 28 18:28:40 harmless Jan 28 18:28:49 summary and description are cosmetic Jan 28 18:29:42 kergoth: bluelightning: so basically sth is not clicking here. ldd on uclibc image not present, but present in uclibc-package.inc Jan 28 18:29:59 as bluelightning already said, you'd have to make sure it actually installs the files that FILES_ldd is looking for Jan 28 18:30:00 kergoth: bluelightning: the same thing done in eglibc-package.inc works, so ldd present in eglibc image Jan 28 18:30:51 kergoth: well, I checked the image and ldd is not there, so not installed is the answer. Is that answer for your question? :) Jan 28 18:30:55 Xz: check what the ldd subdirectory in the packages-split subdir of the uclibc workdir has in it Jan 28 18:31:59 bluelightning: have to rebuilt image :| will check in 45min Jan 28 18:32:05 the image is way farther down the line, as bluelightning says, you need to check what actually got installed by the recipe Jan 28 18:45:20 bluelightning: kergoth: ok, so ldd/ subdirectory in uclibc's packages-split is empty :| Jan 28 18:45:38 Xz: right, so it never installed anything Jan 28 18:46:59 bluelightning: so either uclibc-packages.inc should not say 'PACKAGES = "ldd" or ldd/ subdir should contain some stuff Jan 28 18:48:37 /etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: No space left on device Jan 28 18:48:45 that looks scary, does it not? How can I debug what causes it? Jan 28 18:49:24 lpapp: use 'mount' to figure out whre /etc sits first Jan 28 18:49:36 is there a virtual/${TARGET_PREFIX}ar? Jan 28 18:49:52 Xz: yeah, I know which partition is that, but I am not sure why it is getting full. Jan 28 18:49:54 ar is from binutils Jan 28 18:50:12 lpapp: is your partition in RAM or on some Flash/other device? Jan 28 18:50:33 do I need to do something to pull in i586-poky-linux-ar? The $AR variable is set, but the command it's set to isn't in my path Jan 28 18:51:23 Xz: nor flash, ubigs. Jan 28 18:51:25 ubifs* Jan 28 18:51:34 just do a DEPENDS += "binutils-native"? Jan 28 18:52:49 lpapp: if you have df/du tools you can check sizes of stuff on your partition Jan 28 18:52:59 it sounds like you'd wnat the cross one, technically, if you want i586-poky-linux-ar Jan 28 18:53:02 thats cross prefixed Jan 28 18:53:14 virtual/${TARGET_PREFIX}binutils or so Jan 28 18:53:23 lpapp: untill you cannot since that's during boot, right? Jan 28 18:53:46 Xz: I know the size as I set it up in u-boot. Jan 28 18:55:27 lpapp: hard to say anything about that problem. Maybe prepend /etc/rcS.d/S37populate-volatile.sh:line1 with 'strace' to have better understanding of what happens Jan 28 18:55:34 lpapp: assumming you have strace on your image Jan 28 18:56:02 I do not. Jan 28 18:56:29 kergoth: yeah, I'm trying to use $AR in my recipe -- the variable is set but the value it contains isn't in my PATH Jan 28 18:56:35 I'll try what you suggested Jan 28 18:56:45 lpapp: add strace to the image - that's something you can try Jan 28 18:57:33 Xz: I do not know how to read strace... It looked a bit spammy to me all the time. :-) Jan 28 18:59:18 lpapp: so how do you want to debug it? As I understand you know size of your image and you know size of contents and there is some free space on image. However /etc/rcS.d/S37populate-volatile.sh: complains about no free space Jan 28 19:02:02 hmm, the ^{} thing with tags broke for this tag in this repo Jan 28 19:02:06 doing the ls-remote iwthout that works fine Jan 28 19:02:12 does that only work for annotated tags? Jan 28 19:02:40 with annotated tags, the tag is its own object, not just a ref to a commit object.. Jan 28 19:08:59 kergoth: thanks -- that worked Jan 28 19:09:47 np Jan 28 19:10:19 Garibaldi|work: that said, recipes default to pulling in the cross toolchain, so its a bit odd you'd need to do so manually, unless you're inhibiting hte default deps Jan 28 19:10:59 yeah, I figured so. I'm not doing anything (that I know of) to inhibit the defaults though Jan 28 19:11:37 name of the package (including -native or -nativesdk) can prevent it.... also adding INHIBIT... something (forget offhand) in the recipe can.. Jan 28 19:12:03 yeah, I'm doing neither of those Jan 28 19:13:06 I'll take a look at what I have and double check that I didn't fubar something along the way Jan 28 19:16:39 So I build my image using EXTRA_IMAGE_FEATURES = "debug-tweaks ssh-server-openssh dev-pkgs dbg-pkgs tools-sdk tools-debug " Jan 28 19:17:08 However, I cannot find gcc or any of the other programs that some of these packages are supposed to come with...am I missing something here? Jan 28 19:18:14 to start with, make sure nothing is overriding that, see what its really set to. bitbake -e yourimage|grep IMAGE_FEATURES= Jan 28 19:18:30 kergoth, thanks will try that right now Jan 28 19:20:37 SDKIMAGE_FEATURES="dev-pkgs dbg-pkgs" Jan 28 19:20:37 EXTRA_IMAGE_FEATURES="debug-tweaks ssh-server-openssh dev-pkgs dbg-pkgs tools-sdk tools-debug tools-testapps nfs-server tools-debug tools-profile " Jan 28 19:20:37 IMAGE_FEATURES="debug-tweaks tools-sdk dev-pkgs tools-testapps splash dbg-pkgs tools-profile nfs-server tools-debug ssh-server-openssh" Jan 28 19:22:06 kergoth, seems that it should be okay no? Jan 28 19:23:02 indeed. might want to look at the packages installed in the image. there's a package list in buildhistory Jan 28 19:23:09 also the manifests Jan 28 19:27:06 kergoth, I don't see a tmp/buildhistory directoy...I do see a tmp/buildstats but didn't find any package information in that folder Jan 28 19:27:15 * newell is checking manifests Jan 28 19:30:16 will rebuild with buildhistory enabled Jan 28 22:20:53 kergoth, so I rebuilt my image with buildhistory enabled and I am looking at the installed-packages.txt for my image and I see gcc in there but I cannot find it at all on the actual image when I boot up the board. Jan 28 22:21:07 Any hints on why this could be like this? Jan 28 22:21:27 Its weird...b/c I remember that I used to have gcc in the PATH and installed on earlier builds Jan 28 22:21:31 * newell scratches his head Jan 28 23:49:15 sounds like you hvae some other problem going on, perhaps flashing the wrong image or so :) Jan 29 01:17:36 gah, qemu-native just hit an ICE in my host compiler Jan 29 01:17:38 * kergoth grumbles Jan 29 01:40:10 kergoth: ice in AZ? :) Jan 29 01:42:26 no just South Carolina Jan 29 01:47:31 you think weather is funny *now*... just wait a couple years... Jan 29 01:48:16 and with that, it's time to bail Jan 29 02:39:34 mranostay: we're enjoying mid 70s around here Jan 29 02:39:38 best time of the year, makes summer worth it **** ENDING LOGGING AT Wed Jan 29 02:59:58 2014