**** BEGIN LOGGING AT Fri Dec 11 02:59:58 2015 Dec 11 05:23:09 #c++ Dec 11 07:40:14 Hi, does opkg give a way to build deb files from source (like dpkg-buildpackage)? Dec 11 08:41:07 hi all Dec 11 08:41:17 how can I bitbake qt source alone? Dec 11 08:41:23 bitbake meta-qt5? Dec 11 09:22:23 kanupatar: You want to build qtbase? Dec 11 09:40:40 anyone capable of creating a fido branch in the meta-mingw layer? Dec 11 10:05:40 sujith_h: yes Dec 11 10:06:02 kanupatar: Yes you can use go with meta-qt5 Dec 11 10:06:25 sujith_h: error Dec 11 10:06:35 sujith_h: I have tried it earlier Dec 11 10:06:56 sujith_h: | grep kerala ? Dec 11 10:38:37 kanupatar: What is the error you get? Dec 11 10:38:54 kanupatar: yup Dec 11 10:46:13 sujith_h: now it is solved Dec 11 10:46:23 sujith_h: where Dec 11 10:49:03 Hi, can somebody tell me how to add a library to the meta-toolchain? Dec 11 10:50:27 DatGizmo: don't use meta-toolchain, instead use the populate-sdk task on your image Dec 11 10:50:33 ie bitbake core-image-sato -c populate_sdk Dec 11 10:50:51 then you get a toolchain that includes all the libraries that you've got in your image Dec 11 10:51:13 rburton: then all libraries which are used in the image will be in the toolchain? Dec 11 10:51:18 yes Dec 11 10:51:26 rburton: thanks :) Dec 11 12:03:01 <|Sno|> JaMa: what's about the samba patches flying around on oe-devel@? (http://lists.openembedded.org/pipermail/openembedded-devel/2015-November/104740.html, http://lists.openembedded.org/pipermail/openembedded-devel/2015-November/104721.html - and follow ups) Dec 11 12:14:00 |Sno|: I'm still waiting for test-dependencies jenkins job to finish Dec 11 12:14:26 it will take few more days or a week Building recipe: python-numpy (1780/2503) Dec 11 12:16:17 <|Sno|> JaMa: thanks for the update :) Dec 11 12:16:45 <|Sno|> I still think, Yocto needs something like gnats for patch submittng, too Dec 11 12:17:12 <|Sno|> that saves those insane questions ... Dec 11 12:19:16 we have patchwork Dec 11 12:29:36 and we have people working on making it more awesome too Dec 11 12:30:16 https://patchwork.freedesktop.org/project/intel-gfx/patches/ <— like this Dec 11 12:38:48 <|Sno|> JaMa: the 2nd sent patches aren't in patchwork Dec 11 12:38:55 <|Sno|> only those from 13th Nov Dec 11 12:47:41 I see some from 19th: http://patchwork.openembedded.org/project/oe/list/?state=*&q=samba&archive=both Dec 11 12:48:11 test-dependencies job is running since 20th Nov Dec 11 13:57:58 |Sno|: there is also upgrade for talloc and libldb in master-next, I don't know which one Joe plans to merge first but they conflict with each other Dec 11 13:58:12 but contrib/joeythesaint/meta-networking-next contains your changes Dec 11 13:58:16 not the upgrades Dec 11 14:00:48 otavio: Hi, Do you know how to get access from linux to the persistent bits in the System Reset Controller of an IMX6? Dec 11 14:07:16 |Sno|: now they are also included in master-next Dec 11 14:07:19 for test next week Dec 11 14:32:42 hi is there a package to stress linux system? something like stress-ng ? Dec 11 14:33:14 stress what? memory? io? network? Dec 11 14:34:25 pretty much everything that might be possible. Mainly cpu but also memory Dec 11 14:35:42 there seem to be a few packages - stress, crashme - never used them myself. Dec 11 14:35:57 to put in context, i have a stream of data coming in over serial port, constant stream of 115kbps. what I really want to see is if the kernel can handle this under heavy loads Dec 11 14:36:19 if I'm just trying to find out if a system has faulty equipement (ie I don't need stats) then I just build the kernel woth maximum parallelism about 4 times in a row. Dec 11 14:37:44 @fledermaus: can you point me where those recipes (stress, crashme) live? Dec 11 14:38:14 sure, one moment. Dec 11 14:38:27 (@ doesn't mean what you think it means on IRC btw) Dec 11 14:40:24 don't know where the upstream is but the original source and debian packaging are here: Dec 11 14:40:33 https://packages.debian.org/jessie/stress Dec 11 14:40:52 may or may not already be available in yocto/oe/etc Dec 11 14:44:38 darkhorse_: may be something appropriate in here http://layers.openembedded.org/layerindex/branch/master/recipes/?q=bench Dec 11 14:45:24 e.g. lmbench or stream Dec 11 14:54:02 So do you need to add packages like zlib into RDEPEND in packages? Dec 11 14:54:22 I see it in DEPEND but not in RDEPEND on a package I'm working with Dec 11 14:55:14 but the binary needs zlib Dec 11 14:56:01 I'm coming at this as a Gentoo guy (I know in the before times in the long long long ago bitbake took some influence from Gentoo) and in our case you need to list all those out in RDEPEND. Just wondering if someone got lazy. Dec 11 14:57:09 Cardoe: if the library is linked in normally (dynamic linking) then it is implicitly RDEPENDed upon, aiui. Dec 11 14:57:20 thanks fledermaus, much appreciated :) Dec 11 14:57:47 you only need a package in RDEPENDS if it is an external binary, or the library is dlopened or similar. Dec 11 15:00:41 fledermaus: ah ok. So in the case of zlib its in SO_NEEDED so its fine. Dec 11 15:02:38 fledermaus: so follow on. The package in question is xen from meta-virtualization. If it builds up xen-libvhd and then it also builds up xen-blktap as two different packages. If the binaries inside of xen-blktap have SO_NEEDED on libvhd do I need to add that into RDEPEND can it work out RDEPENDS within a package? Dec 11 15:07:56 Did that make sense? Dec 11 15:09:40 fledermaus: no, you don't, it'll handle inter-package runtime dependencies within a single recipe just as it does for any other packages Dec 11 15:09:44 er, Cardoe Dec 11 15:09:47 sorry, miscomplete Dec 11 15:10:25 kergoth: thanks Dec 11 15:13:16 hmm? Dec 11 15:13:18 oh. Dec 11 15:13:23 * fledermaus returns to his slumber. Dec 11 15:27:38 t0mmy: I did a syscall change for the reset Dec 11 16:11:28 <|Sno|> JaMa: I'm happy to resend my patches after the update, that was the root-cause of my question regarding the status :D Dec 11 16:19:40 t0mmy: Android kernel does it Dec 11 17:15:57 RP: around ? I am seeing a problem with 1.6 bitbake when sstate is plugged into workspace from a sstate server over nfs, the problem happens when it cant find a particular sstate object on server, it returns error from fetcher and then proceeds to build the package locally and build succeeds in the end. However the end return code of bitbake is still error code that it got from sstate fetch failure, this is breaking autobuilder since it then thinks build Dec 11 17:15:57 has failed, any ideas ? Dec 11 18:27:04 Hi! I had a weird case and I'm trying to figure out what happens and if you guys have seen something like that. Dec 11 18:27:15 I have created a USB bootable key and tried to boot on a NUC with Ubuntu installed on SATA. Dec 11 18:27:35 It boot the yocto kernel then start the Ubuntu rootfs? I mean it pop the Ubuntu desktop... Dec 11 18:27:52 So I disable the SATA in the BIOS then manage to boot the sato-dev usb key image. Dec 11 18:28:07 Then removing the usbkey and reenabling the SATA back and was unable to boot ubuntu anymore? Dec 11 18:28:15 I was seeing 2 SATA drive in the BIOS with same label?? Dec 11 18:28:28 So what could have cause this? Dec 11 18:28:51 If you want more details here my procedure: https://gist.github.com/kapare/6b5f1f1ca4c5b3e570c2 Dec 11 18:45:40 kergoth: do you keep your ticket IDs when comitting into OE repos ? Dec 11 18:46:22 generally no, we don't want to clutter up the upstream repos. we include them for commits to our layers (i.e. meta-mentor, meta-sourcery) even if they're public, but once it goes from there to upstream we drop that metadata Dec 11 18:53:10 Hmm, would https://github.com/MentorEmbedded/meta-mentor/pull/636 make sense for upstream? TOPDIR is dangerous to export, but it's useful to have available, hence the OE_ prefix. it's a different approach for yocto #7670 Dec 11 18:57:47 found part of my problem after mounting the image -> /media/boot/EFI/BOOT/grub.cfg -> linux /bzImage root=/dev/sda2 ... should use the UUID Dec 11 19:18:23 kergoth: ok from meta-mentor -> oe-core is one way path Dec 11 19:18:36 but say if you change oe-core internally Dec 11 19:18:51 and propose that change into upstream oe-core Dec 11 19:19:08 do you have different commit policies for meta-mentor and oe-core internally ? Dec 11 19:19:37 we almost never fork upstream, in the rare case it's necessary we'll include issue info in those commits, but strip it out when we submit them and rebase the branch if necessary Dec 11 19:20:48 we had to fork oe-core/poky for a release since we required the shallow git bits and that wasn't merged upstream yet, and you can't modify bitbake from a layer, but that's a pretty rare case for us Dec 11 20:02:11 Hello, I'm having some troubles with libdrm; when I try to build qtbase (from meta-qt) with GLESv2, it uses TI's proprietary driver (omap5-sgx-ddk-um-linux from meta-ti) Dec 11 20:02:37 these drivers (libIMGegl.so, libsrv_um.so) raise "undefined reference" to libdrm.so (and libdrm_omap.so, libwayland-server.so) because they are not in the sysroot Dec 11 20:03:41 but I could see they are nicely packaged in my deploy/rpm, so why they are not extracted to my sysroot? Dec 11 20:54:23 Hmm, we should implement REQUIRED_PACKAGECONFIG Dec 11 20:54:53 ie rpm's beecrypt dep seems to be mandatory, and our packaging requires debugedit, which is only built if the libelf packageconfig is enabled Dec 11 20:55:03 also librpm/librpmdb will fail to link without db Dec 11 20:55:27 qemu requires fdt for some targets, wpa needs at least one ssl implementation.. Dec 11 21:01:15 I agree it could be a good safety net Dec 11 21:01:54 I expect most folks don't go removing random packageconfigs, but still, as you say, best to be safe. also i imagine some folks would want to pare things down as much as possible, so some sort of guideline about what will completely xplode when doing that would be good Dec 11 21:02:12 khem`: https://gist.github.com/kergoth/2c556d9e34cbcd03cb82 - twisted and wrong, i know Dec 11 21:02:15 :) Dec 11 21:03:15 good start at least Dec 11 21:03:24 seems a bit windy on a friday Dec 11 21:03:27 :) Dec 11 21:04:31 planning on reworking that to emit a .conf with PACKAGECONFIG_remove_pn-foo lines instead of running every time Dec 11 21:05:15 going through all the random prototyped crap i have laying around that i never did anything about :P Dec 11 21:05:32 https://github.com/kergoth/meta-named-configs-prototype#readme, https://github.com/kergoth/meta-named-configs-prototype/blob/master/recipes-core/busybox/busybox_1.23.2.bbappend Dec 11 21:07:25 hmm Dec 11 21:42:02 Hmm, I need to write some unit tests for the shallow git support, and that's not going to be fun Dec 11 21:44:28 * paulg wonders on which repos the shallow support delivered a substantial saving. Dec 11 21:45:56 paulg: kernel is the big one, the git mirror tarball is >1gb Dec 11 21:46:12 shallow, depending on how much history you want to keep, is around 130mb Dec 11 21:46:27 if you're distributing sources to a customer for BB_NO_NETWORK support, its significant Dec 11 21:48:01 the cool thing is, instead of going just by commit depth on a branch/srcrev, you can specify specific revs to remove, which means you could remove, say, all of the kernel.org commits and keep all of your changes from there by excluding the most recent version tag which was merged to the branches you care about. i.e. remove v4.0 and previous but keep everything else Dec 11 21:48:24 then the person getting it can restore the missing content from kernel.org which a quick git fetch --unshallow Dec 11 21:48:29 odd, mainline is about 600MB, and when we purge the stable tags we don't use, I would be surprised if we broke 1G Dec 11 21:49:01 removing unused branches or tags does very very little, because 90% of the commit history is common to all branches Dec 11 21:49:10 the first thing we did was look into single-branch Dec 11 21:50:00 all the stable stuff is off on individual branches, so getting rid of that is a win. Dec 11 21:50:41 we saved like 25 megs by removing all branches/tags but the one referenced in the SRC_URI Dec 11 21:50:45 pretty trivial Dec 11 21:50:47 * kergoth shrugs Dec 11 21:51:47 oh well, even if it isn't a giant win, it can't hurt to have the ability. Dec 11 21:52:49 the shallow support by default filters the branches, but having it without that woudln't be a bad thing Dec 11 21:53:11 can't really use it much on linux-yocto atm though, it requires that multiple branches be kept around for its branch validation stuff at the moment Dec 11 21:54:02 shallow proved itself to be a huge pain in the ass, way way more complex than you might think. shallow is implemented with a graft to remove the commit's parents. if a later commit merges an earlier commit from before the grafted point, nearly all of the history is still kept Dec 11 21:54:15 jumps right over the graft Dec 11 21:54:25 had to instead graft every point where the history intersects our branches Dec 11 21:55:09 yeah, knowing what I know about git, I'd largely written off shallow as a clusterfsck in the making. Dec 11 21:56:05 its improved quite a bit now that you can fetch --unshallow and whatnot. .git/shallow is just a list of commits to graft to nothing. the common case of clone --depth is easy, but we can't do that since we don't know the depth from branch HEAD to SRCREV Dec 11 22:00:16 * kergoth ponders Dec 11 22:12:01 * kergoth considers submitting https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mel/classes/sstate-distro-fallback.bbclass for oe-core (or at least meta-oe) Dec 11 22:29:13 So, I still don't understand how files are copied to the sysroot Dec 11 22:29:55 on omap5-sgx-ddk-um-linux, I added 'DEPENDS += "libdrm"', and I can't see libdrm*.so in my sysroot Dec 11 22:30:13 and qtbase still fails for the same errors Dec 11 23:00:08 if you added it to depends, then it will be in the sysroot for the recipe depending on it. Dec 11 23:00:12 look again Dec 11 23:13:47 kergoth: I found something interesting, libdrm from meta-ti won't install its lib in the sysroot, but the default libdrm will Dec 11 23:14:24 I'm trying to compare the Makefile.am from their sources (since both include the same libdrm.inc) Dec 11 23:14:41 (nothing really different so far) Dec 11 23:16:37 if libdrm didn't install its files into the sysroot, the recipe would be useless, but we do builds from meta-ti on a daily basis.. of course, we haven't updated our upstream layers in a while, maybe it was a recent change Dec 11 23:16:58 kergoth: nope Dec 11 23:17:08 kergoth: no recent changes Dec 11 23:19:04 kergoth: are those builds made with a compatible machine (ti33x|ti43x|omap-a15)? Dec 11 23:19:15 made for* **** ENDING LOGGING AT Sat Dec 12 02:59:59 2015