November 30, 2016 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >
November 30, 2016 [00:16:29] *** andy_js <andy_js!~andy@2.218.92.54> has quit IRC (Quit: andy_js)[00:28:55] *** merzo <merzo!~merzo@93-195-113-92.pool.ukrtel.net> has quit IRC (Read error: Connection reset by peer)[00:29:09] *** merzo <merzo!~merzo@93-195-113-92.pool.ukrtel.net> has joined #oi-dev[00:43:39] *** ngchk1 <ngchk1!~wilkens@business-178-015-081-200.static.arcor-ip.net> has quit IRC (Quit: Leaving)[00:58:31] *** merzo <merzo!~merzo@93-195-113-92.pool.ukrtel.net> has quit IRC (Remote host closed the connection)[02:00:18] *** makruger <makruger!~Michael@pool-108-20-232-57.bstnma.fios.verizon.net> has joined #oi-dev[02:23:05] *** tozhu <tozhu!~Thunderbi@218.88.87.183> has joined #oi-dev[02:32:21] <oibot> Project illumos-gate build #4702: SUCCESS in 1 hr 26 min: https://hipster.openindiana.org/jenkins/job/illumos-gate/4702/[03:03:36] *** makruger <makruger!~Michael@pool-108-20-232-57.bstnma.fios.verizon.net> has quit IRC (Ping timeout: 260 seconds)[03:39:30] *** tozhu <tozhu!~Thunderbi@218.88.87.183> has quit IRC (Ping timeout: 256 seconds)[03:52:25] *** freakazoid0223_ <freakazoid0223_!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has joined #oi-dev[03:55:01] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has quit IRC (Ping timeout: 248 seconds)[03:55:04] *** freakazoid0223_ is now known as freakazoid0223[04:20:14] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has quit IRC (Read error: Connection reset by peer)[04:23:03] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has joined #oi-dev[04:59:55] *** tozhu <tozhu!~Thunderbi@218.88.87.183> has joined #oi-dev[05:18:17] *** tozhu <tozhu!~Thunderbi@218.88.87.183> has quit IRC (Ping timeout: 252 seconds)[05:24:21] *** DrLou <DrLou!~DrLou@c-73-33-92-169.hsd1.nj.comcast.net> has joined #oi-dev[05:24:21] *** ChanServ sets mode: +o DrLou[05:33:56] *** echelog-2 <echelog-2!~echelog-2@108.61.103.42> has joined #oi-dev[05:34:49] *** avsej <avsej!~avsej@node.avsej.net> has joined #oi-dev[05:34:49] *** avsej <avsej!~avsej@node.avsej.net> has quit IRC (Changing host)[05:34:49] *** avsej <avsej!~avsej@fedora/avsej> has joined #oi-dev[06:30:29] *** leoric <leoric!~leoric@46.147.125.214> has joined #oi-dev[06:48:03] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev[06:49:20] *** grueni <grueni!~chatzilla@HSI-KBW-134-3-91-29.hsi14.kabel-badenwuerttemberg.de> has quit IRC (Remote host closed the connection)[06:49:26] *** nikolam <nikolam!~nikolam@unaffiliated/nikolam> has joined #oi-dev[06:59:39] *** leoric <leoric!~leoric@46.147.125.214> has quit IRC (Remote host closed the connection)[06:59:44] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 260 seconds)[07:13:58] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev[07:46:24] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Remote host closed the connection)[07:46:45] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev[08:00:16] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 258 seconds)[08:00:39] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev[08:05:41] *** FuntDobraWork <FuntDobraWork!~FuntDobra@212.34.53.106> has joined #oi-dev[08:09:02] <alp> gwr: BTW, I see issues similar to https://www.illumos.org/issues/7624 unrelated to intel drm driver. ligtdm seems fail to restore text mode console....[08:09:12] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 250 seconds)[08:09:13] <alp> gdm does this fine[08:09:14] <Agnar> moin[08:23:24] <nikolam> Maybe gdm is supposed to stay default and not to be replaced in last snapshot with lightdm[08:26:39] <alp> no it is not[08:26:54] <alp> the only reason for gdm to survive is SunRay installations[08:27:53] <alp> when someone ports gdmdynamic to lightdm, gdm has no use[08:28:49] <nikolam> good to know.[08:29:23] <tsoome> how does the lightdm shut down the Xorg?[08:29:30] <nikolam> As I remember, Sunray installations do not work on Hipster, but last worked on 151a8 as I remember?[08:30:12] <tsoome> it feels like lightdm may be using too big hammer to kill the Xorg and wont give wi time to clean up[08:30:22] <tsoome> s/wi/it/[08:31:51] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev[08:33:56] <alp> nikolam: last time I've checked SRSS on OI (in 2014 IIRC) it worked with some tweaks[08:34:59] <nikolam> there were reports on ML they use Sunrays in production but only with 151a[08:35:13] <tsoome> I mean, thats seems the case about re-activating console on svcadm disable lightdm - I can see in many cases the console is left inactive, and the console re-activation is done by Xorg on its shutdown.[08:35:16] <nikolam> so it worked on hipster in '14?[08:36:01] <nikolam> I have sunray to try it out.[08:40:27] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 244 seconds)[08:43:55] *** merzo <merzo!~merzo@91.217.179.122> has joined #oi-dev[08:45:22] <alp> tsoome: I thought it was done by display manager itself - https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/desktop/lightdm/patches/14-vt-switch.patch[08:47:29] <tsoome> well, in sense it does not matter what does it, just I have witnessed 2 things to happen 1) either its not done or 2) if its done, according to dtrace ustack(), it was done by Xorg[08:48:59] <tsoome> also note there are 2 scenarios - one is VT switch - you do not shutd down the X, but switch to console VT, and this code seems to be the case for switch[08:49:22] <tsoome> but there is also the case for lightdm+Xorg shutdown[08:50:08] <tsoome> the cases where console is left inactive, are about svcadm disable lightdm[08:52:15] *** alanc <alanc!~alanc@inet-hqmc01-o.oracle.com> has quit IRC (Remote host closed the connection)[08:53:32] <tsoome> anyhow, you can witness it by: dtrace -n :tem:tem_switch:entry {stack(); ustack();}[08:59:47] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev[09:00:02] *** alanc <alanc!~alanc@inet-hqmc01-o.oracle.com> has joined #oi-dev[09:00:02] *** ChanServ sets mode: +o alanc[09:03:09] *** grueni <grueni!~chatzilla@HSI-KBW-134-3-91-29.hsi14.kabel-badenwuerttemberg.de> has joined #oi-dev[09:03:47] <alp> added some debug... It says that lightdm succesfully executes ioctl(open_a_console('/dev/vt/active'),VT_ACTIVATE, 1);[09:04:08] <alp> tsoome: BTW, should it be /dev/vt/active or /dev/vt/0 ?[09:04:34] <alp> also, it does it before killing Xorg[09:04:39] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 268 seconds)[09:04:42] <alp> and this can be an issue[09:05:15] <tsoome> Im not really too sure, probably should check the Xorg code.[09:06:06] *** grueni <grueni!~chatzilla@HSI-KBW-134-3-91-29.hsi14.kabel-badenwuerttemberg.de> has quit IRC (Client Quit)[09:06:23] <tsoome> if X is running, the vt 7 should be “active” one, no?[09:08:04] <tsoome> in that sense, the “active” node does not sound right. Also from vt devices, vt 0 is for vtdaemon, vt 1 should be the “console”, and rest are just virtual terminals[09:10:32] <tsoome> So when the lightdm is shut down, there should actually happen 2 things for VT - the first vt should be switched to, and the console should be re-activated.[09:14:12] *** FuntDobraWork <FuntDobraWork!~FuntDobra@212.34.53.106> has quit IRC (Ping timeout: 250 seconds)[09:14:45] <tsoome> Also, I think the VT switch can not happen before X is down, which is why dtrace did show the Xorg issuing ioctl VT_ACTIVATE[09:15:47] <alp> Yes, I think I should move vt switch code[09:15:51] <alp> found proper place[09:21:49] *** FuntDobraWork <FuntDobraWork!~FuntDobra@212.34.53.106> has joined #oi-dev[09:22:04] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev[09:22:54] *** tsoome <tsoome!~tsoome@220-90-235-80.dyn.estpak.ee> has quit IRC (Ping timeout: 256 seconds)[09:26:46] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 265 seconds)[09:30:44] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev[09:31:49] <alp> tsoome: this worked[09:31:59] <alp> need testers[09:32:16] <alp> pkg://userland/system/display-manager/lightdm at 1 dot 19.3,5.11-2016.1.0.0:20161130T082530Z[09:44:16] *** tsoome <tsoome!~tsoome@20-10-196-88.dyn.estpak.ee> has joined #oi-dev[09:47:03] <alp> tsoome: will you review https://github.com/OpenIndiana/oi-userland/pull/2636/files ?[09:47:44] <alp> we essentially move vt switch from stage where lightdm just received SIGTERM to just before exit from main loop (program)[09:48:08] <alp> I'm a bit confused with existing (gdm) comments[09:48:18] <tsoome> do you have binary? I can test it on my some VM:)[09:48:25] <alp> they speak about VT1 and use /dev/vt/0 ;)[09:48:32] <alp> pkg://userland/system/display-manager/lightdm at 1 dot 19.3,5.11-2016.1.0.0:20161130T082530Z[09:48:49] <alp> do you want just binary ?[09:49:02] <tsoome> I cant install pkg atm, my nightly repo is not accessible atm[09:50:13] <alp> should we tell user about VT0 or VT1 in debug output ? ;)[09:51:32] <alp> tsoome: http://buildzone.oi-build.r61.net/test-lightdm/lightdm[09:53:27] <alp> vt(7i) speaks about console 1-12[09:53:45] <alp> so 1 should be used externally[09:55:21] <tsoome> yes, the 0 is for vtdaemon private use, same as lofi device 0 is for lofi control, and 1.. N are mapped devices[09:55:46] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 265 seconds)[09:59:19] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev[09:59:31] <tsoome> seems much better[10:00:26] *** ptribble <ptribble!~ptribble@cpc108961-cmbg20-2-0-cust21.5-4.cable.virginm.net> has joined #oi-dev[10:02:59] <tsoome> there is still different interesting artifact - when you run series of svcadm enable lightdm; svcadm disable lightdm then at some point the lightdm start will take quite some time. but it may be some SMF mechanism there tryinf to protect from spam or something[10:03:32] <tsoome> but, so far the console is revovered every time I run svcadm disable[10:04:34] <tsoome> this is with framebuffer console btw.[10:05:33] <alp> can I add you to reviewers?[10:05:52] <tsoome> let me see the code first[10:05:58] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 256 seconds)[10:05:59] <alp> :)[10:06:33] <tsoome> you can list me done some tests (not that the tests I did did cover all the cases)[10:06:42] <alp> it's a bit hard without whole lightdm at hand...[10:08:38] <tsoome> yes, I just did notice, reading it does not make much sense at all:D[10:15:04] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev[10:23:44] *** ngchk1 <ngchk1!~wilkens@business-178-015-081-200.static.arcor-ip.net> has joined #oi-dev[10:38:09] <alp> switch uptime ... uptime is 6 years, 2 days, 23 hours, 20 minutes[10:38:22] <oibot> Project oi-userland build #2695: FAILURE in 2 hr 22 min: https://hipster.openindiana.org/jenkins/job/oi-userland/2695/[10:39:04] *** andy_js <andy_js!~andy@2.218.92.54> has joined #oi-dev[10:54:42] *** nikolam <nikolam!~nikolam@unaffiliated/nikolam> has quit IRC (Ping timeout: 258 seconds)[10:56:42] *** nikolam <nikolam!~nikolam@unaffiliated/nikolam> has joined #oi-dev[10:58:12] *** kohju <kohju!~kohju@59.84.158.183> has quit IRC (Ping timeout: 260 seconds)[10:58:30] *** makruger <makruger!~Michael@pool-108-20-232-57.bstnma.fios.verizon.net> has joined #oi-dev[11:02:25] *** kohju <kohju!~kohju@gw.justplayer.com> has joined #oi-dev[11:02:25] *** ChanServ sets mode: +o kohju[11:03:30] *** jimklimov <jimklimov!~E9926362@31.7.243.238> has joined #oi-dev[11:06:33] *** jimklimov <jimklimov!~E9926362@31.7.243.238> has quit IRC (Read error: Connection reset by peer)[11:25:44] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has quit IRC (Ping timeout: 258 seconds)[11:36:30] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has joined #oi-dev[11:39:13] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 245 seconds)[11:39:55] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has quit IRC (Ping timeout: 258 seconds)[11:41:17] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has joined #oi-dev[11:49:59] <Agnar> hello...are there any plans to kill 32bit in hipster? to be precise: no longer ship 32bit binaries/libs with the OS like in oi-userland?[11:50:39] <alp> hello[11:50:49] <igork> Agnar: try to update illumos userland components with 64bit builds :)[11:50:52] <igork> first[11:50:52] <tsoome> Agnar: that will be *huge* work[11:50:53] <alp> don't know about libraries, most should be preserved[11:51:12] <tsoome> and yes you can not just nuke libs, it will break a lot[11:51:42] <Agnar> tsoome: actually I ask, because I stumbled about a blog entry from alanc (https://blogs.oracle.com/alanc/entry/lp64_bit_by_bit) regarding sol11. I wonder if there are any plans to do the same[11:51:44] <tsoome> also, our userland (gate or not) is mostly 32-bit and filled up with 64-bit bugs[11:51:49] <alp> as for 32-bit applications, now we ship 64-bit when they are known to work better (and when 32-bit apps requires sufficient work to fix them)[11:52:16] <Agnar> does illumos/hipster still support 32bit systems?[11:52:23] <alp> no[11:52:27] <Agnar> ok[11:52:28] <alp> at least OI[11:52:35] <alp> illumos supports[11:52:35] <tsoome> it would be really nice to cleanup and work out those issues, but it will need dedication[11:52:36] <Agnar> ok, good to know[11:52:44] <tsoome> “support"[11:52:52] <tsoome> we build 32-bit kernel yes.[11:53:02] <tsoome> it probably does run[11:53:15] <igork> i dropped 32bit kernel build on my tree and iso :)[11:53:18] <Agnar> that answers at least the question for me: "do I have to build 32bit and 64bit?" :)[11:53:22] <igork> save some space and build time[11:54:02] <tsoome> but 32-bit updates are probably not tested.[11:54:41] <alp> pkg is known to be broken on 32-bit systems[11:54:51] <tsoome> it has been asked few times if we should remove 32bit kernel, but has hit the wall always[11:54:55] <alp> and we ship 64-bit software in /usr/bin[11:55:39] *** jimklimov <jimklimov!~E9926362@31.7.243.238> has joined #oi-dev[11:55:52] <Agnar> alp: oh that's really good to know...wouldn't that mean that a 64bit only python would be ok? (I have issues on sparc here)[11:56:11] <alp> what python version?[11:56:27] <Agnar> 2.7.12[11:56:36] <alp> so far 2.7 and 3.4 support both 32/64 bits[11:56:41] <tsoome> I would guess the part of the issue is that there are only few who dare tou touch build system… ;)[11:56:42] *** tozhu <tozhu!~Thunderbi@223.85.203.28> has quit IRC (Ping timeout: 268 seconds)[11:56:57] <tsoome> s/tou/to/[11:57:50] <alp> as these are bottom of stack, you can't start dropping 32-bit software starting from python ;)[11:58:32] <tsoome> well, for distro it is a bit easier[11:58:46] <tsoome> the impact is a bit lesser[11:58:49] <Agnar> tsoome: I have to in any case, as we call gcc in python 2.7 build with -m32 *and* -m64 combined. which is fine for gcc/x86 but not for gcc/ssparc (cool, eh? compiler behaves different with the same flags on different architectures)[11:59:26] <tsoome> aye.[11:59:54] <tsoome> well, for sparc it is actually even more simpler, as for sparc you do not have 32bit kernel at all.[12:00:16] <tsoome> in that sense its just an question how much 32bit userland you want to build.[12:00:32] <Agnar> tsoome: yes, for that reason - and because I have to build everything else as well - I think of killing -m32 completely[12:01:00] <tsoome> for complete kill, you want to grab bug list from igork ;)[12:01:08] <tsoome> its not short[12:01:11] <Agnar> tsoome: for python[12:01:12] <Agnar> :)[12:01:17] <Agnar> not for oi-userland ;)[12:01:19] <tsoome> ah, then its easier;)[12:08:26] *** nikolam <nikolam!~nikolam@unaffiliated/nikolam> has quit IRC (Quit: Leaving)[12:10:56] <Agnar> oh...and while we are talking...when building python2.6 with gcc4.9 the linked complains about the undefined symbol "asm" in libpython2.6.so - does anyone know which lib "asm" supplies?[12:13:21] *** makruger <makruger!~Michael@pool-108-20-232-57.bstnma.fios.verizon.net> has quit IRC (Ping timeout: 268 seconds)[12:20:24] <jimklimov> No :\[12:20:24] <jimklimov> I thought the answer could be along the lines of[12:20:24] <jimklimov> for L in {/usr,}/lib/*.{so,a} /usr/gcc/*/lib*/*.{so,a} ; do nm "$L" | grep -w asm && echo "^^^ $L"; done 2>/dev/null[12:20:33] <jimklimov> but this did not find it :\[12:24:21] <alp> Agnar: can it be asm vs __asm__ ? https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html[12:24:37] <jimklimov> grepping for that... for some time now[12:24:54] <Agnar> jim: :/[12:24:58] <Agnar> alp: could be[12:25:44] <tsoome> python is using embedded asm?[12:27:30] <Agnar> tsoome: oh yes....[12:27:41] <Agnar> The asm keyword is a GNU extension. When writing code that can be compiled with -ansi and the various -std options, use __asm__ instead of asm (see Alternate Keywords).[12:27:48] <Agnar> from: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html[12:28:02] <Agnar> so, that's the problem, as we compile with -std=c99[12:28:18] <tsoome> send the bill for your time to gnu:P[12:29:02] <Agnar> oh, FSF owes me bunches of money...[12:29:26] <tsoome> :D[12:31:13] <jimklimov> yes, 100 hours times their rate... which is... 0$/hr :)[12:32:19] <jimklimov> so, could `CFLAGS += -Dasm=__asm__` help here?[12:33:00] <tsoome> the better question would be, are you embedding x86 asm to sparc binary?;)[12:33:40] <tsoome> altho it will blow up at build time anyhow[12:34:05] <jimklimov> =D[12:34:22] <jimklimov> maybe they have different asm's for different platforms ifdefed somehow?[12:34:48] <tsoome> I guess we will hear soon enough:P[13:00:49] <oibot> Yippee, build fixed![13:00:49] <oibot> Project oi-userland build #2696: FIXED in 2 hr 22 min: https://hipster.openindiana.org/jenkins/job/oi-userland/2696/[13:02:20] <jimklimov> I guess that one did not explode ;p[13:19:20] <Agnar> tsoome: it should be of course sparc asm and since it is python 2.6 in oi-userland, I suspect it should be safe to build (as python2.7 has no issues here)[13:58:00] <xenol> ok, just gave a talk about dynamic tracing and when people compared dtrace to linux alternatives[13:58:10] <xenol> they understood when I called linux "special ecosystem" :)[13:58:57] *** tomww <tomww!~tom@unaffiliated/tomww> has quit IRC (Ping timeout: 252 seconds)[14:00:37] <Agnar> xenol: hehe[14:06:39] *** tomww <tomww!~tom@unaffiliated/tomww> has joined #oi-dev[14:06:39] *** ChanServ sets mode: +o tomww[14:11:45] *** tozhu <tozhu!~Thunderbi@218.88.87.183> has joined #oi-dev[14:16:40] <Agnar> yikes, after update to hipster 22016 my ldap connections failed because the cert database in /var/ldap is ina old unsupported format...[14:16:57] <jimklimov> ^\[14:18:46] <alp> Agnar: what application does fail? Note, we recently removed old mozldap libraries[14:19:02] <Agnar> ldap_cachemgr[14:20:01] <Agnar> and certutil[14:21:32] *** tozhu <tozhu!~Thunderbi@218.88.87.183> has quit IRC (Ping timeout: 256 seconds)[14:24:43] <alp> can you truss it?[14:25:29] <alp> (look if it tries to access /usr/lib/*ldap60*[14:25:40] <xenol> opensnoop ftw[14:27:16] <Agnar> alp: seems not[14:27:26] <alp> then I hope it's not me ;)[14:28:37] <alp> how old are working and not-working BEs?[14:28:46] <Agnar> alp: please try in an empty directory: certutil -N -d . ; certutil -L[14:29:17] <Agnar> the working ones are from march, this one is from start of november iirc[14:30:46] <Agnar> https://paste.ec/paste/5BTJ2GES#u5rC54rT-KZY16WySHOqh9x1GK7GeBK+F7zlGE+OjZv[14:33:24] <alp> can you give the exact date of working BE ? or pkg info userland-incorporation ?[14:33:32] <alp> (in working BE)[14:34:49] <Agnar> FMRI: pkg://openindiana.org/consolidation/userland/userland-incorporation at 0 dot 5.11-2016.1.0.7766:20161031T203540Z[14:43:17] <alp> Agnar: your example is not entirely correct - you should do 'certutil -d . -L' , and this works[14:44:49] <alp> and certutil -L tries to open nonexistent ~/.netscape/cert8.db and ~/.netscape/cert7.db[14:45:42] <Agnar> oh[14:46:01] <Agnar> right.[14:46:53] <Agnar> let's see if creating new certs is enough[14:51:55] <Agnar> hm. at least ldap_cachemgr still does not work:[14:52:17] <Agnar> Nov 30 14:49:59 dhcpserv nscd[9899]: [ID 293258 user.error] libsldap: Status: 53 Mesg: openConnection: simple bind failed - DSA is unwilling to perform[14:53:15] <jimklimov> what do the ldap server logs show?[14:53:22] <jimklimov> and which server?[14:53:46] <jimklimov> perhaps its error.log[14:54:20] <jimklimov> you can also try verbose ldapclient options to bind with the same credentials to see if it works or what it complains about[14:54:35] <Agnar> jimklimov: OpenDS, worked for years now. error is as expected: [30/Nov/2016:14:53:44 +0100] DISCONNECT conn=1389 reason="Protocol Error" msg="The client sent a request to the Directory Server that could not be properly decoded as an LDAP message: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?"[14:55:03] <Agnar> if ldap_cachemgr does not find a working certificate, it silently falls back to plain text ldap on the ssl port[14:55:47] <jimklimov> ok, if you're sure... OR it may be that it no longer uses some obsoleted crypto and tries some newer one that OpenDS (or its JVM) does not support?[14:56:34] <Agnar> jimklimov: *might* be, but have we touched the mozilla nss libs that much?[14:56:36] <alp> does it at least accesses cert files?[14:56:45] <alp> last update was in March[14:57:12] <alp> we ship nss 3.23[14:57:19] <jimklimov> So a couple of other options to try is to start OpenDS with a latest JDK (or, as it happened to some Sun Java System products, the latest JDK that is willing to start this service without errors), and maybe to migrate from OpenDS to OpenDJ?[14:58:11] <Agnar> alp: i'll truss ldap_cachemgr...[14:58:22] <alp> wait, first of all we should find out if it doesn't want to establish ssl connection or even doesn't try to[15:00:06] <jimklimov> snoop/ngrep/tcpdump[15:02:54] <Agnar> alp: it opens and reads the cert8.db and the key3.db[15:10:57] *** FuntDobraWork <FuntDobraWork!~FuntDobra@212.34.53.106> has quit IRC (Ping timeout: 268 seconds)[15:16:54] <alp> interesting, if it tries to establish ssl connection...[15:17:33] <Agnar> but talks then plain[15:17:57] <Agnar> the ldap_cachemgr is btw a good example of hard-to-debug-binary[15:18:14] <Agnar> logs nearly nothing, has no debug flags and operates a lot via door()s[15:41:00] <Agnar> what?![15:41:27] <Agnar> I switched openDS jdk from the local installed jdk1.6 to openjdk7 and now it works...[15:41:36] <Agnar> I don't want to know...[15:42:09] <Agnar> even with old client certs[15:42:14] <Agnar> what the heck?[15:45:42] <Agnar> ok. seems the mozilla nss libs got modified that can not any longer handshake correctly with the old jdk1.6.0[15:45:56] <Agnar> ok guys, sorry for making you nervous.[15:46:55] <jimklimov> IT happens :-)[15:47:15] <Agnar> java and the wonders of SSL[15:47:24] <Agnar> one could write a book about it[15:48:04] <jimklimov> well, a lot of toolkits deprecate insecure protocols[15:48:17] <jimklimov> probably this is yet another case[15:48:32] <jimklimov> just like sunssh not handshaking with modern openssh by default[15:50:43] <Agnar> jepp[15:51:17] <alp> does anyone know how to use hiera? ;)[15:53:36] <Agnar> oh. puppet. *shiver*[15:53:41] <Agnar> sorry, no![16:13:42] *** tsoome <tsoome!~tsoome@20-10-196-88.dyn.estpak.ee> has quit IRC (Quit: tsoome)[16:19:03] *** fronald <fronald!~fronald@187.38.139.231> has joined #oi-dev[16:21:21] <fronald> hi[16:21:45] <fronald> anyone knows what the service mount /export/home directories in /home?[16:22:44] <fronald> what the service mount this? /home/fronald on /export/home/fronald read/write/setuid/devices/dev=4750005 on qua nov 30 13:10:39 2016[16:23:20] <igork> autofs[16:25:35] <fronald> thanks. I will reboot now, but the good news is: Oracle Database 11g running successful on OpenIndiana Hipster. I create SMF for startup instances and now is ok.[16:25:59] <fronald> SunOS Eleanor 5.11 illumos-218912f i86pc i386 i86pc Solaris[16:26:28] <fronald> i'll reboot. back later.[16:26:33] *** fronald <fronald!~fronald@187.38.139.231> has quit IRC (Quit: Leaving)[16:31:07] <alp> good to know :) I hope you have MOS account to report unexpected ORA-* ;)[16:31:35] <Agnar> hehe[16:35:02] *** fronald <fronald!~fronald@187.38.139.231> has joined #oi-dev[16:36:00] <fronald> SQL*Plus: Release 11.2.0.1.0 Production on Wed Nov 30 13:34:47 2016[16:36:01] <fronald> Copyright (c) 1982, 2009, Oracle. All rights reserved.[16:36:01] <fronald> Connected to:[16:36:01] <fronald> Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production[16:36:01] <fronald> With the Partitioning, OLAP, Data Mining and Real Application Testing options[16:36:01] <fronald> SQL>[16:36:05] <fronald> uhuuuuu \o/[16:38:39] <Agnar> turn on ASLR and tell us if it still works ;)O[16:41:40] <fronald> you talking about Address Space Layer Randomization?[16:41:54] *** tozhu <tozhu!~Thunderbi@218.88.87.183> has joined #oi-dev[16:44:11] *** jimklimov <jimklimov!~E9926362@31.7.243.238> has quit IRC (Ping timeout: 246 seconds)[16:48:10] *** tozhu <tozhu!~Thunderbi@218.88.87.183> has quit IRC (Ping timeout: 250 seconds)[16:51:07] <xenol> yeah[16:52:42] *** tsoome <tsoome!~tsoome@220-90-235-80.dyn.estpak.ee> has joined #oi-dev[16:54:11] <Agnar> fronald: yes :)[17:24:31] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has joined #oi-dev[17:27:06] *** wacki <wacki!~wacki@p200300454647180042A8F0FFFE63E17C.dip0.t-ipconnect.de> has joined #oi-dev[17:27:32] <wacki> xenol, alp: #2632 should be clean (firefox only) now.[17:28:13] <alp> merged[17:29:19] <wacki> Thanks[17:41:10] <alanc> we have to specifically disable ASLR for the DB even on Solaris, since otherwise you can't map the shared memory consistently across processes[17:41:47] <alanc> and yes, the Oracle userland gate is almost all either 32+64 or 64-bit-only now - very few 32-bit only left[17:42:18] <fronald> how do it? The sxadm not found[17:42:19] <tsoome> thats good work:)[17:46:08] <richlowe> ptribble, Agnar: did you look at the PIE stuff yet?[17:47:07] <ptribble> richlowe: sorry, still working on getting my build server up to date[17:47:10] <tsoome> alanc: hopefully at some day the AD support will get improved as well, currently the group membership expansion is absolutely horrible (I have seen like 40+ second wait for id -a etc) and ad site discovery should be able to deal with variable network masks…[17:48:18] <alanc> sorry, don't really pay much attention to AD, as all the machines I use are plain LDAP[17:48:58] <richlowe> ptribble: I'm likely to ask for at least review without y'all[17:49:13] <richlowe> if I break it, be gentle :)[17:49:23] <richlowe> alanc: still use smartcard stuff?[17:49:47] <alanc> I don't - the team who just put in all the smartcard package updates to userland does[17:49:48] <richlowe> tsoome: if you want illumos AD better, talk to gwr (and he'll complain about kerberos. a lot.)[17:50:17] <tsoome> I know[17:50:19] <richlowe> alanc: well, I don't care about using it with solaris, either, really.[17:50:29] <tsoome> just that @work we have S11[17:50:33] <richlowe> alanc: I just want to know why OSX pretends it knows about my card, but then absolutely ignores it.[17:50:35] <alanc> they claim it even works with my gdm3 packages[17:50:37] <tsoome> 11.3[17:53:01] <tsoome> richlowe: we have even more “fun” at work - as they have extended AD over countries, and only our own AD servers are resolving ip to name, which means if by any reason the “foreign” server is attempted to be used, it will fail as GSS-API needs names…[17:53:22] <richlowe> I am happily ignorant about windows, stuff :)[17:53:25] <richlowe> My method is "ask Gordon"[17:53:45] <tsoome> yea, unfortunately the microsoft and AD is now new enterprise...[17:54:04] <richlowe> I updated the computer that's basically a TV to windows 10 (actually, replaced it, since it started making horrid noises)[17:54:09] <richlowe> that was quite a shock[17:54:22] <richlowe> but everything still works as well/badly as previously[17:54:39] <tsoome> thats why I use apple tv;)[17:54:45] <richlowe> _but_, windows 10 supports decent l10n without needing a pro edition.[17:54:49] <richlowe> so it defaulted to welsh.[17:54:55] <tsoome> :D[17:55:16] <tsoome> ah, thats why you were using those welsh dates etc...[17:55:20] <tsoome> I see.[18:02:35] *** merzo <merzo!~merzo@91.217.179.122> has quit IRC (Ping timeout: 246 seconds)[18:03:01] <richlowe> browser sends cy in the accept header.[18:03:09] <richlowe> about once a month, I happen to use a site that knows what it means.[18:03:14] <richlowe> generally via horrific abuse of google translate[18:03:46] <alp> if I break puppet, who will complain?[18:19:39] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has quit IRC (Ping timeout: 268 seconds)[18:31:37] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has joined #oi-dev[18:32:01] <alp> it even works with hiera[18:47:48] <richlowe> probably xenol?[18:48:10] <xenol> no, I am ansible guy[18:48:13] <richlowe> I just wish I could convince my (pip installed) ansible to give up on python2.6[18:48:28] <xenol> hmm?[18:48:35] <xenol> I use it with 2.7 with no problems[18:49:03] <richlowe> it's probably an artifact of me never knowing which python packaging thing is which, but I can't get it to let go of 2.6[18:49:21] <richlowe> I keep meaning to uninstall all the non-packaged python stuff I have and package it[18:49:23] <richlowe> but effort.[18:49:49] <richlowe> if someone were to write a "look at the pip and easy_install'd stuff, and crap out simple userland packages" tool, that would be spectacular ;)[18:50:09] <xenol> that's not easy[18:50:38] <xenol> it would be nice if we provided python wheels on pypi for openindiana[18:50:48] <xenol> but how to persuade people?[18:51:53] <richlowe> violence and liquor.[18:52:09] <xenol> I am peaceful person :>[18:53:10] <igork> xenol: pypy will be interest[18:53:51] <xenol> pypy as a python intereper or pypi as a python package index[18:54:26] <igork> pypy can using as replacement[18:55:05] <xenol> good luck with the compatibility[18:57:50] <alp> seems to be working[19:04:12] <xenol> ok, i consider myself weird when I request some project to support OpenIndiana[19:04:34] <xenol> but after seeing issue for Plan 9 support, I am not going to feel that weird again[19:05:38] *** ptribble <ptribble!~ptribble@cpc108961-cmbg20-2-0-cust21.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)[19:06:24] <tsoome> :D[19:08:15] <richlowe> plan9 support is either easy, or absolute hell.[19:08:27] <richlowe> also, in that regard, the new VMS[19:08:51] <richlowe> back in the day everyone had some horrid corner of their source tree where the code had dollar signs in it, and sane people feared to tread.[19:09:02] <richlowe> or, for alanc's benefit "Not that long ago really, everyone..."[19:10:08] * alanc is suddenly struck by flashbacks to Apollo Domain/OS[19:11:13] <xenol> if one created an issue for DOS support, would tha be considered trolling?[19:11:44] <alanc> HPE must have the most horrible collection of source archives now - VMS, Domain/OS, HPUX, Ultrix, OSF/1, Tru64, IRIX...[19:12:33] <alanc> if only they'd bought Sun to complete the collection - well, that and waiting for IBM to sell off their AIX line and snatching it up before Lenovo does[19:15:02] <alp> xenol: what do I miss to build pcs?[19:15:10] <alp> it requires bundle...[19:15:40] <alp> is there some issue with this component?[19:28:32] <alp> OK, let's try packaging bundler...[19:37:28] <alp> we have an issue... build system efficiently supports only one ruby version[19:38:03] <alp> so far I think it's OK, but it can be an issue in future, when we want to add the same bundler, for example, for ruby-22[19:45:22] <richlowe> copy what was done for python (actually, I think Oracle already did)[19:45:25] <richlowe> so just take it from them, presumably.[19:53:37] <oibot> Project oi-userland build #2697: SUCCESS in 2 hr 23 min: https://hipster.openindiana.org/jenkins/job/oi-userland/2697/[20:32:16] <alp> bundler evidently doesn't respect Oracle's ideas about ruby layout...[20:44:26] *** wacki <wacki!~wacki@p200300454647180042A8F0FFFE63E17C.dip0.t-ipconnect.de> has quit IRC (Read error: Connection reset by peer)[21:48:29] *** jimklimov <jimklimov!~E9926362@2a00:1028:8382:5552:3155:ccd4:fbec:d8fd> has joined #oi-dev[21:52:32] *** jimklimov <jimklimov!~E9926362@2a00:1028:8382:5552:3155:ccd4:fbec:d8fd> has quit IRC (Ping timeout: 246 seconds)[22:05:29] <richlowe> well that's cute, that time osx _only_ accepted my card[22:05:32] <richlowe> didn't _say_ so, just said every password was wrong.[22:14:36] <oibot> Project oi-userland build #2698: SUCCESS in 2 hr 20 min: https://hipster.openindiana.org/jenkins/job/oi-userland/2698/[22:18:31] *** andy_js <andy_js!~andy@2.218.92.54> has quit IRC (Read error: Connection reset by peer)[22:18:41] *** andy_js <andy_js!~andy@2.218.92.54> has joined #oi-dev[22:22:01] *** WebDawg <WebDawg!~webdawg@officialg0d.com> has quit IRC (Ping timeout: 252 seconds)[22:28:19] *** tozhu <tozhu!~Thunderbi@218.88.87.183> has joined #oi-dev[22:30:06] *** WebDawg <WebDawg!~webdawg@officialg0d.com> has joined #oi-dev[22:35:05] *** tozhu <tozhu!~Thunderbi@218.88.87.183> has quit IRC (Ping timeout: 265 seconds)[22:40:50] *** merzo <merzo!~merzo@93-195-113-92.pool.ukrtel.net> has joined #oi-dev[22:58:31] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has quit IRC (Read error: Connection reset by peer)[23:00:54] *** leoric <leoric!~leoric@37.112.232.138> has joined #oi-dev[23:16:15] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has joined #oi-dev[23:48:31] *** leoric <leoric!~leoric@37.112.232.138> has quit IRC (Remote host closed the connection)[23:53:02] *** freakazoid0223 <freakazoid0223!~chatzilla@pool-173-49-14-128.phlapa.fios.verizon.net> has left #oi-dev