**** BEGIN LOGGING AT Mon Jan 28 02:59:57 2019
Jan 28 05:52:26 <khem> RP: my local builds with tunes change look good for cortex-a5 machine
Jan 28 09:21:59 <yacar_> hi Tom_builder, you shall refer to 3.1. Setting Up to Use the Extensible SDK of https://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html
Jan 28 10:11:12 <Guest40284> Hi, in my team we are considering upgrading from 2.4 to 2.6.
Jan 28 10:12:36 <Guest40284> While looking for some docs etc, I've found that 2.6 is not in download page, no release note on we site . Is 2.6 a "regular" stable release?
Jan 28 10:13:41 <LetoThe2nd> Guest40284: it certainly is, but it its strongly encouraged to use git
Jan 28 10:16:22 <Guest40284> Yep we use git, it's just that while looking for some migration doc etc, there are several places where 2.5.2 and 2.4.4 are mentionned but 2.6.x is not so I was wondering.
Jan 28 10:18:13 <LetoThe2nd> Guest40284: https://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release
Jan 28 10:18:13 <Guest40284> Is there some info about test report generation using 2.6? We used to do xml output but it went away in 2.6, what are the other possibilities, especially to plug result in CI?
Jan 28 10:19:30 <Guest40284> yep I got this doc , but thanks
Jan 28 10:19:51 <LetoThe2nd> well you asked for the migration doc, and thats it :)
Jan 28 10:20:21 <Guest40284> OK I was not clear, sorry
Jan 28 11:30:44 <RP> rburton: some worrying data: wget https://autobuilder.yocto.io/pub/non-release/20190127-9/testresults/qemux86-64-ptest/testresults.json
Jan 28 11:30:47 <RP> rburton: then cat testresults.json  | sed 's/\\n/\n/g'  > testresults1.json
Jan 28 11:30:57 <RP> rburton: then grep for TIMEOUT:
Jan 28 11:37:19 <yocti> New news from stackoverflow: How to integrate Yocto Project and GCOV to find out coverage report? <https://stackoverflow.com/questions/54401095/how-to-integrate-yocto-project-and-gcov-to-find-out-coverage-report>
Jan 28 12:02:45 <derRichard> can yocto create me a src.rpm?
Jan 28 12:04:17 <derRichard> i fear the answer is "no", but maybe i miss something
Jan 28 12:11:52 <derRichard> hmm, the source archiver sounds good
Jan 28 12:12:08 <Crofton> yeah
Jan 28 12:12:18 <Crofton> We do the same sort of thing differently
Jan 28 12:12:53 <rburton> derRichard: it can but only if you dont' expect to be able to rebuild it
Jan 28 12:13:55 <derRichard> rburton: hmmm. it is more or less (ab)used as tar ball? ;)
Jan 28 12:14:10 <rburton> yes
Jan 28 12:14:27 <rburton> if you do want srcrpm that you can rpmbuild then http://git.yoctoproject.org/cgit/cgit.cgi/meta-translator/ exists but dear god i'm lucky i survived writing that. don't use it.  that's an argument for why you shouldn't do that.
Jan 28 12:16:03 <derRichard> rburton: ok :-)
Jan 28 12:27:45 * kanavin couldn't resist looking
Jan 28 12:27:48 <kanavin> " Whereas in normal usage package_rpm is
Jan 28 12:27:48 <kanavin> used to generate a minimal .spec that can build a binary package,
Jan 28 12:27:48 <kanavin> meta-translator generates a more complex .spec that includes the build
Jan 28 12:27:48 <kanavin> instructions from the .bb input so that the generated SRPM can be rebuild in
Jan 28 12:27:48 <kanavin> another build system (for example, OBS).
Jan 28 12:27:49 <kanavin> "
Jan 28 12:28:19 <kanavin> that does sound like it's barely feasible
Jan 28 12:28:44 <rburton> correct!
Jan 28 12:28:49 <derRichard> in my case t'll go for tar ball :)
Jan 28 12:54:28 <RP> Having two mechanisms to do the same thing means by definition one is broken
Jan 28 13:00:12 <derRichard> RP: computers are very, very broken :-)
Jan 28 13:00:43 <LetoThe2nd> RP: disagreed.
Jan 28 13:00:57 <LetoThe2nd> RP: it means by definition AT LEAST one is broken
Jan 28 13:11:03 <derRichard> hmm, isn't there some fetchall command in bitbake to download all needed sources?
Jan 28 13:11:54 <derRichard> ah, not for images ;-\
Jan 28 13:13:51 <derRichard> --runall=fetch it is^^
Jan 28 13:21:29 <RP> LetoThe2nd: true :)
Jan 28 13:22:02 <RP> derRichard: that is the best way
Jan 28 13:23:40 <derRichard> RP: just noticed that yocto still started to build stuff. i tried: bitbake --runall=fetch myimage
Jan 28 13:23:49 <derRichard> i want to download all sources but not more
Jan 28 13:27:13 <RP> derRichard: its probably building something like svn-native ?
Jan 28 13:28:17 <RP> derRichard: if that is a problem, tweak ASSUME_PROVIDED?
Jan 28 13:28:21 <RP> and HOSTTOOLS
Jan 28 13:30:10 <derRichard> RP: it started to build python-native plus a ton dependencies. i guess to run the git fetch python tooling?
Jan 28 13:30:44 <RP> derRichard: git is in ASSUME_PROVIDED so I still suspect svn
Jan 28 13:32:24 * derRichard runs again and finds
Jan 28 13:32:36 <derRichard> at least none of *my* recipes has a svn src-uri :)
Jan 28 13:34:14 <RP> derRichard: it could be another fetcher dependency, I'm just guessing
Jan 28 13:35:21 <derRichard> i will find out
Jan 28 13:35:34 <derRichard> if it builds only fetcher stuff, this is no big deal
Jan 28 13:35:48 <RP> derRichard: use bitbake -g <other options> and have a look at task-depends.dot
Jan 28 13:36:12 <derRichard> i don't have a 1000 inc screen ;)
Jan 28 13:36:15 <derRichard> *inch
Jan 28 13:39:22 <kanavin> derRichard: the .dot file is entirely textual and easy to make sense of, there's a misconception that you need to convert it to some enormous svg, but you don't.
Jan 28 13:45:29 <derRichard> kristoiv: true, the dot file is really something one can get a sane info out
Jan 28 13:45:34 <derRichard> RP: bingo, svn it is
Jan 28 13:45:35 <derRichard> "tremor.do_fetch" -> "subversion-native.do_populate_sysroot"
Jan 28 13:51:33 <RP> derRichard: I'd quite like to find a different url for tremor so we don't have any svn urls
Jan 28 13:52:05 <RP> derRichard: ah, you're on an older release. We did get rid of that :)
Jan 28 13:53:22 <derRichard> RP: this project is sumo, yes
Jan 28 13:53:38 * derRichard is currently working on many yocto projects
Jan 28 13:56:07 <derRichard> upgrade from rocko, a nightmare (not because of yocto, other horrors...)
Jan 28 14:11:52 <RP> rburton: replied about the problems in the systemd patches, dropped from -next, retrying a new patchset. Have worked with Khem to find what I think is a good fix for the arm tune issues
Jan 28 14:24:07 <kanavin> RP: I am working on python-sanity btw :) just writing a test that would catch the notorious quiet module build regressions
Jan 28 14:26:27 <kanavin> ERROR: Logfile of failure stored in: /home/alexander/development/poky/build-python-sanity/tmp/work/x86_64-linux/python3-native/3.7.2-r0/temp/log.do_install.129812
Jan 28 14:26:27 <kanavin> Log data follows:
Jan 28 14:26:27 <kanavin> | DEBUG: Executing shell function do_install
Jan 28 14:26:27 <kanavin> | The necessary bits to build these optional modules were not found:
Jan 28 14:26:27 <kanavin> | _bz2                  _curses               _curses_panel
Jan 28 14:26:29 <kanavin> | _dbm                  _gdbm                 _hashlib
Jan 28 14:26:31 <kanavin> | _sqlite3              _ssl                  _tkinter
Jan 28 14:26:35 <kanavin> | _uuid                 readline
Jan 28 14:26:37 <kanavin> |
Jan 28 14:26:39 <kanavin> \0/
Jan 28 14:28:03 <RP> kanavin: nice :)
Jan 28 14:28:41 <RP> kanavin: I'm just depressed at the ptest output :(
Jan 28 14:30:43 <kanavin> RP: that's hardly surprising though, as no one made a focused effort to make that better
Jan 28 14:31:22 <kanavin> plus, we don't really enable it, so it doesn't get visibility in downstream
Jan 28 14:33:05 <RP> kanavin: yes and no. The autobuilder does give us results and QA does compare them. They're just more broken than I'd like
Jan 28 14:43:21 <nacknick> after I use populate_sdk - how should I use it? I want to compile a program for the board
Jan 28 14:44:45 <nacknick> I tried to run /opt/fslc-framebuffer/2.4.4/sysroots/armv7ahf-neon-linux-gnueabi/usr/bin/arm-linux-gnueabi-gcc - but it says "/lib/ld-linux-armhf.so.3: No such file or directory"
Jan 28 14:46:28 <LetoThe2nd> nacknick: you have to source the environment file that comes with the sdk. after that, in that very shell all necessary things should be set
Jan 28 14:47:08 <nacknick> do you mean to configure "sysroot" path?
Jan 28 14:56:02 <khem> RP: a new QA error i am seeing is 06:32:43 ERROR: python-twisted-18.4.0-r0 do_package: QA Issue: python-twisted-src is listed in PACKAGES multiple times, this leads to packaging errors. [packages-list]
Jan 28 14:56:27 <JPEW> khem: Is that with master-next?
Jan 28 14:58:08 <JPEW> khem: If so, its probably because of 8fd8ae119c0 ("Change default debug split to make separate source packages")
Jan 28 14:58:23 <khem> yes
Jan 28 15:02:10 <JPEW> khem: Looks like that recipe is it is making it's own -src package (not particularly sure of the reason)...
Jan 28 15:02:23 <nacknick> LetoThe2nd: How should I use gcc? I could not figure it out
Jan 28 15:03:49 <LetoThe2nd> nacknick: ". environment.sh" in the shell you want to use for building
Jan 28 15:04:40 <LetoThe2nd> after that, your build system should be able use the newly set environment.
Jan 28 15:09:00 * derRichard wonders why poky sets in rpms as build host "reproducible", but sets the build date to the current date. :-D
Jan 28 15:10:01 <khem> JPEW: yah it needs some TLC
Jan 28 15:13:50 <nacknick> LetoThe2nd: do you mean "./setup-environment" which I ran before using bitbake? because I've already ran it
Jan 28 15:14:43 <LetoThe2nd> nacknick: thats the point. do not run it, source it.
Jan 28 15:15:16 <nacknick> "source it"? I'm not sure what does it mean
Jan 28 15:19:29 <LetoThe2nd> ". setup-environment"
Jan 28 15:19:41 <LetoThe2nd> nacknick: and if in doubt, google "bash source"
Jan 28 15:23:45 <RP> khem: that patch is likely to merge soon, that issue is in the recipe
Jan 28 15:27:59 <nacknick> LetoThe2nd: "source setup-environment build" for instance?
Jan 28 15:28:40 <LetoThe2nd> nacknick: now, why "build"?!?
Jan 28 15:28:47 <nacknick> instead of "build" I need to choose another directory?
Jan 28 15:28:53 <nacknick> I don't know which one :S
Jan 28 15:29:20 <nacknick> -- /opt/fslc-framebuffer/2.4.4/sysroots/armv7ahf-neon-linux-gnueabi/ ??
Jan 28 15:31:03 <LetoThe2nd> nacknick: i totally and strongly suggest to have a look at the corresponding documentation: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#sdk-using-the-standard-sdk
Jan 28 15:40:07 <RP> alimon: around?
Jan 28 15:40:20 <yates> when you do a "devtool mdoify -x <package> src/blah", are the existing patches for package applied?
Jan 28 15:46:36 <kergoth> the tree is constructed based on SRC_URI by running unpack & patch
Jan 28 15:47:46 <yates> so yes..
Jan 28 15:54:13 <rburton> nacknick: the sdk doesn't have 'build directories'
Jan 28 15:55:13 <malanecora> Hi dudes! I have a crda/wireless-regdb bbappend with some python scripts to create keys...but the build is failing due to "ImportError: No module named builtins"
Jan 28 15:55:44 <malanecora> If I install the package python-builtins, the error that arises is "ImportError: No module named attr"
Jan 28 15:55:54 <malanecora> python-future*
Jan 28 15:58:52 <rburton> is your append broken?
Jan 28 15:58:58 <rburton> there is no standard python module called attr
Jan 28 15:59:18 <rburton> maybe you need to depend on https://github.com/python-attrs/attrs
Jan 28 15:59:50 <malanecora> rburton: I supose
Jan 28 16:00:06 <malanecora> rburton: It worked fine until I upgradesd from Rocko to Thud
Jan 28 16:00:31 <rburton> well, if the code uses python-attrs then you'll need to have that in dependencies
Jan 28 16:01:23 <malanecora> rburton: Yep, gonna try that. Ty!
Jan 28 16:03:39 <malanecora> rburton: No luck at all
Jan 28 16:03:42 <kergoth> it wasn't called 'attr' in rocko either
Jan 28 16:03:57 <malanecora> kergoth: sure it was not
Jan 28 16:04:23 <malanecora> kergoth: The installation of python-future might be modifiying the script
Jan 28 16:05:04 <malanecora> kergoth: I just installed python-future in order to fix the builtins module import error
Jan 28 16:05:28 <malanecora> kergoth: Though it seems to fix nothing :P
Jan 28 16:06:20 <kergoth> that's not a correct fix indeed. future should be used by the authors of the project where appropriate not a user trying to get it to run. builtins is aprt of python itself, not the future package unless they're dealing with python version incompatibilities and actually use futures directly
Jan 28 16:06:23 <kergoth> future, rather
Jan 28 16:07:54 <malanecora> kergoth: hmmm...got it
Jan 28 16:08:10 <malanecora> kergoth: I'll have to struggle with this a little more
Jan 28 16:10:25 <nacknick> LetoThe2nd: Thank you very much. I was looking for that manual...
Jan 28 16:30:15 <rburton> malanecora: might be better to paste the actual errors
Jan 28 16:49:49 <alimon> RP: hi
Jan 28 16:52:08 <RP> alimon: were you looking at the ptest runtime test code or were you leaving that to me? I just looked at it and I see what you mean about the code :/
Jan 28 16:52:26 <RP> alimon: I just don't want to duplicate effort if you're looking at it
Jan 28 16:53:00 <RP> alimon: I also wondered if you'd seen cases where processes persisted after ptest-runner had supposedly killed them and intermixed logging in a confusing way
Jan 28 16:55:30 <yates> how do i find out the current "active recipe", i.e., a recipe which would be cleared with "devtool reset -a"?
Jan 28 16:58:21 <alimon> RP: I had the intent to fix the ptest runtime test but not spend time on it yet, I have certain workload these days so if you want to do it go ahead.
Jan 28 16:59:41 <alimon> RP: regarding the corruption on the logging, I didn't see anything like that, In the ptest-runner code I use a pipes (stdout, stderr) and close after the process ends.
Jan 28 17:02:12 <florian> Uh, looks like the gitsm fetcher in thud is broken submodule specs without a hostname.
Jan 28 17:04:01 <florian> A line like url = git@bitbucket.org:someone/something.git in .gitmodules ends up in ... protocol=git@bitbucket.org
Jan 28 17:04:23 <mdp> florian, smurray mentioned he was possibly looking at a fix for some aspect of broken gitsm on thud the other day. dunno if he'll chime in today wrt his findings as he's off teaching a f2f class atm.
Jan 28 17:05:18 <florian> mdp: ok, the first pats sounds good... the second not that much :-)
Jan 28 17:05:18 <RP> florian: there are a ton of gitsm fixes on master
Jan 28 17:05:57 <mdp> florian: I was only half-listening, but his issue might be specific to subdirectories of submodules
Jan 28 17:06:51 <florian> RP: I'll give them a try... these fix this issue it might be good to get them into stable as well.
Jan 28 17:07:09 <RP> florian: well, they fix several things and break others. I'm waiting until its stable first
Jan 28 17:07:29 <RP> florian: if master doesn't work we'd love to know about it and get that fixed (and test case added)
Jan 28 17:08:19 <armpit> RP, want me to process your master-next build?
Jan 28 17:08:31 <florian> RP: okay
Jan 28 17:10:54 <armpit> RP, the perf builds being run, do they land on the wiki or should they?
Jan 28 17:11:52 <RP> armpit: I posted about the systemd boot failures on list so they're covered (and the broken patch is still in -next so I need to drop that)
Jan 28 17:12:15 <RP> armpit: we probably need bugs for the "random" failures we keep seeing :(
Jan 28 17:12:51 <armpit> k, will look into
Jan 28 17:12:58 <RP> armpit: the perf builds, not sure if they hit the wiki or not. they do hit the performance mailing list though
Jan 28 17:13:48 <armpit> RP, I am thinking in the case if they fail to run. does that show up in the perf mailing list?
Jan 28 17:14:04 <RP> armpit: no, failures are not covered there
Jan 28 17:14:17 <armpit> k
Jan 28 17:15:00 <RP> armpit: we just changed things on the perf machines so they;re about twice as fast now. Had to reset the stats repo so we don't compare apples to oranges
Jan 28 17:16:37 <RP> armpit: you ask a lot of good questions, I just wish I had better answers
Jan 28 17:16:50 <RP> alimon: thanks, I guess whichever of us gets to it first :)
Jan 28 17:17:22 <RP> alimon: I'll look more into the logs issue, I could be misreading things somehow or they could be getting corrupted
Jan 28 17:18:35 <khem> RP: yes its in recipe as I noted
Jan 28 17:38:38 <yocti> New news from stackoverflow: What is the recommended way to organize Yocto project repository(-ies)? <https://stackoverflow.com/questions/53907168/what-is-the-recommended-way-to-organize-yocto-project-repository-ies>
Jan 28 17:41:35 <dkc> is there a way with wic/wks to create a partition with a few files extra-files in it? To store config files for instance
Jan 28 17:51:27 <mnemoc> I use `repo`, `build-*` and `downloads/` directories at the root of the workspace, and everything else inside at `sources/*`
Jan 28 17:51:58 <mnemoc> works-for-me (tm)
Jan 28 17:52:12 <mnemoc> yocti ---^
Jan 28 17:52:13 <yocti> mnemoc: Error: "---^" is not a valid command.
Jan 28 17:52:28 * mnemoc ashamed
Jan 28 17:52:57 * mnemoc hides
Jan 28 17:55:29 <rburton> mnemoc: yocti is a bot, one of the things it does is post new relevant posts from SO
Jan 28 17:55:34 <rburton> hello, yocti
Jan 28 17:55:41 <rburton> hm
Jan 28 17:55:42 <rburton> yocti: hello
Jan 28 17:55:43 <yocti> rburton: Error: "hello" is not a valid command.
Jan 28 17:55:47 <rburton> rude
Jan 28 17:56:45 <RP> yocti: praise rburton
Jan 28 17:56:45 <yocti> RP: Error: There are no praises in my database for #yocto.
Jan 28 17:57:00 <rburton> even ruder!
Jan 28 17:58:03 <rburton> kanavin_: why do you need vte-native?
Jan 28 17:59:05 <RP> yocti: karma rburton
Jan 28 17:59:05 <yocti> RP: Karma for "rburton" has been increased 3 times and decreased 0 times for a total karma of 3.
Jan 28 21:13:46 <khem> halstead: http://git.openembedded.org/ comes out to be marked "not secure" on browser i wonder if this should be fixed
Jan 28 21:15:22 <halstead> khem, http:// URLs are always "not secure".
Jan 28 21:16:56 <halstead> khem, Perhaps we should offer https://git.openembedded.org/ though. We haven't yet.
Jan 28 21:16:57 <khem> so we should get https setup then maybe Crofton should help
Jan 28 21:17:13 <Crofton|work> oh bother
Jan 28 21:17:16 <halstead> khem, Is someone calling for https://git.openembedded.org/ ?
Jan 28 21:17:27 <khem> halstead: no but
Jan 28 21:17:33 <Crofton|work> planning ahead
Jan 28 21:17:34 <halstead> Just a good idea in general?
Jan 28 21:17:37 <khem> I think browsers are getting tighter
Jan 28 21:17:40 * Crofton|work is waiting for a plane
Jan 28 21:18:05 <khem> Crofton|work: dont wait .. let it come
Jan 28 21:18:11 <halstead> Browsers will "never" stop supporting http://
Jan 28 21:18:12 <Crofton|work> yeah
Jan 28 21:18:27 <Crofton|work> but browsers will warn it is shit :)
Jan 28 21:18:37 <khem> halstead: yes but they will start bitching about it more and more
Jan 28 21:18:51 <Crofton|work> been on email/OE admin bing during layover
Jan 28 21:18:54 <khem> and does not give a lot of confidence when someone sees that
Jan 28 21:18:58 <Crofton|work> +1
Jan 28 21:19:10 <Crofton|work> we are being forced to drop http://
Jan 28 21:19:23 <Crofton|work> by forces of good
Jan 28 21:19:27 <khem> especially security guys who are driven to ban http urls as much as they can
Jan 28 21:22:41 <halstead> Are there really security staff who want to ban read-only http:// public websites?
Jan 28 21:23:08 <Crofton|work> it is likely :)
Jan 28 21:23:34 * halstead shrugs. 
Jan 28 21:23:51 <halstead> I suppose they have to justify their jobs somehow.
Jan 28 21:24:08 <halstead> Anyway adding https is easy enough and I'm happy to do that.
Jan 28 21:24:14 <halstead> I could use an easy task right now. ;)
Jan 28 21:29:55 <halstead> khem, Crofton|work All set, https://git.openembedded.org/
Jan 28 21:30:40 <Crofton|work> heh
Jan 28 21:30:41 <Crofton|work> thanks
Jan 28 21:32:44 <khem> halstead: that was fast
Jan 28 21:32:59 <khem> halstead: how about doing same for all yocto and oe sites
Jan 28 21:33:12 <khem> e.g. http://errors.yoctoproject.org/
Jan 28 21:33:43 <khem> halstead: maybe disable http for git.oe.org ?
Jan 28 21:33:59 <khem> oh well that can wait may be
Jan 28 21:35:40 * khem sees a nice lock next to git.oe.org feels so good
Jan 28 21:35:54 <halstead> khem, People probably count on the existing links working. I wouldn't not mess with that. Especially when there is no benefit.
Jan 28 21:36:50 <Crofton|work> emotional support symbol
Jan 28 21:36:51 <khem> halstead: https://konklone.com/post/were-deprecating-http-and-its-going-to-be-okay
Jan 28 21:37:58 <khem> https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
Jan 28 21:41:05 <halstead> khem, Is there a problem with https://errors.yoctoproject.org/ ?
Jan 28 21:43:08 <khem> no, my link needs adjusting
Jan 28 21:43:23 <khem> but I wonder when I type error.yp.org it should default to https and http
Jan 28 21:45:58 <halstead> khem, If you want your browser to prefer https when you enter a partial URL you can install https://www.eff.org/https-everywhere
Jan 28 21:46:30 <halstead> khem, By default your browser prefers http when you don't include the protocol.
Jan 28 21:47:36 <khem> halstead: yeah it does not help when bookmarks have http :)
Jan 28 21:49:08 <halstead> khem, Thanks for the article. Let me know if you spot any YP or OE sites that don't allow https. It should be available everywhere. We force https for logins but otherwise try to leave the protocol up to the user.
Jan 28 21:56:37 <halstead> khem, We can look in to domains where we can force https for users all the the time. I don't want to force any automated processes to change though.
Jan 28 22:01:45 <khem> thats ok a soft nudge to start using https will go long way
Jan 28 22:42:09 <halstead> khem, For http://git.openembedded.org/ I've made it redirect to https://git.openembedded.org/. Other URLs will be served though. This will help people who type the domain and search engine rankings without much possibility of breaking any old scripts. (same for errors.yp)
Jan 28 22:42:47 <khem> superb
Jan 28 22:54:29 <RP> khem: tune change passed testing
Jan 28 22:58:23 <khem> RP: yay
Jan 28 22:59:30 <kroon> I can't run aclocal on target, complains about missing signals, perl -le 'print for keys %SIG', yields nothing
Jan 28 22:59:57 <kroon> wonder if its a regression since the perl updates
Jan 28 23:00:20 <khem> halstead: https://openembedded.org says Info or Not secure
Jan 28 23:00:32 <khem> details see https://support.google.com/chrome/answer/95617?visit_id=636843131537615008-1464303268&p=ui_security_indicator&rd=1
Jan 28 23:00:35 <khem> even if its https
Jan 28 23:00:50 <khem> yp.org is ok
Jan 28 23:03:59 <halstead> khem, It's because of the paypal button on the OE site.
Jan 28 23:04:42 <rburton> kroon: huh the ab *should* be exercising that
Jan 29 02:17:53 <khem> halstead: ah we need the paypal button :)
Jan 29 02:26:51 <shauno> are you sure?  the paypal button looks fine here.  mine's complaining because the "some rights reserved" logo and the OSL logo are being requested over http.  both redirect to https anyway, so changing both the img src to https... should fix it
Jan 29 02:27:59 <shauno> (if you open the js console in chrome, they should show up as 'mixed content' errors while loading)
Jan 29 02:28:21 <khem> I see, I will let halstead handle it
Jan 29 02:30:55 <shauno> looks like an easy win though.  I wish they were all that tidy
Jan 29 02:31:15 <halstead> shauno, khem Oh true. The paypal button is unknown. Those two are the mixed-content. Wrong column. Either way it is probably an easy fix for the wiki admins.
Jan 29 02:32:49 <shauno> it's been driving me nuts on internal wikis.  chrome's getting progressively shoutier about it
**** ENDING LOGGING AT Tue Jan 29 02:59:56 2019