**** BEGIN LOGGING AT Wed Mar 27 02:59:57 2019 Mar 27 05:48:18 New news from stackoverflow: How can I do "export $(dbus-launch) in booting Mar 27 08:09:59 Morning guys! Mar 27 08:10:25 I'm getting the following error when trying to extract the sdk (via -c populate_sdk): Mar 27 08:10:48 "Error: Transaction check error: file /lib/firmware/ti-connectivity/wl18xx-fw-4.bin from install of linux-firmware-wl18xx-1:0.0+git0+1baa34868b-r0.0.noarch conflicts with file from package wl18xx-fw-8.7.3-r0.0.cortexa9t2hf_neon" Mar 27 08:11:10 Has anyone faced the same issue? Mar 27 08:11:30 When I bitbake my image that doesn't happen Mar 27 08:11:58 (wl1837-fw is from meta-ti) Mar 27 08:13:14 I tried removing linux-firmware-wl18xx from the image in the local.conf file Mar 27 08:13:20 But it didn't worked Mar 27 08:13:23 work* Mar 27 08:15:30 not exactly the same issue, but I'm getting issues with linux-yocto-tiny .. so it's kinda related to linux-firmware Mar 27 08:15:42 not sure what's goign on Mar 27 08:18:01 I understand that the when it tries to install the wl18xx-fw from meta-ti the same file is already installed in the system (due to the previous execution of linux-firmware) Mar 27 08:18:33 What I don't understand is why is installing the file from linux-firmware Mar 27 08:18:45 Since it is not installed in the image Mar 27 08:22:20 I'm new to yocto so I can't help much, sorry ._. Mar 27 08:23:48 Uhu Mar 27 08:24:02 Welcome to a world of pain and, eventually, satisfaction Mar 27 08:24:16 (And some more random pain) Mar 27 08:25:10 Still, great world Mar 27 08:25:23 mkhoory: what problems are you seeing? there's little chance to help you given the current information. Mar 27 08:27:19 LetoThe2nd, I am following instructions to build yocto-tiny for qemuarm. Bitbake tries to fetch linux-yocto-tiny-4.18.21(etc.) which I assume is the kernel. It seems to finish downloading, but the fetch operation fails, and tries again and again Mar 27 08:27:40 I think the issue is that it's trying to check out a particular commit but it's not finding it. Mar 27 08:28:04 mkhoory: which instructions specifically? Mar 27 08:28:41 LetoThe2nd, sorry, i mean poky-tiny. Here: https://wiki.yoctoproject.org/wiki/Poky-Tiny Mar 27 08:29:42 mkhoory: and you're on poky master HEAD? Mar 27 08:31:01 no, I'm on a local branch that is tracking yocto-2.6.1, as described in the quickstart guide (https://www.yoctoproject.org/docs/2.6.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html) Mar 27 08:31:54 malanecora, my previous experience was with RTOSs like RTEMS. Yocto can't be more painful than that, can it? ;) Mar 27 08:32:17 mkhoory: ok, so its the yocto-2.6.1 tag. anything else that i need to know? Mar 27 08:32:37 mkhoory: Fair enough...haha Mar 27 08:35:00 LetoThe2nd, I've set my MACHINE variable to qemuarm, DISTRO to poky-tiny, and PACKAGE_CLASSES to "package_ipk". My layers are meta, meta-poky, and meta-yocto-bsp Mar 27 08:35:05 not sure what else to mention Mar 27 08:35:30 mkhoory: if its only those modifications, then noting else to mention. ok, let me give it a spin. will report back then. Mar 27 08:35:47 all packages seem to have been fetched and built correctly, it's just that bitbake is stuck on fetching the linux kernel or so it seems Mar 27 08:36:12 the raspberry pi issue I had seem to have been corrected after performing a git pull on the raspberry pi layer Mar 27 08:36:21 mkhoory: we'll see. just takes a couple of minutes, i'm kicking off a completely blank build to reproduce. Mar 27 08:36:30 ok thanks Mar 27 08:37:42 If you want I can paste my build log Mar 27 08:38:05 not yet. Mar 27 08:50:36 mkhoory: ok, i think i can reproduce it. Mar 27 08:50:55 mkhoory: let me see if i can actually spot the error, otherwise will probably have to wait for zeddii Mar 27 08:54:52 interesting Mar 27 08:55:41 I was suspecting that it's my network or something Mar 27 08:56:11 mkhoory: nope. i mean, its a config that doesn't get much exercise anymore. Mar 27 08:58:54 I was under the impression that poky-tiny is a pretty popular config for people to start off with Mar 27 08:59:01 mkhoory: absolutely not Mar 27 08:59:20 how come? isn't it the best way to start for resource-constrained devices, or for "lean" builds? Mar 27 09:00:31 mkhoory: poky in itself is the config to start off for small devices, but with the restriction of not sacrificing too much comfort. Mar 27 09:01:03 mkhoory: poky-tiny is rather meant as a showcase on how far you can go down if you REALLY REALLY want or need Mar 27 09:01:32 mkhoory: i mean, a standard poky core-image-minimal build for qemuarm is usually way less then 8MB Mar 27 09:02:48 I see Mar 27 09:04:42 My current target is to understand how the SDK works, how I can build applications for my target. But first I figured I'd get a yocto-tiny image running on qemu Mar 27 09:04:48 at least a hello world Mar 27 09:05:10 mkhoory: in that case, you're absolutely better off with using the standard poky Mar 27 09:05:35 mkhoory: you will run into WAY less problems Mar 27 09:06:05 I see. I have tried the standard poky on a raspberry pi and I felt I could trim it down further, which is why I was looking into yocto-tiny Mar 27 09:06:25 poky-tiny* .. damn I keep confusing the names >_> Mar 27 09:06:56 well of course you *CAN*. but the quesiton should be. "do i need?" Mar 27 09:07:22 because once you leave out a couple of standard basics for the sake of tinyness, life becomes complivated. Mar 27 09:07:26 eventually, yes, not for resource constraints, but just to reduce complexity of the image. Right now, now Mar 27 09:07:29 I understand that Mar 27 09:07:35 Right now, no* Mar 27 09:08:15 i mean, what complexity would you leave out of core-image-minimal on poky? its basically just kernel + busybox + minimal infrastructure Mar 27 09:08:37 so I was thinking, if I started with poky-tiny, I could add the packages I needed as I go, vs going through all the packages in the standard build and removing what I dont need Mar 27 09:08:51 mkhoory: naaaaah you're on the completely wrong track here. Mar 27 09:09:08 mkhoory: the IMAGE defines what goes into the generated thing. Mar 27 09:09:25 mkhoory: the DISTRO rather defines the ABI. like, selecting the libc Mar 27 09:09:58 of course there is some correlation, but for leaving things out of the image, well, leave things out of the image. Mar 27 09:10:32 I'm still very new. I appreciate your advice, it is very helpful. Thank you. I guess I'll switch to standard poky then. Mar 27 09:11:17 I still havent learned about recipes, etc. I was thinking I'd do that after understanding the SDK Mar 27 09:11:33 mkhoory: bad approach, if you ask me Mar 27 09:12:00 mkhoory: the sdk is something you can do once you have understood how images and recipes work. because the sdk actually is based off those Mar 27 09:14:36 mkhoory: reasoning behind this: the sdk is something that the image/distribution developer can prepare and hand out to people who are only expected to develop *FOR* the image/distribution, but not work on that itself Mar 27 09:14:57 mkhoory: yet if you are learning the yocto/OE ways, you are being the image/distribution developer Mar 27 09:17:27 I see. I will do more reading then. I just wanted to build a hello world app for my target Mar 27 09:18:29 mkhoory: wel, the "hello world" equivalent of a distribution dev is core-image-minimal + psplash :) Mar 27 09:24:20 sometimes I wonder if yocto is right for me, considering that the target is not mass produced, and i dont need a "distribution" as much as I need a linux kernel with my own custom applications Mar 27 09:25:18 it depends. and it certainly is not for every usecase. Mar 27 09:26:03 however, I do feel that separating the distribution from my applications would really assist with the development process Mar 27 09:26:44 and has other advantages like easily being able to install an updated version of my applications Mar 27 09:26:45 yocto/OE can offer a lot of power, if you actually invest in harnessing it. but its totally not a "i just want to" thing Mar 27 09:36:07 So, is there a way to exclude packages from being included in the SDK? Mar 27 09:36:34 I have already tried the classic ways Mar 27 09:47:21 mkhoory: so, in case you are interested in real, hard numbers for comparison: poky vs. poky-tiny is 5.4M / 1.3M for the kernel and 2.6M / 861K for the rootfs(cpio.gz) Mar 27 09:48:14 mkhoory: so the only real difference IMHO is that basically everything is ripped out of the kernel to render it bootable but useless for most usecases, for the sake of tinyness. Mar 27 09:53:26 zeddii: there is a typo in eta/recipes-kernel/linux/linux-yocto-tiny_4.18.bb: KBRANCH_qemuarm should refer to 4.18, not 4.15 Mar 27 09:56:39 Hi All Mar 27 09:57:17 is there any file in yocto where packages used in image are listed with SRC_URI ? Mar 27 09:57:43 rokm: no Mar 27 09:57:55 is there any command for this maybe ? Mar 27 09:57:59 rokm: no Mar 27 09:58:02 -.- Mar 27 09:58:18 rokm: what would that file list if the source file was locally included in the layer? Mar 27 09:58:28 LetoThe2nd, Interesting Mar 27 09:59:14 LetoThe2nd: it will be listed too Mar 27 09:59:35 I need this for licences things Mar 27 10:00:06 I read 3.32.3 chapter in PDM Mar 27 10:00:18 mkhoory: just gave it a try, poky-tiny is broken to the point where it doesn't even boot in the canonical runqemu anymore Mar 27 10:00:45 rokm: read what in where? Mar 27 10:01:11 rokm: i mean, its only software, about anyhing is possible. but its not there for you. if you think you need it, go create it. Mar 27 10:03:26 LetoThe2nd: 3.32.3. Maintaining Open Source License Compliance During Your Product's Lifecycle in Yocto dev manual Mar 27 10:04:48 rokm: yes, but as far as i know that paragraph, it nowhere states that you have to include all SRC_URI things in your image. Mar 27 10:05:01 yeee I know Mar 27 10:05:11 it states that you have to include the licenses, as explained in https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#providing-license-text Mar 27 10:05:27 It suggest to provide tarballs with sources Mar 27 10:05:46 as a additional inforamation about packages Mar 27 10:06:39 it suggests to provide the source tarballs, yes. again, SRC_URIs would be totally pointless as they might be valid only locally, and their payload would have to be in the tarball anyways. Mar 27 10:07:21 rokm: it sounds like you are trying to find a way around providing your metadata, as pointed out in https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#providing-compilation-scripts-and-source-code-modifications Mar 27 10:07:39 rokm: yet gplv3 is relatively clear about it. Mar 27 10:07:50 for previous point - you are right Mar 27 10:08:02 i know that i am right :) Mar 27 10:08:10 heard it a couple of times already. Mar 27 10:08:31 for second one - I need to collect licences information and URL to sources of packages that were used in image Mar 27 10:08:49 no Mar 27 10:09:06 you do not have to provide links or whatever to where you got stuff from Mar 27 10:09:13 you have to provide the sources. Mar 27 10:09:38 hmm :) Mar 27 10:10:03 but IANAL, and will better stop here. if you want to do things right, contact somebody who is experienced with this, and will stand in for given advice. Mar 27 10:10:12 (toganlabs, for example) Mar 27 10:10:31 OK Mar 27 10:10:47 I think you are right - again Mar 27 10:11:19 thanks Mar 27 10:14:52 LetoThe2nd, lol ok, I'll just wash my hands from that then Mar 27 12:49:40 New news from stackoverflow: OpenGL: Mesa3D Offscreen Software Rendering Performance Issues Mar 27 12:52:20 hi there, Mar 27 12:52:53 I have a recipe that depends on another one, actually it's a simple program using alsa-lib, I'm using SDK and devtool Mar 27 12:53:14 I wanted to add some debug to alsa-lib, so I made devtool modify alsa-lib Mar 27 12:53:47 I checked the sources did not eventually change anything Mar 27 12:54:18 but now devtool is failing with "* opkg_prepare_url_for_install: Couldn't find anything to satisfy 'alsa-lib'. Mar 27 12:54:18 " Mar 27 12:54:53 It's at the do_rootfs moment Mar 27 12:55:12 do you have any ideas about what went wrong? Mar 27 13:22:42 khem: have you noticed any reports that glibc is producing faulty binary when gold is used instead of bfd? I'm seeing it on armv7a when qemu-arm is crashing with segfault because of this Mar 27 14:18:41 kanavin: just doing my no more python2 in oe-core builds dance Mar 27 14:18:56 kanavin: asciidoc was the last hangon, and there's a good enough py3 port :) Mar 27 14:18:56 rburton: and how is it? Mar 27 14:19:03 it works -> ship it Mar 27 14:22:19 rburton: awesome, I guess there are still recipes that need python2 to run scripts at build time? Mar 27 14:23:02 kanavin: almost certainly. haven't done a build without py2 on host for a while. asciidoc managed to get rid of it from the build. Mar 27 14:23:55 so basically, nothing explicitly lists python(-native) in its DEPENDS anymore? Mar 27 14:24:59 not in sato builds Mar 27 14:26:28 what happens if you remove the python2 recipes, and try to build world? Mar 27 14:26:32 does anything complain? Mar 27 14:27:13 shall try shortly Mar 27 14:27:25 (pnblacklist is better) Mar 27 14:27:52 kanavin: welcome back, hope you have a good break! :) Mar 27 14:28:16 ca-certs needs host py2 still Mar 27 14:28:50 rburton: does it need "python" or py2 specifically? Mar 27 14:29:07 RP: python, but we symlink that to py2. not sure if the code is py3-safe. Mar 27 14:29:08 * RP notes we still have "python" pointing at py2 Mar 27 14:29:22 yeah had to neuter that because it assumes that py2 is in the hosttools :) Mar 27 14:29:31 ninja too Mar 27 14:29:46 pretty sure ive got a patch for these somewhere Mar 27 14:30:35 rburton: did you make it point at py3? might make for an interesting test Mar 27 15:28:39 * kergoth yawns Mar 27 15:32:42 RP: cheers, yes it was a good one :) Mar 27 15:34:51 RP: I sent a few housekeeping patches; I also have more invasive version upgrades, which I am holding back until after warrior is done (I guess?) Mar 27 15:37:10 kanavin: sounds good, we are after freeze and need to focus on release now Mar 27 16:15:40 khem: does llvm really need perlnative pythonnative to build? Mar 27 16:15:55 khem: specfically why python2-native? its not the dependencies. Mar 27 16:45:07 RP: when is the next release cutoff? i think mesa needs a small tweak to build for etnaviv Mar 27 16:47:27 and bitbake/glibc need some tweak to produce usable libc when gold is enabled :/ Mar 27 16:47:32 binutils/glibc Mar 27 16:48:11 RP: is gold enabled in any of the builds run on AB? Mar 27 16:54:07 JaMa: no Mar 27 16:55:19 tlwoerner: We're effectively in freeze now. I know the mesa update was late, I was persuaded it was probably the better version to have though. If its causing pain we might have to consider reverting :/ Mar 27 16:56:46 ll Mar 27 16:56:47 RP: i don't think etnaviv is widely used, and i think the fix is quick (a 1:1 replacement). i'm looking into it now Mar 27 16:59:02 tlwoerner: ok. its a tricky issue knowing what to do with updates close to release Mar 27 16:59:33 we stand a way better chance of upstream help with bugs if we're close to released versions though Mar 27 17:13:20 RP: all good, the change needs to be made to a _bbappend in meta-freescale Mar 27 17:25:52 speaking of mesa, we might actually want to again update to 19.0.1 Mar 27 17:26:36 as x.0.0 releases are considered 'development' by the upstream (even though they still go through a few rc iterations to fix known issues :-/ Mar 27 17:26:51 19.0.1 is not yet out though Mar 27 17:27:02 oh, it is! Mar 27 17:27:57 Hi all. I'm new to bitbake/yocto, and trying to come up to speed. Bit of a learning curve, but it's pretty amazing all that it does. Anyways, I'm trying to make a hello world image for a NXP/freescale dev board. Mar 27 17:28:04 My settings are: machine = imx7ulpevk, distro = fslc-x11, layers (all checked out to sumo) = meta-poky, meta-oe, meta-freescale, meta-freescale-distro, meta-freescale-3rdparty, meta-yocto-bsp target = core-image-minimal Mar 27 17:28:37 Things look good on the card, but u-boot is completely silent, when trying to boot Mar 27 17:29:04 anybody have any thoughts? or places I should look into? Mar 27 17:31:41 kanavin: https://www.mesa3d.org/relnotes/19.0.1.html you have 19.0.0 link in the 19.0.1 upgrade Mar 27 17:31:53 armpit: we have a problem with fedora29 and sumo: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/120 Mar 27 17:31:59 JaMa, that is on purpose, as that's where the policy is specified Mar 27 17:32:11 (the policy regarding 19.0.0 vs 19.0.1) Mar 27 17:34:27 kanavin: it's like that for couple releases (at least since 17.0.0 http://lists.openembedded.org/pipermail/openembedded-core/2017-February/132762.html) isn't list of bugfixes in 19.0.1 more important than this old change in mesa versioning? Mar 27 17:35:13 JaMa, nope, and if you want the bugfixes, just change the single letter in the URI Mar 27 17:36:12 I need to explain why a version update this late in the release cycle, so a link to the upstream explanation is appropriate Mar 27 17:36:16 RP, k Mar 27 17:36:48 on the other hand, this will not be backported to any stable branches (which is where the list of fixes is useful to the branch maintainers) Mar 27 17:36:56 RP, same error from last night Mar 27 17:38:04 armpit: for the sstate errors, halstead is going to comb over the sstate mirror and remove the broken artefacts, we'll then rerun and see if they reappear Mar 27 17:38:13 * RP isn't sure why that happened :( Mar 27 17:38:36 uninative ? Mar 27 17:38:43 armpit: no Mar 27 17:39:05 * RP suspected the buildperf machines but its probably not them, or I can't find a codepath anyway Mar 27 17:39:33 just blame Canada Mar 27 17:39:46 * armpit south park ref Mar 27 18:16:23 ...speaking of mesa... Mar 27 18:16:44 the layerindex needs to be regenerated, it still thinks openembedded-core's mesa is at 18.3.4 Mar 27 18:17:01 (which leads to bad links when clicked) Mar 27 19:22:54 tlwoerner, layerindex update has been running for 2 days. I've killed the update and allowed it to restart. Mar 27 19:23:31 halstead: that's odd, i thought it normally runs several times a day? Mar 27 19:27:23 tlwoerner, It does. Every 3 hours. But if it is already running another won't begin. Mar 27 19:27:44 ouch! big update i guess Mar 27 19:32:58 RP, armpit Here is small list of missing siginfo files. Should I remove the corresponding tgz files? Mar 27 19:33:06 RP, armpit http://sstate.yoctoproject.org/5e-missing.txt Mar 27 20:20:10 tlwoerner: halstead: if it's been running for 2 days there is some kind of problem :/ Mar 27 20:20:29 could you see where it was stuck? Mar 27 20:28:38 are there any plans to switch mesa to use meson? Mar 27 20:28:55 tlwoerner: there is change for that on the ML Mar 27 20:29:11 nice! Mar 27 20:43:07 bluelightning, The last log lines before I killed it are up at https://paste.fedoraproject.org/paste/-LA18rI8RzzHfrMoCUMrIg Mar 27 23:04:44 halstead: I think its fine to remove those. I was wondering if there is a pattern but I can't spot one Mar 27 23:08:12 RP, Okay. I'm still searching out files that is just a small selection. I haven't found the reason why these are missing but not the tarballs yet. Mar 27 23:17:42 halstead: is it only a subset of the sstate directories like 5e but not others? Mar 27 23:18:28 halstead: I did log onto the nas and removed the 2.4.999, 2.6.999 and similar sstates just to reduce some confusion on the public facing interface Mar 27 23:23:27 armpit: FYI I backported an extra patch to sumo to avoid testresult problems Mar 27 23:23:33 armpit: was already in thud Mar 27 23:24:15 halstead: I think I'm ready to trigger attempts at the stable builds again. Not sure if i should wait for the sstate cleanup or go for it... Mar 27 23:50:45 RP, thanks Mar 28 00:13:19 * RP gives a build another try since it likely won't hit the errors second time around as the release sstate mirror is already there **** ENDING LOGGING AT Thu Mar 28 02:59:57 2019