**** BEGIN LOGGING AT Mon Nov 05 03:00:01 2018 Nov 05 08:50:49 <_mac13_> Hi, I have problem with creating recipe that use azure git repository. BB is not able to fetch sources from git, error is fatal: Unable to look up ssh.dev.azure.com:v3, but when I switch : with / then fetch timeouts because git adds .git at the end of ther url, I have no idea how this link should look Nov 05 08:51:10 The certificate on git.yoctoproject.org has expired Nov 05 09:19:05 hello, is fetching via gitsm currently broken in any way on poky master branch? Nov 05 09:19:19 because it somewhat looks that way to me Nov 05 09:19:48 for example I set SRC_URI = "gitsm://eserver/cgit.cgi/eepromctl;protocol=http;branch=master" Nov 05 09:20:04 which should be a correct URL on LAN Nov 05 09:20:18 do_fetch: The URL: 'gitsm:eeprom;protocol=git@eserver;name=eeprom;bareclone=1;nocheckout=1' is invalid and cannot be interpreted Nov 05 09:20:38 that is the error I get Nov 05 09:24:12 ndec: I guess the information should be directed to you? Nov 05 09:27:07 henriknj: halstead is the one we need for that Nov 05 09:27:27 halstead: wiki certificate has also expired Nov 05 09:28:41 RP, oh. It must not have reloaded correctly. One moment Nov 05 09:30:57 RP, correct cert is being offered now. Nov 05 09:31:08 halstead: thanks Nov 05 09:32:55 great Nov 05 10:04:58 New news from stackoverflow: Yocto use boot-efi-ia32 but x64 linux kernel Nov 05 11:14:11 what is installing kernel-image (and thus kernel-image-bzimage) to rootfs image in sumo? bitbake -e of the image recipe doesn't show anything adding this dependency, or it's well hidden in python magic Nov 05 11:25:40 sup people, anyone done anythhing with meta-secure-core in the past ? as for like encrypting rootfs ? Nov 05 11:52:29 hi guys,On a recipe I am inheriting pypi and setuptools to install some python modules, but I notice that it is using python2 modules , how do I make it use pip3 in order to install python3 modules? Nov 05 11:58:45 just found pypi + setuptools3 :) Nov 05 12:01:18 * RP wonders where oe-selftest should be writing logs :/ Nov 05 12:02:00 most other logs end up in TMPDIR/logs, selftest currently does not Nov 05 12:04:48 RP: selftest is wrong and it should dump to LOG_DIR/selftest Nov 05 12:05:00 Can somebody correct my understanding of *-initial packages ? Nov 05 12:05:09 lIke gcc-cross-initial, or glibc-initial Nov 05 12:05:19 lukma: those recipes have complicated bootstraps Nov 05 12:05:21 those are needed to bootstrap the "full blown" ones? Nov 05 12:08:17 /boot/bzimage ends up on rootfs when it should not since kernel is just deployed and flashed to raw partition instead. but kernel-image and it's dependency kernel-image-bzimage are pulled to rootfs despite this, but nothing shows the RDEPENDS. How do those kernel packages end up on rootfs then? Nov 05 12:10:26 mcfrisk: maybe inspect the dot files? IIRC bitbake -g generates the dependency graphs. Nov 05 12:12:26 LetoThe2nd: yes checking that now. pure buildhistory packages/ doesn't show the dependency, neither does bitbake -e. Nov 05 12:20:57 rburton: Could you shed some light on this problem? Nov 05 12:21:15 lukma: yes, they are Nov 05 12:21:17 Why such approach is needed with OE/yocto ? Nov 05 12:23:59 lukma: personally i'm happy with 'bootstrap is complicated' lest i become knowledgable here and expected to mantain it Nov 05 12:24:23 rburton: Is this the issue with chicken - egg problem? (with the preparing the sysroot for such complicated projects) ? Nov 05 12:26:13 yeah, iirc its because we're building both gcc and glibc which inter-depend Nov 05 12:26:56 rburton: Agreed, easier said than done though Nov 05 12:27:34 A little off-topic, but this channel is full of people who work at this level: I have two SLIGHTLY different versions of a board. The only difference is the QSPI flash-chip. Since it's actually the same driver that takes care of both versions, it doesn't really matter which string I put in the "compatible" definition in the DTS. Should I (a) put both of them, comma-separated into the "compatible" definition, (b) maintain two different DTSs, or (c) just forget abou Nov 05 12:28:48 I'm leaning towards (a), more or less as an indicator to a human reading the DTS, that this definition is compatible with both versions. Nov 05 12:39:07 rburton: wondering what to do with master-next and thud-next... Nov 05 12:39:25 RP: ross/thud is not exactly small... Nov 05 12:39:30 (running a test build locally of it) Nov 05 12:44:35 RP: whats in nightly-qa-extras2 Nov 05 12:44:51 (want to do a test spin of a mingw patch) Nov 05 12:46:15 rburton: mingw is in one of the extras. Helper repo has the config Nov 05 12:46:43 its in the original helper, wondering what helper2 does Nov 05 12:53:46 rburton: there is no helper2? Nov 05 12:53:57 erm Nov 05 12:54:02 qa-extras2 Nov 05 12:54:34 rburton: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/tree/config.json#n602 Nov 05 12:55:01 rburton: so mingw is in -extras Nov 05 12:55:14 http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/tree/config.json#n573 Nov 05 13:24:42 is it possible to have do_image_wic[depends] rely on two different tasks in two different recipes? Nov 05 13:25:28 something like do_image_wic[depends] += " testing-recovery-image:do_image_complete;testing-factory-image-swu:do_image_complete" does not work for me Nov 05 13:25:58 error message is Task 'depends' should be specified in the form 'packagename:task' Nov 05 14:11:22 sigh, can't figure out why kernel-image gets installed to all my images. at least it's empty and I can remove the kernel-image to kernel-image-bzimage RDEPENDS to avoid hitting partition size limits. Would be nice to know what makes kernel-image so special that it's not visible in RDEPENDS, buildhistory or bitbake -e output. Nov 05 16:08:52 zeddii ping Nov 05 16:08:58 zeddii_home, ping Nov 05 16:09:19 pong. Nov 05 16:09:40 naked ping and pong? Nov 05 16:10:35 v.4.14 tiny should have the hash for v4.14/standard/tiny/common-pc or v4.14/standard/tiny/base Nov 05 16:10:50 the .76 update is pointing to base Nov 05 16:11:21 fails to build in sumo Nov 05 16:11:35 surprised Master / thud is not seeing this Nov 05 16:12:02 interesting. what machine are you building ? I can build 4.14 here and see what's up. Nov 05 16:12:13 hash c5aca000e387da12ce375251c829f653503d32b4 -> Merge branch 'v4.14/standard/base' into v4.14/standard/tiny/base Nov 05 16:12:24 tiny should point to v4.14/standard/tiny/base by default. Nov 05 16:12:40 zeddii: can we add arm as on option for tiny ? Nov 05 16:12:55 zeddii: currently we only have it for x86 alone Nov 05 16:12:58 but the branch in sumo is v4.14/standard/tiny/common-pc" Nov 05 16:13:48 poky-tiny disto Nov 05 16:13:56 hmm. Nov 05 16:14:11 yah. I wonder if my update scripts are busted. sec. Nov 05 16:14:39 master is using /common-pc Nov 05 16:14:49 so is should have failed Nov 05 16:14:54 khem. the windriver guys sent the qemuarm patches for tiny a bit ago. I queued my parts of them. I need to check to see where they landed. Nov 05 16:15:22 armpit. hell. it is wrong in my config file Nov 05 16:15:47 yes, the branch by default is common-pc/base, but I'm definitely using the hash of standard/base when it updates. Nov 05 16:16:17 so the branch in tiny recipe needs to change ? Nov 05 16:17:16 or the hash needs to change to the common-pc/base one. but if I do track down what khem was just asking about then changing the default branch to the generic one is the right call. Nov 05 16:18:02 i matched the hash to /common-pc Nov 05 16:18:37 k. that's the quick fix. I can change master to point to the xx.yyy/standard/tiny/base Nov 05 16:18:45 but I can change the branch to /base to match the hash the is already there Nov 05 16:18:51 k Nov 05 16:19:15 I'm changing mine now. I suppose it should really go in for the release, since I have NFI how it is building in master. Nov 05 16:19:51 k, will wait then. no rush for sumo Nov 05 16:20:01 cool. git-sending-email shortly. Nov 05 16:20:57 k, I wonder why we are not seeing this on thud Nov 05 16:24:31 what error are yo seeing, it is the fetcher ? build ? Nov 05 16:25:15 and khem. looks like I deleted qemuarm tiny support when I removed the 4.15 versioned recipe. restoring that now. but will hold that until after the release. once it is in 4.18, I can't commit that crime again. Nov 05 16:25:23 http://errors.yoctoproject.org/Errors/Build/70521/ Nov 05 16:25:33 must be Monday. strang things popping up everywhere. Nov 05 16:25:56 ERROR: Fetcher failure: Unable to find revision c5aca000e387da12ce375251c829f653503d32b4 in branch v4.14/standard/tiny/common-pc even from upstream Nov 05 16:26:29 k. as expected how odd that it doesn't show in thud. Nov 05 16:29:13 oh wait, I know why. Nov 05 16:29:50 armpit. it'll build now. no patch required. Nov 05 16:30:02 magic.. I like it Nov 05 16:30:14 > git push origin v4.14/standard/tiny/common-pc:v4.14/standard/tiny/common-pc Nov 05 16:30:14 DISPLAY "(null)" invalid; disabling X11 forwarding Nov 05 16:30:14 Counting objects: 1, done. Nov 05 16:30:14 Writing objects: 100% (1/1), 255 bytes | 0 bytes/s, done. Nov 05 16:30:14 Total 1 (delta 0), reused 0 (delta 0) Nov 05 16:30:15 To ssh://git@git.yoctoproject.org/linux-yocto.git Nov 05 16:30:17 823b430faf80..7512686522f1 v4.14/standard/tiny/common-pc -> v4.14/standard/tiny/common-pc Nov 05 16:30:33 there was an issue with the git origin in 4.14 and my push didn't go for that branch Nov 05 16:30:44 what you found was correct. the SRCREV is not correct to the KBRANCH Nov 05 16:30:57 but the common-pc/base one, should have the tiny/base one. if I pushed it. Nov 05 16:31:23 the fetcher will roll it back, and since there are no patches on the sub branch, all is well. again, if I pushed it. Nov 05 16:31:36 so I'll fix it in master, but will hold it for post release. Nov 05 16:31:55 haha, I have been there done that before Nov 05 16:31:56 thanks Nov 05 16:32:21 actually, thanks for catching that. I'll clean up the crime so it can't return Nov 05 16:32:40 and that's why thud doesn't see it, if it build 4.18/tiny*, the branches don't have that problem, they are all updated when I push. Nov 05 16:36:15 cool Nov 05 16:38:17 People were asking about source mirror issues at ELC-E/OEDEM. Short answer is there were some, halstead and I have a) fixed them and b) written a new test to stop it regressing Nov 05 16:40:21 zeddii, build passed for tiny. thanks Nov 05 16:40:29 MAGIC! :D Nov 05 16:51:16 RP for which repos ? Nov 05 16:53:22 armpit: anything the autobuilder builds Nov 05 16:53:45 k Nov 05 16:54:04 Maybe somebody knows what what is the purpose of : OECORE_KNOWN_INTERPRETER_NAMES Nov 05 16:54:32 In other words - why do we need to pass version to glibc from bitbake? Nov 05 16:54:49 * armpit now has the Edinburgh bug Nov 05 17:01:18 lukma: meta/recipes-core/glibc/glibc/0007-readlib-Add-OECORE_KNOWN_INTERPRETER_NAMES-to-known-.patch should be self evident Nov 05 17:01:46 khem: why does the system then sed the name to EGLIBC and use EGLIBC in the ..inc file? Nov 05 17:02:47 khem: ah, its just expanding the placeholder Nov 05 17:02:53 hmm :/ Nov 05 17:03:23 The part I do not get is why when I do use devtool Nov 05 17:03:56 the "Author: OpenEmbedded " Nov 05 17:04:09 adds Committing changes from do_patch Nov 05 17:04:21 and removes this line ....... Nov 05 17:04:52 And this patch seems to be auto generated ....... Nov 05 17:06:12 lukma: you're trying to use devtool on glibc? I suspect you're hitting conflicts as that file is also machine edited with sed Nov 05 17:06:39 RP: I see.... as there some other errors shows up. Nov 05 17:06:53 The purpose is to build the image with new glibc Nov 05 17:07:00 s/purpose/goal Nov 05 17:08:43 I'm just confused with the presence and then removal of OECORE_KNOWN_INTERPRETER_NAMES Nov 05 17:09:35 lukma: Basically the code generates some extra values and places them in that file (or may generate no extra values) Nov 05 17:29:06 Is ubuntu-18.04 supposed to be in SANITY_TESTED_DISTROS for thud? Nov 05 17:31:27 JPEW: probably. Maintenance of that field is probably lacking at this point :( Nov 05 17:32:08 Is it usually just set to match the autobuilder nodes? Nov 05 17:32:31 JPEW: yes Nov 05 17:32:47 JPEW: I think we've lost the people who'd normally do that :/ Nov 05 17:34:16 RP: Ah Nov 05 17:56:31 we can all do that Nov 05 17:56:38 * armpit but is lost Nov 05 19:13:51 is this url valid ? : http://errors.yoctoproject.org/ClientPost/JSON Nov 05 19:22:14 Does anyone have familiarity with debugging a yocto-built linux kernel on hardware using Vivado SDK? I have various CONFIG_DEBUG options set in my linux kernel recipe but when I try to attach and debug the kernel from Vivado SDK, some variables, etc., are flagged with an error about no location information being found in DWARF data. Nov 05 21:10:20 tgoodwin: vivado forums might be bette r Nov 05 22:07:23 New news from stackoverflow: Yocto: bbappend file which remove System V init script Nov 05 22:37:30 New news from stackoverflow: PCIe link down on R-Car Salvator-xs Yocto AGL [closed] **** ENDING LOGGING AT Tue Nov 06 03:00:00 2018