**** BEGIN LOGGING AT Fri Dec 08 03:00:02 2017 Dec 08 06:33:29 Good morning:) Dec 08 06:35:45 I have in my/etc/inittab line like: S1:12345:respawn:/bin/start_getty 115200 ttyS1 vt102 and as I assume this produce "Id "s1" respawning too fast: disabled for 5 minutes ..." messages Dec 08 06:36:21 how I can rid it on yocto side to not build system with this entry. Dec 08 09:59:41 I am trying to use weston (wayland) running as a non-root user added with the extrausers bbclass. Clearly this use case is currently not supported using the poky/meta/recipes-graphics/wayland/weston-init recipe but I cant get it to work myself either. Simply adding a su [user] -c in the weston-start script doesnt do it Dec 08 10:06:03 wouterstreamit: does this user even have access to the relevant devices? if you're writing your own script you'll probably have better luck in the wayland irc channels as its their software Dec 08 10:37:02 Hi all Dec 08 10:43:58 I have a recipe that inherits from OE core-image class with a ROOTFS_POSTPROCESS_COMMAND. I'd like to do something in this function with a file located in the directory of this recipe, but can't seem to be able to find a variable that can properly locate said file Dec 08 10:44:13 When I use "SRC_URI" to add my file it doesn't find it either Dec 08 10:53:08 MajorGrub: maybe share your recipe ? Dec 08 10:53:33 nayfe: ok Dec 08 10:55:35 nayfe: https://pastebin.com/raw/C2KLWJK2 Dec 08 10:57:31 Do I need to use the trick "FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:" Dec 08 10:57:32 ? Dec 08 10:58:02 maybe you need to create a separe recipe to handle file shipping? Dec 08 10:58:56 nayfe: my goal is to take images generated and put them in some archive file Dec 08 11:01:48 Well Dec 08 11:03:48 MajorGrub: brb lunch Dec 08 11:04:13 nayfe, hi :) Dec 08 11:04:34 nayfe: alright Dec 08 11:05:22 nayfe, do you know with file/setting is responsible that add S1:12345:respawn:/bin/start_getty 115200 ttyS1 vt102 in inittab? Dec 08 11:05:54 I just found: ../meta/conf/machine/qemux86-64.conf:SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1" Dec 08 11:06:25 yes that Dec 08 11:07:40 but how I can overide this setting in my custom meta or recipe? Dec 08 11:08:03 I try already to add it to my local.conf without success Dec 08 11:52:56 joshuagl, rburton: I managed to get a full backtrace on that hang fwiw, I mailed it Dec 08 12:01:35 ooo Dec 08 12:11:16 rburton, joshuagl: confirmed that running the command standalone doesn't do this Dec 08 12:12:52 the command does report the db was "corrupt" after a crash in bdb Dec 08 12:20:17 and creating a new build directory alongside the original doesn't reproduce Dec 08 12:27:02 yet copying tmp/sysroots from one to the other breaks it Dec 08 12:44:47 hey Dec 08 12:44:51 anyone home Dec 08 12:45:45 nope. at the office. Dec 08 12:48:40 damn Dec 08 12:49:31 so I am trying to connect testopia to jenkins, Dec 08 12:49:55 but beginning with the bz_webservice_demo.pl file which just kinda hangs Dec 08 12:51:00 giving it the --debug parameter isnt delivering much either. where does it send that debug info Dec 08 13:01:32 anyone got time to help me get bz_webservice_demo working? Dec 08 13:07:18 really not sure who you expect to help join testopia to jenkins in here... Dec 08 13:07:47 Edward__: this is pretty much a very specific topic, so it will be better off on the ML, I think. according to the wiki, you can also CC corneliux.stoicescu@intel.com - please remember that it is friday, and most people are off for a quieter weekend already, or really soon. Dec 08 13:22:56 thanks Dec 08 13:23:06 maybe something a bit more generic Dec 08 13:50:06 MajorGrub: re, you need to use ${WORKDIR}, you can also use https://patchwork.openembedded.org/patch/138100/ to add some files to rootfs Dec 08 13:50:08 rburton, joshuagl: copying rpm/smart from the broken builddir into the working one breaks it Dec 08 13:54:25 RP: some kind of race/resource access issue? Dec 08 13:54:39 hmm, maybe not :-/ Dec 08 13:56:10 joshuagl: could be, not sure Dec 08 14:10:42 rburton, joshuagl: narrowed to rpm.real specifically Dec 08 14:16:42 rburton, joshuagl: I have a lead. One is relocated in the sysroot correct, the other is not. So its a uninative problem Dec 08 14:17:46 :-o Dec 08 14:17:48 great work RP Dec 08 14:20:41 joshuagl, rburton: pre-rss we only sysroot relocate things from sstate, not things build natively. I'm guessing its mixing and matching some things from sstate and some not. If the host libc version has different internals, that mix of host and uninative libc is probably hanging Dec 08 14:21:26 particularly things using more complex things like libc shared memory futexes Dec 08 14:22:52 lots of incremental morty builds over different host gcc meant something incompatible made it into sstate? Dec 08 14:23:34 I am trying to use systemd to start weston as a different user, and according to #wayland I should compile systemd with PAM support and add a line PAMName=login in my weston service definition. Doing this causes an error when starting the service "Failed with result 'protocol'". What am I doing wrong? Dec 08 14:23:57 I added pam to my DISTRO_FEATURES to add pam support Dec 08 14:26:43 rburton, joshuagl: we can't really change the behaviour in morty? :/ Dec 08 14:26:48 (of sstate) Dec 08 14:27:40 RP: no, probably not :-/ Dec 08 15:01:47 armpit: see above, I think we understand why morty hangs Dec 08 15:02:04 I also have a horrendous fix in mind :/ Dec 08 15:03:54 RP: You're seeing bitbake hang while building morty? 1.32 branch, right? Dec 08 15:04:49 georgem We're seeing smart hang Dec 08 15:05:18 georgem: bitbake's build hangs as a result but its not bitbake that is actually hanging Dec 08 15:05:41 Ah okay. I'm not using RPMs so that would explain why I haven't seen anything unusual. Dec 08 15:06:25 georgem: you need to be using sstate shared across distros with different glibc versions Dec 08 15:08:26 * georgem nods Dec 08 15:14:21 RP, k. Dec 08 15:14:28 * armpit just woke up Dec 08 15:15:33 armpit: its proving a fun one :/ Dec 08 15:16:03 I do try to help the younger generation Dec 08 15:16:39 hmm, my "this should work great" version of the fix just spewed ~3000 ERROR: messages :) Dec 08 15:25:19 RP, thats how it always is.. Dec 08 15:55:49 New news from stackoverflow: New Yocto release is not compatible with Raspberry pi3 model b Dec 08 16:29:48 armpit: thinking http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-morty&id=f4278b172613e98ff420744951f76b2458ef3ae1 is what we need... Dec 08 16:30:46 k, let me pull it in and start a build Dec 08 16:31:24 armpit: we're about to enter halstead's maint window Dec 08 16:31:50 k Dec 08 16:32:50 armpit: I can put this and your other patches into morty-next Dec 08 16:35:21 ok Dec 08 16:37:41 armpit: pushed Dec 08 16:37:59 armpit: we can run a morty-next as soon as halstead is done Dec 08 16:39:01 k, but there are some patches missing Dec 08 16:39:36 armpit: there are? :/ Dec 08 16:39:45 stable/morty-next has gnu-efi fixes Dec 08 16:40:03 had build issues Dec 08 16:40:08 armpit: sorry, I had the wrong branch of yours Dec 08 16:40:09 that those fixed Dec 08 16:40:41 sorry. I switched this week. should have deleted the other one Dec 08 16:41:10 armpit: do I have them all now? :) Dec 08 16:41:17 (/me repushed) Dec 08 16:41:44 yes Dec 08 16:42:08 so should I use the new cluster? Dec 08 16:43:01 armpit: we can, yes Dec 08 16:47:57 rburton: how do we get files out a system with no network connection (e.g. within the QA framework)? Dec 08 16:51:33 RP: annoyingly busybox has a receive-over-xmodem command but not the send version Dec 08 16:51:52 within qa we have ssh! Dec 08 16:51:56 rburton: right :/ Dec 08 16:52:03 rburton: not in poky-tiny Dec 08 16:52:36 rburton: I'm just remembering why I've kept this around, it is actually useful when you have a troublesome board and only serial works Dec 08 16:53:17 rburton: minicom should really rrecommend it btw since iirc it calls into it Dec 08 16:53:50 hm yeah the debian package does Dec 08 16:53:58 well, can we at least not install it out of the box Dec 08 16:54:02 its SO OLD Dec 08 16:54:10 and i saw the patches and almost fainted Dec 08 16:54:18 rburton: I was surprised it was in so many packagegroups Dec 08 16:54:42 rburton: I assume upstream is totally dead? Where does debian use? Dec 08 16:54:58 half tempted to put it into a repo on git.yp.org Dec 08 16:56:04 debian uses it, via recommends in minicom Dec 08 16:56:37 ok, don't remove recipe, add recommends to minicom, remove from packagegroups, vet where minicom is added Dec 08 16:57:10 rburton: fair enough, thanks. The serial machine feature is probably the contentious part Dec 08 16:57:35 rburton: its not like its large though Dec 08 17:02:56 hi. i wonder if anybody is looking into 2.15.0 git changes: it does not support --set-upstream any more Dec 08 17:04:40 joshuagl: you have a "bug" related to the reproducible builds. what is the best way to check the status of the overall situation? Dec 08 17:07:18 RP: not sure i want to force it into every image that has a serial port. i'm happy with removing all mention from the packagegroups, adding a recommends to minicom. for poky-tiny QA if we need it then we can get it into the images. Dec 08 17:24:08 rburton: it depends what you think "serial" means as a machine feature I guess Dec 08 17:25:09 RP: "has a serial port" != "i want to do xmodem transfers" in my mind Dec 08 17:26:57 rburton: it did kind of mean "I want to debug my board using serial" Dec 08 17:27:13 pretty sure thats not what its used for... Dec 08 17:27:59 rburton: you also are dropping it from lsb images. Does lsb require it? Dec 08 17:28:07 no, checked Dec 08 17:28:12 rburton: ok, cool Dec 08 17:28:43 rburton: so I agree with self-hosted and lsb, less sure about the others Dec 08 17:30:54 RP, we can reboot everything except fedora and tumbleweed right? Dec 08 17:31:25 halstead: we can reboot those as well now I think Dec 08 17:31:30 rburton: agree? Dec 08 17:31:48 yes, reboot away Dec 08 17:32:32 halstead: the morty hang has left a lot of hung processes on the workers so a full reboot of everything might be good Dec 08 17:33:12 Glad I checked. Dec 08 17:42:54 halstead: we've only learnt that today Dec 08 18:06:43 armpit, .io is ready to work. Dec 08 18:12:26 halstead, armpit: fired a morty-next Dec 08 18:12:33 halstead: thanks Dec 08 18:41:47 RP: you happen to know if anyone has done any work on improving copydebugsources() to handle S outside of WORKDIR, i.e. externalsrc? Dec 08 18:42:17 or anyone else, fo rthat matter Dec 08 18:42:21 guessing the answer is probably no Dec 08 18:42:25 * kergoth checks bugzilla Dec 08 18:43:56 mckoan|away: I have got rpi3 graphics going with x11 and mesa yes, I havent tried qt5 specifically Dec 08 23:04:19 sigh.. morty... Dec 08 23:32:14 armpit: :( Dec 08 23:32:47 armpit: at least all consistent esdk failure and not hanging? :/ Dec 08 23:34:22 kergoth: I'm afraid not Dec 09 00:05:53 armpit: reproduces easily at least... **** ENDING LOGGING AT Sat Dec 09 03:00:00 2017