**** BEGIN LOGGING AT Fri Jun 21 02:59:57 2019 Jun 21 07:02:05 good morning Jun 21 07:17:59 hello. My do_populate_sdk for my image fails on qttools -> warning: library search path "/usr/lib/llvm-6.0/lib" is unsafe for cross-compilation Jun 21 07:18:25 \/usr/lib/llvm-6.0/lib/libclang.so: file not recognized: file format not recognized Jun 21 08:25:17 Hi guys, do you have any hints about this one : https://community.nxp.com/message/1167806 Jun 21 08:25:31 I've found a thread here from two years ago but the issue did not seems to be fixed : https://yocto.yoctoproject.narkive.com/BofTeBvr/esdk-install-script-failure Jun 21 08:27:03 I guess we have the same issue now, but I have try many things and always end up stuck at the same point Jun 21 09:08:10 hello folks Jun 21 09:08:21 i wonder whether the sstate-cache works like ccache, in a way Jun 21 09:08:25 that it stores .o files Jun 21 09:10:06 no Jun 21 09:10:09 it stores the packages Jun 21 09:10:14 (and other metadata) Jun 21 09:10:54 if you delete tmp and rebuild and image from sstate, it simply extracts the packages from sstate and then builds an image, nothing else needs to be done Jun 21 09:14:54 rburton, ahh, i see! Jun 21 09:25:33 does yocto allow me to use docker images on the system created with yocto? i mean: does it have build recipies for the docker daemon? Jun 21 09:26:41 Piraty: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=docker Jun 21 09:27:12 rburton: thanks a lot! Jun 21 09:27:49 thats the answer to 'is there a recipe for ' Jun 21 09:28:37 i see Jun 21 09:28:45 * Piraty bookmarked the link Jun 21 09:29:22 i'm in the process of evaluating build systems so $management can make a decision :-/ Jun 21 09:35:33 note that meta-virtualisation is behind https://resources.windriver.com/helix-platform/wind-river-helix-virtualization-platform-demonstration work, so presumably it actually works Jun 21 09:41:02 this sentence in the manual reads rather funny: "The source archiver class can generate tarballs and SRPMs and can create them with various levels of compliance in mind. " Jun 21 09:41:56 in my mind, it reads the same as "... and can create them with various levels of non-compliance in mind." Jun 21 09:42:39 lol yeah the english there isn't great Jun 21 09:43:10 question: do we want to prefer pigz over gzip (paging RP) Jun 21 09:44:31 (i think yes) Jun 21 10:02:32 New news from stackoverflow: How to configure LIC_FILE_CHECKSUM for https downloads in SRC_URI in Yocto Jun 21 10:15:35 Hi guys. I have updated the yocto layers to 'thud'.. But now, the U-boot can't load the kernel, it say: "Wrong Image Format for bootm command"... When I have replaced the new uImage with an old uImage, then it booted. So, seems that in a new layer the kernel uImage has a different format.. So, my question is: where is it possible to change the Kernel Image format: in yocto or in menuconfig? Jun 21 10:35:01 rburton: yes, I think so Jun 21 10:36:40 rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/739 :/ Jun 21 10:36:50 rburton: | pigz: abort: internal threads error Jun 21 10:37:45 rburton: max open files too low on opensuse151 maybe Jun 21 10:40:32 hmm, same on all the workers Jun 21 11:18:54 Hey guys anyone how to install postgresql? Jun 21 11:19:38 I cant use the psql command Jun 21 11:30:51 hm, why does the core-image.../ folder in deploy/licenses/ sometimes contain license.manifest with a list of all packages in the image.. and sometimes, it doesn't Jun 21 11:31:04 sometimes, it does only contain image_license.manifest with the bootmanager licenses in it! Jun 21 11:32:45 New news from stackoverflow: core-image-weston with x-server backwards compatibility Jun 21 11:36:03 Someone know how to install postgreSQL and use the psql tool? Jun 21 12:23:17 hm, when I'm using the archiver class and let it archive the sources used to build the image, does it also archive the build-dependencies? i.e DEPENDS-recipes of them? Jun 21 12:23:29 iirc, GPL requires it Jun 21 12:26:14 RP: damnit!! Jun 21 12:27:01 litb: if you do a build from scratch, then it will archive *everything* used Jun 21 12:27:33 RP: maybe its threading too heavily and hitting the limit anyway? or is the limit huge Jun 21 12:32:53 RP: oddly i thought sstate_create_package was already using pigz Jun 21 12:33:49 yes Jun 21 12:34:05 they all failed like that? Jun 21 12:50:58 i honestly didn't think i changed anything for the native case Jun 21 12:57:48 RP: oh that build only has the priority change, so how can that be my fault :( Jun 21 13:23:02 what do I run to make an 'rpi-sdimg' file from my built without rebiolding? Jun 21 13:23:02 rburton: I'm not blaming you, just bad luck with you asking about pigz I think Jun 21 13:23:06 *building Jun 21 13:23:29 rburton: it is odd coincidence though :/ Jun 21 13:25:51 rburton: Ah, I figured it out; I did fix perl-ptest, I just haven't pushed the patches to the mailing list (I wasn't done testing them) Jun 21 13:31:30 rburton: At least, I think http://lists.openembedded.org/pipermail/openembedded-core/2019-June/283946.html will fix it Jun 21 13:47:21 JPEW: cool Jun 21 14:02:08 weird. in the manual, it says that in order to use PREMIRROR with git repositories, you need to set BB_GENERATE_MIRROR_TARBALLS : " Causes tarballs of the Git repositories, including the Git metadata, to be placed in the DL_DIR directory. Anyone wishing to create a source mirror would want to enable this variable. " Jun 21 14:02:59 why is this? I don't have set that variable, any my DL_DIR contains git repository clones in DL_DIR. why is this not sufficient to create a source mirror? Jun 21 14:22:38 litb: IIRC BB_GENERATE_MIRROR_TARBALLS pacakges up the git repos a little differently, and you have to do it that way to publish them as a premirror Jun 21 14:33:13 New news from stackoverflow: CrossCompile jrxtx with yocto Jun 21 14:41:18 w1ndy_: https://layers.openembedded.org/layerindex/recipe/5558/ Jun 21 15:07:30 rburton, O problema é que esse pacote não instala o psql Jun 21 15:08:49 rburton, Sorry for that. The problem is that i cannot use psql. i can only connect to it remotely Jun 21 15:09:51 JPEW, ah i see! Jun 21 15:10:13 maybe it's even more efficient because the git repository will contain all the history while the tarballs could contain just the needed snapshots Jun 21 15:11:38 litb: Ya, I'm the "normal" format for git repos in DL_DIR is more efficent that the mirror tarball format, but the mirror tarball lets you get everything in a single file download Jun 21 15:11:57 s/I'm/I suspect/ Jun 21 16:09:38 JPEW, thanks! Jun 21 16:10:14 I'm currently looking into using the archiver.class-generated tarballs as a PREMIRROR. understanding the PREMIRROR syntax is a bit daunting ^^ Jun 21 16:22:42 this should definitely be part of the manual: https://www.inango.com/wp-content/uploads/2019/01/Yocto-Source-Mirrors-Mechanism.pdf Jun 21 16:28:57 litb: I don't think you can use the archive.class genertated tarballs for PREMIRRORing Jun 21 16:29:34 JPEW, ohh, hm. I thought that it was the whole point that I can hand over the source code for my image to customers, so that they can rebuild and customize it Jun 21 16:30:39 Perhaps for archiver.bbclass, but I don't think thats the purpose of a premirror Jun 21 16:31:08 archiver is for GPL compliance Jun 21 16:31:27 JPEW, yeah, I'm just reading the above mirror-mechanism pdf and it says that if the protocol is changed for a mirror, then if the original protocol was git, then the changed protocol needs to fetch from a tarball called like 'git2_hostname.path.to.repo.git.tar.gz' Jun 21 16:31:37 that's not at all what the archiver-output names look like, i'm afraid Jun 21 16:31:38 if you want to host a source mirror then just share your DL_DIR Jun 21 16:32:15 if you want it to include *just* what is needed then that's simple enough: new config, populated DL_DIR as premirror, bitbake world -c fetch. Jun 21 16:33:05 rburton, hm, we are in the impression that for GPL and LGPL compliance, we need to provide the source-code of the used libs, so that the user can rebuild them. Jun 21 16:33:32 sure, and the tarball+patches is absolutely acceptable for tha Jun 21 16:33:34 therefore, since archiver is for gpl compliance, we thought that it provides us with that functionality :/ Jun 21 16:34:09 rburton, hm, but for that, it needs the buildsystem aswell, and a way to inject that code so that the buildsystem uses it Jun 21 16:34:31 I thought that this is the purpose of PREMIRRORS or DL_DIR Jun 21 16:34:43 now you're entering 'speak to your lawyer' territory. releasing the layer would be an interesting interpretation. Jun 21 16:35:00 PREMIRRORS is just a mirror that is used first. DL_DIR is the local cache. Jun 21 16:36:21 hm, I think that then we may be better of tarballing our DL_DIR (and enabling mirror-tarballing of git), and not using archiver, and releasing our bsp and os layer Jun 21 16:36:23 if you want to include build instructions then just push the layer, and use archiver to expose the tarballs. the layer will refer to the upstream SRC_URIs and contain the patches, right? archiver is needed to satisfy the terms but can otherwise be ignored. Jun 21 16:36:53 people who just want to satisfy gpl and that's it just use archiver to get the tarballs/patches for all the GPL pieces Jun 21 16:36:56 the archiver then seems to be of not much use for us, since the above things will do all it does aswell, and more Jun 21 16:37:39 not sure why you think premirrors/git-tarballs is needed for gpl Jun 21 16:37:54 unless you're hosting a source mirror for kindness Jun 21 16:38:27 which is fair as that's what http://downloads.yoctoproject.org/mirror/ is Jun 21 16:38:52 rburton, colleagues read the GPL. I can speak for the LGPL only now. the LGPL requires that if you distribute binaries, you also need to distribute the sources, and build scripts and any patches you used Jun 21 16:39:21 arguably the build scripts are in the tarball: makefile etc Jun 21 16:39:22 so if you just distribute the sources and patches, it's not enough because users can't build the software with them. they need the layers aswell, and a way to tell the layers to use those sources Jun 21 16:40:07 but as i said, if you want to include the layer in that definition then push the layer to git Jun 21 16:41:14 rburton, thanks. i think that's what we should do. the archiver would still be usedful because it will contain all licenses and all copyrights. we must distribute those alongside our binaries Jun 21 16:41:21 right Jun 21 16:42:05 and for people to be able to rebuild from source, we don't need to distribute all the build-dependencies alongside. so for that, we can on-demand distribute the DL_DIR (stripped of proprietary things) Jun 21 16:42:48 why isn't the archiver enough for that? Jun 21 16:43:47 at no point does the *gpl say that the source provided has to be the same one that is built. archiver+layer is sources+build instructions Jun 21 16:44:57 it says that the complete and corresponding sources need to be provided. which according to colleagues and books they read means that it must be the same source Jun 21 16:45:14 including any patches applied in them Jun 21 16:45:37 and the build scripts. but not necessarily toolchains or common system libraries Jun 21 16:46:12 i disagre, but fine. ship a DL_DIR: the little trick above will make a fresh one with only what you needed. Jun 21 16:49:46 thanks Jun 21 16:50:10 weird that deploy/licenses/ + deploy/sources/ output is around 1.3GB but build/downloads/ is 12GB. that's very unexpected Jun 21 16:50:46 it's probably the toolchain that takes all that. Jun 21 17:57:20 can it be assumed that the latest version of bitbake will work with metadata that was built using an older version of bitbake? Jun 21 18:17:07 rewitt: i wouldn't want to bet on it Jun 21 18:18:13 rburton: That's what I thought, I'm trying to figure out all the reasons to say why I won't put bitbake in the container images https://github.com/crops/poky-container/issues/36 Jun 21 18:39:18 rewitt: as reasons go, the total lack of api stability is a pretty good one Jun 21 18:40:45 rewitt: close it :) Jun 21 18:40:54 rburton: Thanks. That was my first reason, but I did add another reason because a new user isn't going to understand they are essentially asking "Why isn't there a bitbake package?" Jun 21 18:41:16 that reminds me! kergoth can you remove bitbake from pip please :) Jun 21 18:41:31 kergoth: https://pypi.org/project/bitbake/ Jun 21 18:41:46 oh maintainer zecke, misread the author bit Jun 21 19:02:09 RP, AB changes are ready for testing. Anything to queue? Jun 21 19:08:38 * halstead runs errands. Jun 21 19:10:29 * darknighte realizes it's been > 6 months since connecting to #yocto Jun 21 19:13:12 lol Jun 21 19:17:45 * darknighte waves at fray Jun 21 19:23:07 \o/ Jun 21 20:34:15 New news from stackoverflow: How should incrementing a package revision be handled when adding/editing a .bbappend file? Jun 21 21:47:12 welcome back darknighte! :) Jun 21 21:47:49 halstead: build is away Jun 21 21:55:01 RP: thx! Jun 21 22:22:52 Thank you RP. I'll check in on it in a few hours. **** ENDING LOGGING AT Sat Jun 22 02:59:57 2019