**** BEGIN LOGGING AT Mon Jun 20 02:59:59 2016
**** BEGIN LOGGING AT Tue Oct 25 19:29:13 2016
Oct 25 19:34:26 <Crofton|work> titankiller, you are going down a very very hard path
**** ENDING LOGGING AT Tue Oct 25 19:38:38 2016

**** BEGIN LOGGING AT Tue Oct 25 19:42:10 2016
Oct 25 19:50:00 <titankiller> err...
Oct 25 19:50:12 <titankiller> till death
Oct 25 19:50:16 <titankiller> :-)
Oct 25 20:09:50 <fishey1> titankiller: I tried something similar, trying to use an internal fork of daisy and adding new versions of packages to it. I gave up when gcc started ICEing. Too many interconnected things to backport.
Oct 25 20:11:16 <fishey1> my argument to the folks upstairs was that we would basically be trying to duplicate all the hard work the upstream yocto folks do, but we'd be doing it worse, with less knowledge, less experience, and less manpower. Perhaps a political solution would be easier :)
Oct 25 20:16:35 <tlwoerner> does krogoth need the python3 curses stuff for building on the cmdline?
Oct 25 20:29:25 <bluelightning> tlwoerner: no python3 requirement for krogoth - that's only for morty/master
Oct 25 20:39:45 <tlwoerner> bluelightning: awesome, thanks for the clarification :-)
Oct 25 20:43:33 <bluelightning> tlwoerner: np
Oct 25 20:50:06 <Crofton|work> fischerm, +1
Oct 25 20:50:50 <Crofton|work> I am very interested in why people get stuck on old releases, and how we can help unstuck people
Oct 25 20:51:10 <moto-timo> wiki article idea: how to convince your management to update your custom layer
Oct 25 20:51:16 <Crofton|work> lol
Oct 25 20:51:36 <moto-timo> it would sure be easier for those of us trying to answer questions :)
Oct 25 20:52:14 <Crofton|work> I ran into a case with daisy once, very very painful
Oct 25 20:52:32 <moto-timo> Remember the good old days when daisy was new? :)
Oct 25 20:52:36 <Crofton|work> yeah
Oct 25 20:52:47 <Crofton|work> I suspect evil vendor kernels
Oct 25 20:52:53 <moto-timo> die die die
Oct 25 20:53:11 <moto-timo> "you might want to upstream that"
Oct 25 21:01:14 <fischerm> Crofton|work: ?
Oct 25 21:02:20 <Crofton|work> fischerm, not you, you are stuck on jethro :)
Oct 25 21:04:55 <fischerm> what's the +1 for?
Oct 25 21:05:50 <fischerm> I has a confused
Oct 25 21:38:21 <tlwoerner> Crofton|work: i'm sure vendor kernels/bsps play a significant part
Oct 25 21:39:24 <tlwoerner> in my experience there are a lot of people who work with computers who don't trust them very much, who still think evil gremlins are responsible for most computer behaviour
Oct 25 21:39:35 <Crofton|work> lol
Oct 25 21:39:49 <tlwoerner> as such, once they acquire a certain confidence with a given system, they're loath to change anything
Oct 25 21:40:45 <tlwoerner> i'm sure many/most computer people have been in the situation where a manager wants them to add new features or port to a new device... by changing as little as possible (?)
Oct 25 21:41:02 <tlwoerner> "add this feature... but don't change anything"
Oct 25 21:41:04 <tlwoerner> :-)
Oct 25 21:42:23 <tlwoerner> it's the same mindset that used to say: "nobody ever got fired for buying IBM"
Oct 25 21:43:06 <tlwoerner> https://www.quora.com/What-does-the-phrase-Nobody-ever-got-fired-for-choosing-IBM-mean
Oct 25 21:43:33 <tlwoerner> if you search for that phrase, it redirects to wikipedia's article on FUD ;-)
Oct 25 21:43:40 <tlwoerner> https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
Oct 25 21:44:31 <tlwoerner> managers are actually taught that keeping up to date is risky, good luck breaking that pattern
Oct 25 21:45:05 <tlwoerner> "i know the bugs in my 50 year old software. what bugs are in yesterday's Linux kernel release? nobody knows"
Oct 25 21:56:23 <neverpanic> Crofton|work: For us it's a variant of "we can't guarantee that all our code will compile fine with GCC 5.2"
Oct 25 21:56:44 <neverpanic> So we're sticking with GCC 4.9 but writing C++14, which is, let's say, an less than ideal combination
Oct 25 21:57:06 <neverpanic> And as always, it's not the technical people that don't want to upgrade
Oct 25 22:33:13 <fishey1> Crofton|work: in my case, a company was using a fork of daisy provided by a vendor to use a hardware platform also provided by that vendor. The vendor had no interest in updating poky. In fact, from what I hear they would have liked to use an even older poky revision, and daisy was considered new.
Oct 25 22:34:54 <fishey1> This was Nov 2015 according to my logs.
Oct 25 22:36:45 <fishey1> So they really should have been using fido 1.8 or jethro 2.0 (fido was definitely out, jethro probably had been tagged). No idea why they decided to go back 2 revisions
Oct 25 22:37:01 * paulg wonders if he's missing some obvious way to avoid wic and plugins/source/bootimg-efi.py since he doesn't care about EFI and it is failing do_rootfs
Oct 25 22:37:25 <fishey1> And they stayed on the old poky revision primarily due to a complete lack of expertise on yocto development.
Oct 25 22:38:10 <fishey1> Sure, there is a custom kernel & u-boot, but those are fairly easy to keep around while updating to newer yocto revisions.
Oct 25 22:39:42 <bluelightning> paulg: check what IMAGE_FSTYPES is set to and remove images you aren't interested in?
Oct 25 22:39:49 <bluelightning> s/images/types/
Oct 25 22:42:16 <paulg> bluelightning, ya saw it had wic in there, but even after clearing that in my conf/local.conf it got over-rode somewhere else..
Oct 25 22:42:55 <paulg> something unconditionally wants me to move to EFI.  :)
Oct 25 22:44:36 <fishey1> paulg: `bitbake -e your-image-here | less` and searching for IMAGE_FSTYPES should show the source of the override.
Oct 25 22:45:20 <fishey1> IMAGE_FSTYPES_remove = "bad-image-type" should work in most cases, but you may want to look at why it's being added.
Oct 25 22:46:16 * paulg researches
Oct 25 22:46:43 <paulg> #   append /home/paul/poky/meta-yocto-bsp/conf/machine/include/genericx86-common.inc:23
Oct 25 22:46:43 <paulg> #     "wic"
Oct 25 22:47:12 <paulg> so if you build x86, you get wic.
Oct 25 22:47:27 <paulg> ...assuming I'm reading that correctly
Oct 25 22:47:46 * paulg tests _remove
Oct 25 22:49:41 <paulg> fishey1, bitbake -e makes it look like _remove will work ; testing do_rootfs currently -- thanks.
Oct 25 22:51:09 <fishey1> what is a wic image anyhow? Just a image containing the bootloader & partition table already? Does it stand for something?
Oct 25 22:51:16 * fishey1 is used to arm platforms
Oct 25 22:52:22 <paulg> fishey1, AFAICT, it is some glue between grub and creating the magic EFI images for x86.
Oct 25 22:53:06 <paulg> the .py doesn't have any comments, so that is just my semi educated (aka puddle of drool) guess.
Oct 25 22:53:07 <zeddii_home> its from kickstart origially
Oct 25 22:53:09 <zeddii_home> ‘https://bugzilla.yoctoproject.org/show_bug.cgi?id=3847
Oct 25 22:53:10 <yocti> Bug 3847: enhancement, High, 1.5.1, tom.zanussi, VERIFIED FIXED, New partitioning description and tooling
Oct 25 22:53:22 * paulg pats yocti on the head
Oct 25 22:53:45 <paulg> did it reach its kickstart funding goal?   ;-)
Oct 25 22:55:03 <bluelightning> wic = corruption of "OE Image Creator"
Oct 25 22:55:52 <bluelightning> basically an effort to create a standard mechanism for multi-partition image creation
Oct 25 22:56:55 <bluelightning> fishey1: there's nothing x86 specific about it btw - in fact as of recently we create images for beaglebone and edgerouter using it by default
Oct 25 22:59:41 <fishey1> "whole image create", maybe?
Oct 25 22:59:51 <fishey1> s/create/creator/
Oct 25 23:00:37 <paulg> bluelightning, fwiw, it started failing for me about a week or so ago... with this rather uninformative message...
Oct 25 23:00:47 <paulg> Error: Couldn't find HDDDIR, exiting
Oct 25 23:01:16 <paulg> WARNING: exit code 1 from a shell command.
Oct 25 23:01:16 <paulg> ERROR: Function failed: do_image_wic (log file is located at /home/paul/poky/build/tmp/work/genericx86_64-overc-linux/cube-essential/0.1-r0/temp/log.do_image_wic.6557)
Oct 25 23:01:26 <bluelightning> paulg: would you mind filing a bug for that?
Oct 25 23:01:44 <paulg> to be fair, I have NFI if I was generating EFI images prior to that, or if my config needs some new setting.
Oct 25 23:01:54 <paulg> ya, sure I can file a bug.
Oct 25 23:02:05 <bluelightning> I suspect you weren't, that default was probably only added recently
Oct 25 23:06:45 <paulg> bluelightning, could be -- I did git whatchanged on the scripts/lib/wic/plugins/source/bootimg-efi.py  and it has been around for a while
Oct 25 23:08:04 <paulg> 1fe840a4a0fbb (Ed Bartosh          2016-09-20 12:15:59 +0300 23) IMAGE_FSTYPES += "wic"
Oct 25 23:08:10 <paulg> that OTOH is pretty recent.
Oct 25 23:08:32 <paulg> from  -----   git blame meta-yocto-bsp/conf/machine/include/genericx86-common.inc
Oct 25 23:19:24 <paulg> cd ..
Oct 25 23:22:46 <armpit> what channel will that bring you to
Oct 25 23:23:35 <paulg> #oe   :)
Oct 25 23:24:09 <paulg> bluelightning, YOCTO 10501
Oct 25 23:24:41 <paulg> or, for yocti's benefit, bug 10501
Oct 25 23:24:42 <yocti> Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=10501 normal, Undecided, ---, richard.purdie, NEW , do_image_wic  fails with "Error: Couldn't find HDDDIR, exiting"
Oct 25 23:36:02 <moto-timo> halstead: ping
Oct 25 23:36:11 <halstead> Hi moto-timo!
Oct 25 23:36:16 <moto-timo> hi!
Oct 25 23:36:41 <moto-timo> autobuilder.yoctoproject.org is unresponsive. Maintainence or?
Oct 25 23:37:52 <halstead> moto-timo, Doing the last Dirty COW patches.
Oct 25 23:38:00 <halstead> moto-timo, It should be up though.
Oct 25 23:38:09 <moto-timo> halstead: ok. I can wait til tomorrow. Thanks.
Oct 25 23:38:19 <halstead> moto-timo, No need to wait.
Oct 25 23:38:44 <halstead> moto-timo, Is it refusing to accept new build orders?
Oct 25 23:39:09 <moto-timo> I'm just trying to connect to web interface and watching Firefox spin
Oct 25 23:39:16 <halstead> moto-timo, Ah. I see. Go to https://autobuilder.yoctoproject.org/main/builders/nightly directly for now.
Oct 25 23:39:26 <halstead> moto-timo, I'll get that fixed.
Oct 25 23:39:57 <moto-timo> specifically, I am trying to download from pub/ for the RC4 artifacts
Oct 25 23:40:33 <halstead> moto-timo, Ah. The NAS isn't quite back up yet.
Oct 25 23:40:38 <moto-timo> k
Oct 25 23:40:45 <moto-timo> bio break. thank you
Oct 25 23:40:47 <halstead> moto-timo, All those disks take a long time to come online.
Oct 25 23:41:06 <moto-timo> np. I was just worried, but you've got it handled
Oct 25 23:58:30 <moto-timo> halstead: it's back now. thanks.
Oct 25 23:58:45 <halstead> moto-timo, Thanks for the ping!
Oct 25 23:59:00 <moto-timo> halstead: ochoa's soon ?
Oct 25 23:59:25 <halstead> moto-timo, Yes please. Also there is supposed to be a Jefro lunch soon.
Oct 25 23:59:37 <moto-timo> halstead: Jefro sighting today :)
Oct 26 00:00:20 <halstead> moto-timo, Ping me tomorrow or Friday if you want to head to Ochoa.
Oct 26 00:00:38 <moto-timo> halstead: k. Probably Friday.
Oct 26 00:01:05 <halstead> moto-timo, I have a 1-1:30pm meeting any other time works.
Oct 26 01:57:35 <Crofton|work> fishey1, the headache is when gcc updates and old kernels will not build
Oct 26 01:57:47 <Crofton|work> We have to find a way to punish evil vendor kernel
Oct 26 02:36:21 <khem> yeah just fixed two gumstix kernels today to build with gcc6
**** ENDING LOGGING AT Wed Oct 26 02:59:58 2016