**** BEGIN LOGGING AT Mon Dec 17 03:00:01 2018
Dec 17 06:51:39 <webreformer> Hi,
Dec 17 06:51:59 <webreformer> I am getting slf deadlock in libGLESv2.so.2
Dec 17 06:53:02 <webreformer> I have created debug build
Dec 17 06:53:12 <webreformer> but I am not able to see call stack
Dec 17 06:53:20 <webreformer> > Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Dec 17 06:53:48 <webreformer> CALL STACK :
Dec 17 06:53:52 <webreformer> -----------------------------
Dec 17 06:54:46 <webreformer> (gdb) bt
Dec 17 06:54:46 <webreformer> #0  0x0000ffffa0a12564 in __lll_lock_wait (futex=futex@entry=0xaaaadde686a0, private=0) at /usr/src/debug/glibc/2.26-r0/git/nptl/lowlevellock.c:46
Dec 17 06:54:46 <webreformer> #1  0x0000ffffa0a0b7f8 in __GI___pthread_mutex_lock (mutex=0xaaaadde686a0) at /usr/src/debug/glibc/2.26-r0/git/nptl/pthread_mutex_lock.c:80
Dec 17 06:54:46 <webreformer> #2  0x0000ffff9f9d2074 in ?? () from /home/user/sdk/usr/lib/libGLESv2.so.2
Dec 17 06:54:47 <webreformer> #3  0x0000000000000001 in ?? ()
Dec 17 06:54:49 <webreformer> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Dec 17 06:54:51 <webreformer> ------------------------------------------
Dec 17 06:56:13 <webreformer> Can anyone suggest me some resources and tips to get more information about deadlock ?
Dec 17 08:12:56 <mckoan> good morning
Dec 17 12:26:15 <mrpelotazo> I have a custom systemd only distro configured as described in section "7.24.1. Using systemd Exclusively" of the mega manual but the generated image doesn't contain the /sbin/init symlink
Dec 17 12:27:13 <derRichard> maybe it needs an initramfs which starts systemd for you
Dec 17 12:27:30 <derRichard> a "full blown" systemd setup includes an initramfs
Dec 17 12:28:36 <mrpelotazo> derRichard: I've been running that image fine on sumo (no initram). Is after the upgrade to thus that is stopped working
Dec 17 12:30:10 <mrpelotazo> derRichard: the kernel is able to mount my rootfs partition but it panics when calling try_to_run_init_process("/sbin/init") because the init symlik is missing
Dec 17 12:30:34 <ernstp> why isn't BBPATH sorted according to layer priority? thinking about include/require
Dec 17 12:30:54 <derRichard> mrpelotazo: as workaround pass the path to systemd via init=
Dec 17 12:31:13 <derRichard> mrpelotazo: but again, maybe the new image type assumes that you boot with an initramfs which knowns about systemd
Dec 17 13:01:51 <mrpelotazo> derRichard: passing the init= parameter won't help since /lib/systemd/systemd is not part of the image neither the other systemd-*
Dec 17 13:03:10 <derRichard> this is news to me
Dec 17 13:03:18 <derRichard> you said that only the symlnk is missing
Dec 17 13:03:20 <rburton> mrpelotazo: sounds like your image doesn't have systemd installed
Dec 17 13:03:36 <rburton> is this a custom image, or core-image-*?
Dec 17 13:04:00 <mrpelotazo> derRichard: sry I've found out meanwhile...
Dec 17 13:05:32 <mrpelotazo> rburton: yes I'm building a custom image with a few install appends
Dec 17 13:05:43 <rburton> sounds like you forgot to install the init manager :)
Dec 17 13:06:34 <mrpelotazo> rburton: do I have to install systemd explicitly in my image?
Dec 17 13:06:46 <rburton> depends how you're building the image
Dec 17 13:07:23 <rburton> the core-image-* recipes use core-image.bbclass which uses image features and default installs to get stuff like init in the image
Dec 17 13:09:07 <rburton> ie core-image.bbclass has
Dec 17 13:09:13 <rburton> CORE_IMAGE_BASE_INSTALL = '\
Dec 17 13:09:13 <rburton>     packagegroup-core-boot \
Dec 17 13:09:13 <rburton>  ...
Dec 17 13:10:01 <rburton> packagegroup-core-boot depends on init  via ${VIRTUAL-RUNTIME_init_manager}
Dec 17 13:31:30 <nacknick> After changing recipe it changes the package's binary, but when loading the image, it saves a previous version of the executable... Anyone knows why?
Dec 17 13:32:06 <nacknick> changes the package's binary in yocto folder I  mean
Dec 17 13:32:44 <nacknick> I see the change. But in the final image - it contains a previous version for some reason
Dec 17 13:33:45 <nacknick> even in 'package' folder I see the correct binary.... only in 'wic' file (MBR) it's no the current one
Dec 17 13:33:55 <nacknick> not*
Dec 17 14:01:17 <mrpelotazo> rburton: i was inheriting from "image" in my custom image. changed it to "core-image" and now works, thanks!
Dec 17 14:15:29 <nacknick> How do I write wic.gz to sd card? I used
Dec 17 14:15:50 <nacknick> 'wic' until now. but after I formatted the sd card it does not work
Dec 17 14:16:41 <nacknick> gunzip -c '.../pyro/build/tmp/deploy/images/marsboard/core-image-minimal-marsboard.wic.gz' | sudo dd of=/dev/sdX bs=1M  iflag=fullblock oflag=direct conv=fsync status=progress
Dec 17 14:17:14 <nacknick> Does not work as well... It's writing, but the board is in boot loop when trying to load the image
Dec 17 14:22:23 <fsdun> nacknick, did you rebuild the image?
Dec 17 14:22:58 <nacknick> yes
Dec 17 14:23:19 <nacknick> I think that the problem is in writing the image into the sd card
Dec 17 14:23:23 <fsdun> If you use wic it already contains partition table. just dd it to the device (not partition=
Dec 17 14:23:57 <fsdun> my first question was related to your first question
Dec 17 14:23:58 <nacknick> until now I used 'wic write <wic file> /dev/sdb'
Dec 17 14:24:12 <fsdun> ok.
Dec 17 14:24:17 <fsdun> should be fine
Dec 17 14:24:30 <nacknick> about your first answer, there is a way to force rebuild?
Dec 17 14:24:56 <nacknick> or I must to change a recipe so I will rebuild
Dec 17 14:25:02 <nacknick> must change8
Dec 17 14:25:05 <nacknick> *
Dec 17 14:25:28 <fsdun> if you change some component in recipe bitbake will rebuild all packages having a build dependency
Dec 17 14:25:54 <nacknick> wic command does not do anything since I formatted the sd card
Dec 17 14:25:59 <fsdun> where do you apply your changes?
Dec 17 14:26:02 <nacknick> maybe I should format it in a certain way?
Dec 17 14:26:11 <nacknick> in one package... diffutils
Dec 17 14:26:40 <fsdun> only one problem first
Dec 17 14:26:56 <fsdun> diffutils first
Dec 17 14:27:12 <fsdun> what are you doing using diffutils?
Dec 17 14:27:26 <nacknick> modify diff binary
Dec 17 14:28:10 <nacknick> maybe I did not see the change because of the writing problem, so the problems might be connected each other
Dec 17 14:30:13 <nacknick> fsdun, how should I format the sd card? because wic does not do anything right now and I can't check anything
Dec 17 14:34:38 <fsdun> if you want to see updated partition table you maybe need to run blockdev --rereadpt <device>
Dec 17 14:36:47 <nacknick> blockdev: ioctl error on BLKRRPART: Inappropriate ioctl for device
Dec 17 14:40:22 <nacknick> fsdun
Dec 17 14:42:47 <fsdun> nacknick, do you replace /dev/sdX by something matching you device?
Dec 17 14:43:28 <nacknick> of course
Dec 17 14:43:52 <nacknick> sudo /home/amit/fsl-community-bsp/sources/poky/scripts/wic write /home/amit/fsl-community-bsp/build/tmp/deploy/images/imx6ullevk/core-image-base-imx6ullevk-20181217123558.rootfs.wic /dev/sdb
Dec 17 14:44:13 <nacknick> fsdun, this is the exact command I use
Dec 17 14:44:19 <fsdun> ok
Dec 17 14:44:35 <nacknick> in the past it worked.... now it does not do anything (since the sd card format)
Dec 17 14:44:46 <fsdun> you can print partition table using fdisk -l on file
Dec 17 14:44:49 <nacknick> maybe I should format it in another way, I don't know
Dec 17 14:45:13 <fsdun> only copy wic to the SD Card
Dec 17 14:45:34 <nacknick> Disk /dev/sdb: 501.2 MiB, 525546496 bytes, 1026458 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x17805894  Device     Boot Start     End Sectors   Size Id Type /dev/sdb1  *     8192   53425   45234  22.1M  c W95 FAT32 (LBA) /dev/sdb2       57344 1026457  969114 473.2M 83 Linux
Dec 17 14:45:42 <nacknick> if you can read it :|
Dec 17 14:45:47 <fsdun> this should do everything if it's done right
Dec 17 14:46:46 <fsdun> 2 partition. does it match your expectation?
Dec 17 14:47:12 <nacknick> https://imgur.com/a/yaEqMod
Dec 17 14:48:00 <nacknick> s
Dec 17 14:48:00 <nacknick> I'm not sure what my expectation are :)
Dec 17 14:48:07 <nacknick> is
Dec 17 14:49:26 <nacknick> I had 'root' and 'boot' partitions that were created automatically by using 'wic'
Dec 17 14:49:31 <fsdun> let's get back to diffutils
Dec 17 14:49:35 <nacknick> now it does not create them
Dec 17 14:49:41 <fsdun> what are you doing and how?
Dec 17 14:50:17 <nacknick> I don't need a solution for diffutils actually... If I can't write to the sd card....
Dec 17 14:50:50 <fsdun> I think It's writing correctly
Dec 17 14:52:36 <RP> kergoth: given the md5 collisions problem we should change siggen to use sha256 too?
Dec 17 14:53:18 <nacknick> fsdun. the sd card is empty
Dec 17 14:53:24 <nacknick> it's not writing
Dec 17 14:59:54 <fsdun> nacknick, but you showed the partition table
Dec 17 15:00:11 <nacknick> and what did you see?
Dec 17 15:01:25 <fsdun> a 22.1M partition using vfat and bootflag enabled and a 474.2M linux partition
Dec 17 15:02:04 <nacknick> and when inserting the sd card to the computer it seems empty
Dec 17 15:02:09 <nacknick> this is how it should be?
Dec 17 15:02:34 <fsdun> maybe you should disable your automount stuff first
Dec 17 15:03:25 <nacknick> I have a led that flickers when reading/writing from/to the sdcard. when I ran wic at past - it flickered. now it does not...
Dec 17 15:04:06 <fsdun> then you should verify if the used devices is the device you expect
Dec 17 15:04:09 <nacknick> what automount?
Dec 17 15:04:43 <nacknick> yes it is. I checked with 'mount' command
Dec 17 15:04:46 <nacknick> this is the device
Dec 17 15:09:51 <fsdun> please remove the usb stick and check if the expected device disappears
Dec 17 15:13:30 <nacknick> it does
Dec 17 15:19:55 <ak77> I have moved some out-of tree modules to another layer, but now I get compilation errors like "__LINUX_ARM_ARCH__  is not defined". what could be wrong
Dec 17 15:20:28 <ak77> I did cleanall on linux, and these modules.
Dec 17 15:20:33 <ak77> Didn't help
Dec 17 15:21:54 <ak77> it does say "Kernel configuration is invalid. |          include/generated/autoconf.h or include/config/auto.conf are missing. |          Run 'make oldconfig && make prepare' on kernel src to fix it.", but kernel compiled fine
Dec 17 15:26:06 <gedda__> Bitbake recipe: I have a bare git repo mirror packed in a tar ball in my recipe as SRC_URI = "file://repo-mirror.tar.gz" aswell as a SRCREV = "<commit-id>". When I'm trying to build this however, bitbake only unpacks the tar-ball and then assumes that repo-mirror.git is the working-dir. This obviously fails as a mirror first needs to be cloned into a separate folder first to get a work-dir. How do I specify in my recipe to clone the m
Dec 17 15:26:51 <ak77> gedda__: maybe do_unpack[postfuncs] += my_clone_func ?
Dec 17 15:27:47 <gedda__> ak77: Ah, why didn't I think of that. I'll have a look at it. Is there any nice built in function for doing a git clone?
Dec 17 15:28:52 <ak77> gedda__: that I don't know, I think git is a prerequisite, so it should be available, and you do simple git clone
Dec 17 15:29:43 <gedda__> ak77: Thank you, still pretty new to yocto
Dec 17 15:34:15 <kergoth> you could do that, yes, but you could also just use our existing git mirror tarball support isntead of rolling your own
Dec 17 15:41:42 <nacknick> Someone has any idea why wic does not work for me?
Dec 17 15:51:20 <nacknick> when using wic, I should write to sdb or sdb1 (for instace)
Dec 17 15:51:24 <nacknick> instance
Dec 17 15:51:25 <nacknick> ?
Dec 17 15:52:47 <kergoth> wic creates a partition table, so the main device would be correct
Dec 17 15:53:05 <kergoth> but you can just use wic to create the image and then write the image with dd if wic write isn't doing the job..
Dec 17 15:53:21 <nacknick> weird... only when I choose sdb1 it seems to "write"...
Dec 17 15:53:48 <nacknick> can you elaborate how to do that using dd?
Dec 17 15:53:51 <nacknick> and wic?
Dec 17 16:09:07 <nacknick> sudo dd of=/dev/sdb bs=1M  iflag=fullblock oflag=direct conv=fsync status=progress
Dec 17 16:09:14 <nacknick> should be sdb or sdb1?
Dec 17 16:09:34 <nacknick> becuase I have "dd: failed to open '/dev/sdb': Invalid argument"
Dec 17 16:12:32 <rburton_> does /dev/sdb exist?
Dec 17 16:14:06 <nacknick> yes
Dec 17 16:14:23 <nacknick> rburton, no as partition. as device
Dec 17 16:14:24 <nacknick> not
Dec 17 16:17:27 <gedda__> kergoth: I would love to, unfortunately the build server is off the grid due to security concerns
Dec 17 16:18:26 <kergoth> you can't run the build one time on a host with network connectivity to create the mirror tarball, then add that to the downloads dir on the build server or via an internal mirror?
Dec 17 16:21:36 <rburton_> nacknick: well dd not working isn't really a yocto problem, that's your system
Dec 17 16:21:54 <rburton_> you can happily write to /dev/sdb.  maybe you've got it mounted still?
Dec 17 16:22:35 <JPEW_> Alright, I need to make a decision on the name for the hash equivalent "hashes".... so far taskedgehash is my best option
Dec 17 16:23:08 <nacknick> I f ound a solution
Dec 17 16:23:32 <nacknick> I just removed sdb, sdb1 and sdb2 from /dev and use wic again and it works now
Dec 17 16:24:53 <gedda__> kergoth: I've tried to convince the management to do something like that, but since I work in the defence industry every minimally progressive decision takes _years_ to get approved
Dec 17 16:26:16 <nacknick> it still writes old binary of diffutils for some reason, but at least I can write an image again
Dec 17 16:26:37 <nacknick> now need to find a solution for diffutils problem... (fsdun, rburton...)
Dec 17 16:41:51 <kergoth> gedda__: ahh, fair enough. i remember working for a dod contractor at one point, we had ot submit a purchase order for $0 to install vim on the desktops
Dec 17 16:41:54 * kergoth rolls eyes
Dec 17 16:45:03 <nacknick> the binary that inside /image folder should be in the final image?
Dec 17 16:45:36 <rburton_> nacknick: no
Dec 17 16:45:50 <nacknick> so which one?
Dec 17 16:45:59 <rburton_> nacknick: the contents of the package is what goes into the image
Dec 17 16:46:16 <rburton_>  /image is one of several work directories
Dec 17 16:46:20 <nacknick> ok. so the binary that inside /package will be in the final image?
Dec 17 16:46:43 <RP> JPEW: lets get this sorted, yes. I don't like edge :/
Dec 17 16:47:11 <rburton_> nacknick: if you want to check the contents of the package, actually check the contents of the package
Dec 17 16:47:41 <rburton_> nacknick: why don't you share the recipe changes you've made so we can tell you where you got it wrong?  that helped a lot last time, two days of asking then you shared the recipe and we told you what paths were wrong.
Dec 17 16:49:12 <RP> JPEW: I think I have it, "uuhash"
Dec 17 16:50:06 <rburton_> to get the hash, do you uuencode?
Dec 17 16:50:30 <RP> rburton: gah ;-). more based on the idea of uuid
Dec 17 16:50:59 <rburton> i'd be wary of calling it uu<foo> unless it really is universally unique
Dec 17 16:51:20 <RP> rburton: the idea is its the "resolved" hash for this task, so there is a unique element to it
Dec 17 16:51:37 <nacknick> here's my modified diffutils' recipe: https://pastebin.com/2kCrqkja
Dec 17 16:51:40 <nacknick> rburton
Dec 17 16:52:25 <nacknick> it copies as expected, but when loading the image to the board, it has a previous version of what I did
Dec 17 16:52:44 <nacknick> I tried bitbake -f -c clean diffutils
Dec 17 16:52:48 <nacknick> did not help
Dec 17 16:52:57 <RP> JPEW: If you don't like uuhash, unihash since we're resolving it to one?
Dec 17 16:53:13 <rburton> unihash gets my vote fwiw
Dec 17 16:54:47 <RP> JPEW_: strongly leaning to unihash
Dec 17 16:57:46 <yocti> New news from stackoverflow: Where are bitbake python functions documented <https://stackoverflow.com/questions/24769944/where-are-bitbake-python-functions-documented>
Dec 17 16:58:58 <JPEW_> RP: Ya, I like that one... short for "unifiedhash"?
Dec 17 16:59:12 <JPEW_> Or "universally unique" rather
Dec 17 17:00:30 <JPEW_> Bah, I need to read the chat history more.... :)
Dec 17 17:01:06 <RP> JPEW_: yes, those :)
Dec 17 17:01:23 <RP> JPEW_: lets run with that?
Dec 17 17:01:30 <JPEW_> Ok, unihash it is. I'll try to get the patches sent today
Dec 17 17:02:59 <RP> JPEW_: thanks, been meaning to think more and sort the name so we can get this one over the finish line! :)
Dec 17 17:05:53 <nacknick> rburton when changing local.conf (just added a package) - I see it in the final image. but the last change I did to diffutils - not
Dec 17 17:06:18 <rburton> nacknick: you're sure diffutils is going in the image right
Dec 17 17:06:44 <rburton> ie you're not looking at /usr/bin/diff as a symlink to busybox
Dec 17 17:06:56 <nacknick> I changed diffutils' binary several times and now I have a previous version in the final image, although under /image folder the binary is different
Dec 17 17:07:25 <nacknick> rburton, yes, it's just a binary that prints something to the screen
Dec 17 17:07:40 <nacknick> under /image it prints something else than in the final image
Dec 17 17:08:37 <kergoth> hmm, wonder if anyone has messed with populating 'path' in vim to the available layers, either via bblayers.conf parsing or some basic heuristics if */conf/layer.conf exists
Dec 17 17:08:50 <kergoth> then 'gf' would work on relative paths in require/icnlude lines
Dec 17 17:09:12 <kergoth> could probably get it working on inherited classes too actually
Dec 17 17:11:34 <JPEW_> kergoth: This is my favorite vim binding (works anywhere too): https://github.com/JPEWdev/vim-config/blob/master/vimrc#L166
Dec 17 17:12:10 <kergoth> ah nice. i use a lot of fzf, but not searching the word under the cursor.. nice one
Dec 17 17:17:37 <RP> kergoth: I assume you agree moving bitbake to sha256 everywhere is probably best? I can't really see any alternative :/
Dec 17 17:19:53 <RP> kanavin: Should I merge the AUH patch?
Dec 17 17:20:35 <kergoth> that seems like the obvious path, yeah
Dec 17 17:21:46 <RP> kergoth: nice thing is it appears to "just work", we don't have assumptions about the algorithm thankfully
Dec 17 17:23:16 <RP> 1.3 million calls to getVarFlag parsing OE-Core, 840,000 of them from build_dependencies :/
Dec 17 17:26:49 * RP should mention https://bugzilla.yoctoproject.org/show_bug.cgi?id=13089 here
Dec 17 17:26:50 <yocti> Bug 13089: normal, Undecided, 2.7 M4, srifenbark, ACCEPTED , Document best practices from the Core Infrastructure project
Dec 17 17:27:13 <RP> if anyone is interested in helping with that talk to me...
Dec 17 17:52:09 <kergoth> oof
Dec 17 17:57:58 <yocti> New news from stackoverflow: How to upgrade git based recipe using devtool krogoth in yocto <https://stackoverflow.com/questions/53820418/how-to-upgrade-git-based-recipe-using-devtool-krogoth-in-yocto>
Dec 17 18:55:18 <aehs29> is it valid to specify a flag for a variable for a specific recipe from a conf file?, as in pn_PACKAGECONFIG[something] on local.conf for example
Dec 17 19:01:38 <Crofton> aehs29, after Christmas, I need to start builidng ultra96 images
Dec 17 19:04:25 <aehs29> Crofton: as far as I know the builds for ultra96 are working fine right now, if you wait for 2019.1 it will be thud compatible
Dec 17 19:08:27 <Crofton> without needing vivado on buil machine?
Dec 17 19:09:48 <khem> RP: JaMa updated couple of patch for glibc 2.29 as well. if you are retrying please use the latest patch on kraj/glibc-2.29
Dec 17 19:49:05 <aehs29> Crofton: oh there's the catch
Dec 17 19:49:49 <aehs29> bluelightning: paul you joined just after I asked the question, you might know this
Dec 17 19:50:09 <aehs29> bluelightning: is it valid to specify a flag for a variable for a specific recipe from a conf file?,  pn_PACKAGECONFIG[something] on local.conf for example
Dec 17 19:50:33 <bluelightning> aehs29: I don't think you can combine overrides and varflags no
Dec 17 19:50:43 <bluelightning> at least not that I'm aware of
Dec 17 19:50:52 <aehs29> bluelightning: ok yeah thats what I thought, just wanted to make sure haa
Dec 17 19:53:43 <aehs29> bluelightning: thanks!
Dec 17 21:27:43 <RP> khem: last build seemed ok from a glibc perspective. What do we want to do with the patch? Just hold for now?
Dec 17 21:38:43 <ant_home> khem, seems I borked my git branches...sorry
Dec 17 21:39:46 <JaMa> RP: it's fixing the build with DEBUG_BUILD is enabled
Dec 17 21:40:12 <JaMa> well the missing patch is fixing Os builds on aarch64
Dec 17 21:40:47 <JaMa> and the updated patch is just refreshed patch based on what was requested in upstream glibc
Dec 17 21:41:35 <JaMa> and khem bumped SRCREV a bit as well
Dec 17 21:42:39 <RP> JaMa: ah, I misread the message from khem, thanks for clarifying :)
Dec 17 21:43:02 <RP> khem, JaMa: question still stands - do we merge this now or wait for 2.29?
Dec 17 21:43:10 <JaMa> http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master&id=a192d99f946b2777d69300f03e2ba16014a90746
Dec 17 21:43:15 <RP> I know we were doing this in preparation
Dec 17 21:43:43 <JaMa> I'm fine with merging khem's version and then ^ as separate commit on top
Dec 17 21:44:01 <JaMa> I'll check what's included in khem's SRCREV bump
Dec 17 21:44:22 <JaMa> hopefully both my patches will be included in final 2.29
Dec 17 21:44:24 <RP> JaMa: I understood it to be pre 2.29 for testing just so we're ready
Dec 17 21:44:42 <RP> obviously good to find issues and sort now though! :)
Dec 17 21:45:40 <JaMa> just 3 commits in SRCREV bump
Dec 17 21:45:41 <JaMa> 551e81d9e3 Do not clobber r12 for ia64 syscalls.
Dec 17 21:45:41 <JaMa> df648905e7 Add test that MAP_* constants agree with kernel.
Dec 17 21:45:41 <JaMa> 6bbfc5c09f Add statx conditionals for wordsize-32 *xstat.c
Dec 17 21:46:29 <JaMa> ah, I see what you mean now, the question is whether to merge this at all now, not about v1 or v2 of the patch..
Dec 17 21:49:46 <RP> JaMa: right, do we wait for 2.29 to be released?
Dec 17 21:49:49 <ant_home> have you tested with gcc7 as well?
Dec 17 21:51:23 <JaMa> what, the removed gcc7? :)
Dec 17 21:51:46 <ant_home> I had to summon gcc6 not so long ago...
Dec 17 21:52:02 <ant_home> ..for nothing...
Dec 17 21:52:24 <JaMa> RP: I'll leave that to khem (after he finishes the world builds), but my builds were surprisingly successful, only the ltp was failing for me and khem already fixed that one
Dec 17 21:52:50 <RP> JaMa: I was surprised too :)
Dec 17 21:53:32 <ant_home> JaMa, it's jansa/master right?
Dec 17 21:53:46 <JaMa> khem: the Os issue is still reproducible with qemuarm64 http://errors.yoctoproject.org/Errors/Build/73674/ and the patch still works
Dec 17 21:54:25 <JaMa> ant_home: http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/glibc-2.29
Dec 17 21:54:35 <JaMa> ant_home: you get gcc-9 as a bonus :)
Dec 17 21:54:37 <ant_home> I can test now with mipsel
Dec 17 21:54:54 <ant_home> not-so-tested
Dec 17 23:21:18 <MDavis> Got a quick question that hopefully someone might be able to answer.  I am trying to add udisks2 from meta-oe.  For some reason my image size jumps 60MB when the package is only ~1MB
Dec 17 23:21:58 <MDavis> I checked the RDepends and the only one listed is acl which I already have, however for some reason a whole long list of python .pys in /usr/lib/python3.5 are getting added in too
Dec 17 23:22:10 <MDavis> I can't seem to figure out what the source of them is
Dec 17 23:24:24 <ant_home> bitbake -g is your friend
Dec 17 23:26:27 <ant_home> bitbake -g -u depexp <target>
Dec 17 23:28:01 <MDavis> I went through -g but that doesn't seem to separate out DEPENDS vs RDEPENDS
Dec 17 23:28:47 <MDavis> and -u depexp seems to be gone
Dec 17 23:30:20 <ant_home> pls check https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=2ahUKEwjHx6m_gajfAhVNJhoKHRCiDpYQygQwAnoECAkQAg&url=https%3A%2F%2Fwww.yoctoproject.org%2Fdocs%2F2.2.1%2Fref-manual%2Fref-manual.html%23usingpoky-viewing-dependencies-between-recipes-and-tasks&usg=AOvVaw0t1dUuUoeogbkiHbm52VxP
Dec 17 23:30:26 <ant_home> oops
Dec 17 23:30:57 <ant_home> Yocto manual 2.3.4
Dec 17 23:33:46 <ant_home> have you found out what needs python stuff?
Dec 17 23:34:48 <MDavis> no thats my problem I am trying to find out what needs the python stuff
Dec 17 23:35:00 <MDavis> the only listed RDEPEND is acl which I already have
Dec 17 23:35:54 <ant_home> inherit autotools systemd gtk-doc gobject-introspection
Dec 17 23:36:13 <ant_home> it's n heavy stuff to build
Dec 17 23:36:46 <MDavis> Nevermind I found it
Dec 17 23:37:00 <ant_home> I think you're not installing th esingle package
Dec 17 23:37:07 <MDavis> it is libblockdev that is bringing it in
Dec 17 23:37:18 <ant_home> ah
Dec 17 23:41:19 <ant_home> khem, with glibc-2.29 the gcc-cross-mipsel-8.2.0 still builds that darn kernel. No regressions here
Dec 17 23:43:43 <ant_home> great work, guys
**** ENDING LOGGING AT Tue Dec 18 03:00:00 2018