**** BEGIN LOGGING AT Thu Aug 25 02:59:58 2016 Aug 25 04:46:38 Hi, I've got a question regarding a QA Error message during the package stage of a recipe I've added Aug 25 04:48:18 The cause of the error I know: the recipe working dir package folder has an extra directory in it that isn't listed in the FILES_${PN} list in the recipe Aug 25 04:49:22 the problem is I don't want the directory, or even know why that directory is in there in the first place when it isn't in the recipe workdir image directory Aug 25 04:51:14 ie: build/tmp/work////image contains only etc, usr and var Aug 25 04:51:45 but build/tmp/work////package contains only etc, usr, var and run Aug 25 04:54:27 the recipe has a do_install_append that runs "install -d ${D}${localstatedir}/run/app" to create a run state directory in the image (which it does), and this is the only way I can see it accidentally creating the /run/app directory in the package dir, ie if localstatedir is empty Aug 25 04:55:26 however, it can't be, because it creates to /var/run/app, as expected Aug 25 04:57:08 Furthermore, if I change the install to be "install -d ${D}${localstatedir}/something_silly/app", I get the /var/something_silly/app in both the image and package locations, but neither /run/app or /something_silly/app in the package dir Aug 25 04:59:03 any suggestions on what might be causing this extra directory in the package directory? None of the scripts in the recipe temp directory explicitly create it, and the logs don't provide enough information to see where it came from Aug 25 07:16:46 hi ppl, I like to run my yocto image in qemu. The target system is a cortex-a8. Now I have zImage, zImage-am335x-phycore-rdk.dtb and core-image-full-cmdline-phycore-am335x-1-20160803115252.rootfs.ext4 files. But all that qemu shows me is a black window. Aug 25 07:17:21 qemu-system-arm -cpu cortex-a8 -kernel zImage -dtb zImage-am335x-phycore-rdk.dtb -M versatilepb -hda core-image-full-cmdline-phycore-am335x-1-20160803115252.rootfs.ext4 -no-reboot -show-cursor -m 128 --append "root=/dev/sda rw console=ttyAMA0,115200 mem=128M highres=off rootfstype=ext4" Aug 25 07:17:29 sorry for the spam :-) Aug 25 07:41:14 mwarning: usually qemu does not git the specific peripheral set etc. to run machine specific images. it might be easier to just rebuild your image for a qemuarm/qemux86/qemuXXX machine. Aug 25 07:54:36 so I'm trying do build qtdeclarative, but it fails because it generates a Makefile for qmldevtools that contains /usr/lib/libQt5Bootstrap.lib (i.e. wrong $prefix or path in general) as a target dependency. Aug 25 07:55:23 s/.lib/.la Aug 25 08:01:12 the makefile is generated during compilation stage using the corresponding .pro file and subsequently make'd. So there is no sed'ing inbetween :-/ Aug 25 08:03:42 LetoThe2nd: thanks, but how do I rebuild my image for qemuarm? I thought that the image is already ready. The sdcard image works on our arm hardware so far. Aug 25 08:04:28 mwarning: select MACHINE = "qemuarm" in local.conf Aug 25 08:04:40 ah, I did not know that. Aug 25 08:04:47 I will try that Aug 25 08:27:31 hi guys Aug 25 08:40:52 Hey guys, we just realised something, why not change the name yocto 10^-24 to 10^-42, yocto is the answere to everything :D Aug 25 08:44:16 not sure we have the power to do that :) Aug 25 08:45:20 rburton: actually we would need power^-16 Aug 25 08:48:06 To bad :P Aug 25 08:48:14 we should join the comittee that decided this Aug 25 09:02:19 is there some way to have interfaces name like eth0 eth1...? depending on the hardware, interfaces name can change. It seems that an udev rule is written by /lib/udev/write_net_rules in most of the linux distributions. how can i do the same in my yocto distribution? Aug 25 09:04:33 s65b44: you can just install additional rule file, no problem Aug 25 09:06:28 true, but i mean, it looks based on the mac address, so i have to know, in advance, the mac addresses of each of the physical interfaces Aug 25 09:10:01 s65b44: well thats a convention that might be used in that rule you mentioned. but you're free to implement another scheme as you please - plus, there are other approaches these days which offer other name generation schemes. Aug 25 09:10:48 s65b44: see for example https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Aug 25 09:12:48 LetoThe2nd: thanks, i'll take a look Aug 25 09:28:13 How can I change the default compilation optimization level of all recpies, at the moment everywhere is '-O2' but, I really don't know, since my update 3.18 to 4.1 everything on my board is slow? Aug 25 09:37:43 HyP3r: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-FULL_OPTIMIZATION Aug 25 09:38:08 see http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-SELECTED_OPTIMIZATION too Aug 25 09:38:50 what i did was to search for "-O2" in the output of 'bitbake -e' btw, and seeing what variables it showed up in :) Aug 25 09:39:17 would be nice if those glossary entries linked to each other Aug 25 10:02:33 Ulfalizer: thank you for that information :) Aug 25 10:03:29 np Aug 25 10:04:49 HyP3r: 'bitbake -e' is a great debugging tool. the latest version of the reference manual has a fleshed-out section on it: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#usingpoky-debugging-viewing-variable-values :) Aug 25 10:15:37 Ulfalizer: I have this Refrenece Manual all the time open, but I was dumb enough to _not_ search for Optimization Aug 25 11:31:23 Bitbake tells me TMPDIR can't be on NFS.... Is that because of file locking concerns? (Supposedly locking works on *some* NFS implementations?) Aug 25 11:38:31 belen: i have a question regarding toaster, again :) Aug 25 11:38:51 i made a custom image recipe Aug 25 11:39:06 i can build it just fine with toaster but Aug 25 11:40:05 when i open the corresponding build page, i do not see bootloader or kernel images under 'Other Artifacts' Aug 25 11:40:32 and when i build the standard image 'core-image-sato' then i can see them Aug 25 11:40:41 a feature or a bug ? Aug 25 11:41:37 or i'm doing something wrong Aug 25 11:43:55 gunnarx: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5442 Aug 25 11:43:56 Bug 5442: enhancement, Medium, 1.6 M1, liezhi.yang, RESOLVED FIXED, sanity.bbclass: check TMPDIR is not on nfs Aug 25 11:47:57 iskander_work: definitely not a feature. It is probably a bug. It could be because a previous image has created bootloader and kernel images that are valid for your new image as well, so the build system will not create them from scratch, so toaster is not picking them up. Again, we have fixed it for the next release. Again, that doesn't help you :( Aug 25 11:50:34 hmm, any idea where in source i should look for this bug ? Aug 25 11:51:49 or maybe which git commit fixed it Aug 25 12:09:53 Hey there I need help Aug 25 12:10:01 Is there anybody that can help me ? Aug 25 12:11:03 ilkerdagli: asking the actual question you have is pretty much the only way to find out Aug 25 12:11:19 When I do, bitbake meta-toolchain-qt5 its installing the qt 5.5 version, But i need qt 5.6 or greater Aug 25 12:21:10 iskander: OK, thanks for the bug link. It says "Only specific directories are expected to work on nfs...DOWNLOADS and SSTATE". Is that correct or a typo? Or is it that DOWNLOADS and SSTATE are the only ones that are *NOT* expected to work on NFS? Aug 25 12:37:51 hi Aug 25 12:42:38 I need to build and install meta-toolchain-qt5 with version 5.6 or greater, In my enviroment when I do bitbake meta-toolchain-qt5 it builts the 5.5 version. How can I do that Aug 25 12:49:11 iskander_work: let me see Aug 25 12:50:41 belen: i found a bugzilla case https://bugzilla.yoctoproject.org/show_bug.cgi?id=10107 Aug 25 12:50:42 Bug 10107: normal, Medium, 2.2 M3, elliot.smith, IN PROGRESS REVIEW , Kernel artifacts not shown Aug 25 12:50:50 but i'm not sure it is the same problem Aug 25 12:51:07 it applies to a newer version Aug 25 12:51:45 iskander_work: yes, that's definitely part of the work. There is one more series for artifact fixes. That's what I trying to find Aug 25 12:52:19 iskander_work: they probably won't apply to krogoth though, but at least they might give you some indication on how to fix things there Aug 25 12:52:38 thanks Aug 25 13:12:09 iskander_work: I think I found it. I believe this was the patch series that solved most of the artifacts issues, including the one you are seeing with the kernel files http://lists.openembedded.org/pipermail/bitbake-devel/2016-July/007679.html Aug 25 14:19:02 belen: thank you, i'll check it out and report back Aug 25 14:44:16 Hello. Is there something special about package name overrides? Aug 25 14:44:29 That is, do they have special semantics like _append or _remove Aug 25 14:44:40 no more special than class or machine overrides Aug 25 14:45:15 So bitbake has no special understanding of them .. it's just an informal namespace mechanism by OpenEmbedded layers; right? Aug 25 14:46:06 overrides are handled by bitbake Aug 25 14:47:55 Hmm .. the bitbake user manuals does not mention them at all; except this paragrpah: "As with all package-controlling variables, you must always use the RDEPENDS variable in conjunction with a package name override" Aug 25 14:48:14 And that's the only mention of it .. no talk about special handling it all .. which is confusing me a bit :-( Aug 25 14:48:38 there is no special handling in bitbake. the packaging code adds the package name to OVERRIDES, and thenb itbake handles it like every other override. Aug 25 14:48:55 well, i take that back, rdepends is handled by bitbake, but not through an override :) Aug 25 14:52:08 ah, that was it .. OVERRIDES .. Aug 25 14:52:37 great .. now I can find all the relevant parts in the docs :D Aug 25 14:52:49 rburton, kergoth, Thanks a lot! Aug 25 15:07:57 what is the best way to install man pages with a recipe? Aug 25 15:08:50 best way is that the "make install" installs them for you Aug 25 15:08:59 otherwise write a do_install_append and install them yourself Aug 25 15:28:42 * darwish wonders why mainstream distributions don't use bitbake/yocto for building their distros (instead of inventing their own mechanisms) Aug 25 15:30:28 darwish: that would be so nice, because if they would to this with yocto we have for everything a recpie Aug 25 15:31:15 And Developer of Software would take a close look at there Librarys and Tools if they are compatible to Yocto. Aug 25 15:31:33 At the moment you have to patch every configure.ac script to fix path problems :S Aug 25 15:32:29 It's well documented in the industry how solutions created originally for the 'low-end' can dominate after a while .. so there's hope :D Aug 25 15:33:09 That's the story of Linux itself, and x86 in 386/486 era, and ARM afterwards :D Aug 25 15:34:08 Yeah today Linux gets 25 :3 Aug 25 15:34:28 simple answer.. people would rather not have to cross compile Aug 25 15:34:48 darwish: the OE/YP approach is to cross compile everything Aug 25 15:35:22 this is great in that lots more targets, optimizations, and better 'reproducibity'.. but it causes a lot of people to go outside of their comfort zones and understand some of the ramifications of cross compiling Aug 25 15:36:06 fray, while building x86 distributions, they build their own GCC/toolchain anyway not to get 'polluted' with the hosting system Aug 25 15:36:21 and use that for compiling the entire distribution .. Aug 25 15:36:32 So that's not very foreign from the concept of cross compiling .. I guess .. Aug 25 15:36:38 but the reality is they are polluted with the host system.. Aug 25 15:37:05 they are kind of doing cross compilation, but not really.. since they expect to be able to compile and run at the same time Aug 25 15:37:35 the second you have to 'run' something you built as part of the compilation step -- the second you have introduced a potential host pollution Aug 25 15:37:47 yeah, correct .. Aug 25 15:37:49 tick-tick-boom Aug 25 15:37:57 it very often happens on Fedora, debian and others that they can only build the distro on the distro.. Aug 25 15:38:17 some of the tools have to be built with the tool Aug 25 15:38:19 (maven) Aug 25 15:38:20 they are very good at showing things are reproducible (out of necessity)... but they have no real bootstrap process other then use the tool Aug 25 15:39:27 moto-timo, wow :D Aug 25 15:40:58 you have to build maven three times if you want the current version Aug 25 15:41:05 usual way on a desktop distro to prove reproducible is.. build once, use that build to build again -- check if the output is the same -- if it's not build time three.. check again.. if it's not you have a bug.. if it is.. you are "good" Aug 25 15:41:15 moto-timo -- jynx Aug 25 15:41:21 lol Aug 25 15:41:31 PITA Aug 25 15:42:00 I much prefer cross compilation.. boostrap and build once.. want reproducible.. do it again and show it's the same.. Aug 25 15:42:08 heck yeah Aug 25 15:42:25 but just because you've bootstrapped means it is expected to be baring a bug... once that is usually fairly easy to find.. (not always fix) ;) Aug 25 15:46:17 darwish: "_" at the end of a name only does something special if "" appears in OVERRIDES or if is something magical like "append" Aug 25 15:46:59 people often call all "_foo" suffixes overrides though Aug 25 15:48:37 some "overrides" (in that sense) are handled manually inside anonymous pythons (https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#anonymous-python-functions) Aug 25 15:48:54 in e.g. base.bbclass Aug 25 15:50:37 https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html#anonymous-python-functions is a better link. has more detail. Aug 25 15:59:58 ...or handled in the default versions of tasks. for example, the default version of do_package (from meta/classes/package.bbclass, which is inherited by base.bbclass, which is inherited by all recipes) goes through the PACKAGES and FILES_* variables manually. it's not built into bitbake itself. Aug 25 16:19:36 Ulfalizer, a small question then; when I do 'bitbake -e mesa | grep OVERRIDS', I see "pn-mesa" as the package override value Aug 25 16:19:45 not just mesa .. Aug 25 16:20:26 darwish: it's because "pn-${PN}" is the string that appears in (the default value of) OVERRIDES Aug 25 16:20:43 the pn- override isn't a package name override, it's a recipe name override Aug 25 16:20:49 if it was just ${PN}, then _mesa would work as an override. that would be more likely to clash with other stuff though. Aug 25 16:21:09 yup .. so when I say FILES_{PN} = "xxx" .. there's no override named plain "mesa" Aug 25 16:21:09 * Ulfalizer didn't even see the "package" part Aug 25 16:21:25 darwish: yeah, that's one place where it would clash Aug 25 16:23:03 Ulfalizer, kergoth .. bitbake docs state that for YYY_XXX to work, OVERRIDES must have the "XXX" string .. so I wonder how FILES_mesa = "" and FILES_mesa-dev work even though there's no plain "mesa" in OVERRIDES Aug 25 16:23:18 * darwish hopes he's not complicating things for himself .. Aug 25 16:23:44 [08:59:58] ...or handled in the default versions of tasks. for example, the default version of do_package (from meta/classes/package.bbclass, which is inherited by base.bbclass, which is inherited by all recipes) goes through the PACKAGES and FILES_* variables manually. it's not built into bitbake itself. Aug 25 16:23:45 darwish: the _mesa part isn't handled through the OVERRIDES mechanism there. do_package takes care of it itself. Aug 25 16:24:04 it just happens to use the same "syntax" Aug 25 16:24:06 ah .. I see Aug 25 16:25:09 So for it FILES_libc is just a full name variable without any overrides; excellent Aug 25 16:25:37 Ulfalizer, kergoth .. I send my gratitude again .. things begin to make lot more sense :D Aug 25 16:26:01 yeah, it doesn't use overrides in the OVERRIDES sense at least. people often call the "_libc" part an override even there though. Aug 25 16:26:09 it can be a bit confusing Aug 25 16:26:25 np Aug 25 16:37:01 anyone using systemd-networkd and updates his hostname from dhcp? Aug 25 17:50:59 kergoth: I was explaining recipe vs package difference to some one new to OE and he was holding his head I dont know if he was feeling enligtened or mad Aug 25 17:51:29 fact that PN can also be one of possible output package adds to confusion Aug 25 18:01:35 Is it necessary to adjust BBFILE_COLLECTIONS when creating a layer.conf ? Aug 25 18:02:22 if you don't, it won't be a functional layer from bitbake's perspetive, so yes Aug 25 18:03:08 I was looking at an example layer.conf and wasn't sure how many of the variables were necessary, since I basically want to create an empty recipe. Aug 25 18:03:09 Thanks Aug 25 18:35:33 hi guys, I'm enabling systemd on my image following the tutorial: http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#selecting-an-initialization-manager, but the package systemd-serialgetty is not installed in the image Aug 25 18:36:19 I read the systemd recipe and the systemd-serialgetty is on the rrecommended packages Aug 25 18:36:49 What i've missed Aug 25 19:31:13 igor2: are you setting PACKAGECONFIG to have 'serial-getty-generator' in systemd ? Aug 25 19:35:02 yes, i just figure out what was wrong Aug 25 19:35:28 it was because my distro was setting SERIAL_CONSOLE = "" Aug 25 19:35:53 thanks khem Aug 25 19:39:47 igor2: Kudos for describing the problem for others and the channel log Aug 25 19:39:57 zeddii: I have to add https://gist.github.com/kraj/8c59659aae97141ed1803d3758767744 for drm backend to work effectively with virtualbox as a new fragment on top of linux-yocto would you mind including this in default kernel config if its not already ? Aug 25 19:40:08 The worst is when someone has an obscure problem on the internet, and then you see them finish the thread with "nvm figured it out". No explanation. :D Aug 25 19:52:57 Is there any guide for which elements in layer.conf or a particular recipe are required? Aug 25 19:53:31 For example, I notice .bb files with 'HOMEPAGE = "whatever"' If I don't have a homepage, do I need to even set the variable? Aug 25 19:54:02 hweaving: only thing that's strictly required is LICENSE i think. for quick testing, you can set it to "CLOSED". Aug 25 19:54:42 depending on the output package format, you might end up with some default values for "required" metadata fields i guess, e.g. if the format requires a SUMMARY Aug 25 19:57:24 (recipes build packages. images are generated from those packages. in case you haven't gotten to that point yet.) Aug 25 19:57:41 package in the rpm/deb/ipk sense Aug 25 20:01:50 Ulfalizer: Thanks! I'm guessing "PR" is "Package Revision" Aug 25 20:02:22 Ulfalizer: For license, I'm hoping I can use a common license (MIT) so I don't have to worry about the checksum Aug 25 20:03:06 yup, PR is package revision. the description was fleshed out a bit recently: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-PR Aug 25 20:03:31 Ulfalizer: I literally just searched that webpage for "PR =" and didn't notice the variables section, my bad Aug 25 20:03:36 hweaving: the checksum is to verify that the license doesn't change, so if you want to do that, you'd still need a checksum Aug 25 20:04:08 i'm bored by licensing stuff, so i'm probably not the right guy to give advice there though :) Aug 25 20:04:28 important, but oh so boring to me for some reason :/ Aug 25 20:04:52 hweaving: no problem. there's a lot of manual. :S Aug 25 20:05:02 Ulfalizer: I can understand, it's busywork to grab a md5 sum, write the lines, etc. Aug 25 20:06:15 that and politics in general :P Aug 25 20:07:23 Well if you're running a business, licenses are sadly important (as mind-numbing as they are to try to read) Aug 25 20:07:36 So that you don't break the law or cheat someone out of what they create Aug 25 20:07:41 Now CHOOSING a license, that gets more political :p Aug 25 20:08:49 important and boring :) Aug 25 20:09:20 like accounting Aug 25 20:09:23 not breaking any licenses btw, so not that ;) Aug 25 20:09:43 yup Aug 25 20:10:07 politics-processing code *shudder* Aug 25 20:22:17 If I'm using a recipe to install arbitrary files (e.g. HTML webpage files) onto the root filesystem, which is the proper paradigm? Aug 25 20:22:39 1. Including these files in FILES_${PN} += "whatever" Aug 25 20:22:46 2. Using do_install_append to manually copy the files Aug 25 20:22:48 3. Other Aug 25 20:23:06 If one of these approaches allows bitbake to detect the files changed and recopy them, that would be ideal Aug 25 20:23:57 hweaving: how do you store the html files? Aug 25 20:24:23 Ulfalizer: Under my own meta-blabla layer Aug 25 20:24:34 As plaintext files in a directory structure Aug 25 20:25:20 i use 1 and 2 as needed ;-) Aug 25 20:27:05 if you fetch those files to ${WORKDIR} with SRC_URI = "file://... ..." first, then yocto might take their contents into account when calculating task checksums (which determine when tasks get rerun). i'm not actually sure though. Aug 25 20:27:43 things are generally smoother if you store contents in some external repository Aug 25 20:28:30 rob_w: I want the checksums taken into account if possible, yes Aug 25 20:28:52 hweaving: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#source-fetching-dev-environment Aug 25 20:29:07 see the first note. that's what i thought. Aug 25 20:29:07 I have an offline build environment so I'm not fetching from anything besides the yocto non-build directories Aug 25 20:29:30 Ulfalizer: Thanks, I'll experiment using file:// Aug 25 20:30:28 hmm never though about that .. need to check that too ;-) Aug 25 20:30:54 i guess that's one good reason to still use SRC_URI = "" to fetch local files instead of referencing them directly in e.g. do_install. if you do the latter, then do_install won't get rerun if the files change. Aug 25 20:31:16 *SRC_URI = "..." Aug 25 20:31:40 Ulfalizer: I think I was warned about that with things like post-install scripts. e.g. if you manually run the recipe it works, but bitbake won't detect it automatically without the checksum stuff. Aug 25 20:34:52 pretty obvious that SRC_URI file://... stuff is checksummed in retrospect. otherwise changing patch files wouldn't retrigger builds either. Aug 25 20:39:31 Ulfalizer: compliance is quite important for OSS based products and license checksum is one part of helping with that workflow Aug 25 20:39:42 I'm guessing there's no way to use wildcards for file:// in SRC_URI? Aug 25 20:39:52 Or mass-checksum a directory? Aug 25 20:39:59 hweaving: whats your usecase ? Aug 25 20:40:12 khem: yeah, it's important stuff. not saying anything else. Aug 25 20:40:21 khem: Offline build environment, local root filesystem overlay in a certain directory, I want those files copied on top of the rootfs image before deployment Aug 25 20:40:46 khem: This means I either way the copy to happen EVERY time bitbake runs, or I want the copy to run when any of the overlay files change Aug 25 20:40:52 *I either want Aug 25 20:41:14 I'm creating my own recipe to do the copy / install since I was advised against post-install scripts with yocto Aug 25 20:41:16 hweaving: explain the overlay contents Aug 25 20:41:29 are you overwriting the content coming from base ? Aug 25 20:41:44 khem: HTTPS certs, webpage files, other vendor-specific scripts / files Aug 25 20:42:03 OK, that seems usual case. Aug 25 20:42:09 khem: I just want to add extra files to the rootfs, not overwrite (as far as I'm aware right now) Aug 25 20:42:15 I assume you are putting all this into one package Aug 25 20:42:23 khem: Yes, from a single recipe Aug 25 20:42:40 dont worry image builder will barf if there are duplicate providers Aug 25 20:42:48 OK Aug 25 20:42:55 so you really have two options Aug 25 20:43:22 In theory I could zip up my rootfs overlay and use that as a source, and that would get checksummed. But, that makes my development cycle longer because I have to run a re-zip command every time I change a file Aug 25 20:43:46 commit your sources into recipe metadata along with a makefile and then use a recipe to drive this makefile to do the usual steps Aug 25 20:44:06 the one you describe is the second and good option Aug 25 20:44:22 yes you have to and you should Aug 25 20:44:33 otherwise how do you track your changes Aug 25 20:45:54 I would suggest to create a SCM repo for all your files Aug 25 20:46:03 and then commit changes to that repo Aug 25 20:46:20 and fetch/package it using bitbake recipe like other recipes Aug 25 20:46:49 I would suggest to manually bump the SRCREV in recipe so you have a controlled change management Aug 25 20:48:18 would the makefile-in-metadata approach even work? yocto won't know that the makefile in turn depends on the source files. Aug 25 20:48:47 * Ulfalizer thinks repo is the nicest solution too, followed by tarball in metadata Aug 25 20:49:08 khem: Thanks for the detailed thoughts, you raise excellent points Aug 25 20:49:31 I was thinking about making the local testing cycle more efficient rather than the eventual repo setup Aug 25 20:49:45 As long as I can use a local offline git repo then that could work Aug 25 20:49:55 Ulfalizer: it still will need the fetch stuff Aug 25 20:50:07 its just that sources are combined with yocto Aug 25 20:50:08 I don't fully understand how SRCREV works right now Aug 25 20:50:31 hweaving: you point the recipe to a given version to use when fetching from SCMs Aug 25 20:50:42 khem: yeah, that'd work. thought you meant just fetching the makefile, to avoid the "wildcard" problem. Aug 25 20:50:48 khem: So if I lock the SRCREV variable to a specific revision, then do more commits to the local repo, only the referenced one will get pulled Aug 25 20:50:59 e.g. if its git then you say SRC_URI = "git://...." SRCREV = "sha-id" Aug 25 20:51:34 that informs bitbake git fetcher that I need to pick up the source from location x and head should point to sha-id Aug 25 20:51:52 Ulfalizer: yes thats sneaky but can be done. Aug 25 20:52:07 although, -2 for that approach Aug 25 20:52:14 20 points from Gryffindor Aug 25 20:52:44 not cleanly though. would need to take the content of the other files into account too. Aug 25 20:52:47 hweaving: read through http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#new-recipe-fetching-code Aug 25 20:52:53 it might help a bit Aug 25 20:53:04 in getting the fetching basics in OE Aug 25 20:53:36 khem: Working on it, thanks Aug 25 20:53:53 khem: Wouldn't you need to use the "ref" option in your SRC_URI line to force only rev = SRCREV? Aug 25 20:54:04 per http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-SRC_URI Aug 25 20:54:59 hweaving: there are defaults which will be a fallback Aug 25 20:55:31 If I'm trying to lock a certain revision in, I'd rather make it explicit I Think Aug 25 20:55:32 I think Aug 25 20:56:55 hweaving: fetching is documented here https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#idm1100848 Aug 25 20:56:57 in detail Aug 25 20:57:29 hweaving: "locking" to a specific revision is the standard approach. knowing that the build output won't change behind your back because someone pushed to a repo is nice. Aug 25 20:57:34 if you are dealing wth git see this https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#git-fetcher Aug 25 20:58:16 you can also set SRCREV = "${AUTOREV}" if you are the only developer in company :) Aug 25 20:58:20 if you really really want to always get the latest revision, look up AUTOREV: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-AUTOREV Aug 25 20:58:55 although autorev will always poke at your repos whenrver you build so its not good for offline builds Aug 25 20:59:07 * hweaving opens 200 tabs Aug 25 20:59:29 Thanks for the pointers Aug 25 21:03:19 khem: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-SRC_URI does not seem to mention the "protocol=" feature Aug 25 21:03:39 I'm currently guessing that lets you manually override the processor, since an example showed protocol=git Aug 25 21:04:28 khem: Nevermind, found it under 4.3.5 for the Git Fetcher specifically Aug 25 21:07:13 I'm confused by the general options in http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-SRC_URI vs. the fetcher-specific options in https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#git-fetcher Aug 25 21:07:43 With git:// you can use "rev=", but wouldn't this conflict with the SRC_URI "rev" option? Aug 25 21:16:15 hweaving: IIRC SRCREV will override ti Aug 25 21:16:16 it Aug 25 21:16:35 khem: Ah, I didn't see that in the documents Aug 25 21:16:55 "mindate" etc. are also mentioned, which I assume would work with git://, but I haven't looked up an example yet Aug 25 21:17:39 looks like rev= and SRCREV have to agree if you specify both. see srcrev_internal_helper() in lib/bb/fetch2/__init__.py. Aug 25 21:18:07 those options are fetcher specific too mindate etc. are good for cvs Aug 25 21:18:11 yuck cvs Aug 25 21:18:37 hweaving: the documentation maintainer is a friendly guy if you want to submit stuff btw: https://bugzilla.yoctoproject.org/enter_bug.cgi?classification=Documentation Aug 25 21:18:55 there's definitely some holes in the docs from time to time :) Aug 25 21:20:31 Ulfalizer: I'm not meaning to criticize, just trying to understand Aug 25 21:21:13 I'll just use SRCREV alone with the understanding that the default behavior is to only pull the matching revision :) Aug 25 21:21:14 hweaving: i wasn't meaning to criticize either. it was a honest tip if you ever feel like doing it. i've submitted lots of stuff. Aug 25 21:21:18 Thanks Aug 25 23:04:16 git is starting to make sense Aug 25 23:04:19 This is a really scaring feeling :( Aug 25 23:07:52 https://xkcd.com/1597/ Aug 25 23:11:45 That is far too accurate Aug 25 23:23:34 So true... Aug 25 23:27:32 I can't find ".=" in the reference manual Aug 25 23:27:41 Does it mean to replace a variable, or modify, or append? Aug 25 23:30:56 hweaving: it's in the bitbake user manual: https://www.yoctoproject.org/docs/2.2/bitbake-user-manual/bitbake-user-manual.html Aug 25 23:32:13 Ulfalizer: Your name is so hard to tab-complete :( I just found it, thanks Aug 25 23:32:20 Append without spaces Aug 25 23:32:58 why is it hard to tab-complete? :/ Aug 25 23:33:23 Ulfalize is my alter ego :P Aug 25 23:41:19 Ulfalizer: Because first it finds "ulf", then "Ufalize", and I have to type the entire thing or it won't complete your name Aug 25 23:41:24 My client doesn't cycle through every option Aug 25 23:42:59 works in irssi at least Aug 25 23:43:16 maybe it doesn't like that Ulfalize is a prefix of Ulfalizer :| Aug 25 23:43:18 How do licenses work with Yocto and generating embedded images? As I understand, for MIT-licensed software, the COPYING file must be included even with binary distributions Aug 25 23:43:28 Ulfalizer: Precisely Aug 25 23:43:48 However, I don't see licenses copied into the embedded filesystem Aug 25 23:48:26 hweaving: that's because you're expected to distribute them alongside your image Aug 25 23:48:44 hweaving: see http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle Aug 25 23:49:12 I see there's a mega manual to go along with the user manual and the reference, thanks :D Aug 25 23:49:47 mega-manual is a concatenation of almost all manuals, I usually just use it if I know something is documented and want to search for it Aug 25 23:51:22 Megaman ual Aug 26 00:24:53 I added a new recipe that an existing recipe depends on. However, bitbake fails, saying the existing recipe "is not going to be installed" Aug 26 00:25:29 The log is unhelpful. What might cause this problem with my recipe that's being depended on? I don't have a do_install(), do_install_append(), or pkg_postinst_${PN} () section, for example. Aug 26 00:26:01 I also haven't set the FILES_${PN} variable in my recipe. Aug 26 00:26:38 hweaving: what's the exact error message? Aug 26 00:27:57 Ulfalizer: It's huge. Running again to grab it. Aug 26 00:28:46 "Some packages could not be installed. This may mean that you have requested an impossible situation..." Aug 26 00:29:04 "The following packages have unmet dependencies" Aug 26 00:29:17 " packagegroup-whatever : Depends: EXISTING-RECIPE but it is not going to be installed" Aug 26 00:30:45 that error seems to be from apt. you must be generating deb packages. not sure what's going on though. Aug 26 00:31:03 the error might be from when those packages are installed to build the image Aug 26 00:32:38 Yep, I'm using deb packages Aug 26 00:33:02 "bitbake -e" doesn't even mention EXISTING-RECIPE. I'm getting dinner and will be back later Aug 26 00:33:22 I did verify RPROVIDES / PROVIDES weren't the issue Aug 26 00:33:53 i'm going to bed soon. would prolly help others if you paste the recipe though. Aug 26 00:34:24 if you're using RPROVIDES already after less than a week, you might be doing something overly complicated :) Aug 26 00:36:35 bitbake -e might tell you more btw. see http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#usingpoky-debugging-viewing-variable-values. Aug 26 01:49:56 I still don't have it working, but I just realized Aug 26 01:50:14 khem: after fighting all day to create a recipe and package, I realized that the version control system is going to make testing small changes to images difficult :p Aug 26 01:50:35 Since every change will need to be committed to master, and SRCREV updated with the full hash Aug 26 01:50:52 Ulfalize: I'm currently investigating bitbake -e for the recipe Aug 26 01:51:25 It's so massive I have no idea where to look though, 17000 lines. All I know is that it's causing a depending package not to build, possibly something to do with apt. Aug 26 02:26:13 Here's one possible clue: I'm seeing other recipes generate three packages Aug 26 02:26:29 WHATEVER-dbg_version, WHATEVER-dev_version, and WHATEVER-version Aug 26 02:26:43 Mine only generates the "dbg" and "dev" packages, not the other one. Aug 26 02:39:33 Probably because I didn't have FILES_${PN} set. Working on that now Aug 26 02:53:51 I solved it! I'm not sure if FILES_${PN} was even needed, but using do_install() to copy files actually created the package successfully **** ENDING LOGGING AT Fri Aug 26 02:59:59 2016