**** BEGIN LOGGING AT Tue Nov 26 02:59:57 2019 Nov 26 07:26:42 what is the recommended way to install systemd files? I need to install a network config file at /etc/systemd/network, but only for a specific distro Nov 26 07:27:31 rcrudo: make a recipe for it, simple as is Nov 26 07:30:45 hmm, ok. thanks Nov 26 07:50:45 Is it possible to provide kernel cfg-files, for "virtual/kernel" ? I want to enable specific kernel options, regardless of which particular kernel I use Nov 26 07:51:30 Regardless for example if I use raspberrypi-kernel or linux-vanilla Nov 26 07:55:36 ThomasD13: in theory yes, if the kernel recipes are similar to yocto defaults. Though in practice with various BSP layers for different SoC's I've never seen this actually working and it's easier to just maintain a target specific kernel config. Nov 26 07:55:59 thank you mcfrisk Nov 26 08:04:44 we have a multiconfig where mc1 refers to an aritifact of mc0. whats the correct/best way to invalidate sstate once the artifact is rebuilt? Nov 26 08:08:54 I've noticed that the layer.conf (created by "bitbake layer tools") looks like this: BBFILES += "${LAYERDIR}/recipes/*/*.bb \ Nov 26 08:08:54 ${LAYERDIR}/appends/*.bbappend" Nov 26 08:09:18 Is that a common way to specify .bbappend in a different path of .bb files? Nov 26 08:11:12 Is there a best practise for .bbappend-files, like to put the layer-directory outside of poky? Nov 26 08:11:42 ThomasD13: thats always a best practise Nov 26 08:12:31 @LetoThe2nd, to summarize all .bbappend-files in top directory "appends"? Nov 26 08:12:45 ThomasD13: nope, no have everything outside of upstream poky Nov 26 08:15:03 rburton: with latest master-next I am seeing sstate issue with go-native see http://jenkins.nas-admin.org/view/OE/job/oe_world_workspace-compare-signatures/872/console Nov 26 08:15:11 any ideas ? Nov 26 08:33:00 New news from stackoverflow: Docker image format Nov 26 08:52:16 just faling to see the probably obvious. how to restrict an append to a specific DISTRO? Nov 26 09:02:20 (other than doing the _distro dance for all things inside it, of course) Nov 26 09:17:05 whoops aehs29 back in 2015 accidentally turned off python bytecode optimisation Nov 26 09:17:13 and nobody noticed Nov 26 09:18:24 * LetoThe2nd wouldn't notice for many more years, cause no using python :) Nov 26 09:18:53 i cleaned up some patches and suddenly the packages all got bigger as .pyo files were being generated Nov 26 09:20:24 RP: do we already have some examples/best practises concerning a mc referring to a rootfs baked in another mc? we're starting to get our heads around it, but trip over one strangeness after the other. Nov 26 09:32:44 bluelightning: thanks for taking the patch (meta-qt4). I should really take a few days off... Not a mistake I usually do, sorry. Nov 26 09:38:42 LetoThe2nd: I think aehs29's layer had an example? Nov 26 09:43:03 I get crazy here :D - What could be possibly gone wrong when a kernel option is not set in my final kernel, but the configuration fragment (.cfg) shows up in the temp/kernel/... - directory? Nov 26 09:45:00 RP: kay, let me look it up Nov 26 09:47:29 RP: you mean meta-freertos? Nov 26 10:15:58 ThomasD13: I'm not using KConfig fragment so need to be checked but.. have you checked your KERNEL_FEATURES? https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#var-KERNEL_FEATURES Nov 26 10:19:05 qschulz, thanks I will look into that. Said that, some other fragments find their way into final .config. I just don't see the difference between working and not working fragments Nov 26 10:19:44 I'm currently trying to debug the do.run_kernel_configme. Which calls a script that works on the fragment files Nov 26 10:20:24 There should be somewhere a merge_config_build.log file, but I cannot find it :( Nov 26 10:25:45 ahhh yeah! I found it! Nov 26 10:27:42 https://pastebin.com/sJrku6S3 Nov 26 10:28:40 "Value requested for CONFIG_STRICT_DEVMEM not in final .config" Okay, thats my problem. Why isn't this printed somewhere as warning during the build process? Nov 26 10:32:06 ThomasD13: there is a fatal error only when merge_config.sh is returning != 0 Nov 26 10:32:42 so merge_config.sh has "successfully" completed Nov 26 10:33:24 but you know, IMO, good contribution to kernel-yocto.bbclass Nov 26 10:33:25 New news from stackoverflow: How to get the ARM tool chain with poky? Nov 26 10:34:40 qschulz, okay. I get the feeling that cfg fragments only get applied if the specific option already "exist" within the defconfig. Is that correct? Nov 26 10:35:32 ThomasD13: I don't know, you' Nov 26 10:35:40 d have to have a look at merge_config.sh script :) Nov 26 10:41:35 hello. I know I'm missing something simple but can you help me overcome this library recipe QA errors? https://gist.github.com/cengizIO/f0e2cf2c2e8f84aab63719a2e76aabc6 Nov 26 10:42:00 dev-elf and dev-deps Nov 26 10:42:11 read the docs but couldn't understand what I'm doing wrong.. Nov 26 10:42:35 rburton would probably beat me Nov 26 10:53:55 cengiz_io: the so library you have in dev should be a symlink to the .so.x.y.z lib is my understanding of your warning Nov 26 10:55:14 cengiz_io: if you have a versioned library, just use a symlink instead of copying the versioned library and strip the version out of its filename. Nov 26 10:55:47 cengiz_io: or if it isn't a versioned library, add the .so lib to FILES_${PN} but I **think** it'll trigger another warning Nov 26 10:55:49 qschulz all I do is `make` the library and it produces `libfreeimage-3.18.so` Nov 26 10:56:33 https://github.com/webOS-ports/meta-webos-ports/blob/master/meta-luneos/recipes-support/freeimage/freeimage_3.17.0.bb Nov 26 10:57:05 cengiz_io: ^ that's a recipe for your SW which is linked from https://layers.openembedded.org/layerindex/recipe/51447/ Nov 26 10:57:40 so maybe you can take some inspiration out of it Nov 26 10:59:19 qschulz didn't know that. thanks. Nov 26 11:00:00 it's so confusing. I assumed that bitbake is already adding header files to -dev package and .so files to regular recipe Nov 26 11:00:35 cengiz_io: but this is based on path, and if the install stage of the package is b0rk3d, then bitbake gets confused. Nov 26 11:01:37 cengiz_io: and the do_configure + do_install stage of the recipe that qschulz linked pretty much suggest that the original install stage makes bad assumptions. Nov 26 11:01:59 LetoThe2nd it does... installing with root permissions etc Nov 26 11:02:50 cengiz_io: it actually isn't. /usr/lib/lib*.so.* are in regular package, /usr/lib/lib*.so are in -dev package Nov 26 11:04:21 because sensible people do not provide a .so but a .so.x.y.z so it's easy to know which version is being used at one point. And then if some SW linking against does not care much about the version of the lib or only for some major version, then they provide/use symlinks to versioned libraries Nov 26 11:05:49 qschulz LetoThe2nd: libfreeimage-3.18.0.so is the only artifact that Makefile produces Nov 26 11:06:01 without modifying with recipe Nov 26 11:06:19 (I've disabled static lib) Nov 26 11:06:29 maybe it's the naming? Nov 26 11:06:39 cengiz_io: I know you're not responsible of this, I'm just saying what people usually expect from libraries and why what I'm explaining is the default in Yocto Nov 26 11:07:07 qschulz ofcourse. I'm just trying to understand what's wrong and what it should be Nov 26 11:07:47 at worst libfreeimage-3.18.0.so.x.y.z Nov 26 11:08:13 but from the naming, it might actually just be a malformed lib filename. MAYBE, it could be libfreeimage.so.3.18.0 Nov 26 11:09:04 which makes the most sense because I'm not sure SW linking against this libraries are actually saying they want to link against libfreeimage-3.18.0.so but more libfreeimage.so (maybe with version number appended) Nov 26 11:09:51 cengiz_io: https://github.com/webOS-ports/FreeImage/blob/master/Makefile.gnu#L38 Nov 26 11:10:26 this most likely should be lib$(TARGET).so.$(VER_MAJOR).$(VER_MINOR) Nov 26 11:10:32 yep. Nov 26 11:10:38 that's makes more sense Nov 26 11:28:10 Greetings folks. Nov 26 11:29:04 This brings back some memories. I have not used irc since the late 80s early 90s took me a bit to remember everything. Nov 26 11:33:44 Post this in Poky as well. Just wante to make sure everyone understand where I come from :) Just a little bit of backstory per say. I am a learning disabled 52yr old but I love to learn new things. So I was told about Yocto to do with a project myself and my partner are wanting to do. Nov 26 11:33:54 but here is the error I am getting and nope I can not program to save my life YET. :) but going to start to learn. Nov 26 11:34:09 ERROR: Task (virtual:native:/home/thedarrens/Gubbins/Yocto/FHOS/poky/meta/recipes-devtools/bison/bison_3.0.4.bb:do_compile) failed with exit code '1' Nov 26 11:35:21 ../bison-3.0.4/lib/fseterr.c:77:3: error: #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib." Nov 26 11:35:21 | 77 | #error "Please port gnulib fseterr.c to your platform! Look at the definitions of ferror and clearerr on your system, then report this to bug-gnulib." Nov 26 11:43:32 cengiz_io: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries#Non-versioned_Libraries Nov 26 11:46:29 couldn't found recipe dependency list with bitbake -g recipe, any idea why? Nov 26 11:48:03 thedarrens: that looks like an error from an older release of poky on a modern system which broke bison. Nov 26 11:48:19 thedarrens: ideally, switch to the latest release of poky (3.0/zeus) Nov 26 11:48:54 ok will do that I did do a git, sorry still learning will try it again thank ruburton Nov 26 11:50:20 i thought we'd fixed up the stable releases by now, so i suspect you're using an old release - on purpose or accident Nov 26 11:50:42 i mean, even if you wanted to stick with 2.7 or 2.6, the latest point release of those had that fixed. Nov 26 11:51:18 must be by accident. I did this to get it Nov 26 11:51:20 git clone -b sumo git://git.yoctoproject.org/poky.git Nov 26 11:51:32 hm maybe we didn't fix sumo. Nov 26 11:51:53 well it is a learning expeiance so off to do it again Nov 26 11:51:56 anyway thats old. if you're not tied to sumo for any particular reason, switch to zeus Nov 26 11:53:30 not at all. As I said on was just told to learn yocto from a old friend that knows about my learning disabilies and hell here I go. Nov 26 11:53:36 THanks again Rburton Nov 26 11:57:42 thedarrens: you can find a lot of introductory explanations at https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj Nov 26 11:58:01 sweet Thank you Leto. Nov 26 12:25:12 Well, that seems to be working much better. Thank you again. Nov 26 12:27:25 thx rburton Nov 26 12:59:03 maybe a silly question but why does poky core-image-minimal run dbus-daemon? Nov 26 12:59:13 sorry why does it *not* run dbus-daemon? Nov 26 13:00:10 probably because there is no dbus installed by default, unless you tinkered with poky Nov 26 13:03:49 New news from stackoverflow: Bitbake: How to only fetch the sources? Nov 26 13:03:50 milloni: if you add systemd as explained in the documentation (and shown in the live coding sessions) you get dbus basically for free ;-P Nov 26 13:05:29 Watching that right now actually Thank you again LetoThe2nd this will advance the disability project we want to try to do Nov 26 13:05:54 LetoThe2nd: i know, but that's the thing - even if you have systemd installed - it still does *not* have dbus-daemon Nov 26 13:06:15 it does have dbus (the library) and it does use dbus Nov 26 13:06:20 but not dbus-daemon Nov 26 13:07:36 i just saw agl have a bbappend for dbus that adds a systemd service for dbus-daemon and i was like "oh really?" Nov 26 13:10:37 thedarrens: have fun. if you have questions concerning something in the videos, just ask around here. i'm not always around of course, but we'll try to answer ASAP :) Nov 26 13:11:54 No, problem I will do that. lol, I fell like I am 20 again back in the late 80s all I need now is a bbs and I am sorted. Nov 26 13:36:08 my bad, it does install dbus-daemon if on a configuration with systemd Nov 26 13:36:55 presumably the agl bbappend is redundant Nov 26 13:53:56 When I try to to use musl as dependency, it gets skipped because glibc is set as provider for virtual/libc. But I only need musl to static-link inside our initram, it should never end in the rootfs (nor initram for what it's worth). Is there a trick to pull it in regardless, or will I have to pre-compile the binaries for the initram? (I think that's what poky does?) Nov 26 13:59:15 The alternative I though about was to create my own recipe (musl-internal) and have that provide the build-dependencies and avoid the musl that's in poky, which hopefully fixes my usecase but isn't too nice either Nov 26 14:01:29 package-mangement with opkg is updating or showing list-installed Nov 26 14:01:35 not* Nov 26 14:02:45 package_feed_uris and arch variables are defined but not reflecting in opkg configuration Nov 26 14:03:00 opkg list-installed is empty Nov 26 14:04:16 anyone else using package-management saw this behavior?? Nov 26 14:28:52 @LetoThe2nd, would there happen to also been some documentation on, and I am not sure how to phrase this, adding a desktop environment etc Or is that also covered in the videos, Just about at the end of number 1 Nov 26 14:36:44 Hi guys, i have a strange problem regarding yocto and initramfs.. I managed to compile and build initramfs, in the tmp/deploy/images i get file like zImage-initramfs-4.14.xxx.bin, but also i have file zImage--4.14.xxx.bin - which means i have kernel and kernel with initramfs.. final (wks) image for sdcard have only zImage, without initramfs.. i do not use wks boot-partition plugin... question, how do i replace zImage with zImage-initramfs in root Nov 26 14:36:44 filesystem /boot? Nov 26 14:37:46 documentation statets that if i put in local.conf INITRAMFS_IMAGE_BUNDLE = "1" it should do the trick Nov 26 14:38:25 but no matter what i tried (and i tried few things found on internet) i cant get initramfs image in final image Nov 26 14:40:56 im lost.. Nov 26 14:42:50 RP: any idea who to blame for | make[1]: /home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/gcc-crosssdk-aarch64-pokysdk-linux/9.2.0-r0/gcc-9.2.0/build.x86_64-linux.aarch64-pokysdk-linux/./gcc/xgcc: Command not found Nov 26 15:03:51 * armpit blame the old guy in CA Nov 26 15:04:13 rburton, was that selftest? Nov 26 15:05:13 in master-next ? Nov 26 15:05:31 https://git.openembedded.org/openembedded-core/commit/?h=master-next&id=17ea7a4155c1dafde769b18b0372c1c7372d0dc5 Nov 26 15:05:40 maybe ? Nov 26 15:09:43 I have a question about Building Software from an External Source Nov 26 15:09:54 following this https://www.yoctoproject.org/docs/3.0/dev-manual/dev-manual.html#building-software-from-an-external-source Nov 26 15:10:25 looks like you simply nee to include in a recipe inherit externalsrc EXTERNALSRC = "/path/to/sources" Nov 26 15:10:46 but testing that in a recipe it fails Nov 26 15:11:19 actually the build works only if you also set EXTERNALSRC_BUILD = "/some/path Nov 26 15:11:22 Hi, is there a more detailes documentation for "do_image"? Nov 26 15:11:36 or / and "do_deploy" Nov 26 15:11:55 but externalsrc.bbclass says that if externalsrcbuild: Nov 26 15:11:55 d.setVar('B', externalsrcbuild) Nov 26 15:11:55 else: Nov 26 15:11:56 d.setVar('B', '${WORKDIR}/${BPN}-${PV}/') Nov 26 15:12:11 the latter is ignored completely Nov 26 15:12:30 am I misunderstanding something? Nov 26 15:15:06 GeneralStupid: https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#normal-recipe-build-tasks Nov 26 15:16:52 mckoan: if EXTERNALSRC_BUILD is not set, the build directory is actually WORKDIR/$BPN-$PV which is the default for recipes. If it is set, to whatever you've set it to Nov 26 15:17:18 "By default, externalsrc.bbclass builds the source code in a directory separate from the external source directory as specified by EXTERNALSRC. If you need to have the source built in the same directory in which it resides, or some other nominated directory, you can set EXTERNALSRC_BUILD to point to that directory: " Nov 26 15:17:23 https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#building-software-from-an-external-source Nov 26 15:25:22 thedarrens: nope, there is nothing on desktop environments. and i actually don't plan to do so, at least not in the video series as it is not really a common usecase Nov 26 15:28:51 qschulz: that's the problem. If EXTERNALSRC_BUILD is not set WORKDIR/$BPN-$PV is empty Nov 26 15:29:59 rburton: no, not without more context Nov 26 15:34:54 mckoan: your makefile/cmake whatever does not use B correctly? (overriden flags or whatever is passed by yocto to give where to do all the builds) throwing ideas :) Nov 26 15:35:25 mckoan: kind of the behavior of autotools-brokensep for externalsrc? Nov 26 15:35:52 rburton: armpit: I've been looking at https://bugzilla.yoctoproject.org/show_bug.cgi?id=13632 (and 13602) but haven't been able to recreate the fail even under high system load. Any ideas on how to recreate the failure? Nov 26 15:35:53 Bug 13632: normal, Medium+, 3.1 M1, trevor.gamblin, NEW , logrotate.LogrotateTest.test_2_logrotate selftest failure in core-image-full-cmdline Nov 26 15:39:41 tgamblin, sorry no ideas Nov 26 15:40:12 RP, any reason why the last few patches for zeus merge request got dropped ? Nov 26 15:43:27 qschulz: that may be the only reason, thx Nov 26 15:43:39 armpit: buildtools, my next branch Nov 26 15:45:37 rburton, what ? Nov 26 15:45:51 armpit: no reason, I think I just messed up. There were whitespace issues with patches and merges. Can you rebase the branch and I'll see what is left? Nov 26 15:46:42 RP, will do. Nov 26 15:47:20 rburton: some new build failures due to python stuff in master-next see https://errors.yoctoproject.org/Errors/Build/93168/ Nov 26 15:47:31 armpit: also updated -helper as you mentioned Nov 26 15:48:16 cool Nov 26 15:50:28 oh rp added the no-py2 bits Nov 26 15:50:29 bold Nov 26 15:51:16 glmark and jack are waf being dumb Nov 26 15:51:17 rburton: not many failures and the things that did fail aren't clearly related Nov 26 15:51:57 khem: easy fix is to add python to hosttools in meta-oe's layer.conf :) Nov 26 15:53:33 RP, rebased. Nov 26 15:55:39 armpit: which branch? Nov 26 15:56:07 https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/zeus-next Nov 26 15:56:15 YPTM - armin in on Nov 26 15:56:34 YPTM - Jan-Simon is on Nov 26 15:56:57 rburton: I would rather like patches to fix the problems Nov 26 15:59:01 YPTM - Trevor is on Nov 26 15:59:23 armpit: that branch was updated 3 daya ago? Nov 26 15:59:31 * RP is missing something Nov 26 16:00:05 YPTM - moto-timo joined Nov 26 16:00:34 correct. I pushed my -nut version which is what was tested Nov 26 16:00:41 YPTM - Scott Murray joined Nov 26 16:00:56 armpit: I asked if you could rebase it, you said yes? Nov 26 16:01:41 git said no change... fine.. I will make it change Nov 26 16:02:20 armpit: hmm, it did? :/ Nov 26 16:02:28 khem: someone might need to update jack to a recent release first Nov 26 16:03:19 YPTM - Denys is on Nov 26 16:04:41 rburton: usually updates will solve lot of such issues, since other distros are getting py2 free as well Nov 26 16:08:50 YPTM - Khem is on Nov 26 16:10:12 @LetoThe2nd, ok, thanks. Nov 26 16:12:05 thedarrens: what is your actual usecase? Nov 26 16:22:34 mk-meta-python2.sh script: https://gist.github.com/moto-timo/ab70ab96ddbaf5fd1226bd21dbbfec9b Nov 26 16:23:11 this requires git-filter-repo https://github.com/newren/git-filter-repo Nov 26 16:26:26 moto-timo: nice. i'd never seen filter-repo, that looks handy Nov 26 16:31:05 kergoth: this is VERY fast compared to filter-branch Nov 26 16:31:48 i think one of the biggest annoyances i had doing repo splits like this was dealing with renames intelligently when the files moved in and out of the boundaries of the subdir i'm filtering out. bit of a mess Nov 26 16:33:12 kergoth: filter-repo is quite capable, but the examples are a little light on content so far... Nov 26 16:34:55 moto-timo: personally i'd just copy/paste and ignore the history :) Nov 26 16:36:59 i like the idea of keeping it if it's not too troublesome, being able to still git-blame and whatnot is helpful Nov 26 16:37:10 but yeah, depends on the difficulty vs time constraints really.. Nov 26 16:37:39 the history bit is done. the rest is cleanup that had to happen even with copy-paste Nov 26 16:41:55 moto-timo: are you using git filter-branch ? Nov 26 16:42:23 khem: I replaced it with git-filter-repo. much more capable and faster Nov 26 16:42:35 i see cool Nov 26 16:43:30 khem: I haven't quite gotten the handle of using it as a library, but command line (as in my gist) is working pretty well. The --replace-text option is not quite working properly with regex... Nov 26 16:44:03 so I stopped using it and used the --blob-callback instead Nov 26 16:45:48 * armpit why did I get a Disco reference from moto-timo email?? python2 staying-alive Nov 26 16:46:14 * moto-timo laughs with armpit Nov 26 16:46:40 it needs a logo with the disco floor lights... Nov 26 16:47:12 ubuntu codename I guess Nov 26 16:47:31 and the platform shoes with yocto printed on them Nov 26 16:47:42 either have codenames or release names but eh Nov 26 17:00:47 JPEW: I think what I wasn't clear about - sstate will restore any matching hashes and it ignores dependencies unless they're "hard" deps. "hard" deps are only pseudo-native and useradd stuff Nov 26 17:01:29 JPEW: so when the hash for an already installed artefact changes, all bets are off Nov 26 17:04:36 New news from stackoverflow: How to compile a basic c file in yocto Nov 26 17:54:00 rburton: :O Nov 26 17:54:41 aehs29: copy-paste failures that nobody noticed for years! https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/next&id=560f339443a1cd57a1d8a9f9f0cc8aacbb627fef Nov 26 18:01:31 RP: I had a thought: do we (or could we) know that gdb-cross is being rebuilt because the sstate object is missing? Nov 26 18:02:43 JPEW: yes, but we don't know why that could be Nov 26 18:03:20 JPEW: the clue is when we rebuild it and an artefact which matched no longer does Nov 26 18:05:22 RP: Right, I guess I wonder if we need to report a hash to the server in that case. We've already asked the server what the unihash for that taskhash *should* be, reporting it to the server and giving it the option to change it based on outhash seems unnecessary (in that specific case) Nov 26 18:06:04 *if* we can say this task is executing because it is missing sstate and is a dependency for another setscene task Nov 26 18:07:06 Effectively, it means "create the sstate object with this unihash, we don't really care too much if it's contents match because we aren't going to rebuild downstream anyway" Nov 26 18:08:46 JPEW: not sure that helps us Nov 26 18:09:03 * kergoth works on fixing meta-external-toolchain to handle an oe/yocto sdk Nov 26 18:26:21 khem: jack and glmark fixes posted Nov 26 18:27:14 rburton: cool thank you Nov 26 18:27:31 rburton: meta-qt5 will need some py3 love http://errors.yoctoproject.org/Errors/Build/93179/ Nov 26 18:27:43 someone else can deal with that Nov 26 18:32:18 rburton: there is just universal conciousness, all is one, there is no one else Nov 26 18:32:27 rburton: hence you have to fix it Nov 26 18:39:10 rburton: I only see glmark2 fix on ml Nov 26 19:10:16 hi Nov 26 19:55:08 rburton RP hg fetcher is ending in fetch failures seems py2 related see http://errors.yoctoproject.org/Errors/Details/283512/ Nov 26 19:59:34 mercurial recipe needs py3 migration too hmm ok Nov 26 20:04:03 khem: when I did a test with py2 removed a couple of months ago, mercurial seemed like it'd need some work. jack was another one, it's a dependency for a few other things so might be more problematic to blacklist Nov 26 20:06:03 khem: heh, I see rburton has jack fixed already Nov 26 20:52:08 yeah mostly I have sent few fixes Nov 26 20:52:22 mercurial 5.2 has py3 support Nov 26 20:52:25 so lets see how far Nov 26 20:52:34 someone else can deal with hg :) Nov 26 20:53:16 yeah I have it fixed dont worry Nov 26 21:03:04 khem: i've a better jack fix that i somehow didn't send Nov 26 21:03:38 posted Nov 26 21:03:43 also replicated your htop one :) Nov 26 21:07:41 RP: next is one build away from green. weird buildtools failure disappeared on rebuild... Nov 26 21:30:36 rburton: yours or mine? Nov 26 21:56:14 RP: I'm getting the tar sanity check failure from 2c7624c17e43f9215cf7dcebf7258d28711bc3ce (https://travis-ci.org/crops/yocto-dockerfiles/jobs/617421188). Are you using the buildtools-tarball to get around that on the autobuilder? Nov 26 21:57:19 RP: Looks like it happens on Centos7 and Ubuntu 14.04 Nov 26 21:57:33 rewitt: yes, we are using buildtools-tarball on centos7 and debian8 Nov 26 21:57:48 rewitt: 1404 is out of support now so we don't have one of those Nov 26 21:59:02 RP: Ok thanks, I just wanted to make sure I wasn't missing some distro package update. Nov 26 22:00:16 I should probably turn of 1404 as well, I think last time I checked I was looking at EOL only. Nov 26 22:00:38 RP: mine Nov 26 22:02:24 rewitt: given centos7 is getting old, this seemed like the best way forward for the project and reproducibility... Nov 26 22:03:45 RP: I have no problems with it, just wanted to make sure I wasn't screwing something up. Nov 26 22:22:45 rewitt: not at all. Good to see you btw! :) Nov 26 22:31:56 RP: Yeah I'm still alive :) Nov 26 22:32:24 RP: I just lurk in here until I need something ;) Nov 26 23:07:07 RP: drop 'python: clean up command overriding' from next please Nov 26 23:09:05 rburton: gone Nov 26 23:09:14 rburton: does that cause fails on the AB? Nov 26 23:09:23 no, just bad packages Nov 26 23:09:28 rburton: ok Nov 26 23:09:42 got a fixed series, just need to write nice commit messages **** ENDING LOGGING AT Wed Nov 27 02:59:57 2019