**** BEGIN LOGGING AT Thu Jan 10 03:00:02 2019
Jan 10 03:12:57 <robbawebba> derRichard: I'm currently creating a go package recipe and I think I feel your pain now. go.bbclass is quite tough to work with outside of the most simple use case..
Jan 10 03:51:24 <khem> robbawebba: if you spellout the problems we might be able to improve situation
Jan 10 07:32:09 <halstead> moto-timo, You make sense and I agree. I'll make the changes tomorrow.
Jan 10 08:37:02 <derRichard> khem: first of all it _always_ does a shared link, which sounds good but is in fact broken. here in x86_64 i get runtime errors
Jan 10 08:38:48 <derRichard> secondly, it tries to be smart and sets GOPATH and gueses what you want to build. the GO_IMPORT and GO_INSTALL variables are anything but easy to understand
Jan 10 08:39:06 <derRichard> third, absolute zero documentation, except trivial examples with no dependencies
Jan 10 08:39:25 <derRichard> dependency management is also not existent
Jan 10 08:39:43 <derRichard> you need to mess yourself with go get or go dep in do_compile_prepend() hooks
Jan 10 08:42:04 <derRichard> oh yes, and sdk support is also odd. if you install go in your sdk it works only if you set GOROOT yourself :(
Jan 10 08:42:50 <derRichard> given the complexity of go.bbcalls the amount of usefulness is low :(
Jan 10 08:42:54 <derRichard> </rant> :-)
Jan 10 08:43:06 <piotrlewicki> hi everyone
Jan 10 08:43:08 <LetoThe2nd> in a nutshell: don't go, just bash :)
Jan 10 08:43:20 <derRichard> LetoThe2nd: sorry, but this is bs....
Jan 10 08:44:32 <LetoThe2nd> derRichard: heh, the pun was intended to use bash instead of go. i'm all fine with the rant, just go ahead! (even another intended pun! yay!)
Jan 10 08:45:57 <derRichard> LetoThe2nd: in fact, we (my company) try very hard to avoid any bash scripts in systems we design. bash just sucks for everything with more than 50 lines of code :-)
Jan 10 08:46:09 <derRichard> but we are getting ot :)
Jan 10 08:46:28 <piotrlewicki> could you help me with removing the kernel image from the rootfs? I'm installing it separately and I want to make my rootfs image (ubifs) smaller. I have tried RDEPENDS_kernel-base = "" but it didn't do anything and I still have my "/boot" directory filled with uImage symlink and uImage_{version} file that is never used
Jan 10 08:46:38 <LetoThe2nd> derRichard: ot or not, i feel that you feel a little cheered up now? so if yes, mission accomplished!
Jan 10 08:47:08 <piotrlewicki> is there a good way of removing the whole "/boot" directory in rootfs?
Jan 10 08:47:35 <LetoThe2nd> piotrlewicki: thats just tinkering with the symptoms, better find out what actually causes it to be installed, because it isn't by default
Jan 10 08:48:44 <piotrlewicki> ok... that's new to me. so it gets built by default but not installed?
Jan 10 08:48:51 <LetoThe2nd> piotrlewicki: EEEEXACTLY :)
Jan 10 08:49:05 <piotrlewicki> ok. I'll check that.. Thanks for the tip :D
Jan 10 08:49:20 <LetoThe2nd> piotrlewicki: so, getting started would be to bitbake -e your image, and from there dig what actually pulls it in.
Jan 10 08:51:03 <LetoThe2nd> piotrlewicki: and, hint: the package that causes the kernel to be installed is surprisingly named: "kernel" :-)
Jan 10 08:51:09 <piotrlewicki> that's a lot of lines of python codexD
Jan 10 08:51:22 <LetoThe2nd> piotrlewicki: happy grepping!
Jan 10 08:52:07 <LetoThe2nd> piotrlewicki: otherwise, (syntax might by flaky now): bitbake -g your image and then look at package-depends.dot
Jan 10 08:52:16 <piotrlewicki> hehe. thx. and for me the name of the package is "kernel-image-uimage"
Jan 10 08:53:00 <piotrlewicki> ok. That should be enough for me to get going. your help is appreciated :-)
Jan 10 08:53:11 <LetoThe2nd> have fun!
Jan 10 09:22:16 * derRichard wonders why yocto does not enable set -fstack-clash-protection
Jan 10 09:31:10 <rburton> derRichard: patches welcome!  add it to security_flags.inc
Jan 10 09:31:58 <derRichard> rburton: well, this is the easy part. how to you test all this?
Jan 10 09:32:14 <derRichard> i really want avoid sending patches which break things
Jan 10 09:36:02 <rburton> bitbake world
Jan 10 09:36:33 <rburton> or send a patch that you've tested as much as possible, and ask nicely that we run it through the AB
Jan 10 09:37:06 <derRichard> yeah, bitbake world is not an option for me :D
Jan 10 09:37:32 <rburton> doesn't take *that* long
Jan 10 09:37:48 <rburton> (50% of the time in webkit)
Jan 10 09:38:11 <derRichard> the thing is, we're corrently working on 4 yocto migrations, our build servers are rather busy with this :D
Jan 10 09:38:22 <rburton> ha
Jan 10 09:38:35 <rburton> test it locally with an image, if that works post a RFC patch and ask nicely
Jan 10 09:38:47 <derRichard> this is why i run in so much odd stuff. -> moving from custom buildsystems to yocto
Jan 10 09:43:55 <yocti> New news from stackoverflow: Create a mirror of all dependencies of Yocto-based project <https://stackoverflow.com/questions/54125735/create-a-mirror-of-all-dependencies-of-yocto-based-project>
Jan 10 09:44:43 <derRichard> rburton: wait, you mean "bitbake world" on poky? no openembedded-core or meta-openembedded?
Jan 10 09:44:52 <derRichard> then the amount of targets is really not that much
Jan 10 09:45:04 <rburton> poky is oe-core+bitbake+some qa BSPs
Jan 10 09:45:07 <rburton> not meta-oe
Jan 10 09:48:24 <JaMa> without meta-qt5, meta-browser and meta-oe it's just 1/10 of the time of bitbake world :)
Jan 10 09:49:38 <derRichard> rburton: the amount of layers and their combinations will ever confuse me ;-P
Jan 10 09:51:10 <rburton> poky is just bitbake+oe-core+meta-poky, as 1) an example of creating a distro and 2) something designed for QA to test
Jan 10 09:51:39 <derRichard> this actually makes a lot of sense :-)
Jan 10 09:58:16 <JaMa> really? :)
Jan 10 09:58:42 <derRichard> yes
Jan 10 10:00:08 <LetoThe2nd> sense? go away! get behind me, satan!
Jan 10 11:46:03 <murray_> Has anyone build a Yocto build from MacOS. Getting an error relating to sed that i cant seem to resolve.
Jan 10 11:46:57 <murray_> $ MACHINE=var-som-mx6 DISTRO=fslc-x11 . setup-environment build_x11     this command returns sed: illgal option -- r
Jan 10 11:54:53 <jofr> murray_: That's.. not supported..  :)  https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#detailed-supported-distros
Jan 10 11:55:47 <murray_> Ok so i will have to build it from a linux machine
Jan 10 11:55:57 <murray_> This is a pain as it means i have to use a VM :(
Jan 10 11:56:29 <murray_> jofr: Messages above for you :)
Jan 10 11:57:43 <jofr> murray_: Yes  :)
Jan 10 11:58:29 <murray_> jofr: Thanks, I do have one building on a VM but its been over 12 hours so far... @ 82%
Jan 10 12:01:18 <jofr> murray_: Sounds like you need a new machine  :p  Depending on your host-specs, you could assign tons of RAM to your VM and then mount a ramdisk on your guest-system and do your builds there.
Jan 10 12:02:03 <murray_> jofr: This is not really an option as this is just a side project to what we are using the machines to develop.
Jan 10 12:02:57 <murray_> jofr: We have a team that are creating us a custom Yocto build but they seem to be taking ages with it. Was hoping to create a build myself with the packages that i require so i can do some initial hardware/framework testing
Jan 10 12:03:25 <murray_> jofr: Namley, NodeJs, Webserver, FTP and Maybe a package manager
Jan 10 12:04:40 <jofr> murray_: I see
Jan 10 13:11:56 <rburton> murray_: because yocto runs upstream configure/make scripts, and they're for linux, you need a linux-compatible userspace.  you can install the gnu tools using brew on macos to get close, then you need to patch out the linuxisms in bitbake itself (i.e. inotify use), but then you'll discover that pseudo can't work on macos as LD_PRELOAD isn't functional unless you disable all the security features.
Jan 10 13:12:22 <rburton> murray_: basically, use a lean vm.  builds are mostly cpu intensive so a good container won't be much slower.
Jan 10 13:12:56 <rburton> for a one off job, get an amazon cloud machine and do a build in that for a few cents
Jan 10 13:30:09 <tgoodwin> Is there a way to make a recipe re-unpack if its patch task changes (e.g., a variable used in a patch postfunc or patch append changes that would need a fresh copy of source code to run correctly)?
Jan 10 13:32:41 <RP> tgoodwin: its assumed that rerunning a task is always possible. The patch tasks therefore unapply any patches and reapply allowing them to be rerun
Jan 10 13:33:55 <tgoodwin> RP: So implicitly then, it unapplies only things that were patched, not additional tasks associated with the patch task?
Jan 10 13:34:12 <tgoodwin> (i.e., .patch files)
Jan 10 13:34:13 <RP> tgoodwin: correct
Jan 10 13:34:31 <RP> tgoodwin: the patch task would rerun if the patch files change
Jan 10 13:34:52 <RP> well, unpack would since the files it was fetching changed
Jan 10 13:35:42 <tgoodwin> RP: right.  What I'm dealing with are patches that are a bit more dynamic where the patch just preps the file for a generic replacement.
Jan 10 13:36:35 <RP> tgoodwin: I think that would break our assumption that tasks can rerun
Jan 10 13:37:43 <tgoodwin> And indeed it is breaking it.  I was hoping for some mechanism that if a variable in one of those patch tasks changes, then unpack must re-occur as if the patch changed.  It sounds like maybe appending the unpack is the way to go.
Jan 10 13:38:10 <rburton> or a new task between unpack and patch
Jan 10 13:38:45 <tgoodwin> rburton: I think that would fail for the same reason as running these tasks as a part of patch.  The tasks themselves cannot re-run without a fresh copy of source.
Jan 10 13:42:22 <BlauskaerM> How can I save changes that I have made with: bitbake -c menuconfig virtual/kernel ?
Jan 10 13:43:12 <tgoodwin> RP: so if I append unpack and update a variable used in that task, would that invalidate the task so that it reoccurs?
Jan 10 13:50:22 <RP> tgoodwin: yes
Jan 10 13:51:13 <tgoodwin> RP: do you happen to know if a function defined in postfuncs would trigger the same behavior (vs. actually appending the task)?
Jan 10 13:51:35 <rburton> iirc a postfunc that needs to be re-ran will fire the entire task
Jan 10 13:51:48 <tgoodwin> (Thanks for the help BTW.  I think I had some failed assumptions here on using vardeps, etc.)
Jan 10 13:53:17 <tgoodwin> BlauskaerM: I usually go into the recipe work area and pull the `.config` out as a defconfig that I add via SRC_URI.  Or if you know what flags you changed, you can append the kernel's SRC_URI to add in the `file.cfg` with those changes.
Jan 10 13:54:27 <tgoodwin> rburton: thanks, that's what I've been assuming.  I haven't mocked up a test to prove it though.
Jan 10 13:57:09 <tgoodwin> rburton: in a similar train of thought, I was considering adding the variables from my patch task that are "patching the patches" to the do_unpack[vardeps] in an effort to "trick" an unpack to reoccur.
Jan 10 13:57:44 <tgoodwin> Pretty hackish, but that's what I get for having to bake arch strings into sourcecode. :-/
Jan 10 13:57:46 <yates_home> after "smart install kernel-dev", rpm -ql kernel-dev only shows a few files being installed in /boot, none of which are headers.
Jan 10 13:58:00 <yates_home> any idea on where to start looking ?
Jan 10 13:58:54 <yates_home> how are the kernel-dev file package files specified?
Jan 10 13:59:07 <yates_home> correction: how are the kernel-dev package files specified?
Jan 10 14:09:27 <tgoodwin> rburton: and RP: FWIW that (probably rubbish) idea of adding the related variable to unpack's vardeps did cause it to unpack fresh source for my patch tasks.
Jan 10 14:19:35 <yates_home> perhaps i'm not making sense. let me back up. i am trying to write a on the target LKM. the first step is to get the kernel headers installed on the target.
Jan 10 14:20:04 <yates_home> however, normally these are installed via "smart install kernel-dev" (right?)
Jan 10 14:20:41 <yates_home> s/i am trying to write a on the target LKM/i am trying to write a LKM on the target/
Jan 10 14:20:46 <yates_home> (sheesh..)
Jan 10 14:21:15 <yates_home> but that package has no kernel include files etc.
Jan 10 14:21:23 <yates_home> help?
Jan 10 14:22:36 <yates_home> please?
Jan 10 14:23:16 <derRichard> to build kernel modules you need more than header files. you need more or less the full kernel source
Jan 10 14:23:40 <derRichard> i don't know if yocto even allows this use case. better build the module cross using yocto
Jan 10 14:27:03 <yates_home> derRichard: perhaps you are right
Jan 10 14:27:17 <yates_home> i'll do some further digging.
Jan 10 14:37:40 <yates_home> rburton: do you have any thoughts on kernel-dev? shouldn't that just work, like on a regular distro (ubuntu, etc.)?
Jan 10 14:39:02 <derRichard> yates_home: also on a regular distro you need more than "-dev"
Jan 10 14:39:11 <derRichard> the kernel is not like a library
Jan 10 14:39:24 <derRichard> and kernel modules are not users of a lib, they are part of the kernel
Jan 10 14:41:23 <yates_home> what other things would one need on a desktop distro?
Jan 10 14:41:36 <derRichard> kernel-source
Jan 10 14:42:00 <derRichard> suse has -syms, -macros, ...
Jan 10 14:46:02 <yates_home> fedora's kernel-devel states it's all you need to build kernel modules: kernel-devel.x86_64 : Development package for building kernel modules to match the kernel
Jan 10 14:46:11 <yates_home> maybe it's different from suse?
Jan 10 14:47:52 <derRichard> maybe
Jan 10 14:48:51 <yates_home> when do kernel modules get loaded? is it before init or after?
Jan 10 14:49:11 <yates_home> (probably OT)
Jan 10 14:49:31 <yates_home> should we go to pm, derRichard?
Jan 10 14:50:33 <RP> yates_home: you have seen the kernel-devsrc recipe?
Jan 10 14:50:43 <yates_home> RP: no!
Jan 10 14:51:32 <yates_home> oh yeah baby!
Jan 10 15:01:09 <RP> yates_home: there are even tests that test it works!
Jan 10 15:08:36 * kergoth yawns
Jan 10 15:16:58 <derRichard> RP: nice to see kernel-devsrc :)
Jan 10 15:17:30 <BlauskaerM> tgoodwin: .cfg approach seems a little bit advance for me so copied /proc/config.gz and replaced my deconfig file
Jan 10 15:17:34 <BlauskaerM> Hope it works
Jan 10 15:17:44 <BlauskaerM> Thanks for your reply
Jan 10 15:35:08 <derRichard> hm, having realitve paths in bblayers.conf is tricky
Jan 10 15:35:14 <kergoth> yeah, don't do it
Jan 10 15:35:30 <kergoth> determine the path relative to TOPDIR and use that
Jan 10 15:36:24 <derRichard> like here? https://stackoverflow.com/questions/38890788/why-does-the-yocto-bblayers-conf-file-use-absolute-paths
Jan 10 15:37:29 <kergoth> pretty much, yes. or use custom setup scripts to add and use a variable for the yocto root, if it isn't always ${TOPDIR}/..
Jan 10 15:37:52 <kergoth> mentor embedded linux uses custom setup scripts that do that, to point to the mel installation directory
Jan 10 15:38:32 <kergoth> the issue with relative paths is you never know precisely what context any given variable is evaluated and used in
Jan 10 15:38:40 <kergoth> and $PWD changes at points during the build process
Jan 10 15:38:57 <kergoth> for the initial layer setup it may work, but in general it's not a great idea to use relative paths in variables
Jan 10 15:41:42 <derRichard> kergoth: so, i can use something like ${LAYERDIR} in bblayers.conf if i set LAYERDIR in bitbake using my local.conf?
Jan 10 15:42:27 <kergoth> that woudln't make any sense in about 4 different ways
Jan 10 15:42:37 <kergoth> layerdir is already set by bitbake and used in layer.conf for each individual layer, for one
Jan 10 15:42:47 <kergoth> beyond that, local.conf is parsed long, long, long after bblayers.conf is parsed
Jan 10 15:42:59 <kergoth> local.conf can't be parsed until we can use bblayers to find the layers to locate and parse bitbake.conf
Jan 10 15:43:10 <kergoth> okay, two different ways :)
Jan 10 15:43:47 <derRichard> ok :D
Jan 10 15:44:15 <kergoth> bbalyers.conf can only use what's defined in bblayers.conf
Jan 10 15:44:19 <kergoth> it's the first file parsed
Jan 10 15:45:01 * derRichard takes a note
Jan 10 16:37:04 <jonmason> RP: I see the email now and will bottom out on if KVM is supported native and will respond before the end of the day
Jan 10 16:40:57 <RP> jonmason: thanks
Jan 10 17:17:15 <kanavin> rburton: patch is on the way :)
Jan 10 17:18:54 <rburton> kanavin: :)
Jan 10 17:22:17 <Crofton> We should pay attention to this: http://it.tmcnet.com/topics/it/articles/2019/01/10/440873-simplifying-harmonizing-open-source-more-efficient-compliance.htm
Jan 10 17:28:49 <zeddii> ooo. shiny and new:
Jan 10 17:28:52 <zeddii> root@qemux86-64:~# uname -a
Jan 10 17:28:52 <zeddii> Linux qemux86-64 5.0.0-rc1-yoctodev-standard #1 SMP PREEMPT Thu Jan 10 16:01:22 UTC 2019 x86_64 GNU/Linux
Jan 10 17:29:01 <zeddii> SHIP IT
Jan 10 17:29:17 <Crofton> zeddii, ++
Jan 10 17:29:55 * zeddii pushes it to linux-yocto-dev to see what'll explode. booted once. must be golden.
Jan 10 19:04:16 <JPEW> WTF! Bitbake it dying from SIGBUS???
Jan 10 19:04:45 <derRichard> JPEW: do you have a core file or a line in dmesg?
Jan 10 19:09:03 <JPEW> derRichard: No... it's dying inside a docker container. I'm pretty sure it's my own fault (somewhere).... SIGBUS is just the last thing I would have expected
Jan 10 19:31:31 <derRichard> JPEW: well, inside docker...
Jan 10 19:31:44 <derRichard> maybe a mem cgroup kicked in
Jan 10 19:31:55 <derRichard> or you reached the max number of allowed mappings
Jan 10 19:35:40 <JPEW> derRichard: I didn't setup any memory restrictions, so I don't think it's that.... trying with a larger vm.max_map_count
Jan 10 19:36:19 <derRichard> JPEW: did you check dmesg? no oom message?
Jan 10 19:36:36 <JPEW> No, OOM
Jan 10 19:37:10 <JPEW> nothing suspicious in dmesg
Jan 10 19:37:48 <derRichard> hmmm
Jan 10 19:38:04 <derRichard> i still think bitbake ran into a odd restriction and had no clue how to handle it :D
Jan 10 19:38:29 <JPEW> derRichard: That seems likely
Jan 10 19:38:44 <derRichard> a few days ago i saw qt configure failing in odd ways because docker guys thought it is a good idea to block the rather new statx() syscall :D
Jan 10 19:54:23 <JPEW> derRichard: Ok, it appears to be the fault of some code I wrote, not some endemic system problem. Thanks for the help!
Jan 10 19:57:36 <derRichard> JPEW: :-)
Jan 10 20:06:51 <rburton> huh
Jan 10 20:06:54 <rburton> | x86_64-poky-linux-ld.bfd: arch/x86/kernel/head_64.o: unable to initialize decompress status for section .debug_line
Jan 10 20:06:57 <rburton> anyone seen that before?
Jan 10 20:07:47 <rburton> zeddii: ^
Jan 10 20:08:20 <derRichard> one moment, i saw this
Jan 10 20:10:08 <derRichard> rburton: okay, not x86_64. this was on arc
Jan 10 20:16:32 <kroon> rburton, what does "mut" (as in the git branch) stand for ?
Jan 10 20:19:13 <bluelightning> kroon: master under test
Jan 10 20:25:17 <kroon> bluelightning, ah!
Jan 10 20:33:27 <rburton> derRichard: still might be useful. any idea how to solve?
Jan 10 20:34:55 <derRichard> rburton: in the arc case it was a bug in their gcc port
Jan 10 20:35:10 <derRichard> what kernel and gcc version are you using?
Jan 10 20:37:32 <rburton> 4.19.0
Jan 10 20:37:36 <rburton> and whatever gcc is in thud
Jan 10 20:38:14 <derRichard> 8.2
Jan 10 20:38:17 <rburton> hm i wonder if its a elfutils bug, lets revert that
Jan 10 20:38:33 <derRichard> yes, i was about to ask that
Jan 10 20:38:40 <derRichard> maybe another objtool issue ;-\
Jan 10 20:38:42 <rburton> https://bugs.archlinux.org/task/61151
Jan 10 20:38:54 <rburton> khem: hitting https://bugs.archlinux.org/task/61151 in thud, can we pick the fix for binutils
Jan 10 21:30:31 <robbawebba> is it possible to disable bitbake from building *-dev and *-staticdev packages for a specific recipe?
Jan 10 21:43:12 <armpit> aehs29, I am trying your multiconf patches to see if they fix my problem
Jan 10 21:45:27 <kroon> robbawebba, for *-staticdev, checkout no-static-libs.inc *I think*
Jan 10 21:46:08 <kroon> robbawebba, oh, didnt read the part "for a specific recipe"
Jan 10 21:47:20 <kroon> robbawebba, but yeah figure out how to pass extra configure flags so that no static libs are created and append that to your build configuration
Jan 10 21:47:26 <bluelightning> robbawebba: are the packages empty or do they contain files?
Jan 10 21:48:00 <bluelightning> if they contain files you'll need to delete those or otherwise prevent them from being installed at do_install time
Jan 10 21:49:06 <bluelightning> then, you'd need to set ALLOW_EMPTY_${PN}-dev = "0"  and ALLOW_EMPTY_${PN}-staticdev = "0"
Jan 10 21:49:58 <bluelightning> (you could exclude them from PACKAGES instead but that can be tricky depending on what else is going on)
Jan 10 22:02:41 <kergoth> not sur ewhat efect removing them from pakcages would have on the depchains logic, if any
Jan 10 22:02:44 <kergoth> hmm
Jan 10 22:20:04 <aehs29> armpit: they probably will fix the issue in your case, but I had a talk with RP and some changes are still gonna be necessary, so I'll still send a v2 at some point
Jan 10 22:20:32 <armpit> k.
Jan 10 22:37:26 <derRichard> wtf
Jan 10 22:37:27 <derRichard>   file /usr conflicts between attempted installs of pango-1.42.4-r0.core2_64 and libcairo2-1.14.12-r0.core2_64
Jan 10 22:43:25 <robbawebba> bluelightning: they contain files. This is for a custom recipe that inherits from go.bbclass. The -dev and -staticdev packages contain the source code, but I would like to not create these packages if possible. This recipe fetches from a monorepo and has a ton of stuff inside it, such as static library files, documentation, makefiles, etc...
Jan 10 22:44:07 <robbawebba> bluelightning: okay, I'll try to delete the files during do_install_append. Thanks for the tip!
Jan 10 22:55:25 <armpit> aehs29, that fixes my problem
Jan 10 22:55:27 <armpit> thanks
Jan 10 22:55:46 <aehs29> armpit: great
Jan 10 23:13:27 <moto-timo> halstead: should we point to eclipse-full for the SDK files that will be kept or should we use the partial mirror URL?
Jan 10 23:15:34 <halstead> moto-timo, Use the partial mirror since it will stay around for sure. The full mirror will just be for the community.
Jan 10 23:15:59 <halstead> moto-timo, Lets get those files copying automatically.
Jan 10 23:26:18 <moto-timo> halstead: thank you, just wanted to double check. Agreed on automation.
Jan 10 23:44:11 <halstead> moto-timo, Can you confirm that http://downloads.yoctoproject.org/eclipse/downloads/drops4/R-4.9-201809060745/ is all we need?
Jan 10 23:45:02 <halstead> moto-timo, I can mirror the whole drop if that is better. Just mirring *linux-gtk-x86_64.tar.gz right now.
Jan 10 23:54:57 <moto-timo> halstead: trying to figure out their new versioning scheme (2018-09, 2018-12 and so on versions)
Jan 10 23:55:25 <moto-timo> halstead: 4.7.3, 4.7.3.a, 4.8.* should all be backed up
Jan 10 23:56:49 <moto-timo> halstead: https://download.eclipse.org/eclipse/downloads/drops4/R-4.8-201806110500/
Jan 10 23:57:07 <moto-timo> halstead: https://download.eclipse.org/eclipse/downloads/drops4/R-4.9-201809060745/
Jan 10 23:57:24 <moto-timo> halstead: https://download.eclipse.org/eclipse/downloads/drops4/R-4.10-201812060815/
Jan 10 23:57:43 <ebolton> hey all, trying to install an ESDK generated from krogoth based env....I've tried ESDKs generated from several images (including core-image-minimal), and on the last install step I get a ton of these errors:
Jan 10 23:57:51 <ebolton> ERROR: Unexpected tasks or setscene left over to be executed:
Jan 10 23:57:51 <ebolton>    task 1114 of 2442 (ID: 1178, /home/ebolton/poky_sdk/layers/poky/meta/recipes-extended/parted/parted_3.2.bb, do_fetch)
Jan 10 23:59:14 <rburton> ebolton: if you can, consider using normal SDKs instead
Jan 10 23:59:48 <rburton> the traditional ones are more reliable, especially in an older release like krogoth
Jan 11 00:00:09 <ebolton> rburton: lol, they work fine....but the whole point of what I'm working on is trying out ESDK, I guess they first showed up in krogoth so maybe not so much?
Jan 11 00:00:10 <halstead> moto-timo, I meant when you open the link and look at the index. Are files there the only ones needed to save for YP in a drop?
Jan 11 00:00:35 <rburton> ebolton: pretty much.  the flexibility is nice but they're a bit more fragile, especially in krogoth
Jan 11 00:01:24 <ebolton> rburton: will do
Jan 11 00:17:41 <rburton> RP: fyi, mut was mostly green on the ab
Jan 11 00:32:15 * armpit ab's of steel
Jan 11 01:02:49 <moto-timo> halstead: oh duh. yes.
**** ENDING LOGGING AT Fri Jan 11 02:59:57 2019