**** BEGIN LOGGING AT Mon Nov 02 02:59:57 2020 Nov 02 07:07:50 yo dudX Nov 02 07:50:50 good morning Nov 02 08:24:05 Hi! My shell script returns 1 but the C-function "system()" returns 256 from calling this shell script. I use yocto's busybox. What could I do to get 1 as return value from system()? Nov 02 08:24:59 Have you seen such effect also? Nov 02 08:29:14 i have replaced all calls to system() by boost::prcoess for the sake of improved control Nov 02 08:29:57 fbre: -1 maps to 256. calling system() isn't really a good idea anymore as it executes things with shell. Nov 02 08:30:35 mcfrisk: i guessed that but wasn't certain enough to actually pronounce it, thanks! Nov 02 08:53:38 LetoThe2nd: Thank you. I'm gonna look for alternatives to system() Nov 02 08:57:59 Good morning Nov 02 08:58:48 What is the minimum I have to do after moving tmpdir? Basically delete sstate and rebuild everything? Nov 02 09:02:00 nope, sstate should be location agnostic Nov 02 09:02:08 just point to sstate and rebuild Nov 02 09:03:30 that's what I tried..."tmp/work/x86_64-linux/xz-native/5.2.4-r0/recipe-sysroot-native/usr/share/quilt/scripts/patchfns: No such file or directory" Nov 02 09:04:03 I deleted tmp and changed tmpdir in local.conf Nov 02 09:04:29 had to do a cleanup before releasing stuff Nov 02 09:05:01 i am almost convinced that you did something else than just "remove tmp, repoint TMPDIR", because that pretty much certainly rebuilds perfectly. Nov 02 09:06:17 I removed some i586 optimizations in my machine conf...other than that, nothing Nov 02 09:07:05 * LetoThe2nd has a hard time believing that. or you did things not in the order you are describing now. Nov 02 09:08:10 because 1) remove tmp 2) edit machine config 3) edit TMPDIR 4) build is almost such a standard use case that it would've been noticed. Nov 02 09:09:08 I was doing some spring cleaning and removed a few folders under meta/recipes-extended that I wasn't .bbappend-ing any more Nov 02 09:09:39 just like i said. Nov 02 09:09:45 xz-native was not part of the spring-cleaning :D Nov 02 09:09:52 thats what you think. Nov 02 09:09:55 seriously. Nov 02 09:10:01 yeah...I get ya... Nov 02 09:10:21 so I should probably just clean everything and start over Nov 02 09:11:03 1) do a build. 2) wipe tmp 3) reassign TMPDIR 4) rebuild. if it still breaks, do a bugreport, because thats what it is then. if it doesn't break after you tried a clean reproducer, you did something fishy ( even if you don't remember it). Nov 02 09:11:32 the fishy thing might also have been quite a bit in the past, if so far the affected stuff hasn't been rebuilt Nov 02 09:12:56 that is probably the case Nov 02 09:13:17 pretty sure I haven't anything "bad" today Nov 02 09:15:08 like i said - it is of course possible that you have hit a somewhat exotic bug. but especially in that area, i highly doubt it. Nov 02 09:19:15 way more likely to be my fault than some exotic bug Nov 02 09:19:25 jonmason: if people can't configure their phone to mute notifications overnight then that is their problem :) Nov 02 09:26:38 What is actually the meaning of build/tmp/work and build/tmp/work-shared? Nov 02 09:27:11 Why that separation? Nov 02 09:27:27 work-shared is where gcc and the kernel put a source tree because their trees are so huge its worth the pain of managing it like that Nov 02 09:28:18 ah ok Nov 02 09:44:21 Hi! I have an issue related to symbolic links. For some reason my build/tmp path is cached to /home/op/hdd symbolic link path instead of /home/hdd absolute path. It gave me error in conf/templateconf.cfg, I fixed path there. Nov 02 09:45:06 But now when I run bitbake myimage it gives "Error, TMPDIR has changed location. You need to either move it back to /home/op/hdd/yocto-build/build/tmp or delete it and rebuild" Nov 02 09:45:23 well then remove and rebuild? Nov 02 09:45:29 " Either fix the cause of this error or at your own risk disable the checker (see sanity.conf)." Nov 02 09:46:08 Well, it is not desirable to delete tmp directory in my case because I will lose this working day... too mucxh time to rebuild. Nov 02 09:46:26 Is there way to fix path to tmp directory? Nov 02 09:46:45 whats the problem with remove, rebuild? if the sstate stay, it will take only a couple of moments. Nov 02 09:47:25 and sstate is location agnostic, so you can move it around at will. Nov 02 09:49:40 DanmerZ: if you don't believe me, then just rename your tmp to tmp_i_dont_trust_leto, and rebuild. as long as you didn't tinker with your sstate-cache, the tmp structure should be rebuilt in minutes, if not seconds. Nov 02 09:50:06 good, I am trying this, thank you Nov 02 09:55:39 people having fun with their tmp directories today it seems :D Nov 02 09:56:29 I am building from scratch...had to be done anyway before I do a final commit and write instructions for the next poor soul who has to take over after me :D Nov 02 09:57:33 yeah it seems we're having a tmp/sstate day. Nov 02 09:58:57 don't have a clue what was wrong here...but clean build is refreshing no matter what...then I'll remove some of the i586 optimizations again and see what happens Nov 02 10:00:31 I'm building so much stuff I don't need :( gotta get better at starting from scratch Nov 02 10:01:21 pretty sure I don't need btrfs-native and swig-native...lol Nov 02 11:50:09 so I found the "bug", LetoThe2nd...and it could be my ignorance because I haven't read the documentation properly Nov 02 11:50:33 carlsb3rg: pray tell so we can warn others :) Nov 02 11:51:30 I set DL_DIR to ${TOPDIR}/../downloads...and SSTATE_DIR to ${TOPDIR}/../sstate-cache...turns out TMPDIR doesn't like being set to ${TOPDIR}/../tmp Nov 02 11:52:15 I have to make my stuff user-agnostic and bitbake doesn't like ~ much either... Nov 02 11:55:19 carlsb3rg: How about setting TMPDIR to ${TOPDIR}/tmp and using a symlink? Nov 02 11:55:43 I'd avoid '..' in any of those variables if possible Nov 02 11:56:22 there are many ways to "Rome" and I know a few fixes...it was just surprising since DL_DIR and SSTATE_DIR didn't mind ;) Nov 02 11:57:05 I could just put it back in build and .gitgnore it away which is what I probably will end up doing Nov 02 11:59:32 carlsb3rg: because DL_DIR and SSTATE_DIR are specifically meant to be user- and build- agnostic, whereas TMP, well.. its not build-agnostic? ;-) Nov 02 12:02:36 makes sense, but the error message was a bit unfriendly...would be nice if the conf parser gave some kind of warning/error Nov 02 12:03:05 we are never unfriendly! Nov 02 12:03:24 we, and our messages are jut sometimes... "not optimally friendly!" Nov 02 12:03:38 haha :D Nov 02 12:04:55 okay...not "unfriendly", but 10 pages of red stuff from a couple of random packages was "kinda cryptic" Nov 02 12:05:24 * LetoThe2nd makes note to yiel 42 pages of red stuff next time. we can always improve! Nov 02 12:05:42 carlsb3rg: Bitbake is probably fine with '..' in the path but some projects are picky about their build paths Nov 02 12:06:26 Do you know which recipes failed? If they're in oe-core then I expect '..' in TMPDIR will never work Nov 02 12:06:42 If it will never work we could add a sanity check Nov 02 12:09:05 this time round it was dbus do_populate_sysroot_setscene that reported the error Nov 02 12:09:17 which is in meta/recipes-core...so oe... Nov 02 12:11:00 paulbarker: i hereby strongly oppos user sanity check! Nov 02 12:11:01 +s Nov 02 12:12:15 the actual problem is not being able to find files in pseudoroot Nov 02 12:13:30 maybe pseudoroot doesn't like relative paths Nov 02 12:16:38 carlsb3rg: Could you open a bug for this? Nov 02 12:17:08 At least that way it won't get forgotten Nov 02 12:18:02 sure Nov 02 12:31:41 should I file it under oe-core or bitbake? Nov 02 12:51:16 https://bugzilla.yoctoproject.org/show_bug.cgi?id=3408 from 2012 :D Nov 02 13:47:40 carlsb3rg: oe-core. Open a new bug, the old one seems to be specific to a failure in expat do_unpack Nov 02 15:03:55 Morning, hopefully Friday went well. My back decided to go out Friday morning at about 4am. SO I spent all day drugged up in bed trying not to move.. Nov 02 15:05:30 woohoo! free drugs! Nov 02 15:06:26 ya, the anti nausea rocks.. :P Nov 02 15:06:54 (actually best medicine ever, puking one second.. take one.. hits my tongue, 30 seconds later, no desire to puke) Nov 02 15:07:19 (that is how bad my back hurt, was making me nauseaous.. :P) Nov 02 15:07:43 damn, that's rough Nov 02 15:07:48 \o/ Nov 02 15:08:17 second time this has happened in 6 months.. (the first time was the first time this EVER happened).. so it may be time to go see a specialist and have my back checked.. UGH Nov 02 15:08:35 the sit/stand desk actually is helping, I'm able to stand at least which usually hurts less Nov 02 15:08:53 I've been to hospital once where the nurse said "just a short sting when we'll insert the needle now" and the lights go out within about a second. Nov 02 15:38:29 Im getting: do_fetch: Fetcher failure: Fetch command failed with exit code 128, output: Nov 02 15:38:29 fatal: Refusing to fetch into current branch refs/heads/master of non-bare repository Nov 02 15:38:29 fatal: the remote end hung up unexpected Nov 02 15:38:56 Try doing a clone manually of the repo Nov 02 15:39:08 the final line suggests that its the remote's fault Nov 02 15:39:51 i did change the ssh key but if clone the repo localy it works but bitbake fails Nov 02 15:59:07 omg it was a permmision issu in the download dir Nov 02 16:51:46 LetoThe2nd: nice trick with awk, but now I'm wondering why this not built-in as bitbake feature. Something like bitbake example -e FOOBAR (variable as filter parameter) would be easier to understand and work with. Nov 02 16:52:13 that syntax wouldn't work, as -e works with or without a recipe Nov 02 16:52:34 but yes, that functionality is clearly useful, but doing so cleanly without introducing a whole new ui would be the question Nov 02 16:53:43 -e is more like C compiler preprocessing switch Nov 02 16:54:13 you dont want to add filters in bitbake for that. its fine to write tools to post process the output Nov 02 16:55:39 I rather miss my bb tool at times, that's why it had subcommands with different syntax than the default, though admittedly wasn't perfect itself Nov 02 16:55:56 should fix it, but meh, my motivation on non-required codign is squat lately Nov 02 16:56:15 khem: meta-clang breaks mesa with oe-core master Nov 02 16:58:08 khem: tinfoil API Nov 02 17:00:57 kanavin_home: stop trying to break mailman! Nov 02 17:01:11 kergoth: miss? I use it daily still Nov 02 17:02:40 https://github.com/rossburton/bb/blob/master/libexec/bb-var is 'show me a variable' Nov 02 17:14:54 rburton: I was a bit worried that this might get me auto-banned Nov 02 17:24:18 ubi1_0 file system is full. I can not install any software on it. Enlarge root partition ? Can I use IMAGE_ROOTFS_EXTRA_SPACE or IMAGE_ROOTFS_SIZE or IMAGE_OVERHEAD_FACTOR ? Thanks. Nov 02 17:26:18 yes Nov 02 17:26:21 all of those :) Nov 02 17:27:18 EXTRA_SPACE is "i want N spare space", _SIZE is explicitly how much you want, overhead factor is, well, don't worry about that Nov 02 17:27:45 Thanks. Nov 02 17:30:23 ,The size of ubi2:update will be reduced accordingly ? Or How to change the size of ubi2:update? Nov 02 17:31:30 rburton: I thought https://github.com/kraj/meta-clang/commit/3427029851cd2654b1359ccbe7f111ff76655a81 fixed it Nov 02 17:32:58 oh Nov 02 17:33:02 so yeah i should update my clone Nov 02 17:33:04 thanks :) Nov 02 17:50:57 rburton, yeah... keep up ; ) Nov 02 20:29:40 Hi all, I have a beginner question. I've been going over the letothe2nd's live yocto youtube series so I've got the poky core-image-minimal up and running and I don't seem to find an answer what I'm trying to do Nov 02 20:30:12 I'm trying to add a layer that someone else has written to get .net coreCLR cross compiled for an embedded image here https://github.com/Tragetaschen/meta-aspnet Nov 02 20:30:45 in the readme, there are dependencies on bitbake, openembedded-core, meta-mono, and meta-clang Nov 02 20:31:33 does poky already have bitbake and oe-core? I guess generally I'm not quite clear how I need to place the dependencies so that they can be used in the build Nov 02 20:33:27 yes, poky is bitbake+oe-core+meta-poky/meta-yocto (depending on release) Nov 02 20:35:16 ok. So what I need to do is git clone the meta-mono and meta-clang into my yocto build dir (currently yocto-test/build and yocto-test/poky), then edit bblayers.conf to add the new layers? Nov 02 20:35:20 am I missing any steps? Nov 02 20:42:06 kent: Sounds correct Nov 02 20:43:06 kent: What do you mean by "build dir" ? Nov 02 20:43:44 I created a yocto-test where I cloned poky into, so yocto-test/poky Nov 02 20:43:59 maybe my terminology is not so good, it's just my yocto test project dir? Nov 02 20:46:36 kent: Ya, that's fine. Just wanted to make sure it wasn't the directory where all you build output is (defaults to "build"); then one that you get dropped into when you run oe-init-build-env Nov 02 20:46:55 You probably don't want to put layers in there in case you want to delete it :) Nov 02 20:49:34 yeah that makes sense Nov 02 21:01:50 ok I cloned the dependencies for the layer, including meta-clang. Then I ran bitbake dotnet-source-build and I get ERROR: Layer clang-layer is not compatible with the core layer which only supports these series: dunfell (layer is compatible with gatesgarth) Nov 02 21:02:50 kent: you have to check out the branches of the cloned repositories that line up with the poky/oe-core you're using Nov 02 21:03:06 kent: i.e. you can't use a dunfell release with master branches of the layers, the latter are for a newer release than that Nov 02 21:04:52 I want to make sure I understand - so if I have a dunfell poky branch, I'll need to switch to the dunfell branches of the cloned repos? And the error is telling me that the meta-clang master is only supporting the gatesgarth poky branch? Nov 02 21:06:27 correct Nov 02 21:07:06 of course, some layers don't keep current, and their master branches might or might not support the current release, it depends on the layer. ubt that's the rule, yes Nov 02 21:08:17 ok. I'm not particularly tied to dunfell, that's just what was shown on the live coding sessions... is it good practice just to move to gatesgarth then? looks like that's release 3.2 as of Oct? Nov 02 21:11:50 kent: Ya, I think gatesgarth should be releasing shortly Nov 02 21:11:58 this week, most likely Nov 02 21:17:40 ok another beginner question... when I'm looking at someone else's layer here https://github.com/ThadHouse/meta-aspnet , how do I know the bitbake recipe commands? there are several recipe-aspnetvnext, recipe-devtools, recipes-dotnet, etc... Nov 02 21:18:17 or is it the name of the .bb files inside the recipe folders? Nov 02 21:20:36 there is a dotnet-source-build_2.2.3.bb file, would the bitbake command be 'bitbake dotnet-source-build_2.2.3' ? is the version necessary at the end there too? Nov 02 21:20:46 no, just dotnet-source-build Nov 02 21:43:32 kanavin_home: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1501/steps/8/logs/step2d mesa build race? Nov 02 21:48:57 RP: possibly, is this the first occurrence? Nov 02 21:52:15 kanavin_home: yes, just wondering what to do with it Nov 02 21:53:30 kanavin_home: that is with current master plus a handful of patches so the recent mesa upgrade was in there Nov 02 21:54:04 RP: make a tarball of the broken build dir and give it to me for inspection? :) Nov 02 21:54:28 (as usual, once it's failed, don't touch anything inside!) Nov 02 21:55:02 kanavin_home: you have ab ssh now? Nov 02 21:55:26 RP: I kind of do, it lets me into only some hosts, not all Nov 02 21:55:37 I'll try now Nov 02 21:55:56 typically ubuntu1804-ty-3 is my goto host for private builds Nov 02 21:56:46 kanavin_home: I've saved the build to pokybuild's ~/saved/build-st-3644728 Nov 02 21:56:57 on fedora31-ty-1 Nov 02 21:57:07 RP: I managed to get in there Nov 02 21:57:22 kanavin_home: cool Nov 02 22:25:45 RP: I have a patch, will test now Nov 02 22:26:00 the usual missing dependency in meson.build Nov 02 22:29:54 kanavin_home: that was quick, thanks! Nov 02 22:48:36 is git://git.yoctoproject.org/ sick? cloning git://git.yoctoproject.org/linux-yocto.git takes *ages* Nov 02 22:48:53 derRichard: halstead would be the person to ask Nov 02 22:49:11 I'll check. Nov 02 22:49:37 clone runs here now for more than 20 minutes. Nov 02 22:49:51 my build server is fast and has a good internet connection :) Nov 02 22:50:55 derRichard, Yes. There were some long running processes that could have caused slow clones. I halted them. Any better now? Nov 02 22:52:17 halstead: yes, looks better. thanks a lot for the quick support and fix! Nov 02 22:53:01 Great. We are moving to new servers this month that will solve this long term. Nov 02 22:54:29 +1 Nov 02 23:26:37 What is the gstreamer version going to be for gatesgarth ? Is it 1.63 or 1.18 ? Nov 02 23:37:45 I have it on good authority that 1.31337-beta is where you want to be... Nov 03 01:25:44 can anyone guess what's wrong with this file? downloads/76f64a28dc4685507d12f57fe5cfc89f6c32f8e6.tar.gz.done if I add it to our premirror with _many_ files it starts failing over NFS with "find downloads/ -type l" : "find: ?downloads/?: Too many levels of symbolic links" there are no symlinks there (that "-type l" would recognize) Nov 03 01:27:17 it's not a symlink Nov 03 01:27:19 7163480fff007dc98978899b556dcf06f8a462c8.tar.gz.done: 8086 relocatable (Microsoft) Nov 03 01:27:22 7e74bcb4f9706f36f752d1c3d3164628ccf2aae5.tar.gz.done: 8086 relocatable (Microsoft) Nov 03 01:33:23 od -c also doesn't show anything special in this file https://paste.ubuntu.com/p/rVt622R8n7/ so I guess it's NFS in some weird state (I've already tried to re-mount it on client which didn't help) anyone else seen this? Nov 03 01:33:59 the NFS server side is ancient 2.6.18-238.el5 kernel where at least this NFS was working reasonably well until now **** ENDING LOGGING AT Tue Nov 03 03:00:33 2020