**** BEGIN LOGGING AT Thu Jan 16 02:59:59 2014 Jan 16 08:26:53 good morning Jan 16 08:46:52 hi mckoan Jan 16 09:56:18 koen: ping Jan 16 10:00:50 morning all Jan 16 10:01:58 hi bluelightning Jan 16 10:02:06 hi woglinde Jan 16 11:14:33 hi bluelightning, woglinde, all Jan 16 11:14:40 hi pb_ Jan 16 11:15:34 gm pb Jan 16 11:19:21 ok, today will be stupid question from me day Jan 16 11:19:36 I have an odroid-xu + lcd panel Jan 16 11:19:51 splash seems to work Jan 16 11:19:55 but X isn't Jan 16 11:20:08 startx says I am missing some programs Jan 16 11:20:14 xterm twm etc Jan 16 11:20:40 hmm, would those come in via x11-base? Jan 16 11:21:41 RP: my git fu is failing me, I tried to push to the website repo you emailed me the other day and I can't seem to do it Jan 16 11:22:44 jackmitchell: at a guess make sure you specify git push git@... master:refs/heads/master Jan 16 11:22:48 RP: I have added git@git.openembedded.org/openembedded-web-frontpages Jan 16 11:23:07 jackmitchell: spell out refs/heads/master as the destination Jan 16 11:44:34 RP: git push git@git.openembedded.org/openembedded-web-frontpages master:refs/heads/master is still failing... Jan 16 11:45:02 does not appear to be a git repository, apparently Jan 16 11:47:00 jackmitchell: git push git@git.openembedded.org:openembedded-web-frontpages master:refs/heads/master ? Jan 16 11:48:16 RP: that did it, thanks Jan 16 11:48:55 RP: is it going to be added to cgit, or is there somewhere that it is viewable online? Jan 16 11:49:18 the site it'self and code Jan 16 11:51:23 jackmitchell: I'd have expected it to have appeared. You may have to ask ka6sox about that as I don't think I have any access Jan 16 11:52:45 ok Jan 16 11:52:54 jackmitchell, you and I need to talk with ka6sox Jan 16 11:53:02 Have you talked to him at all about this? Jan 16 11:53:21 I'm going to try hard to get something people are happy with so we can launch before fosdem Jan 16 11:53:37 Crofton|work: I spoke to him a few weeks ago, but haven't spoken since Jan 16 12:01:48 Crofton|work: it's hard to imagine that you really want xterm and twm. I think there must be something a bit wrong with your session scripting. Jan 16 12:02:25 I enabeld x11 and qt4-pkgs in IMAGEFEATURES Jan 16 12:02:36 this gets me startx that tries to start those Jan 16 12:02:44 I don't think we even have recipes for those, at least not in oe-core. Jan 16 12:03:10 I am sort of debugging what happens to idiots trying to build x11 images :) Jan 16 12:03:22 I should file a bug Jan 16 12:04:04 X11 image for embedded is bad Jan 16 12:04:08 *g* Jan 16 12:04:28 I want to get to qt embedded eventually Jan 16 12:04:47 well, core-image-x11 claims to be "A very basic X11 image with a terminal". If that doesn't work then I agree you should probably file a bug for it. Jan 16 12:05:25 in this case, I amde an inmage by adding x11 Jan 16 12:05:31 Crofton|work: I think you have hit the bottom of the default Xsession script which is basically saying hey dude, I tried to run something but you really haven't given me much choice Jan 16 12:05:32 I suppose I should find that file also Jan 16 12:05:39 yeah Jan 16 12:05:59 I would prefer better messages for lusers though Jan 16 12:06:01 I don't think that just adding x11 is likely to achieve anything very useful. You need to pick some actual programs to run. Jan 16 12:06:08 yep Jan 16 12:06:31 Crofton|work: I thought we had most of LXDE in OE Jan 16 12:06:35 but yeah, if oe-core is shipping an xsession that refers to xterm and twm then I guess that would be a bug as well. Jan 16 12:06:52 pb it doesnt say how to start the xterm Jan 16 12:07:10 woglinde: what doesn't? Jan 16 12:07:18 ok Jan 16 12:07:28 -> core-image-x11 claims to be "A very basic X11 image with a terminal". Jan 16 12:07:35 core-imae-x11 uses x11-base :) Jan 16 12:07:38 not x11 Jan 16 12:07:40 rebuilding Jan 16 12:08:15 woglinde: doesn't mini-x-session start it automatically? Jan 16 12:09:26 dont know did not need it so far Jan 16 12:09:48 but you can start X and xterm withput xsession foo Jan 16 12:09:56 from cmdline Jan 16 12:13:36 XorA: there is a meta-lxde, but the maintainer hasn't added it to the layer index :( Jan 16 12:15:31 Next stupid question Jan 16 12:15:32 http://pastebin.com/LYVRHugK Jan 16 12:15:48 apparently I have a pointing device issue that will not let the server start Jan 16 12:17:42 that is a bit odd. does the server just hang there? Jan 16 12:18:10 seems to Jan 16 12:18:23 I do not get the background pattern I eexpect Jan 16 12:19:41 replacing image with one with x11-base installed Jan 16 12:21:01 trying to get a gnuradio app running on this over screen for FOSDEM Jan 16 12:21:38 the lcd screen :) Jan 16 12:21:58 I'm not sure that modern xservers actually display the stippled background any more. Might be worth trying to start an application just to be sure that it isn't running. Jan 16 12:22:11 yeah Jan 16 12:22:19 the new image should start Jan 16 12:22:28 if core-image-x11 works :) Jan 16 12:25:59 crofton at least we can fix it in brussel Jan 16 12:26:37 heh Jan 16 12:26:43 I'd like to avoid that :) Jan 16 12:26:48 eventhough it would be fun Jan 16 12:27:10 fixing demos at the stand stresses everyone Jan 16 12:51:50 gah no pulseaudio Jan 16 12:52:04 crofton sound is needed? Jan 16 12:52:14 apparently Jan 16 12:52:27 I thought the gnuradio sink would work without it, but it seems to get sucked in Jan 16 12:52:45 and the image doesn't have the binary for some reason Jan 16 12:53:01 gotta run Jan 16 12:53:03 more later Jan 16 12:56:48 RP: you called? Jan 16 12:57:02 pb_: rburton has just noticed that eglibc appears to dlopen libgcc in pthread_cancel. Are we missing a dependency? Jan 16 12:57:32 pb_: context being that something in the glib test suite calls pthread_cancel Jan 16 12:57:42 but this image doesn't actually have libgcc installed Jan 16 12:58:29 maybe glib needs an explicit dependency, but i can't see where that actually calls pthread_cancel (unless it's called by another pthread function, that glib does call) Jan 16 12:59:15 rburton: is pthread_cancel in ${PN} or a sub package? Jan 16 12:59:45 I guess its libpthread so it is the main package? Jan 16 12:59:52 yeah Jan 16 12:59:57 its standard posix threading Jan 16 13:00:40 rburton: I think we need to uncomment that line (and fix the comment) Jan 16 13:01:35 pb_: btw, that "appear as a file" problem was in fact a deletion race Jan 16 13:04:16 RP: yeah, that libgcc thing is a long-standing issue. I think the dependency has been ping-ponging in and out for the past few years. Jan 16 13:04:52 RP: there have been a variety of threads on the mailing list about it, let me find a link Jan 16 13:07:09 http://patches.openembedded.org/patch/49633/ has some discussion Jan 16 13:08:10 RP: I had some issues with pthread_cancel Jan 16 13:08:16 I had to RDEPEND on libgcc Jan 16 13:08:23 turns out using gdb to break on pthread_cancel is tricky Jan 16 13:11:31 the two irc links (from 2008!) that I mentioned in that email thread have quite a lot of background discussion on the issue. Jan 16 13:12:08 I have a vague recollection that at one point I thought the right answer was to teach package.bbclass to find binaries that could call pthread_cancel and add an rdepends on libgcc_s for them. I'm not sure whether the situation has changed since then though. Jan 16 13:12:28 i haven't read the irc log but splitting out libpthread seems sane Jan 16 13:12:51 right, that would be a sane thing to do in any case. Jan 16 13:14:10 the eglibc packaging sucks, mostly because it's still the same as when that recipe was originally written (more than a decade ago) and I think our understanding of how things should be done has moved on a bit since then. Jan 16 13:18:58 uclibc lalallaaaaa Jan 16 13:19:02 pb_: after reading all of that i'm none the wiser :) Jan 16 13:20:27 oh, I now remember that the eglibc diagnostic is a bit misleading because there are other functions than pthread_cancel which can lead to that situation. Jan 16 13:21:03 so, if you are finding that a breakpoint on pthread_cancel is never hit, that might be the reason. you could try breaking on pthread_cancel_init(), which is the actual function that does the checking. Jan 16 13:21:11 aha Jan 16 13:21:21 i was about to dig out the source and check for something like that Jan 16 13:22:06 ah called via pthread_exit() Jan 16 13:22:24 that's why i didn't find it in the glib source Jan 16 13:22:34 huh, that is a bit odd. Jan 16 13:22:57 well, if pthread_exit() ends up going down that path, this would imply that basically any program which links -lpthread should also be pulling in libgcc_s. Jan 16 13:23:17 so in that case, putting libpthread.so in its own package and making that one rdepend on libgcc_s sounds like a fine solution. Jan 16 13:23:35 pb_: http://pastebin.com/6XKwF66k Jan 16 13:24:58 oh, right, yes. Jan 16 13:25:26 I guess pthread_exit() obviously does need to unwind. Jan 16 13:27:09 in the general case, anyway. in the particular case at hand it probably doesn't really, but there is no easy way for the runtime to figure that out. Jan 16 13:27:30 so yeah, I think adding libgcc_s as a dependency for all libpthread-using programs is the right thing to do. Jan 16 13:28:45 split the package out or magic "you linked to pthread" dependencies addition? Jan 16 13:29:00 splitting the package up would be easiest. Jan 16 13:29:50 teaching package.bbclass to spot libpthread in NEEDED and add the extra rdepends wouldn't be hard either, since it already analyses all the necessary shlibs bits, but it would be a special-case hack and I don't think there's any good reason to do that. Jan 16 13:31:30 best be careful of the wrath of JaMa Jan 16 13:31:53 breaking on-target upgrades, you mean? Jan 16 13:32:00 yeah Jan 16 13:32:46 well, my view has always been that this is a problem for distros that care about it to sort out. I don't think we really want to clutter up oe-core with loads of compatibility cruft. Jan 16 13:33:56 pb_: why isn't it already catched by shlibs providers? Jan 16 13:34:19 glibc uses dlopen Jan 16 13:34:24 JaMa: because there isn't any shared library linkage, it's dlopen()ed. Jan 16 13:34:58 "spot libpthread in NEEDED" then it's not there, is it? Jan 16 13:35:05 admittedly, if any non-trivial use of libpthread ends up requiring libgcc_s, I can't think of any particularly good reason why it couldn't just be linked. Jan 16 13:35:12 JaMa: no, that's a different library. Jan 16 13:35:27 libpthread is linked, and is in NEEDED, and the shlibs code does do the right thing with it. Jan 16 13:35:29 ok, I'll read more of backlog first :) Jan 16 13:35:37 JaMa: libpthread dlopens libgcc Jan 16 13:35:53 but libpthread doesn't link -lgcc_s, does not have a NEEDED for it, and so shlibs doesn't add a dependency Jan 16 13:36:16 JaMa: currently libpthread is in libc6. We should probably split libpthread into a separate package and add an explicit libgcc dependency Jan 16 13:36:31 there is the side issue, which I think is why rburton mentioned your name, that right now libpthread is rolled up into libc6 so shlibs doesn't distinguish it from libc.so Jan 16 13:37:10 JaMa: I guess distros could hardcode a link between pthread and the libc6 until such times as the feeds have rebuilt with the missing dependencies on the new libpthread Jan 16 13:37:11 if we break libpthread out into its own package, which would be a good thing, it can rdepend on libgcc_s and everything will be peachy expect that now old binaries will break because their rdepends="libc6" suddenly won't get them libpthread.so any more Jan 16 13:38:01 right, exactly. distros can just put RDEPENDS_libc6 = "libpthread6" or something in their configuration as an interim workaround. Jan 16 13:38:54 after reading backlog it looks sane and fine solution Jan 16 13:39:29 good-o Jan 16 13:39:37 let's make it so, then Jan 16 13:39:49 well assuming that opkg doesn't use libpthread :) Jan 16 13:40:00 heh Jan 16 13:40:04 I'm fairly sure it doesn't Jan 16 13:40:29 because then it would nicely upgrade libc6 to package without libphtread and then fail to install libphtread dependency :) Jan 16 13:41:06 but I volunteer to test such upgrade-path once patch is on ML Jan 16 13:41:17 excellent Jan 16 13:41:24 * pb_ lunchtime now Jan 16 13:41:39 assuming that I'll make shr images from master bootable again soon Jan 16 13:53:15 is someone using '@' in branch name? It looks like I'm the lucky one again to find that bb.fetch.decodeurl regexp doesn't parse it correctly Jan 16 13:53:25 I'm adding new url to fetcher test Jan 16 13:58:06 JaMa: yeah, that decodeurl regexp is teh suck Jan 16 13:58:19 I started rewriting those bits of bitbake to use a proper url parser the other week. Jan 16 13:59:59 well someone at work decided that our branching policy would be to use @ everywhere and we're using dylan with bitbake 1.18, how unfortunate combination Jan 16 14:00:08 heh Jan 16 14:00:38 you should then ask that 'someone' to fix it ;-) Jan 16 14:01:42 asking 'architect' to fix it, isn't always best way to solution :) Jan 16 14:02:14 JaMa: once fixed in master that sounds like a good candidate for a backport Jan 16 14:02:20 right. let's them fix the architecture instead! Jan 16 14:06:56 bluelightning: I guess that complete rework to use proper url parser would be too dangerous to backport, but I can try to fix just the regexp for @ Jan 16 14:07:25 JaMa: right, I was thinking of the regex fix Jan 16 14:08:11 (not to cast any shadow over improving the URL parsing in master, of course) Jan 16 14:10:03 I need the backport of archiver Jan 16 14:10:26 unfornatly my simple try did not work because of tasks rework Jan 16 14:10:58 woglinde: the one from poky-contrib patchset? Jan 16 14:12:08 bluelightning: I'm looking at regexp and it doesn't look very easy to fix (I cannot think about any character which cannot be in username and has to be in location) :/ Jan 16 14:12:54 I'll test with proper url parser if it does the right thing I can at least check how they do it Jan 16 14:18:17 pb_: testing your patch with bitbake-selftest shows failure on different URL, did it pass for you? Jan 16 14:18:20 - ('http', 'www.google.com', '/index.html', None, None, {}) Jan 16 14:18:24 + ('http', 'www.google.com', '/index.html', '', '', {}) Jan 16 14:19:25 + few errors before that like: Jan 16 14:19:26 File "/usr/lib64/python2.7/re.py", line 238, in _compile Jan 16 14:19:26 raise TypeError, "first argument must be string or compiled pattern" Jan 16 14:19:26 TypeError: first argument must be string or compiled pattern Jan 16 14:20:03 jama yes Jan 16 14:21:45 I was forward-porting that RFC for archiver I've sent earlier and IIRC it was only about sstate-name varflags Jan 16 14:22:26 but I plan to backport his patchset as well to test it in our dylan build, so I can ping you later Jan 16 14:24:02 RP: ping Jan 16 14:28:31 hum, that one, shouldn't it go to oe-core ? Jan 16 14:28:33 https://lists.yoctoproject.org/pipermail/poky/2014-January/009499.html Jan 16 14:29:08 RP: I've got build stuck on etex txiversion.tex Jan 16 14:29:18 RP: does it sound familiar? Jan 16 14:30:14 RP: it takes 100% CPU Jan 16 14:30:32 fabo: We've see this occasionally but don't understand why Jan 16 14:31:21 RP: it didn't happened before and now it's happens pretty often Jan 16 14:31:38 jama thanks Jan 16 14:50:20 slash is good character for separating username and location :) Jan 16 15:35:34 what's state of the art for figuring what triggers a recipe/package getting built? Jan 16 15:36:41 JaMa: ah yes, right. I did fix that as well but apparently I forgot to send an updated patch. Jan 16 15:37:10 JaMa: iirc, after that I also ran into some problem with the MIRRORS code wanting to use "http?s" as a scheme. I don't quite recall the details of that one. Jan 16 15:38:21 also, I think there is still at least one place in oe-core (grub maybe) which has a stray trailing ';' on the SRC_URI and will cause that code to choke. I'm not sure whether to patch the code to accept that, or just fix up all the remaining broken uris. Jan 16 15:39:01 qt4 wants pulseaudio? Jan 16 15:40:35 Crofton|work: it depends on it directly IIRC Jan 16 15:40:57 what installs the pulseaudio "server" Jan 16 15:41:47 my fedora box has /usr/bin/pulseaudio, but not the image OE builds Jan 16 15:43:31 Crofton: "pulseaudio-server" Jan 16 15:43:37 heh Jan 16 15:43:45 I wonder that doesn't end up in the image Jan 16 16:11:22 woglinde: do_deploy_archives[sstate-name] = "deploy_archives" Jan 16 16:11:52 woglinde: this line alone seems to be enough to get it started again in dylan build, but I'm waiting for build to finish to see if it actually works Jan 16 16:38:23 jama ????? Jan 16 16:38:58 jama did you just copy the archiverclass? Jan 16 16:39:09 and removed the three otherone? Jan 16 16:42:43 woglinde: yes and added this line Jan 16 16:43:01 + updated archiver config of course to match with new local.conf.sample.ext Jan 16 16:43:09 hm okay thanks Jan 16 16:43:13 I will try it Jan 16 16:43:48 Currently 6 running tasks (1474 of 10980): Jan 16 16:45:23 jama did you add it in the and? Jan 16 16:46:16 ups I mean at the end of archiver.bbvlass? Jan 16 16:48:23 hm seems to work Jan 16 16:48:24 nice Jan 16 16:48:44 at least I do not get the python errors Jan 16 16:49:47 halstead: Crofton|work : i was unscribed from the automated-mailing too, like tlwoerner . i can't find the http link to the list. can you add me back? Jan 16 16:51:28 jama hm okay it patches native packages too Jan 16 16:51:55 jama args I meant it package native stuff too which is maybee not needed Jan 16 16:52:46 ndec, You can resub at https://lists.yoctoproject.org/listinfo/automated-testing a good of users was manually unsubscribed by accident. Sorry. Jan 16 16:53:17 halstead: ok. just did. Jan 16 16:53:48 halstead: hmm. i got this: "An attempt was made to subscribe your address to the mailing list Jan 16 16:53:48 automated-testing@yoctoproject.org. You are already subscribed to this mailing list" Jan 16 16:54:00 so, i guess i wasn't really removed.. Jan 16 16:54:46 jama ah okay could be all tweaked Jan 16 16:54:48 exelcent Jan 16 16:56:30 till later Jan 16 17:05:01 ndec, We tried to add everyone back who was accidentally removed. We must have restored your subscription last night. Jan 16 17:05:23 ok. thanks! Jan 16 17:30:44 so... has everyone been looking through the bugzilla to pick which bugs they're going to be working on this weekend? ;-) Jan 16 17:42:19 I need to find the gumption to join the bug squashing first :) Jan 16 17:45:45 I've been staring at my bug list Jan 16 17:51:27 * tlwoerner cheers Jan 16 17:51:58 and joins in the search for gumption Jan 16 17:59:01 You know what I'd like to see taken on as a project, or perhaps do myself, is really and truly get everything using doc generation distro features, rather than the weird hodgepodge we've got going right now Jan 16 17:59:20 would take some grunt work, going through each recipe, but that would really be nice Jan 16 18:00:01 kergoth: i'm not sure what you mean, "doc generation distro features" (?) Jan 16 18:00:13 kergoth: bring that one up again in a few weeks Jan 16 18:00:27 I mean allow toggling documentation generation for recipes. Ideally via packageconfig at the recipe level and distro features at a config level Jan 16 18:00:45 ah yes, like the xorg stuff Jan 16 18:00:54 any use of makeinfo, help2man, etc.. Jan 16 18:01:12 the packageconfig stuff isn't all tied to distrofeatures, is it? Jan 16 18:01:13 not sure if we'd want one feature or multiple, e.g. for man page vs actual emitted documentation like html files Jan 16 18:01:33 not technically, no, but in some cases the default packageconfig value for a recipe will be set based on distro features Jan 16 18:01:36 * mr_science thinking of recipes with only packageconfig options Jan 16 18:01:45 as a first step, i thought it would be interesting to write a script that would go through all the recipes and generate a table (?) of all the ./configure options Jan 16 18:01:54 the packageconfig would be the most important piece, distro features would just let you toggle it for all recipes rather than one at a time Jan 16 18:02:39 tlwoerner: i bet one could easily gather the available args by using autoconf/m4 tracing of the macros to pick up all AC_ARG_WITH/AC_ARG_ENABLE Jan 16 18:02:44 * kergoth shrugs Jan 16 18:03:10 yes, and the results could be transformed into PACKAGECONFIGs :-) Jan 16 18:05:44 I wish folks would read the buildsystems of the software they're creating recipes for a bit more closely, then the recipes would have been more fleshed out to begin with, with all explicit configure args, and clean and explicit variable passing into non-autotools makefile-based buildsystems, rather than the default -e in EXTRA_OEMAKE crap Jan 16 18:05:46 oh well.. Jan 16 18:07:02 some days i think it'd be fun to recreate oe-core from scratch, slowly and with care Jan 16 18:07:09 but i may be weird that way Jan 16 18:07:13 :) Jan 16 18:09:38 kergoth: haha! over the recent break i found myself thinking the same thing :-) "what would OE look like if we started over, knowing what we know?" Jan 16 18:10:03 https://gist.github.com/kergoth/8424665 Jan 16 18:11:04 *bookmarked* Jan 16 18:12:34 just some stuff i'd be interested in seeing in such a recreation, personally Jan 16 18:12:35 heh Jan 16 19:07:03 denix, I also need to complain about meta-ti sucking Jan 16 19:08:06 Crofton|work: there is a special place for complains - it's called /dev/null :) Jan 16 19:08:20 ERROR: Function failed: Fetcher failure for URL: 'git://arago-project.org/git/projects/u-boot-keystone.git;protocol=git;branch=master'. Unable to fetch URL from any source. Jan 16 19:08:36 I just found out I should add the meta-ti layer to my sdr manifest Jan 16 19:09:13 https://github.com/balister/oe-gnuradio-manifest/commit/33604da98c0993b505f9e0fd870cfffee6f336eb Jan 16 19:10:05 Crofton|work: arago server has limited resources, so sometimes it refuses connections when under heavy load. I'm working on the upgrade now... Jan 16 19:10:11 ok Jan 16 19:10:15 so restart build? Jan 16 19:10:29 should work now Jan 16 19:10:52 k Jan 16 19:13:43 wth? Jan 16 19:14:12 that's two days in a row this stupid laptop has gone molten-hot for no reason Jan 16 19:15:16 OE build on background? :) Jan 16 19:16:48 nope Jan 16 19:17:04 it's idling with all cores over 90 C Jan 16 19:17:47 rebooting should at least get back to normal for a while... Jan 16 19:21:14 Crofton|work: if you were thinking of participating in the bug hunt this weekend, it would be great if you could fix the MeetingBot to generate good URLs :-) Jan 16 19:21:30 rofl Jan 16 19:21:42 should i file a bug for it? ;-) Jan 16 19:21:42 I need to fix my upload script and bug ka6sox Jan 16 19:29:51 hmm, maybe 3.12.6 wasn't the best choice for corei7... Jan 16 19:39:07 3.13.0-rc8-00005-ga6da83f sounds like much better option Jan 16 19:44:44 because it's more bleeding-edge? Jan 16 19:53:40 Hello. Could someone offer insight to the choice in bitbake's sstate_install calling to oe.path.copyhardlinktree ? Jan 16 19:54:58 I can understand it from a space-saving stand point, but in my case I am working on building out a set of distributed instances of yocto/oe bitbake in docker containers that have DEPLOY_DIR_IMAGE set to what ends up looking like a different filesystem to the container. Thus, hardlink fails rather obvioiusly. Jan 16 20:00:26 Hrm, looks like this condition is attempted to be caught. Jan 16 20:00:42 http://git.openembedded.org/openembedded-core/tree/meta/lib/oe/path.py?h=dora#n87 Jan 16 20:10:51 * mr_science tests both the camera system *and* lunch Jan 16 20:11:01 simultaneously even... Jan 16 20:12:57 erk.. looks like its problem with the lxc container mount issues. Jan 16 20:46:05 got it. Jan 16 20:47:05 os.stat(x).st_dev is not necessarily accurate, since it it tracks the device it is from, which doesn't necessarily relate correctly inside containers. Jan 16 20:47:21 have to walk the path backwards to find the mount Jan 16 20:48:15 aha, interesting Jan 16 20:48:57 http://pastie.org/pastes/8640241/text Jan 16 20:49:50 * WarheadsSE digs for patch submittal Jan 16 21:04:08 and viola. that did indeed work. Jan 16 22:09:10 there are days I hate the corp email server... Jan 16 22:10:19 you say this as if there are days, you like it ;-) Jan 16 22:10:37 OWA has decent cert.. the TLS port does NOT. Jan 16 22:10:51 so I have to go remembering where the hell the right way to bypass ssl cert checks is.. Jan 16 22:11:25 eitherway, patch dropped to oe-core. Jan 16 22:11:48 even if it screwed my message into . Jan 16 22:14:49 smtpsslcertpath = "" :-D Jan 16 22:15:02 yeah, i remember NOW that I did it :P Jan 16 22:15:11 .gitconfig for the win Jan 16 22:15:14 fire and forget Jan 16 22:15:34 although it took me hours of searching to find that undocument feature Jan 16 22:16:51 yeah Jan 16 22:16:58 took me about 15 minutes of annoyed Jan 16 22:17:10 then opened the perl script and lo-and-behold Jan 16 22:17:15 mash/win Jan 16 22:17:40 * XorA nukes F20 for forgetting the certs Jan 16 22:23:14 whats the config item though Jan 16 22:23:22 smtp.sslcertpath? Jan 16 22:23:33 [sendemail] Jan 16 22:23:51 sendemail.smtpsslcertpath Jan 16 22:24:59 which is annoyingly not consistant with http.sslVerify :-( Jan 16 22:25:16 of course. Jan 16 22:25:27 but I would rather not disable what I don't have to. Jan 16 22:26:17 yeah, it all seemed to work until F20 Jan 16 22:34:57 Ah, well, not a Fedora user.... so **** ENDING LOGGING AT Fri Jan 17 02:59:58 2014