**** BEGIN LOGGING AT Tue Jan 08 02:59:57 2019 Jan 08 03:33:23 New news from stackoverflow: Adding iptables to yocto causes image do_rootfs to fail due to wrong kernel version [closed] Jan 08 09:06:16 robbawebba: could be Jan 08 09:30:32 hey there. quick question on recipes: I have a recipe that links a wrapper into /usr/bin/cmd, and another recipe, which I want to overwrite this link. Is there a possibility to enforce a overwrite? For now I can't build my image, because of a conflicts error. Or is the only solution to append to the recipe which creates the link in the first place? Jan 08 10:56:54 rburton: -next was a green build, ok to merge? Jan 08 11:02:50 RP: so the toolchain change shows that icecc in multilib sdks is broken. it was broken before (would only work for the primary tune) but now its more broken. Jan 08 11:03:23 RP: not sure if we just note and file a bug (for JPEW?), or want to wait until that is handled Jan 08 11:03:46 apart from that yes Jan 08 11:03:57 rburton: hmm. I'm tempted just to proceed. Is it obviously broken? Jan 08 11:04:38 currently icecc's nativesdk setup just uses the default tune, and the setup script is ran once with that tune. Jan 08 11:05:20 now, it will run for every tune and i'm not sure what happens: worst case it sets up for a multiarch tune but writes to a file with the name of the base tune? Jan 08 11:05:24 not looked at icecc much Jan 08 11:05:33 will file a bug anyway Jan 08 11:05:37 rburton: the case where there is one tune should work as before? Jan 08 11:05:49 yeah, for one tune my change is a no-op Jan 08 11:05:59 rburton: so we just make the broken case more broken? :) Jan 08 11:06:52 yeah! Jan 08 11:07:06 * RP can live with that Jan 08 11:32:20 RP: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13128 fwiw Jan 08 11:32:21 Bug 13128: normal, Undecided, ---, JPEWhacker, NEW , nativesdk-icecc doesn't work for multilib SDKs Jan 08 11:33:00 rburton: thanks Jan 08 11:33:37 who maintains the go.bbclass file? Jan 08 11:33:50 us this person here on irc? Jan 08 11:43:47 RP: thanks, there was just one issue (with perl-ptest package being erroneously pulled in). This is now fixed, so we can do maybe another spin? http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/perl-sanity Jan 08 11:48:30 kanavin: fired Jan 08 11:48:40 derRichard: khem and maybe otavio Jan 08 11:50:35 khem: otavio: i'm facing go runtime errors on x86_64, they happen because go.bbclass uses a shared go runtime library. so far i'm not sure whether this is an go upstream issue or a yocto problem Jan 08 11:50:41 did you see something like that in the past? Jan 08 11:53:26 the errors are always: Jan 08 11:53:26 runtime: unknown pc in defer 0x564f3b23ea50 Jan 08 11:53:26 fatal error: unknown pc Jan 08 12:06:45 RP: rootfs.py, line 744 _file_equal Jan 08 12:07:02 RP: why is opkg rootfs doing prelink things when none of the others do? Jan 08 12:35:47 rburton, I have googled right now for a similar issue [YOCTO #1894] Jan 08 12:36:43 about issues with multilib vs. python 2.7 Jan 08 12:37:10 do_rootfs: Multilib check error: duplicate files Jan 08 12:38:24 well, it seems the example in Yocto docs do not cope with stubborn recipes Jan 08 12:39:25 rburton: I don't know, that is very very strange Jan 08 12:39:48 RP: hopefully fray has some history? Jan 08 12:41:57 rburton: looks like incremental image issues with prelinked filed Jan 08 12:41:59 files Jan 08 12:42:01 https://patchwork.openembedded.org/patch/66905/ Jan 08 12:42:02 ^ Jan 08 12:42:38 well Jan 08 12:42:39 rburton: I suspect incremental rpm doesn't need this Jan 08 12:42:43 seem sprelink was added to tweak _multilib_sanity_test Jan 08 12:42:44 1) that should be checking if prelink is enabled Jan 08 12:42:53 2) does anyone actually use incremental generation? Jan 08 12:43:06 I am tempted to drop the incremental generation everywhere Jan 08 12:43:27 and yes, 1) is a bug Jan 08 12:44:54 ant_work: patches welcome? Jan 08 12:45:11 (to add a prelink enabled check wrapping the prelink calls) Jan 08 12:47:18 heh, ok, I was unsure it is a bug or an 'impossible' implementation Jan 08 12:47:45 because if you read last (2016) comments I found about this, Khem suggests it's just a bad idea Jan 08 12:47:52 https://lists.yoctoproject.org/pipermail/yocto/2016-October/032505.html Jan 08 12:48:25 this happened after the prelink patch for incremental builds Jan 08 12:48:56 now I have been pointed at python 2.7 failing beautifully :) Jan 08 12:48:59 ant_work: the arm header situation was improved since then iirc Jan 08 12:50:02 here is python Jan 08 12:50:03 https://pastebin.com/FXGJHayV Jan 08 12:50:34 ant_work, rburton: the right fix above was likely to run prelink later Jan 08 12:50:36 the developer sent me thi syesterdeay, current master Jan 08 13:00:30 anyone else having trouble with 4.19.x and grub 0.97 ? Jan 08 13:03:12 Hi, i hope im in the correct channel.. im having trouble changing the permission bits of various application on my OE-based platform. specifically - i try to change the application permissions for busybox and shadow applications. i tried to use do_install_append and ROOTFS_POSTPROCESS_COMMAND with no success (i.e. i see the changes in the tmp/recipe/version/image/ directory, but the final rootfs does not change). any idea what i am miss Jan 08 13:03:38 sagivd: what permissions? Jan 08 13:04:11 regular unix permissions (chmod 770 etc.) and suid bits Jan 08 13:04:22 care to pastebin the change? Jan 08 13:04:28 sure Jan 08 13:07:36 option 1: https://pastebin.com/43CNB12m Jan 08 13:07:42 option 2: https://pastebin.com/JAsDDgPY Jan 08 13:08:20 so in option 2, the files under /etc/ are changed as expected Jan 08 13:08:35 but the /bin/login.shadow remains without suid bit Jan 08 13:09:36 in option 2 - i see the change in tmp../shadow/version/image, but it doesnt reach the machine-image rootfs Jan 08 13:11:18 please ignore the _RW append, it was just a typo (and unrelated) Jan 08 13:11:48 (2) is definitely the better fix Jan 08 13:12:41 agree Jan 08 13:12:45 i wonder if the alternatives code is breaking the bits accidentally, try touching other files that are not being fiddled by alternatives to test Jan 08 13:13:15 ok ill check Jan 08 13:15:40 RP: can you drop the pulse patch from next, i've got a better one coming Jan 08 13:19:08 its compiling Jan 08 13:19:48 if the alternatives is the issue, since im using only a single source per app - can i just remove them from the alternative list? Jan 08 13:20:03 better to fix alternatives Jan 08 13:22:31 it looks like its something else Jan 08 13:23:03 i added "chmod 4777 ${D}${sysconfdir}/login.defs" to do_install_append() of shadow, got permission bits -rwxr-xr-x for login.defs Jan 08 13:23:15 in the rootfs image Jan 08 13:23:38 and -rwsr-xr-x in the shadow recipe Jan 08 13:27:19 rburton: dropped Jan 08 13:28:44 why does runqemu has hardcodded mac address... can I override it somehow? Jan 08 13:33:41 huh, yes I can, only whole netdev qemu arg Jan 08 13:45:48 rburton, so it's another reason at the end... Jan 08 14:00:10 to answer to myself: no, it's not possible to influence qemu mac address when using runqemu Jan 08 14:01:20 ak77: like with all wrappers around qemu, there is always a config option you want to set but is hardcoded in the wrapper :-) Jan 08 14:01:48 :S :) Jan 08 14:01:59 there is QB_NETWORK_DEVICE in qemuboot though Jan 08 14:02:31 it a bbclass, I could affect that Jan 08 14:05:01 or, if I could find out where the qemuboot.conf file is, i could sed @MAC@ mymac it Jan 08 14:06:25 rburton: I didn't think the AB did anything with icecc, how did you discover it was broken? Jan 08 14:08:00 JPEW: eyeballs Jan 08 14:08:17 JPEW: changed how the post-relocate hook behaved, so looked to see what else was using it Jan 08 14:08:27 rburton: Ah, that makes sense Jan 08 14:08:41 if i'm actually wrong feel free to tell me so, but from what i understand its broken in multilib :) Jan 08 14:09:09 Ya, I'm not sure. I will take a look. multlib is another one of those things I'm not very familar with Jan 08 14:10:20 the TARGET_PREFIX variable set by the environment script seems to be a reasonable unique id, different for each multilib tune at least Jan 08 14:28:39 hey there. quick question on recipes: I have a recipe that links a wrapper into /usr/bin/cmd, and another recipe, which I want to overwrite this link. Is there a possibility to enforce a overwrite? For now I can't build my image, because of a conflicts error. Or is the only solution to append to the recipe which creates the link in the first place? Jan 08 14:29:20 you can't have two packages that provide the same file installed at once Jan 08 14:29:39 if you want to be able to switch between those, then use update-alternatives Jan 08 14:29:58 that will give you a cmd symlink that points to whatever one is selected with priorities etc Jan 08 14:38:17 RP: so how could upstream version checks be parallelized? I am not sure actually. Jan 08 14:40:15 RP: what i posted on the list for pulse has a bad commit message, ross/mut has the latest patches Jan 08 14:41:33 @rburton: thanks for clarification Jan 08 14:42:11 kanavin: wrap the call site in a multiprocessing or threading block Jan 08 14:42:54 * RP tends to trust multiprocessing more Jan 08 14:44:58 RP: multiprocessing is not going to work (because it needs to serialize the recipe data, and it includes non-serializable lock objects). Jan 08 14:45:14 RP: so I tried with multithreading, and it resulted in bizarre data corruption errors Jan 08 14:45:44 kanavin: can't you obtain the data you need in the process and just hand a result back? Jan 08 14:47:08 RP: can you explain please? Jan 08 14:49:56 kanavin: I guess the piece I'm forgetting here is tinfoil Jan 08 14:50:27 the datastore connection over tinfoil is serialised Jan 08 14:51:20 to avoid that you'd need multiple build directories each with a tinfoil server Jan 08 14:52:05 we do have code for that with oe-selftest parallelisation but the problem isn't as easily solved as I was thinking Jan 08 14:52:37 kanavin: creating tinfoil API to do it is tempting Jan 08 14:52:59 anyone know what yocto release corresponds to wind river 8? Jan 08 14:53:15 rburton: fray should Jan 08 14:53:48 RP: for example, I wanted to create a plugin to 'bitbake-layers' that would give an overview of recipes update status, but then realized no one would want to wait 12 minutes for it Jan 08 14:53:58 with parallelization it used to be 90 seconds or so Jan 08 14:55:40 kanavin: We should talk with Paul but I think we need some kind of parallel execution tinfoil API Jan 08 14:59:21 RP: yep Jan 08 15:05:42 New news from stackoverflow: Cross compilling .deb package for yocto image?i.e remot3.it [closed] Jan 08 15:29:07 Has anyone else ran into "File name too long" errors when building on master? Looks like bitbake is trying to create an sstate file with a 257 character name Jan 08 15:29:35 I assume this is related to the recent switch from md5 to sha256 pushing the file name lengths up Jan 08 15:32:05 I do have a relatively long package name (containerd-opencontainers), long target triplet (cortexa7t2hf-neon-vfpv4-poky-linux-musleabi) and long version number (v1.0.2+gitcfd04396dc68220d1cecbe686a6cc3aa5ce3667c), but I'm sure I'm not the only one who will run into such a combination Jan 08 15:34:20 that does sound like a bug Jan 08 15:35:07 I didn't realize there was a character limit on a filename, overall path length definitely Jan 08 15:35:31 paulbarker: which filesystem is that? Jan 08 15:35:48 New news from stackoverflow: Which module to install to fix "module QtQuick.Controls.Styles is not installed" error for Yocto? Jan 08 15:35:53 Is it possible to run a python function (not task) under pseudo? (e.g. fakeroot python foobar(arg1, arg2, d))) Jan 08 15:36:11 nope Jan 08 15:36:11 yes.. Jan 08 15:36:24 fakeroot python task() { Jan 08 15:36:26 ... Jan 08 15:36:26 } Jan 08 15:36:30 I swear that works Jan 08 15:36:35 since it's used in package generation Jan 08 15:36:49 you can't do it in a -function-, only a recipe task Jan 08 15:37:05 RP: It's xfs, but https://serverfault.com/a/9548 suggests that the 255 char limit applies more widely as well Jan 08 15:39:18 It doesn't help that the containerd recipe uses the full ${SRCREV} in PV instead of just ${SRCPV}, fixing that should get me below 255 chars here. But definitely an issue that's likely to re-occur Jan 08 15:40:11 in the past when we've hit some issues like that, we've put in a max charater count and just truncated.. it's not the greated solution, but it worked in those cases.. Jan 08 15:40:18 with a checksum in place -- I'm not sure we can do it that way.. Jan 08 15:40:20 paulbarker: hmm. We can easily fix this since the only bit of the filename that is important is the hash Jan 08 15:40:27 may have to truncate on the name/version not the whole filename Jan 08 15:40:37 paulbarker: the other bit is for user use for debugging so we can truncate it Jan 08 15:41:38 It's the file name length limit not the path length limit that's being hit so an alternative would be to add another level of hierarchy on something like the package name and/or target triplet Jan 08 15:42:30 I do see both the target triplet (cortexa7t2hf-neon-vfpv4-poky-linux-musleabi) and the tune (cortexa7t2hf-neon-vfpv4) in the file name so that's some repetition that could be dropped Jan 08 15:44:20 paulbarker: split level makes little sense given this data is just for human readability use Jan 08 15:44:41 reducing duplicate info would be good Jan 08 15:45:34 Ok, for reference the full problem name is 'sstate:containerd-opencontainers:cortexa7t2hf-neon-vfpv4-poky-linux-musleabi:v1.0.2+gitcfd04396dc68220d1cecbe686a6cc3aa5ce3667c:r0:cortexa7t2hf-neon-vfpv4:3:8cf9e07e17de9682ef6e3eb78ac3eca8f942c2a833c4a7f5096cda401c1711e1_prepare_recipe_sysroot.tgz.siginfo' Jan 08 15:46:35 fray: Thats annoying :) Jan 08 15:50:08 The exact failure point is the os.rename call in SignatureGeneratorBasic.dump_sigtask, bitbake/lib/bb/siggen.py Jan 08 15:55:13 YPTM: https://zoom.us/j/990892712 Jan 08 15:55:20 YPTM: sjolley joined Jan 08 15:56:47 YPTM: armin is one Jan 08 15:57:18 on Jan 08 15:57:43 armpit: dual personalities under control today? :) Jan 08 15:57:55 yes Jan 08 15:58:31 * RP is also one Jan 08 15:58:44 (and on) Jan 08 15:59:08 YPTM: Joshua Watt here Jan 08 15:59:29 YPTM: Randy MacLeod joined. Jan 08 16:00:49 YPTM: ross is two Jan 08 16:01:05 RP, we took away his beer Jan 08 16:01:31 YPTM: is on the call Jan 08 16:03:03 * armpit breaking up is easy to do Jan 08 16:03:12 YPTM Minutes : https://docs.google.com/document/d/1Y5IIuE-z0Ykdl-DwuzUJh52flOZuhN_TSAfw2tdU9pg/edit?ts=5c06b22d Jan 08 16:03:35 armpit: lol Jan 08 16:08:03 YPTM: Matt Hoosier (Garmin) here Jan 08 16:29:23 YPTM is over Jan 08 16:31:03 RP: I'm hacking on a patch to shorten the sstate file names without dropping all the useful info, will send as an RFC once it looks ok to me Jan 08 16:31:33 paulbarker: sounds good thanks Jan 08 16:35:20 Something like "${PF}:${SSTATE_PKGARCH}:${SSTATE_VERSION}:" should give enough human readable info, I'll also see if I can limit the length of some of those automatically Jan 08 16:35:29 Hello. Has anything changed between sumo and thud related to package-index? In sumo, it was enough to bitbake and the index (Packages files) were automatically created in tmp/deploy/ipk, but in thud these are missing. Only if I call bitbake package-index I get them back. I'd like to know what changed, and how can I get the old behaviour back Jan 08 16:37:01 StefanS__: I think you always (officially) had to issue package-index separately, if you got index files from just making an image, that was undocumented behaviour. Jan 08 16:37:50 :( Jan 08 16:38:33 I thought I had to run that only when building a new recipe/package and needed the index to be updated. It's weird since code lib/oe/rootfs seems to indicate that the index is ran all the time at rootfs time Jan 08 16:46:11 Anyone here who managed a customized i.MX8 yocto linux? I have i.MX_Yocto_Project_User's_Guide_Linux.pdf and were able to build the Linux yocto image which the vendor provides, but now I want to start to customize that for my own image. Jan 08 16:47:46 I think I need a better description how to do that. That PDF description is not quite good. Jan 08 16:48:23 Any other tutorial available for i.MX8? Jan 08 17:05:16 hmm urgs... Jan 08 17:23:34 tgoodwin Jan 08 17:23:48 missed a window on that click... lol Jan 08 17:29:58 ah found it Jan 08 17:30:06 26a786f86989ce47eac4eecec3b0798730194b05 I think this one changed the behaivour Jan 08 17:30:10 kanavin: ^ Jan 08 17:39:26 StefanS__: the indexes were moved to the image workdir since multple images in parallel had interesting race issues Jan 08 17:40:16 StefanS__: you need to use package-index to say *when* you want the indexes created as any other way is ambiguous Jan 08 17:43:52 yup, got it Jan 08 17:44:24 I was just confused because in sumo the indexes were in DEPLOY_IPK_DIR and now were missing, and wanted to get the same behaviour Jan 08 17:44:30 I'll just run package-index at the end Jan 08 17:44:54 Thanks! Jan 08 19:11:22 RP: http://lists.openembedded.org/pipermail/openembedded-core/2019-January/277509.html do you see any issues ? Jan 08 19:22:02 khem: I don't really like enabling things we don't use but its probably reasonable Jan 08 19:27:33 kanavin: for the perl changes how does ptest look before/after? **** BEGIN LOGGING AT Tue Jan 08 19:32:36 2019 Jan 08 20:19:23 armpit: could you rebase thud-next? I think I've missed some patches but its not easy for me to tell which ones Jan 08 20:19:41 (I have to figure out which ones to apply to bitbake, meta-yocto and so on) Jan 08 20:22:00 * armpit rebase ... again... Jan 08 20:23:54 RP: I am trying to remove dependency on non busybox apps for runit to work Jan 08 20:24:04 zeddii: yt ? Jan 08 20:24:24 zeddii: 4.19 kernel headers have one regression Jan 08 20:24:27 khem: I understand Jan 08 20:24:40 zeddii: we need to backport this patch https://github.com/torvalds/linux/commit/e2c4cf7f98a519eb4d95532bfa06bcaf3562fed5 to 4.19 Jan 08 20:24:44 armpit: hopefully really simple as I think there are about three patches missing from upstream Jan 08 20:25:57 huh. why would using rm_work pull in perl-native.. Jan 08 20:26:19 zeddii: the sample error is here http://errors.yoctoproject.org/Errors/Details/215558/ Jan 08 20:29:48 RP, rebase done and pushed. what is not in next yet are the bitbake-diffsig **** BEGIN LOGGING AT Tue Jan 08 20:53:40 2019 Jan 08 20:59:07 RP: started couple of builds here with latest master-next Jan 08 20:59:20 lets see how perl pans out this time Jan 08 21:08:32 hi all, I'm moving my first steps with yocto, trying to write a recipe. I managed to package a kernel module (I see the ko file inside the rpm package) but when I bitbake core-image-minimal i get https://pastebin.com/VZs9TBSG Jan 08 21:09:41 zino__: could you please post a snippet of your recipe? Jan 08 21:12:45 robbawebba: https://pastebin.com/Bka56bD7 if that's not the relevant part I can post everything Jan 08 21:13:25 JPEW, ping Jan 08 21:15:26 zino__: Are you familiar with the module bbclass for help with the packaging and installation? Jan 08 21:16:38 robbawebba: not yet: any pointer for studying the necessary documentation would be welcome. The entire documentation is huge:) Jan 08 21:17:05 * zeddii_home sees khem’s message here, after he read the email :D Jan 08 21:17:44 robbawebba: I'm quite familiar with buildroot but I still feel a bit lost Jan 08 21:18:36 JPEW, just mentioning it before I forget; I see random changes of data order in the depsig.do_package, for recipe initramfs-boot, file "pkgdata/runtime/initramfs-boot", the line starting with FILES_INFO. Looks like it is set by meta/classes/package.bbclass: d.setVar('FILES_INFO', json.dumps(files)) Jan 08 21:19:19 robbawebba: I did "inherit module" if that's what you're referring to though Jan 08 21:20:14 JPEW, i mean, the digest is changing in the depsig.do_package, due to pkgdata/runtime/initramfs-boot changing randomly Jan 08 21:23:22 kroon: Hmm, OK Jan 08 21:23:48 so what im trying to say is that json.dumps() might not be deterministic Jan 08 21:24:02 kroon: Ya, I would believe that Jan 08 21:24:20 kroon: Perhaps python has something to help with that.... Jan 08 21:25:09 kroon: json.dumps(..., sort_keys=True) Jan 08 21:25:35 JPEW, i can try that and try to reproduce Jan 08 21:26:26 kroon: OK. I've been working on re-writing the signature generation to be more useful for you; I'll post a patch when it is done Jan 08 21:28:22 JPEW, cool. I hope it makes sense and is not too costly, I mean buildhistory could also do some post-processing on the raw data Jan 08 21:29:24 kroon: I think it won't be to bad. The hardest part is actually to get the listing to happen under fakeroot (pseudo) so it can see all the "correct" uid/gid's Jan 08 21:39:59 JPEW, yeah sort_keys=True does the trick Jan 08 21:40:12 JPEW, want me to send patch to ml ? Jan 08 21:40:48 kroon: Yes Jan 08 21:41:20 armpit: thanks, sorted I think Jan 08 21:42:53 JPEW: btw, your last patch to the list didn't quite apply against master. I just took the bit that did Jan 08 21:45:55 RP: Sorry, I really need to drop the "rehash running tasks" from my local sandbox Jan 08 21:47:10 JPEW: I know the problem, I have a ton of this kind of thing :/ Jan 08 21:51:50 RP: Anyway we could add a AB build that uses icecream :D.... The trick I think is that it wouldn't share sstate with any other build :( Jan 08 21:53:26 JPEW: we could, I'm just not sure it that many users or how much we'd have to test to make it worthwhile Jan 08 21:56:08 RP: Fair enough. FWIW, it can be inherited but disabled (ICECC_DISABLED="1") which has the advantage that you can share sstate without having to use it (And would have caught all the recent bugs). Jan 08 21:57:04 * armpit thinks he found another mutliconfig bug Jan 08 21:57:17 RP, cool.. thanks Jan 08 21:59:55 JPEW: I guess I'd be ok with a parsing test for it, its things like the SDK with it enabled which I'm a bit more wary of for test matrix explosion Jan 08 22:07:32 JPEW: is there a good how-to on using icecc Jan 08 22:09:20 khem: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-icecc is pretty close. I think it could use a little more work Jan 08 22:10:15 JPEW: since you are fresh with icecc can you see the gaps and fill them may be Jan 08 22:10:30 khem: Ya Jan 08 22:14:27 I want to do an experiment with this so what are limitationss that I should be aware of Jan 08 22:15:51 khem: You'll want to crank up ICECC_PARALLEL_MAKE.... I use ICECC_PARALLEL_MAKE="-j 24" (for reference, PARALLEL_MAKE is "-j 8"). Jan 08 22:18:03 khem: You also may need to fiddle with ICECC_USER_PACKAGE_BL if there are recipes that don't build. Jan 08 22:19:23 khem: Having a 15 node cluster of your co-worker's PCs helps a lot also :) Jan 08 22:22:39 * RP wonders if any openxt people are around Jan 08 22:25:42 JPEW: ok, I have ubuntu 14.04 and ubuntu 18.04 hosts, I hope thats not an issue Jan 08 22:26:23 Shouldn't be. We have an electic mix Jan 08 22:26:33 14.04, 18.04, Arch, Fedora Jan 08 22:27:26 JPEW: can you share your setup in confs ? Jan 08 22:28:56 e.g. host pre-requisites etc. that are needed on build machines Jan 08 22:31:48 khem: There isn't much configuration required on the compile nodes. Essentially it is install icecc and make sure the firewall doesn't block it. Jan 08 22:32:30 JPEW: ok, and its the host version whatever that distro supports ? Jan 08 22:33:25 khem: Yes. Icecream is pretty good about being backward compatible with itself (e.g. the protocol hasn't changed much). Most of the complicated logic is on the source (client) side compiler shims, so having newer ones of them is nice, but not mandatory Jan 08 22:34:02 is distcc/icecream still a thing? Jan 08 22:34:34 derRichard: Yes Jan 08 22:34:54 JPEW: ok do I need icecc-monitor as well ? Jan 08 22:35:34 It is helpful. Or you can install https://github.com/JPEWdev/icecream-sundae (shameless plug) Jan 08 22:35:55 JPEW: i thought these days sending souces/objects via network is much slower than the actual compile job (if you have fast cpus) Jan 08 22:37:02 derRichard: I think that is true if you can't jack up the parallelism Jan 08 22:37:04 well n/w has become fast too Jan 08 22:37:15 think of 10G interconnects in data-centers Jan 08 22:37:16 New news from stackoverflow: Why can't I copy files into the rootFS from a Yocto recipe Jan 08 22:37:27 they will be fastr than some of SSDs Jan 08 22:37:58 JPEW: how is your minitor better ? Jan 08 22:38:11 khem: this is not the distcc use case. 10 years ago it was very useful. just connect all compuers in your office to have a decent build cluster Jan 08 22:38:28 khem: Its command line only Jan 08 22:38:33 now we have single nodes with many cpus but still not 10g network Jan 08 22:38:42 anyway, getting too much ot :) Jan 08 22:39:03 JPEW: icecream-sundae look nice :-) Jan 08 22:39:08 *looks Jan 08 22:39:44 Thanks Jan 08 22:41:04 derRichard: you still have same usecase in build clusters in data centers Jan 08 22:41:15 JPEW: I see Jan 08 22:41:50 JPEW: so say I have two machines with icecc now if I run icecc enabled build on both of them what happens :) Jan 08 22:41:58 do they attach each other with bits Jan 08 22:42:38 Yes, make sure you start the scheduler daemon on at least one of them (or all of them) Jan 08 22:42:59 It's been a while since I did that, so I don't remember exactly Jan 08 22:43:09 khem: not sure. even in datacenters you have nodes with many local cpus. say 16 to 32. so icecc/distcc won't give you a huge speedup since make -j HUGE (like 512) does not scale Jan 08 22:43:56 buying large instances is expensive where as smaller instances are cheaper Jan 08 22:44:13 pool always wins in scale Jan 08 22:44:22 when you have many devs Jan 08 22:44:55 JPEW: ah scheduler daemon ok Jan 08 22:44:58 it is news to me that recent datacenters use local nodes with that few cpus. even my laptop has many cores Jan 08 22:45:13 JPEW: so any machine that want to issue the jobs has to be running scheduler for sure Jan 08 22:45:44 No, not necessarily. The daemon (iceccd) is separate from the scheduler (icecc-scheduler) Jan 08 22:46:27 so iceccd would take care of sending jobs to scheduler ? Jan 08 22:46:39 They all have to run the daemon. One (or more, they'll do election) has to run the scheduler. For example, here we have a dedicated scheduler because it can be a little resource intensive to have running a developer PC Jan 08 22:47:26 The scheduler just manages and assigns jobs to the daemons. They talk directly to each other once the scheduler decides who is doing what (e.g. not all data flows through the scheduler) Jan 08 22:48:21 yeah ok Jan 08 22:49:22 got iceccd up on both Jan 08 22:49:56 Cool. It it all works right icecream-sundae or icemon should show both nodes attached Jan 08 22:50:04 *If Jan 08 22:50:57 JPEW: OK, now starting/enabling icecc-scheduler.service on both too Jan 08 22:51:14 does it help to have multiple schedulers Jan 08 22:51:19 I guess yes Jan 08 22:51:40 you need to publish .debs and rpms for icecream-sundae Jan 08 22:51:54 or maybe appimage Jan 08 22:52:07 snap or flatpak Jan 08 22:52:19 I've been looking at creating a snap (never done it before, so it's a nice challenge) Jan 08 22:52:55 do it once for all https://appimage.org Jan 08 22:53:22 I'll look at that Jan 08 22:54:18 Anyway, I have to go, so if you have more questions they will have to wait until tomorrow. Jan 08 22:55:10 ok thx ttyl Jan 08 23:04:16 armpit: fired 2.6.1 Jan 08 23:09:03 k Jan 08 23:09:05 thanks Jan 08 23:09:15 a-full ? Jan 08 23:17:33 hm, i get "QA Issue: Architecture did not match (x86-64, expected x86)" for my kernel build. this is expected. userspace is 32bit, but kernel 64bit. but i wonder why i get this error, my bb file already contains: Jan 08 23:17:37 INSANE_SKIP_${PN} += "arch" Jan 08 23:19:44 zino__: yes! inherit module is exactly what I've been referring to Jan 08 23:21:21 zino__: check out the documentation here: https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules Jan 08 23:22:05 and here's an example recipe: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb Jan 08 23:23:43 zino__: pay special attention to to the extra RPROVIDES_${PN} that declares this recipe also provides kernel-module-* Jan 08 23:24:36 hmm, ok. INSANE_SKIP = "arch" did the trick Jan 08 23:24:57 maybe because the kernel recipe does deep black magic ;) Jan 08 23:44:34 armpit: yes, a-full Jan 08 23:45:02 for the Candian's its Full- eh Jan 09 00:18:01 Canada-dry Jan 09 01:03:45 JPEW, so, apparently there are more unstable data entries in the pkgdata output files.. i'll post patches to ml for suggested fixes, but some are not trivial to me, so would be good if you or RP could have a closer look at them **** ENDING LOGGING AT Wed Jan 09 02:59:57 2019