**** BEGIN LOGGING AT Tue Jun 14 02:59:59 2016 Jun 14 07:37:50 Hi Everyone Jun 14 07:37:56 I have a question: Jun 14 07:38:13 Is that possible to "rename" root user to something else in yocto recipe? Jun 14 07:38:48 lewiatan: I'm not sure if that's possible in linux in general... Jun 14 07:38:59 root is a very special name in the unix world Jun 14 07:39:25 you can create another user and give him most/all rights, but that's not technically renaming root Jun 14 07:40:36 I'm sure that renaming root is possible in linux in general and I also know that's not the best idea Jun 14 07:40:54 but my case is like so: Jun 14 07:41:27 i have multiple applications, config files, systemd services, etc that use admin instead of root - it was renamed on different system Jun 14 07:42:34 I know I can add admin account, but then, when I need an access to device, say: /dev/watchdog I will need to add my user to root group and change permissions of /dev/watchdog (permissions for group) Jun 14 07:43:15 since /dev/watchdog is created at runtime- how can I change it's permissions for group in yocto? Jun 14 07:43:35 lewiatan: probably you need to play wid udev rules to do that... Jun 14 07:43:49 (not renaming root, changing permissions of dynamic devices) Jun 14 07:45:31 ok. udev is something new to me. any manual or bitbake recipe example you could recommend? Jun 14 07:46:50 this one is rather good as an udev reference: http://www.reactivated.net/writing_udev_rules.html Jun 14 07:47:40 lewiatan: I would strongly advise playing directly on your device for some time (i.e writing the rules and testing them there) to get the hang of it Jun 14 07:47:57 udev has some pretty cool features and is very good at what it does Jun 14 07:48:15 but it's solving a complicated problem, so the solution can't be completely simple and it takes a little time to master Jun 14 07:48:46 once you've understood udev, writing a .bb or .bbappend that simply add a file in /etc/uder/rules.d should be trivial Jun 14 07:49:36 ok. Thank you - I'm going to try that Jun 14 08:10:32 Is there a way to get a list of files in the sysroot that are (or not) tracked in sstate? Jun 14 08:11:03 root Jun 14 08:11:12 I have just found out one BSP recipe that was copying files directly to the sysroot and causing failures when reusing sstate, and I would like to see if there are other recipes doing the same Jun 14 08:11:21 and now password :D Jun 14 08:50:08 regarding my previous question, it's possible to get a list of things putting in sysroot by looking in tmp/sstate-control. Things like cat tmp/sstate-control/*.populate_sysroot Jun 14 08:50:21 if anyone has a better suggestion, it's always appreciated Jun 14 09:40:02 Hi! How can I abort a Yocto job after some error? That is, after bb.error("Something is wrong!") I want to abort the job. Is there something like 'abort()' maybe? Jun 14 09:40:12 I could not find anything in the documentation =S Jun 14 09:41:08 bb.fatal Jun 14 09:41:28 (or bbfatal if you're in a sh function) Jun 14 10:02:42 Thanks Jun 14 10:37:49 hello. i need to do something like PREFERRED_PROVIDER from an image, which doesn't work according to a discussion on the mailing list. Jun 14 10:38:50 would it work to simply depend on the desired package either from the image or a package that occurs in the image?, e.g. RDEPEND on libjpeg-turbo to "prefer" libjpeg-turbo as the jpeg library? Jun 14 10:41:38 maelcum: can you not just set preferred provider in your distro config Jun 14 10:56:41 rburton: in one case yes, in the other case maybe not because we're building two different images from the same overall setup. Jun 14 10:57:26 the overall setup comes from a team that is not very good at the whole yocto thing :/ Jun 14 10:58:27 for $reasons, both images have packages that depend on the same package, but it has different providers depending on the image to build. Jun 14 10:58:46 well, thanks so far. Jun 14 13:08:46 kergoth: ping Jun 14 14:13:13 Are there ways to trigger a proper rebuild after changing the source files for a package? Jun 14 14:16:33 skfax: it should work magically, but it depends a bit on how you are changing the source file (or, more explicitely, where...) Jun 14 14:16:54 yocto can be used while developing software, but the recommanded way to do that is to use detool Jun 14 14:17:02 (grep the yocto manual for that) Jun 14 14:17:33 if you just go in work/ and modify the source there, you have a high risk of accidentally loosing your changes and no, yocto won't automatically detect code changes. Jun 14 14:19:44 boucman_work: It's a local SRC_URI location where the files are being changed. It does not seem to be detected correctly Jun 14 14:20:17 boucman_work: I'll look into detool, but bitbake would be ideal Jun 14 14:21:17 skfax: devtool calls bitbake internally, but it's the proper way of telling yocto "the source is a moving target on the local filesystem" wheras I am not sure how SRC_URI works to detect file changes Jun 14 14:21:36 remember, yocto's main point is to integrate, not to develop Jun 14 14:21:50 and devtool is a really great tool.... Jun 14 14:22:22 esp if you want to work on a patch to an external software Jun 14 14:23:17 boucman_work: The source is fully contained in a local directory. They are packages for meta-ros describing individual ROS packages Jun 14 14:23:35 boucman_work: I'll try to make devtool work, thanks! Jun 14 14:54:58 hello, the entries in FILES_${PN} seem to be optional as there is no error message given, at least in daisy? Jun 14 14:55:21 if I put some dummy entry without syntax error in there? The documentation does not seem to clarify whether those are optional or mandatory entries Jun 14 15:01:42 lpapp: that's correct, an entry there that matches no file is silently ignored. it's not ideal for user added bits, but we rely on it for our default (the default FILES_${PN} in bitbake.conf lists a ton of common paths which don't exist in plenty of recipes) Jun 14 15:02:17 I see, thanks. Jun 14 15:04:01 I am tempted to suggest a single line to Scott mentioning this in here: http://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html#var-FILES Jun 14 15:04:32 because my colleague was asking me and could not give him an authorized answer without asking or looking into the code :) Jun 14 15:05:09 that would seem reasonable to me. it would be nice if we could improve this is in some way, perhaps handle the default values differently than user added values somehow, so it'd be easier to catch typos, but an unpackaged file is quickly seen as a warning, so not really a big deal usually Jun 14 15:05:12 nisha: Annika asked me to turn off Star Wars Episode 3 Jun 14 15:05:16 ww Jun 14 15:07:45 ulf` :) Jun 14 15:10:07 kergoth: hmm, yeah. My colleague had the issue of not updating the SRCREV and the new version added a new file. The build process finished, but in the end, the package did not contain the expected file. Jun 14 15:11:06 kergoth: you may be interested in ross/dirs on poky-contrib Jun 14 15:11:42 lpapp: that would be firing the unpackaged files qa check, so you should check you haven't accidently turned that off Jun 14 15:12:30 (installed-vs-shipped, warning in oe-core, error in poky) Jun 14 15:19:40 rburton: only INSANE_SKIP_${PN} += "ldflags" Jun 14 15:19:55 lpapp: i mean your distro config Jun 14 15:20:05 check what WARN_QA and ERROR_QA have Jun 14 15:20:17 this is an error, imho. Jun 14 15:22:50 rburton: those are not set Jun 14 15:30:13 kergoth: did you have a chance to look at the runqueue/taskdata changes? I'm assuming you're ok with such a cleanup? Jun 14 15:49:41 RP: yes, sorry I didn't reply yet, I meant to that day and the email got buried. I'm absolutely in favor, I was never a fan of all the id mapping. I haven't thoroughly reviewed the code, though, it's a massive patch :) but you absolutely have my ack. certain external tools might require adjustment, but that's okay, if any do, they were relying on internals anyway, since there's no official api for some of the information Jun 14 15:50:19 rburton: I'm a bit confused, reading your dirs patches, tasks currently run in their own process by the worker, so changing cwd shouldn't affect future tasks at all, only future functions within the task. no? Jun 14 15:52:39 kergoth: postfuncs run in the same context (unless i'm massively misunderstanding this log i was reading) Jun 14 15:53:48 kergoth: and its functions in general, not just tasks. Jun 14 15:54:08 so everything that calls exec_func was chdir'ing to B Jun 14 15:54:17 ah, indeed. okay, fair enough Jun 14 15:55:53 I'm assuming we don't need a try/finally on this since the exception will prevent future processing in that task context regardless, so it's not a big deal if the pwd isnt' restored when an exception is fired Jun 14 15:56:27 rburton: okay, the patches look good to me. i'll try some builds for us and see how it goes Jun 14 15:56:34 thanks Jun 14 15:56:53 works on my local testing, its about to hit our AB Jun 14 15:57:07 as you can see, there's a few little fixes in oe-core needed Jun 14 15:57:28 so it would be interesting to see what else breaks Jun 14 15:58:01 yeah, other layers are what i'm wondering about, hopefully there aren't too many such assumptions Jun 14 16:38:13 what could be the reason of ${libdir}/libfoo.so not becoming part of my package even though the file is there in ${WORKDIR}/image/usr/lib/. Jun 14 16:38:23 so in ${D}/${libdir} Jun 14 16:39:00 by default .so is a symlink to the actual soname, and is only used to link at build time, so is included in ${PN}-dev, not ${PN} Jun 14 16:39:16 it's part of some package or you see the QA warning about it, most likely PN-dev Jun 14 16:44:55 oh, yes, indeed, it is in -dev; gotta look up how to override that Jun 14 16:46:40 there are a number of ways. if you just add that path to FILES_${PN} it won't do much becuase ${PN}-dev is before ${PN} in PACKAGES Jun 14 16:47:13 i usually do this when i need to: Jun 14 16:47:14 FILES_${PN} += "${libdir}/*${SOLIBSDEV}" Jun 14 16:47:14 FILES_SOLIBSDEV = "" Jun 14 16:47:20 you could try that Jun 14 16:47:25 i haven't needed to in some time, though Jun 14 16:47:55 I think I used PACKAGE_BEFORE_PN before. Jun 14 16:48:54 yeah, that works too if you want to rearrange the PACKAGES order instead Jun 14 16:48:59 like i said, a number of ways :) Jun 14 16:49:26 FILES_SOLIBSDEV is used in FILES_${PN}-dev, so emptying it means ${PN}-dev no longer grabs those Jun 14 16:49:29 whichever you prefer Jun 14 16:49:34 as with everything else in yocto, really.. :) Jun 14 16:50:13 ah, ok, I was just preparing with FILES_${PN}-dev = "" Jun 14 16:50:23 did not know SOLIBSDEV works literally. Jun 14 16:50:25 thanks. Jun 14 16:51:50 np Jun 14 19:55:55 can someone tell me where the OE_QMAKE_ vars in qmake_base are used in the qt3 build, because I'm not seeing it. It looks like we aren't patching the linux-g++ mkspecs to actually obey them, unless i'm missing something Jun 14 19:59:21 Hello how are you? ee'm new someone can explain that addresses the issue Jun 14 19:59:33 if you have a question, ask it Jun 14 20:01:21 as? Jun 14 20:02:09 I have a question about bitbake recipes and patches, is anyone available to answer a few questions? Jun 14 20:04:16 I found something in the mailine, I would like to patch back into the current stable branch. I like the idea of including this patch in my recipe. I added the file to SRC_URI but it doesn't seem to be running the patch. I believe it might be a file path issue. Jun 14 20:04:30 my patch is here: /home/ubuntu/jethro/sources/meta-validmfg/recipes-validmfg/dev/dev/add_Nitrogen6QPMAX_and_SOMv2_support.patch Jun 14 20:04:42 trying to patch this file: /home/ubuntu/jethro/sources/meta-fsl-arm-extra/conf/machine/nitrogen6sx.conf Jun 14 20:04:58 but the patch references the file like this: Jun 14 20:05:12 " Jun 14 20:05:45 "a/conf/machine/nitrogen6x.conf" Jun 14 20:06:31 My SRC_URI looks like this: SRC_URI = "file://add_Nitrogen6QPMAX_and_SOMv2_support.patch;apply=yes;patchdir=~/jethro/sources/meta-fsl-arm-extra/" Jun 14 20:07:04 that really doesn't make any sense. Jun 14 20:07:08 you can't patch a layer in a recipe Jun 14 20:07:12 recipes patch their iown sources Jun 14 20:07:26 yeah, I thought something like that. Jun 14 20:07:31 hi is anyone there? Jun 14 20:07:36 what are my options here? Jun 14 20:07:57 nillerbrun, I have a yocto question if you feel like trying Jun 14 20:08:31 nillerbrun: what eaxctly are you trying to do? you can't modify a config file in one layer from another, at all. submit the fix upstream Jun 14 20:09:07 kergoth: what is the protocol on this chat? when can I begin? Jun 14 20:09:21 sorry my terminology isn't there yet, new job, ~2 weeks Jun 14 20:09:21 ? Jun 14 20:09:30 as i said to nillerbrun like 5 minutes ago, Pete_, if you have a question *ask it* Jun 14 20:09:33 don't quibble and ask to ask Jun 14 20:09:37 the fix is already submitted in master Jun 14 20:09:39 just spit it out and wait and see if someone responds Jun 14 20:09:48 got it Jun 14 20:10:02 nillerbrun: then submit the fix as a proposed backport to the stable branch for the stable branch maintainer. Jun 14 20:10:22 assuming the branch still has a maintainer, depends on what branch/release you're on Jun 14 20:10:22 I'm trying to configure a layer to apache2 instead of httpd. Can you direct me to recipes/layers that will do this? Jun 14 20:10:41 uh, the apache2 layer has apache2 Jun 14 20:10:45 er, apache2 recipe Jun 14 20:11:01 and it's images and packagegroups that select what packages get installed, not a layer Jun 14 20:11:03 yes, but I wind up with httpd and want apache to be the server Jun 14 20:11:14 what image are you building, from what layer? Jun 14 20:11:39 not all images and packagegroups are going to provide you an easy way to change teh apckages being included, woudl need more details to say Jun 14 20:11:39 openembedded and it's an intel image Jun 14 20:11:46 neither of those make any sense Jun 14 20:11:55 your'e using oe classic? and "an intel image" isn't useful Jun 14 20:12:00 exactly what image recipe is it? Jun 14 20:12:04 waht bitbake command are you running? Jun 14 20:13:16 regardless, your best bet is probably to create a bbappend in your own layer to the image or packagegroup and in the bbappend change the package being included Jun 14 20:13:29 exactly what variables need to be change i woudlnt' be able to say without more information Jun 14 20:13:35 the recipe is recipes-httpd Jun 14 20:13:41 no, that's not a recipe Jun 14 20:13:44 that's a directory Jun 14 20:13:49 and that's the recipe of the http server, not hte image Jun 14 20:13:56 again, what bitbake command are you running to build your image? Jun 14 20:13:59 underneath that is a series of directories. Assume these are the individual recipes? Jun 14 20:14:05 a recipe is a .bb file Jun 14 20:14:06 bitbake dc-image Jun 14 20:14:11 see the yocto project documentation Jun 14 20:14:17 okay Jun 14 20:14:22 okay, so examine dc-image.bb and see if it's pulling in httpd there Jun 14 20:17:08 nillerbrun: if upstream isn't amenable to applying the change to the stable branch, your best bet would be to create your own layer, copy the machine file to it under a different name, apply the fix to that, and use that as your MACHINE instead of the upstream one Jun 14 20:17:15 bitbake lets you append a recipe, but not a class or config file Jun 14 20:17:24 there are other options, but would need more details to say Jun 14 20:18:24 kergoth: it's a pretty simple patch, just adds device support https://github.com/Freescale/meta-fsl-arm-extra/commit/a10be64136363b90bd225df817a893aa9edb3808.patch Jun 14 20:19:25 ah, that's pretty straightforward Jun 14 20:20:12 it's the kernel recipe which is using the KERNEL_DEVICETREE variable. worst case you could bbappend it in your own layer and do KERNEL_DEVICETREE_append_nitrogen6x = " imx6qp-nitrogen6_max.dtb imx6q-nitrogen6_som2.dtb" Jun 14 20:20:23 or could append to it in local.conf, but that's tougher to maintain going forward Jun 14 20:20:32 yes currently our build proceedure is pretty convoluted, compile and then copy a bunch of file in manually. I would like to get it all in recipes. Jun 14 20:22:08 oh nice, yeah that works, I didn't realize that you could append anything like that. I thought it was special function for certain variables Jun 14 20:22:53 We'll likely switch to krogoth fork soon anyway and this patch won't be necessary. Jun 14 20:22:54 bitbake metadata is all a key/value store, with flags being additional key/value pairs against a variable, as further metadata. anything can be appended, prepended, etc Jun 14 20:23:11 kergoth: thanks! Jun 14 20:23:12 from bitbake's perspective the only difference between a variable and a function is the presence of a single flag internally Jun 14 20:23:20 it's still just a name and a value Jun 14 20:23:50 the bitbake manual or the yocto chapter of the architecture of open source systems book might give you some useful background Jun 14 20:24:18 http://www.aosabook.org/en/yocto.html, https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html (obviously the 1.6 in the url canb e changed to whichever release you're on) Jun 14 20:24:26 yeah i was reading that, but I was concentrating on the section about recipes. Jun 14 20:24:38 bitbake manual covers the basic metadata file format / syntax Jun 14 20:24:46 any suggestions, I'm using a buildtools-tarball from master, and I'm trying to connect (using python2.7 build w/ the SDK) to a https site.. from what I can tell the 'ssl' module isn't findign the certificates.. Jun 14 20:24:56 anyone seen this problem and/or have any idea how to resolve it? Jun 14 20:25:19 i think there were some relatively recent patches to align the certificate paths Jun 14 20:25:22 rings a bell, anyway Jun 14 20:25:31 thats what I thought, but I've not been able to find them Jun 14 20:25:31 i have hit that before, but don't recall what the solution was offhand Jun 14 20:26:33 ya.. there was a patch from paul that fixes the cert dependency -- but it doesn't seem to fix the 'sdk' usage Jun 14 20:26:56 from my strace it appears to be looking in the wrong place for a file that doesn't even exist even if it was looking in the right place Jun 14 20:27:48 fray: "[OE-core] [PATCH v2 3/3] openssl: Ensure SSL certificates are stored on sysconfdir" might be related? Jun 14 20:27:50 * kergoth shrugs Jun 14 20:28:01 could be.. will look.. Jun 14 20:28:14 I'd been searching for 'ca-*' Jun 14 20:28:34 what was the date on that once (trying to figure out how far back Ineed to look) Jun 14 20:29:00 wait found it.. Jun 14 20:29:01 5/23 Jun 14 20:29:02 may 27th Jun 14 20:29:08 followup the 27th Jun 14 20:29:11 * kergoth nods Jun 14 20:29:30 fray: you have Jason's corresponding patch as well? Jun 14 20:30:28 not seeing it Jun 14 20:31:47 * kergoth fights the qt-x11-free build :'( Jun 14 20:32:25 fray: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=d30aedcdf91d78c1553d8aa1f6769d3afa5cce8e Jun 14 20:32:44 oh, man, qt-x11-free didn't create/patch the mkspecs to obey the OE_QMAKE_ vars, instead it relied on make -e? Jun 14 20:32:46 ugh Jun 14 20:32:58 thanks Jun 14 20:33:56 BTW what I'm tryign to do is run 'repo' using the buildtools-tarball output.. it's failing trying to sync from google during the 'init' Jun 14 20:36:00 looks like all of those patches 'fix' the -native case.. it's the nativesdk that is tripping me up Jun 14 20:36:21 * fray checks he has them in his build dir Jun 14 20:42:03 * kergoth grumbles Jun 14 20:42:20 i look forward to the lsb version being bumped and qt3 going away / dying in a fire Jun 14 20:42:40 afaict it inherits qmake_base but then ignores nearly everything the class does. Jun 14 20:45:33 bluelightning: wonder if we should also build up to package_qa for 'devtool build', to check for problems Jun 14 20:46:41 kergoth: there is a config option to change the target Jun 14 20:47:17 kergoth: the task I selected was kind of deliberate though, I wanted to avoid forcing the user to fix those issues when all they wanted was to fix the bugs / make the changes they were immediately concerned with Jun 14 20:47:43 kergoth: perhaps a better solution would be to still do the package QA checks, just demote them all to warnings Jun 14 21:15:46 ah, that makes sense Jun 14 21:41:31 kergoth: the append method seemed to mostly work, but I'm getting an error with do_rootfs Jun 14 21:41:56 ERROR: imx6q-nitrogen6_som2.dtb does not exist. Jun 14 21:42:07 ERROR: Function failed: do_rootfs Jun 14 21:42:10 do_rootfs doesn't use the dtb, the kernel build does Jun 14 21:42:13 that's a bit odd Jun 14 21:43:43 yeah i tried a few variations. I patched the file directly which works, but very puzzling is that if I also add the _append to my recipe, it fails Jun 14 21:44:27 so path only works, _append only fails, patch and _append fails Jun 14 21:44:39 *patch Jun 14 21:46:39 I'm not totally fussed, because I now see that boundary released their fork of krogoth on friday, but in the interest of curiosity Jun 14 22:31:24 is it ok to mix sstate from different branches, i.e. master/krogoth? Jun 14 22:41:11 won't hurt anything Jun 14 22:41:22 anything that should be different will have metadata that's different and different checksums Jun 14 22:41:38 i use a single sstate dir between like 4 different yocto versions, about that many mel versions, etc Jun 14 22:48:58 kergoth: thanks for confirming! Jun 14 22:49:40 np Jun 15 02:29:51 Can anyone make recommendations on converting old qt4 -> recipes-qt to qt5? Jun 15 02:30:14 https://github.com/meta-qt5/meta-qt5; Jun 15 02:30:33 http://wiki.qt.io/Transition_from_Qt_4.x_to_Qt5 Jun 15 02:31:09 events.linuxfoundation.org/sites/events/files/slides/Qt5YoctoSDK_0.pdf **** ENDING LOGGING AT Wed Jun 15 02:59:58 2016