**** BEGIN LOGGING AT Tue Apr 19 03:00:00 2016 Apr 19 07:09:05 good morning Apr 19 08:34:31 if I've got a recipe that after an append has two git:// src uri's, how do I stop it trying to apply the same src rev to both? Apr 19 08:36:10 http://git.projects.genivi.org/?p=meta-genivi-demo.git;a=blob;f=meta-genivi-demo/recipes-multimedia/audiomanager/audiomanager_7.0.bbappend;h=6e4ee6ee21da4ee1c01e33ad71264a542b65f62b;hb=HEAD Apr 19 08:36:51 the parents recipe has a git src uri, with a hard src rev. It looks like bitbake is also trying to parse it against the one in the append, as it says the tag doesn't match the ref Apr 19 08:52:08 CTtpollard: with multiple fetched SRC_URI components you should name them (see e.g. gstreamer1.0_git.bb for example)... Apr 19 08:52:35 CTtpollard: not sure how that works if only your bbappended repo is named but I'd hope that would still work without modifying the original one Apr 19 08:53:31 jku: hmm that may take quite a lot of rework Apr 19 08:54:02 a recent change in the upstream recipe has caused this, it originally also used pv tags instead of srcrev Apr 19 10:51:28 Hello. Does anyone know what exactly needs to be done to fix the "--should-not-have-used-/usr/bin/gpgme-config" error message? It has been asked on mailing list, but I do not understand the answer Apr 19 10:51:59 I have a recipe that depends on gpgme, but configure fails for my recipe with the above message Apr 19 10:52:14 gatisp: basically, switch to using pkg-config instead of gpgme-config Apr 19 10:53:30 bluelightning, in my recipe? Apr 19 10:53:59 gatisp: well, you'll probably need to patch the script (presumably the configure script) that is calling gpgme-config Apr 19 10:54:54 hm, I think it is autotools that generates call to what, but I will need to check Apr 19 10:55:03 *to that Apr 19 11:08:43 is there a way to use a bb append to mask / remove a value from the recipes src uri? Apr 19 11:08:58 SRC_URI_remove Apr 19 11:10:06 rburton: ty Apr 19 11:13:35 bluelightning, for me it seems that gpgme depends on gpgme-config to find the required binaries and should not be disabled with binconfig-disabled Apr 19 11:13:48 bluelightning, see https://github.com/ostreedev/ostree/blob/master/configure.ac#L103 Apr 19 11:14:08 these few lines of AC code generate a lot of calls to gpgme-config Apr 19 11:14:25 I don't see how that could be avoided Apr 19 11:14:30 rburton: currently to remove the recipes srcrev i'm using "INVALID", is there anything cleaner than that? Apr 19 11:18:32 ""? Apr 19 11:19:01 gatisp: erm, it's using PKG_CHECK_MODULES, so it should be calling pkg-config already ... ? Apr 19 11:19:28 it uses a macro inside the test Apr 19 11:19:59 rburton: perhaps it's too late in the day to be reading autoconf stuff Apr 19 11:20:05 rburton: any advice for gatisp? Apr 19 11:20:33 according to docs "The main interface between autoconf and pkg-config is the PKG_CHECK_MODULES macro" Apr 19 11:23:30 rip the body out entirely Apr 19 11:23:57 replace the entire block after have_gpgme=yes, with just [have_gpgme=no] Apr 19 11:24:27 buuut Apr 19 11:24:38 that does imply that we're shipping gpgme without pthread support Apr 19 11:25:41 oh our gpgme recipe is broke Apr 19 11:25:48 no gpgme-pthread.pc Apr 19 11:26:30 building an ostree package for yocto? \o/ Apr 19 11:26:45 ok, so after adding the missing *.pc file the configure.ac should be working? without requiring any changes? Apr 19 11:27:02 yeah, I wrote a recipe ~6months back Apr 19 11:27:29 have been using it for a while, now tried to updated to a more recent version Apr 19 11:27:41 one sec Apr 19 11:27:44 we do actually patch gpgme's AM_PATH_GPGME_PTHREAD so it does the right thing btw... Apr 19 11:28:08 ah the pc file is missing? Apr 19 11:28:23 yes Apr 19 11:29:19 as ostree is looking for the pc first, i wonder if upstream adds some pc files Apr 19 11:30:35 rburton, I can share my recipe, if you want to try to build it Apr 19 11:31:47 i can see why it breaks Apr 19 11:33:05 ah, fire alarm in the office, will be back in 20min Apr 19 11:34:54 rburton, ok, false alarm :D anyways, you meant that you already see why it brakes without the need for recipe? Apr 19 11:37:55 yeah Apr 19 12:18:41 rburton, for this issue not to be forgotten, should I create a bug report? Apr 19 12:20:20 hello Apr 19 12:20:36 are there known issues with yocto git repo? Apr 19 12:23:48 c0rnel: no, what's up? Apr 19 12:31:52 gatisp: can you share your ostree recipe? Apr 19 12:33:00 rburton, http://pastebin.com/KLpCseh2 Apr 19 12:33:37 gatisp: there's a gitsm: fetcher that will get submodules Apr 19 12:34:19 rburton, right, but there are few other workarounds included in autogen.sh Apr 19 12:34:34 rburton, more often than not we get do_fetch failure on linux-yocto-4.1 Apr 19 12:34:50 sounds like the problem that hit genivi on friday Apr 19 12:34:56 so might as well pull the submodules from there, as implemented by upstream Apr 19 12:35:07 only that the genivi workaround is not working here Apr 19 12:36:09 * CTtpollard confirms the genivi git server is having problems with fetches over git Apr 19 12:36:45 CTtpollard: Ah, we've seen that as well. Good to know we're not the only ones. Apr 19 12:37:37 I'm in the process of updating meta-genivi-demo recipes to git fetch over http to remedy the problem in there for now Apr 19 13:20:00 Hi Apr 19 13:20:10 I'm looking for some meta-qt5 guys. :) Apr 19 13:21:09 I sent some bug report this morning on the mailing list. I would like to find the issue and correct it. Apr 19 13:32:59 present: what was the subject? Apr 19 13:33:51 CTtpollard, the question remains what will happen when the http protocol will fail Apr 19 13:34:04 or genivi will go down for whatever reason Apr 19 13:34:21 There is inside meta-qt5 some test to detect what is functionality is present. The EGL one does not seem to take the variable calculated in the main configure file. Apr 19 13:34:24 c0rnel: the eternal fear for central git servers :) Apr 19 13:34:57 Inside configure: QMAKE_LIBS_EGL is correct. Inside the EGL test. It gets back to its default value -lEGL. Apr 19 13:37:56 present: did you check PACKAGECONFIG options passed to configure? Apr 19 13:38:16 present: Yes yes all this part is correct. Apr 19 13:39:24 JaMa: Hmm... I think I don't have trouble with PACKAGECONFIG. I can double check tonight. My point was to get it compiling without any hack. Apr 19 13:39:57 I've got a question about a missing shared object file error I ran across during the 'smart' package manager's execution during the do_rootfs() task. I've put it on stackoverflow with the 'yocto' tag so I don't have to re-explain it every time I ask. I'd really appreciate any feedback. Apr 19 13:42:30 JaMa: There have been many corrections on meta-raspberry layer. And inside the configure the command pkg-configure --libs egl gives the proper answer. Apr 19 13:42:44 JaMa: *now ;) Apr 19 13:43:01 Hi everyone! did anyone had ever a problem with a too long "hash-bang"??? I'm using "meta-gir" and I had an error wich is due to a too long path to the python interpreter, I can solve this by changing my yocto directory, but if anyone knows another solution... Apr 19 13:43:19 JaMa: But this variable computed in the configure does not get used into egl.pro. The variable is even inside .qmake.vars Apr 19 13:45:23 JaMa: The meta-raspberry master branch provides proper pkg-config. And the only reason I can see for now is that the QMAKE_LIBS_EGL default variable override the one computed through pkg-config. Apr 19 13:48:54 aurele_: had that problem before for npm iirc... not sure how I solved it "for good" Apr 19 13:49:06 iirc I had to patch some .m4 used by autoconf Apr 19 13:50:47 boucman_work, thanks, maybe there isn't any solution with this package on yocto Apr 19 13:51:27 present: I don't use rpi, but if your configure gets wrong parameters then the autodetected params may not be used, and e.g. with master-next you need to make sure you have the patch for EXTRA_CONF_PACKAGECONFIG applied to your oe-core Apr 19 13:51:39 present: you didn't say which versions/branches you're using Apr 19 13:52:12 JaMa: jethro for everything but raspberry on master Apr 19 13:52:38 aurele_: I don't think there can be a solution at the yocto level, each package needs to patch its autoconf magic... Apr 19 13:54:26 boucman_work, yes but path to python interpreter is what it is... the package just use the given path Apr 19 14:02:15 JaMa: Hmm... I don't set EXTRA_CONF_PACKAGECONFIG on my own. I guess its done in the linux-oe-g++ file. Apr 19 14:03:50 present: it has to be set in the bitbake metadata, but jethro branch isn't affected by this Apr 19 14:11:28 JaMa: In my layer I only modify gl for gles2. I change the value of PACKAGECONFIG_GL. Apr 19 14:11:56 JaMa: The rest should be done automatically. Apr 19 14:13:31 OpenGL is enabled by default so the compilation of meta-qt5 should take it into account. How can I check the PACKAGECONFIG variable for the recipe? Apr 19 14:14:55 present: bitbake -e recipe-name Apr 19 14:16:25 CTtpollard, :) Apr 19 14:19:53 JaMa: Ok So... If I have the proper PACKAGECONFIG and a proper pkg-config output. Will you have another idea? Apr 19 14:21:42 JaMa: Just checked! I thought not could not here... Apr 19 14:21:47 JaMa: PACKAGECONFIG=" release dbus udev evdev widgets tools libs openssl gles2 xcb xvideo xsync xshape xrender xrandr xfixes xinput2 xinput xinerama xcursor glib gtkstyle xkb jpeg libpng zlib pulseaudio " Apr 19 14:21:51 Correct!!! :) Apr 19 14:22:09 JaMa: The error is getting closer to meta-qt5. :P Apr 19 14:22:52 I'm shamelessly plugging my recent stackoverflow question with the 'yocto' tag . The question is about a missing shared object file error I ran across during the 'smart' package manager's execution during the do_rootfs() task. I'm really stumped. Apr 19 14:24:12 karobar: you might want to shamelessly plug the URL of the stackoverflow question :P Apr 19 14:25:00 ah, good idea :) http://stackoverflow.com/questions/36703804/smart-cant-install-no-package-provides-shared-object-file Apr 19 14:26:09 JaMa: I'll try one more time tonight. Can I open a bug report somewhere? https://github.com/meta-qt5/meta-qt5 does not seems to have issues panel Apr 19 14:26:13 *s Apr 19 14:28:26 karobar: do you compile with rm_work.bbclass ? Apr 19 14:29:08 because the .so is in the sysroot-destdir, but it doesn't seem that make-install added it to the target directory Apr 19 14:29:52 present: it works for other MACHINEs so I would recommend discussing in RPi MLs Apr 19 14:29:52 I would have expected to find it in an image/ subdir of the workdir and in a pkg-split subdir... Apr 19 14:30:34 JaMa: I did already and I checked their work also. Apr 19 14:30:43 i don't use rm_work Apr 19 14:30:52 JaMa: As long as I understant they do a proper job with pkg-config. Apr 19 14:31:24 The meta-qt5 configure gives a proper output for pkg-config --libs egl. Apr 19 14:31:31 I'll say they can't do more. Apr 19 14:32:32 This is still a trouble when there is an interaction but I'm pretty sure this one is not on meta-raspberry side. Apr 19 14:32:42 The trouble is quite small: Apr 19 14:32:52 -lGLESv2 -lEGL does not link Apr 19 14:33:02 -lEGL -lGLESv2 does Apr 19 14:33:15 Which is why it may work for other machines. Apr 19 14:37:24 karobar: ok Apr 19 14:37:43 boucman_work: I think i poorly displayed one section of the question. It appears at a quick glance that libavformat was in the sysroot-destdir, but it was actually libavplugin-53.so Apr 19 14:40:00 yeah, i'm a bit confused... Apr 19 14:40:24 -lEGL -lGLESv2 ... -lEGL (this one comes from the default from Qt) gives at the end : -lGLESv2 - lEGL Apr 19 14:40:29 could you pastebin the result of 'find ./work/core2-64-poky-linux/oracle-jse-jre/1.8.0-u77r0/' ? Apr 19 14:40:46 i.e all the oracle-jse-jre part of tmp/work Apr 19 14:40:57 no wait.. Apr 19 14:40:58 hmm Apr 19 14:41:42 If the variable were properly set we would have: -lEGL -lGLESv2 ... -lEGL -lGLESv2 which would keep the order Apr 19 14:42:09 so, IIUC you have libavformat in your sysroot, but not in your image Apr 19 14:42:13 JaMa: I'll find it! :D Apr 19 14:42:46 so... at somepoint someone did DEPEND on whoever provides libavformat, so it was installed in the sysroot, but we don't know who that is Apr 19 14:43:36 If you can confirm that you have done the proper updates khem_ ;) Apr 19 14:44:21 so first we need to find what package provides libavformat... could you look if the file is somewhere else in your work/ directory (and where) a 'find | grep libavformat' in your work directory should give me all the info I need Apr 19 14:47:34 well, libav is DEPENDed on by the xenoros recipe (i just realized how confusing this seems, i'll clarify better), which provides libavformat.so.53, which does end up in the target image. The problem is that version 54 is missing and is somehow required during do_rootfs. Apr 19 14:49:54 that is, libav_9.18 provides libavformat.so.54, and libav_0.8.X provides libavformat.so.53 Apr 19 14:51:28 JaMa: Can you override QMake Variables? I'm much more doubting that. Apr 19 14:54:11 libav should be DEPENDed by oracle-jse-jre Apr 19 14:55:11 to me it's an error in the oracle recipe, xeneros is not involved Apr 19 14:55:46 oracle-jse-jre might have been compiled before libav (since IIUC it doesn't DEPEND on libav) and have used an old .so Apr 19 15:41:15 boucman_work: I tried your suggestion and moved the dependency on libav into oracle-jse-jre but got the same results Apr 19 15:44:34 karobar: that is, libav_9.18 provides libavformat.so.54, and libav_0.8.X provides libavformat.so.53 <= i'm a bit confused about that line Apr 19 15:44:46 you should not build two versions of the same package, right ? Apr 19 15:45:10 (and did you "bitbake -c dirclean oracle-jse-jre" first ?) Apr 19 15:49:21 boucman_work: I tried your suggestion and moved the dependency on libav into oracle-jse-jre but got the same results Apr 19 15:50:30 uhh i meant to say that i made a recipe for 0.8.x just to see what happens, and it adds libavformat.so.53 to its sysroot. I only build one or the other, not both Apr 19 15:51:22 also, i use `bitbake -c clean oracle-jse-jre` not dirclean and I'm not familiar with the difference Apr 19 15:52:36 IIUC -c clean run "make clean" whereas dirclean removes and recreates the build directory Apr 19 15:53:16 ok.. I don't really understand what's going on here, but I might have a hunch... Apr 19 15:53:36 is oracle-jse-jre compiled from source or is it a binary provided by oracle ? Apr 19 15:59:30 it's the binaries Apr 19 16:02:07 boucman_work: -c clean wipes the entire recipe workdir. sources, build dir, everything. it does not run make clean Apr 19 16:04:02 kergoth: ok, I knew I was confused on that one :) Apr 19 16:04:37 karobar: if jre is a binary, then the version of the lib is probably hardcoded in it... you will need to force libavformat at the corresponding version... Apr 19 16:04:42 the only time make clean is run is in do_configure when it re-runs tasks on an already-built recipe due to metadata changes Apr 19 16:04:51 (and I need to leave soon, can't help you much i'm afraid Apr 19 16:04:58 to try to avoid remnant existing bits from the previous build Apr 19 16:05:53 okay thanks a bunch for the help Apr 19 16:18:19 I'm shamelessly plugging my recent SO question http://stackoverflow.com/questions/36703804/smart-cant-install-no-package-provides-shared-object-file The question is about a missing shared object file error I ran across during the 'smart' package manager's execution during the do_rootfs() task. Apr 19 16:29:15 is it possible to add two versions of the same recipe to a single rootfs? Apr 19 16:31:59 karobar: nope. how would that work, the packages would provide the same files? Apr 19 16:38:22 hmm, i suppose it doesn't really make sense Apr 19 16:41:32 if you had different recipes, with different names, *and* different filenames or install prefixes, then yes, of course, but beyond that.. Apr 19 16:42:13 rpm does let you install multiple versions of the same package, assuming they don't conflict Apr 19 16:42:21 so stuff like libraries with different versions, you can install many Apr 19 16:43:26 that's true. doable without rpm for libs if you use the debian soname based package renaming too Apr 19 16:44:03 but you then have problems where teh -dev packages can't parallel install Apr 19 16:44:25 so if an upstream has proper parallel installable releases - like gtk2 and gtk3 - then have two recipes Apr 19 16:44:35 that's where renaming from glib-1.2, glib-2.0, etc comes in, usually Apr 19 16:44:36 yeah Apr 19 17:54:22 WIll patches we submit to oe-core end up in 2.2/master now, by default, unless we request krogoth? Apr 19 18:07:10 Shouldn't ddimage either unmount the device it's about to write to, along with all its partitions, if any are mounted, or at least abort if they're mounted? Apr 19 18:13:23 I am having a hard time to disable the graphical menu in syslinux Apr 19 18:13:38 I added AUTO_SYSLINUXMENU and setted it to 0 on our image but it fails Apr 19 18:49:44 sato should really scale its icons with screen size or something. the arrows to switch between desktops / icon groups are tiny Apr 19 18:49:59 trying to hit them with the touchscreen on this panel is not enjoyable Apr 19 18:50:48 ir Apr 19 19:29:40 kergoth: re patches, say krogoth if you want them in. we hope to be rolling 2.1rc2 tonight! Apr 19 19:30:03 kergoth: and re sato icons, yeah i know they're tiny for no reason. gtk3 port - due in 2.2m1 - may well fix that. Apr 19 19:30:04 okay, sounds good. i actually have quite a bit pending for 2.2, and wanted to make sure i didn't have to explicitly call that out Apr 19 19:30:09 ah, cool Apr 19 19:30:35 erk. the only way to get wic to enable an initramfs in the bootloader config and copy it into the boot partition is to use a hybrid iso? Apr 19 19:30:49 afaict you can't do it at all for a regular efi disk image.. Apr 19 19:30:52 what the hell? Apr 19 19:31:13 wic has such weirdly hardcoded behaviors both in its python modules and the wks files (though the latter could be addressed via adding a templating mechanism to the metadata) Apr 19 19:31:40 reminds me of toaster in that way, weirdly hardcoded, lots of assumptions, really in opposition to yocto/oe project philosophy Apr 19 19:32:19 guess i can compile the initramfs into the kernel and sidestep the issue Apr 19 19:32:22 for now Apr 19 19:34:00 wonder if you can use dracut on the host to build an initramfs for the target or if it has to run on target Apr 19 19:44:43 kergoth: bug bug bug bug bug bug (please) Apr 19 19:48:11 will do Apr 19 19:48:49 seems like it should just be another option on the bootloader command, to me, rather than hardcoding it inside the python module and having it pull bitbake variables Apr 19 19:48:50 * kergoth shrugs Apr 19 20:09:38 kergoth: I have a wic source plugin that is basically just directdisk-pcbios hacked to use install_cmd = "install -m 0644 %s/%s-initramfs-%s.%s %s/vmlinuz" % (staging_kernel_dir, "bzImage", "mymachine", "bin", hdddir) Apr 19 20:10:32 with that one line change it works Apr 19 20:11:40 But I agree with your assessment Apr 19 20:52:02 How do I clean my build? Apr 19 20:53:09 rm -rf cache sstate-cache tmp Apr 19 20:53:35 Guest43746: the question is, clean it for what reason exactly? Apr 19 20:53:50 if it's "to start completely from scratch" see igor's answer Apr 19 22:07:37 Hi everyone i use variscite dart 6 ul kit it has imx6 chip and i want to boot on emmc i selected pin configuration for emmc but i take an error mmessage: card did not respond to voltage selected ? Apr 19 22:07:40 what is that ? Apr 19 22:15:33 I wanted to start over (to ensure I don't have residual stuff) but not have to download anything again. However, turns out I'm doing a totally new build after all. Apr 19 22:15:45 Sorry for the noise. Apr 19 22:44:41 I wanted to start over (to ensure I don't have residual stuff) but not have to download anything again. However, turns out I'm doing a totally new build after all. Apr 19 22:44:41 Sorry for the noise. **** ENDING LOGGING AT Wed Apr 20 02:59:58 2016