**** BEGIN LOGGING AT Wed Feb 14 03:00:02 2018 Feb 14 03:30:57 New news from stackoverflow: Yocto Project usb sensor acces Feb 14 07:28:46 Hi, folks! Do you know how to determine why package is installed? I use grep to see where is packagename, but i see it only inside IMAGE_INSTALL. I tried IMAGE_INSTALL_remove+="packagename", but with no luck. Feb 14 08:13:58 acrap: it may be a dependency for something else Feb 14 08:14:59 sure, but i can't find any other mentions of the package Feb 14 08:15:59 i ask about the opportunity to get it with bitbucket or some yocto utils Feb 14 08:16:43 and yes i know about -g, but it can't give me enough information Feb 14 08:20:07 i even tried to draw dependency graphs, but tools that must draw it just can't do that cause file size. I saw it is normal in yocto FAQ, but why? Why can yocto do that if it useless? This .dot files are useless, cause graphviz can't process it. Feb 14 08:22:00 acrap: because there are smaller ones too. Feb 14 08:22:39 ok. i get it. sometimes it isn't useless :) Feb 14 08:26:54 any ideas? Only grep all the recipes and *.inc(obviously, i don't use all the recipes)... Is there another way? Feb 14 08:29:16 the simplest trick probably is to deliberately break the package, for example by renaming int from .bb to .bbroken, and kicking off the build again. then bitbake should err out with the unsatisfiable dependency chain. Feb 14 08:39:16 HI. I'm new here and I started working with yocto a few weeks ago. Up until now I could manage every problem with documentation and reading old posts on the mailing list. Now I have a weird problem regarding postinst functionality. Is this the right place? Or should I better write to the mailing list? Feb 14 08:40:18 hawkril: try to describe your problem as concise as possible, and we'll try to help. of course there's no guarantee that we succeed, in which case you probably need to continue to the ML. Feb 14 08:45:02 Board: Digi Connectcore6. Yocto: Morty | I have written a recipe to include our software in an image. and that works, the problem is I wrote a package_postinst function to cerate a database for it,that should be executed on the first boot according to the Maunual, but it doen't get executed. Here is the basic function: Feb 14 08:45:11 pkg_postinst_aoftware() { Feb 14 08:45:11 if [ x"$D" = "x" ]; then Feb 14 08:45:11 if [ -d database ]; then Feb 14 08:45:13 ..updatedbscheme.. Feb 14 08:45:15 else Feb 14 08:45:17 ..createdb.. Feb 14 08:45:19 fi Feb 14 08:45:21 else Feb 14 08:45:23 exit 1 Feb 14 08:45:23 hawkril: use a pastebin, please. Feb 14 08:45:25 fi Feb 14 08:45:27 } Feb 14 08:45:37 sorry Feb 14 08:46:03 https://pastebin.com/wGfX7cLq Feb 14 08:46:22 hawkril: s/aoftware/software/g :-) Feb 14 08:48:07 ^^ just a typo while reducing/cleaning the script Feb 14 08:48:34 chances are that you just are referring to the wrong package name. usually this is done by variable expansion magic: pkg_postinst_${PN} Feb 14 08:51:31 i'd try to get it right with something simple, like a "touch test.txt" or such for starters. once that works, replace it with the full magic command. Feb 14 08:52:12 Okay, I will try that. Haven't thought about that possibility of a wrong package name. And sorry about my violations to IRC etiquette. Haven't used IRC in forever. Feb 14 08:53:10 no problem at all. its just annoying if people don't even try. the point of the mass paste is that it is jsut so much more complicated to read and reason about than in a pastebin :) Feb 14 09:52:45 Sadly, that dind't help. I simplified the postinstall: https://pastebin.com/tgtjK3Kt Feb 14 09:53:41 But still no execution on first boot. But the condition should be correct? Feb 14 09:54:21 i personally haven't used it so far, so i cannot answer for sure, sorry. Feb 14 09:56:35 Thanx for your help. Feb 14 09:57:30 hawkril: check that postinst file gets written to tmp/work/..../your-image/rootfs/etc/rpm-postinsts (I think) Feb 14 09:57:44 hawkril: can't remember exact directory names now Feb 14 09:57:58 and that postinst package gets installed into your image Feb 14 09:58:40 also inspect log.do_rootfs which might contain a clue Feb 14 10:05:42 hello, bitbake is failing to parse my distro configuration I try to derive from poky: https://pastebin.com/BNx22RmM Feb 14 10:06:32 I am getting unparsed line: 'def arm_tune_handler(d):' Feb 14 10:07:46 which is strange since I am trying to just copy-paste stuff from fslc-base.inc in meta-freescale-distro for now Feb 14 10:57:21 hi, is there a way to set in yocto to set QMAKE_LRELEASE Variable before qmake is run in a bb file ? Feb 14 10:59:50 grma: basically anything that is set in a .conf file is visible everywhere. not sure if you need to whitelist it, though Feb 14 11:08:08 LetoThe2nd: that means i have to set a .conf file, put it to my SRC_URI and then in im .bb file how do i source thes conf ? Feb 14 11:08:15 this conf Feb 14 11:14:36 grma: erm, no. as i understand it, this is something that would be distro specific? Feb 14 11:17:06 Hi all, I added a patch to SRC_URI in my recipe but do_patch doesn't get called - any tips, how to fix this? Feb 14 11:19:32 LetoThe2nd: thx, i will do it with patching the .pri file. to complicated for me with a conf file Feb 14 11:22:49 grma: :-) Feb 14 11:24:32 LetoThe2nd: i do not like this too, to change a general .pri file to host OS specific thing, but updateing from old yocto to rocko needs some hacks :-) Feb 14 11:24:53 grma: i didn't object, did i? Feb 14 11:28:06 LetoThe2nd: no, you didn't object, you tried to help me, thx Feb 14 11:28:44 good luck Feb 14 11:44:27 hello guys. Do you have any ideea why installing the dhcp-client into an image also installs the bind package ? I noticed this in rocko, in krogoth this was not the case. Inspecting the dhcp-client ipk it shows(on rocko, not in krogoth) Depends: bind (>= 9.10.5-P3), dhcp-libs (>= 4.3.6), libc6 (>= 2.26) Feb 14 11:45:36 in not just installs it (bind) in the image but it also starts the bind server ... Feb 14 11:54:57 ggtk: well, there is DEPENDS = "openssl bind" if you look here: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/dhcp/dhcp.inc Feb 14 11:55:25 ggtk: also EXTRA_OECONF sets --with-libbind=${STAGING_LIBDIR} Feb 14 11:55:45 so I guess the recipe does not allow for bind being optional Feb 14 11:58:06 eduardas_m: but that's only during build time, doesn't mean that the dhcp-client package needs to RDEPEND on dhcp-server Feb 14 11:58:52 erbo: yeah, I've just noticed that... seems weird there is no RDEPEND for bind Feb 14 11:59:48 if the dhcp-client library links toward a lib that's in the dhcp-server package it would be added automatically Feb 14 12:00:40 I have no rocko build available for me to look around in, but I would guess that is what is happening if dhcp-client indeed has a dependency on dhcp-server Feb 14 12:01:07 check rpm -qRp path/to/dhcp-client*.rpm Feb 14 12:03:30 oh, I see that ggtk already checked the dhcp-client ipk deps Feb 14 12:03:31 ggtk: I'm just wondering why use the dhcp recipe and dhcp-client package in the first place if you are making an embedded system?... I am currently using connman and it's built-in dhcp client... busybox-udhcpc is also an alternative Feb 14 12:04:23 I currently do not seem to have a bind package in my distro Feb 14 12:07:12 erbo: exactly, it doesn't specify RDEPENDS, it's just depends, so just for build as I see it Feb 14 12:08:03 ggtk: if you run ldd on the dhcp-client binary, does it link towards some lib provided by bind package? Feb 14 12:12:22 erbo: yes... it's libdns.so.170 Feb 14 12:12:45 and libisc.so.170 Feb 14 12:13:14 both provided by bind ... Feb 14 12:15:27 so it needs those libs and then it installs the bind ipk, and that installs the init script and there you go, you just got yourself an extra server running Feb 14 12:16:06 feels weird that those are not shipped as separate packages. I've mostly used rpm, but then the libs are usually split out into it's own packages called libfoo-something Feb 14 12:16:41 maybe ipk packaging works differently, or the bind package does something that prevents this Feb 14 12:29:41 ggtk: I guess this is fixed after rocko release, see https://github.com/openembedded/openembedded-core/commit/d74ebc91388941295a2321a295cdb06ee87fc38b#diff-4db1c072faa44ce1e1384174ed663574 Feb 14 12:31:18 I guess you can just backport that yourself using a bbappend Feb 14 12:31:18 erbo: just looked at the krogoth dhclient binary and there it depends only on libcrypto and libc so not so many dependencies Feb 14 12:32:07 erbo: yeah it looks ok, I'll try that. Thanks for the finding! Feb 14 12:34:27 and I guess I also need to update the DEPENDS in the dhcp recipe , right ? or it will just use the correct ipk instead ? Feb 14 12:36:05 It will magically work. The DEPENDS works on recipes, so that the bind recipe it built before dhcp, and then during packaging of dhcp it should find the link and add the approriate dependency to the package containing the lib Feb 14 12:36:48 now that is nice and the change is minor Feb 14 12:38:01 LetoThe2nd: yep. I tried to put recipe to blacklist and after it i got some useful info :) It's a pity that we don't have normal way to get info about dependency chains. Feb 14 12:39:28 erbo: now the dhcp-client.ipk has Depends: bind-libs (>= 9.10.5-P3) :) so it's fixed , no bind dependency anymore Feb 14 12:39:42 my etc/network/interfaces config get overwritten on boot Feb 14 12:39:46 other files I change stay changed Feb 14 12:39:50 any ideas? Feb 14 12:42:13 acrap: we certainly have, i jsut don't know about it :P Feb 14 12:44:37 LetoThe2nd: or we don't. By the way, thank you for the response. Feb 14 12:45:32 ok, I think I just shut it off too quickly after changing the file, wasn't properly written to card Feb 14 13:11:34 Dear All, Feb 14 13:11:34 I do have observed a strange thing - namely Feb 14 13:13:42 packagegroup-foo-backup works but packagegroup-foo-BACKUP silently ends its execution and then Feb 14 13:14:38 I do see "No package packagegroup-foo-BACKUP available. Error: Unable to find a match Feb 14 13:14:53 When referenced from core-image-* Feb 14 13:15:04 Is there any convention with this? Feb 14 13:16:06 lukma: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#new-recipe-storing-and-naming-the-recipe Feb 14 13:16:15 lukma: -> naming the recipe, basically. Feb 14 13:20:03 LetoThe2nd: " Use lower-cased characters and do not include the reserved suffixes -native, -cross, -initial, or -dev casually (i.e. do not use them as part of your recipe name unless the string applies)" Feb 14 13:20:15 But why it is like that? Feb 14 13:20:30 Is there any rationale for this? Like upper case naming is reserved for ....... ? Feb 14 13:20:57 lukma: in short: historic reasons. in long: ask kergoth. in personal: i don't have a clue. Feb 14 13:22:52 LetoThe2nd: Ok :) Feb 14 13:23:20 kergoth: Do you maybe know why only lower letters are allowed with naming recipes? Feb 14 13:23:31 kergoth: Is there any rationale for this? Like upper case naming is reserved for ....... ? Feb 14 13:29:24 lukma: it breaks some of the package managers e.g. I think its against debian rules so this makes life simpler Feb 14 13:30:19 RP: I'm just curious....... Feb 14 13:32:12 lukma: also, we stopped supporting uppercase overrides and the packaging code assumes it can use the package name as an override Feb 14 14:58:46 would be possible to build an image including Qtcore only (no graphics)? Feb 14 15:04:39 mckoan: I think meta-qt5 has a recipe for qtbase, just make sure your image includes only that Feb 14 15:09:05 kanavin: thx, unfortunately qtbase includes some basic graphical dependencies Feb 14 15:09:58 lukma: yep, as RP says, it's due to the package naming coming from recipe naming, and the limitations of the binary package managers we support Feb 14 15:10:32 * kergoth yawns Feb 14 15:25:09 Has anyone tried to build with a meta-xilinx machine (master or rocko branch) recently with the yocto rocko release? I'm getting "login: can't set groups: Operation not permitted" when trying to log into the microzed and zedboard targets but not a qemu-zynq7 target. I found an old e-mail thread from a year ago that didn't seem to have a resolution other than identifying the kernel as a possible cause. Feb 14 15:26:43 mckoan: then file an issue with meta-qt5, I'm not sure where they hang out Feb 14 15:49:13 vmeson: your spelling patch makes me cry as it will trigger a full rebuild :/ Feb 14 15:49:36 vmeson: I just triggered one of those already today :/ Feb 14 15:55:18 vmeson: also, if we're going to do it "# Check its an executable" → "# Check it's an executable" Feb 14 16:25:31 Is there a final 'check' that is supposed to run that ensures the root file system ownership is set (e.g., /usr owned by root:root)? Feb 14 16:26:02 zeddi: there must be some new default for crypto modules in 4.16-rc1 Feb 14 16:26:11 tgoodwin: what exactly are you looking to check? and check against what? Feb 14 16:26:41 zeddii, my build fails if I don't add openssl-native (or diable crypto and libs stuff) Feb 14 16:27:53 kergoth: I'm unable to log in as root to non-QEMU rocko-based build (the error is: login: can't set groups: Operation not permitted). When I mount the file system on my build computer, I see it's owned by an unknown set of IDs almost throughout. Feb 14 16:28:21 tgoodwin: look for IMAGE_QA_COMMANDS in image.bbclass Feb 14 16:28:26 is the user id the user id of the user you used to build? Feb 14 16:28:32 there's a check you can enable to catch that Feb 14 16:28:35 tgoodwin: you can add to that any image qa checks you want Feb 14 16:29:16 kergoth: no, my build system doesn't recognize it (lists 39054:38465, which I don't see for any of my users or groups)) Feb 14 16:29:56 not all of the rootfs is owned by root, so i don't really see how such a check would know what to check the ownership against, short of manually maintaining a list of permissions Feb 14 16:30:28 Right, but certain parts should be. I would imagine most of the top level directories would be. Feb 14 16:35:06 kergoth: When I pull up an older build (jethro, I think), my resulting root /bin, etc. are all root:root. Feb 14 16:35:32 Hi Feb 14 16:36:35 For x86 platform, do we have yocto support Feb 14 16:37:06 Misbah: yes, yocto supports x86 extensively Feb 14 16:38:26 kanavin: thanks for that -- I'm trying to cross-reference what that variable gets set to now vs. in a previous working build. Feb 14 17:54:17 Has anyone ever been successful at compiling python-scipy via bitbake ? Between the distutil, fortran, lapack/blas.. it's not a pleasurable experience. I've gotten somewhat far but now gfortran tries to compile a lib as an executable, which leads to an undefined reference to main.. Feb 14 18:12:38 mjourdan: fortan and lapack/blas would be the biggest hurdles, since fortran is not officially supported in oe-core Feb 14 18:13:06 mjourdan: I am working on packaging the R language, which also requires gfortran (or f77 or f95 or...) Feb 14 18:13:26 mjourdan: I am also working on a major change in python-matplotlib Feb 14 18:13:58 mjourdan: please let us collaborate on scipy and get it into meta-python? Feb 14 18:20:49 It would be nic to see someone conquoer scipy! Feb 14 18:33:42 kergoth: if I unpack my rootfs tar ball, preserving permissions (-p), should the resulting file system have things like /bin owned by root? Feb 14 18:33:57 only if you run tar as root Feb 14 18:34:00 but then, yes Feb 14 18:40:02 kergoth: I re-built this same manifest on a system that isn't connected to an active directory domain controller (so the user ID is 1000 vs. 6 billion-something). In that case, the resulting rootfs partition was mostly owned by that user. Feb 14 18:44:13 I have no idea where those other user and group IDs came from other than that they appeared to be a consistent hash of something common between the two systems (which is the directory server). Feb 14 18:49:29 Alright, found a related bug. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12412 Feb 14 18:49:30 Bug 12412: normal, Medium+, 2.5 M3, stephano.cetola, IN PROGRESS DESIGN , WIC: rootfs wrong file ownership on rocko branch Feb 14 18:49:39 Thanks for the sanity check, kergoth. Feb 14 19:58:01 mjourdan: I did get scipy working a couple of years ago Feb 14 19:58:25 mjourdan: as moto-timo says, lapack was the most challenging Feb 14 19:58:59 mjourdan: at the end I thiink the only way I got it to work was using ATLAS, cross compiling any of the math libraries was a pain Feb 14 19:59:28 mjourdan: even ATLAS took many hours to cross compile but at least it was successful Feb 14 20:00:19 mjourdan: I only got it to work on x86 though, no arm, and I tested it on an Intel Galileo and a Minnowboard Feb 14 20:00:56 moto-timo: I might have the code somewhere, but the reason I didnt send it to meta-oe was that it only worked on arm Feb 14 20:20:41 i am looking into u-boot to be able to delete a file from a fat Feb 14 20:21:05 fatwrite() is possible but i actually wanted to delete a file ? Feb 14 20:28:29 moto-timo,aehs29: fortran/blas was actually the easiest part. Thanks meta-gnss-sdr.. I ended up skipping on ATLAS and instead telling scipy to use the blas implementation from lapack. Though ATLAS seems to be the preferred implementation so I'd have to give it a go probably. Feb 14 20:30:15 moto-timo,aehs29: my biggest pain right now is the fortran compilation of some of scipy's parts. I'll gladly have any bit of information you have about it..! Feb 14 20:31:28 moto-timo: I'd love the cooperation, just be mindful that I'm doing it on krogoth right now. Would be great to have python-scipy in meta-python though that's for sure..! Feb 14 20:32:09 lapack/blas* and not fortran/blas of course Feb 14 20:32:34 is GCC/address sanitizer supported in recent (rocko) ARM toolchains? Feb 14 20:33:07 i'd really love to have a faster alternative to valgrind Feb 15 00:35:03 New news from stackoverflow: Access to Linux sources and headers in bitbake **** ENDING LOGGING AT Thu Feb 15 03:00:01 2018