December 27, 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 | 31 | >
December 27, 2016 [01:01:24] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[01:09:58] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Ping timeout: 250 seconds)[01:16:57] <oibot> Project illumos-gate build #4729: STILL FAILING in 11 min: https://hipster.openindiana.org/jenkins/job/illumos-gate/4729/[01:18:42] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[01:29:52] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Ping timeout: 256 seconds)[01:41:02] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[01:44:35] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Remote host closed the connection)[01:44:57] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[01:48:34] *** merzo <merzo!~merzo@93-60-92-178.pool.ukrtel.net> has quit IRC (Ping timeout: 256 seconds)[01:53:01] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Ping timeout: 258 seconds)[01:54:44] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[01:59:17] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Remote host closed the connection)[02:02:59] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[02:38:17] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Ping timeout: 268 seconds)[02:45:02] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[02:58:48] *** v_a_b <v_a_b!~volker@p54BC749E.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 245 seconds)[03:02:36] *** v_a_b <v_a_b!~volker@p54BC78EE.dip0.t-ipconnect.de> has joined #oi-dev[03:24:20] *** alanc <alanc!~alanc@inet-hqmc05-o.oracle.com> has quit IRC (Remote host closed the connection)[03:24:38] *** alanc <alanc!~alanc@inet-hqmc05-o.oracle.com> has joined #oi-dev[03:24:38] *** ChanServ sets mode: +o alanc[03:37:57] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Ping timeout: 248 seconds)[03:40:03] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[03:57:46] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Remote host closed the connection)[03:57:55] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[04:11:23] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Ping timeout: 258 seconds)[04:13:06] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[04:14:18] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Client Quit)[04:39:13] *** pjama1 <pjama1!~pjama@c211-31-51-11.kelvn3.qld.optusnet.com.au> has joined #oi-dev[04:41:24] *** pjama <pjama!~pjama@c211-31-52-41.kelvn3.qld.optusnet.com.au> has quit IRC (Ping timeout: 256 seconds)[08:07:05] <alp> wacki: install system/header/header-drm[08:07:41] <alp> richlowe: well, it's some incorporation mess which I still don't understand. Perhaps, related to recent build number bump[08:13:07] *** tozhu <tozhu!~Thunderbi@118.115.179.40> has joined #oi-dev[08:15:24] *** tozhu <tozhu!~Thunderbi@118.115.179.40> has quit IRC (Read error: Connection reset by peer)[08:17:21] *** tozhu <tozhu!~Thunderbi@119.145.5.7> has joined #oi-dev[08:19:42] *** FuntDobraWork <FuntDobraWork!~FuntDobra@212.34.53.106> has joined #oi-dev[08:38:36] *** wackni <wackni!~wacki@p548FF7A3.dip0.t-ipconnect.de> has joined #oi-dev[08:40:07] <wackni> alp: It is installed: https://paste.ec/paste/vU5breDC#VIGIjwGziTHSUaTz-mgHHpHBFtUvcOhAFHc+rNEBP5I[08:40:22] *** wackni is now known as wacki[08:41:19] <wacki> Packages that formerly built have now problems...[08:42:01] <alp> will look at it a bit later[08:42:30] <alp> now trying to fix mess with userland-incorporation[08:45:11] <wacki> Ok[08:51:37] *** tsoome <tsoome!~tsoome@220-90-235-80.dyn.estpak.ee> has quit IRC (Ping timeout: 258 seconds)[09:05:25] *** rk4n3 <rk4n3!~rk4n3@24-159-210-156.static.roch.mn.charter.com> has quit IRC (Ping timeout: 248 seconds)[09:13:39] *** tsoome <tsoome!~tsoome@149-11-196-88.dyn.estpak.ee> has joined #oi-dev[09:26:11] *** rk4n3 <rk4n3!~rk4n3@24-159-210-156.static.roch.mn.charter.com> has joined #oi-dev[10:22:58] *** js <js!~js@ip-95-222-169-90.hsi15.unitymediagroup.de> has quit IRC (Ping timeout: 245 seconds)[11:00:12] *** tozhu <tozhu!~Thunderbi@119.145.5.7> has quit IRC (Quit: tozhu)[11:00:31] *** tozhu <tozhu!~Thunderbi@119.145.5.7> has joined #oi-dev[11:02:12] *** tozhu <tozhu!~Thunderbi@119.145.5.7> has quit IRC (Client Quit)[11:04:38] *** tozhu <tozhu!~Thunderbi@119.145.5.7> has joined #oi-dev[11:04:40] *** merzo <merzo!~merzo@92.60.189.225> has joined #oi-dev[11:15:53] *** tozhu1 <tozhu1!~Thunderbi@218.17.157.199> has joined #oi-dev[11:16:14] *** wacki <wacki!~wacki@p548FF7A3.dip0.t-ipconnect.de> has quit IRC (Quit: Lingo: www.lingoirc.com)[11:16:57] *** nikolam <nikolam!~nikolam@unaffiliated/nikolam> has joined #oi-dev[11:17:39] *** tozhu <tozhu!~Thunderbi@119.145.5.7> has quit IRC (Ping timeout: 258 seconds)[11:20:17] *** tozhu1 <tozhu1!~Thunderbi@218.17.157.199> has quit IRC (Ping timeout: 260 seconds)[11:22:06] <denk> btw, guys, I just understood once more issue in mysql/mariadb SMF/config[11:22:28] <denk> plugin dir depends of the enable_64bit property[11:23:31] <denk> i.e. it should be lib/plugin for 32 and lib/amd64/plugin for 64 bits version[11:24:20] <denk> and --plugin-dir=XXX option for the script[11:29:26] *** tozhu <tozhu!~Thunderbi@218.17.157.199> has joined #oi-dev[11:30:12] <denk> huh... inside the binary it is already set, I'm wrong[11:41:01] *** tozhu1 <tozhu1!~Thunderbi@119.145.5.7> has joined #oi-dev[11:44:19] <alp> wacki: yes, there's issue with libdrm. libdrm.pc is wrong[11:44:42] *** tozhu <tozhu!~Thunderbi@218.17.157.199> has quit IRC (Ping timeout: 256 seconds)[11:44:44] *** tozhu1 is now known as tozhu[11:45:28] *** tozhu <tozhu!~Thunderbi@119.145.5.7> has quit IRC (Client Quit)[11:45:43] *** tozhu <tozhu!~Thunderbi@119.145.5.7> has joined #oi-dev[11:46:15] <alp> it's illumos-gfx issue[11:46:22] *** tozhu <tozhu!~Thunderbi@119.145.5.7> has quit IRC (Client Quit)[11:49:00] *** tozhu <tozhu!~Thunderbi@119.145.5.7> has joined #oi-dev[11:49:51] *** tozhu <tozhu!~Thunderbi@119.145.5.7> has quit IRC (Client Quit)[11:52:35] *** andy_js <andy_js!~andy@AAmiens-152-1-49-136.w83-198.abo.wanadoo.fr> has joined #oi-dev[12:02:19] <denk> guys, a user in my host wants another locale, is it possible to add it to a repo?[12:02:35] <denk> "... [23:42] -|- init: failed to set locale to uk_UA.koi8-u, reverted to default C!"[12:03:24] <denk> it's his ircd server[12:05:26] <alp> likely you have to fix it in illumos-gate[12:06:14] <alp> denk: look at https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/localedef/Makefile[12:06:42] <alp> I see some KOI8-U data in usr/src/cmd/localedef/data[12:08:15] <denk> if you need something, do it yourself, I will tell it to him :)[12:08:18] <denk> thanks[12:08:27] <tsoome> jsut push him to utf-8:P[12:08:31] <tsoome> just*[12:11:26] <denk> tsoome: I don't know the reason why he chose this locale[12:12:19] <tsoome> :) probably he is just used to[12:24:34] *** andy_js <andy_js!~andy@AAmiens-152-1-49-136.w83-198.abo.wanadoo.fr> has quit IRC (Quit: andy_js)[12:37:06] *** tozhu <tozhu!~Thunderbi@218.17.157.199> has joined #oi-dev[12:45:10] <oibot> Project oi-userland build #2753: SUCCESS in 2 hr 58 min: https://hipster.openindiana.org/jenkins/job/oi-userland/2753/[12:45:22] <alp> What?[12:46:15] <alp> xenol: we have a problem with jenkins job[12:46:28] <alp> xenol: it reports success even on failure[12:50:24] *** tozhu1 <tozhu1!~Thunderbi@218.17.158.93> has joined #oi-dev[12:54:16] *** tozhu <tozhu!~Thunderbi@218.17.157.199> has quit IRC (Ping timeout: 268 seconds)[12:54:16] *** tozhu1 is now known as tozhu[12:57:47] *** wacki <wacki!~wacki@p548FF7A3.dip0.t-ipconnect.de> has joined #oi-dev[13:07:01] *** tozhu <tozhu!~Thunderbi@218.17.158.93> has quit IRC (Ping timeout: 248 seconds)[13:11:01] <wacki> alp: Thanks for looking at the problems. I haven't been able yet to determine the root cause.[13:27:20] <alp> tsoome: hi[13:28:03] <alp> tsoome: can you find quick example how do I set dependency of one library on another in illumos-gate-style build system[13:28:29] <alp> I mean something like - to build libA libB should be installed in proto area[13:28:49] <alp> or perhaps someone else :)[13:33:24] <tsoome> usr/src/lib/Makefile.lib has the dependency tree[13:34:06] <tsoome> no, remove .lib :)[13:34:22] <tsoome> the usr/src/lib/Makefile is the correct one[13:35:59] <alp> I see : basedeps: libc libm libmd libmp libnsl libnvpair libsocket[13:35:59] <alp> basedeps := TARGET=install[13:36:12] <alp> need something similar in gfx-drm[13:36:17] <tsoome> yea and below are individual ones[13:40:26] <alp> we need some more developer building gfx-drm to spot such issues[13:40:56] <alp> perhaps, time to remove drm from illumos-gate completely? In such way we'll get Gabriele[13:43:16] <tsoome> the question is, does such removal affect distributions which are currently not using new drm code…[13:47:14] <alp> at least omnios ships drm[13:47:55] <alp> if it's included in some basic installation, then yes[14:02:21] <alp> and using cw in gfx-drm.... is strange[14:06:03] <alp> and now drm-tests don't depend on libkms...[14:43:47] *** nikolam <nikolam!~nikolam@unaffiliated/nikolam> has quit IRC (Quit: Leaving)[14:44:09] *** merzo_ <merzo_!~merzo@92.60.189.225> has joined #oi-dev[14:46:33] *** merzo <merzo!~merzo@92.60.189.225> has quit IRC (Ping timeout: 265 seconds)[14:47:38] <alp> I know why this issue doesn't appear in oi-userland gfx-drm build[14:48:02] <alp> it seems, when I use bldenv, some of my environment confuses build[14:48:32] <alp> and oi-userland Makefile uses env -i[14:49:03] <alp> also default env file seems to use debug env...[14:51:34] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[14:57:49] *** FuntDobraWork <FuntDobraWork!~FuntDobra@212.34.53.106> has quit IRC (Quit: leaving)[15:03:52] *** andy_js <andy_js!~andy@AAmiens-152-1-49-136.w83-198.abo.wanadoo.fr> has joined #oi-dev[15:11:10] <alp> and component uses make install, not make...[15:14:22] <alp> PCLIBDIR=/usr/lib/xorg[15:14:22] <alp> $(BUILD64)PCLIBDIR=/usr/lib/xorg/$(MACH64)[15:14:38] <alp> this always set one PCLIBDIR...[15:27:31] <oibot> Project oi-userland build #2754: SUCCESS in 2 hr 42 min: https://hipster.openindiana.org/jenkins/job/oi-userland/2754/[15:42:09] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Ping timeout: 258 seconds)[15:42:34] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[15:43:49] <alp> I hate incorporations[15:49:30] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Ping timeout: 256 seconds)[15:55:39] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[16:06:53] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Remote host closed the connection)[16:07:12] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[16:10:10] *** andy_js <andy_js!~andy@AAmiens-152-1-49-136.w83-198.abo.wanadoo.fr> has quit IRC (Quit: andy_js)[16:14:04] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Ping timeout: 268 seconds)[16:21:40] <alp> gwr: https://www.illumos.org/issues/7692[16:27:08] *** igork <igork!~igork@91.204.58.44> has quit IRC (Read error: Connection reset by peer)[16:27:20] *** igork <igork!~igork@91.204.58.44> has joined #oi-dev[16:32:27] *** tsoome <tsoome!~tsoome@149-11-196-88.dyn.estpak.ee> has quit IRC (Quit: tsoome)[16:37:16] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev[16:42:04] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has quit IRC (Ping timeout: 265 seconds)[17:02:05] *** tsoome <tsoome!~tsoome@220-90-235-80.dyn.estpak.ee> has joined #oi-dev[17:03:49] *** leoric <leoric!~leoric@46.147.243.108> has joined #oi-dev[17:36:12] *** merzo_ <merzo_!~merzo@92.60.189.225> has quit IRC (Ping timeout: 265 seconds)[17:54:32] *** MarcelT <MarcelT!~marcel@85-135-221-159.adsl.slovanet.sk> has joined #oi-dev[18:26:39] *** MarcelT <MarcelT!~marcel@85-135-221-159.adsl.slovanet.sk> has quit IRC (Ping timeout: 268 seconds)[18:27:57] *** MarcelT <MarcelT!~marcel@85-135-149-26.adsl.slovanet.sk> has joined #oi-dev[19:06:39] <oibot> Project oi-userland build #2755: SUCCESS in 3 hr 0 min: https://hipster.openindiana.org/jenkins/job/oi-userland/2755/[20:12:18] <xenol> tomww: here?[20:12:22] <xenol> alp: hmm?[20:14:10] <leoric> ?[20:14:58] <leoric> something is terribly wrong with versioned (PYV and similar manifests)[20:15:27] <leoric> components sometimes are not republished (or published partially)[20:16:20] <leoric> So, when we change BUILD_NUMBER we can get big kaboom[20:16:48] <leoric> Somehow even gmake clean in components/python/* didn't help[20:17:35] <leoric> perhaps, you just should publish them twice ;)[20:31:29] <xenol> Carrie Fisher is dead. Really, this is the worst year..[20:31:56] <xenol> like it wasn't enough with the other events that happened[20:43:19] <tsoome> you really do not want to know how many people do die every year;)[20:46:21] <leoric> google finds http://www.medindia.net/patients/calculators/world-death-clock.asp[20:49:26] <richlowe> leoric: does clobber help?[20:49:46] <richlowe> clean in userland always removes slightly less than I expected.[20:50:30] <leoric> looking at republishing all python/* once again[20:51:00] <leoric> clobber should just remove component archives....[20:51:33] <leoric> and it's not good[20:57:52] <richlowe> I have components (my own fault?) where remnants of build/ survive a 'clean'[20:59:18] <wacki> If packages got a new version old versions will survive a clean.[21:01:25] <leoric> wacki: yes, but it's because how jenkins works - it doesn't run gmake clean[21:01:33] <leoric> wacki: just publish[21:01:44] <wacki> I am not using Jenkins yet.[21:02:14] <leoric> richlowe: I see $(RM) -r $(SOURCE_DIR) $(BUILD_DIR) in setup.py.mk , so it shouldn't be a problem[21:02:52] <leoric> wacki: so I don't understand you. I thought about our build server.[21:02:58] <wacki> That's a problem if you change the version of a package. $(SOURCE_DIR) will change.[21:03:20] <leoric> yes, there are remnants of old sources all over the place[21:03:25] <wacki> No, it's a general problem. Not only on the build server.[21:03:33] <leoric> yes[21:04:07] <wacki> So, before changing a version an automatic gmake clean would help.[21:04:51] <leoric> we can't do it now, as to find out what's changed, we have to checkout new version[21:05:00] <leoric> and this will update SOURCE_DIR[21:05:35] <leoric> in ideal world jenkins would do build in clean zone and environment, and we wouldn't have such problem[21:05:38] <wacki> Yes. It's not that easy :-([21:06:26] <wacki> I just built everything during the last days. That's the reason I found the problem with drm.[21:06:47] <leoric> that's good[21:06:56] <wacki> A lot of other packages fail to build or publish on my server.[21:07:08] <wacki> Alas a complete rebuild takes several days.[21:07:40] <leoric> the issue is that I'm not sure if I can commit fix to gfx-drm without gwr. In any case I'd like to get some review...[21:07:44] <wacki> The use of COMPONENT_BUILD_GMAKE_ARGS has its own problems for some packages.[21:08:33] <wacki> Of course, as I already wrote, I haven't been able to find the root cause let alone fix it.[21:09:25] <leoric> we had one issue with it earlier, when it accidentally was removed from justmake.mk[21:09:56] <leoric> don't see anything suspicious in current head[21:10:03] <leoric> what's problem with it?[21:10:22] <wacki> BTW: There are some packages with dependency problems regarding libGL.so.[21:10:56] <wacki> Some packages only build without COMPONENT_BUILD_GMAKE_ARGS set.[21:11:16] <leoric> jenkins doesn't set COMPONENT_BUILD_GMAKE_ARGS[21:11:25] <leoric> it sets COMPONENT_BUILD_ARGS[21:11:39] <leoric> (if you speak about -jN)[21:12:08] <wacki> There seem to be a race condition. Interestingly I have different results on different machines (my server is an old HP DL380G7 with 2*E5645 and 144GB RAM, my workstation is an HP Z420 with an E5-1620V2 and 32 GB RAM).[21:12:36] <wacki> On the server I formerly used -j18 and on my ws -j8.[21:12:43] <leoric> (and yes, it's perhaps right, but decision was already made, and if someone wants to fix it, this will require some work)[21:13:07] <wacki> Some packages didn't publish on the server but do on the ws and vice versa.[21:13:15] <richlowe> isn't 3rd party software great?[21:13:35] <leoric> do you set COMPONENT_BUILD_GMAKE_ARGS to -jN?[21:13:41] <leoric> or COMPONENT_BUILD_ARGS ?[21:14:07] <wacki> So I removed it. But that results in very long build times.[21:14:14] <leoric> as we 'fix' COMPONENT_BUILD_ARGS for software known to be broken with -jN[21:14:20] <xenol> tsoome: but this wasn't an ordinary person, this was a star wars cast![21:14:52] <wacki> COMPONENT_BUILD_GMAKE_ARGS. As far as I remember xenol recommended not to use COMPONENT_BUILD_ARGS.[21:14:54] <tsoome> but, guess who is still alive?;)[21:15:12] <xenol> tsoome: the rest[21:15:35] <wacki> COMPONENT_BUILD_ARGS is unset for some packages as I found out.[21:15:40] <leoric> yes[21:15:43] <tsoome> https://www.facebook.com/keith.fn.richards/photos/pb.145900995430510.-2207520000.1482869729./1357715200915744/?type=3&theater[21:15:44] <leoric> this is it[21:16:36] <wacki> So, it's recommended to set COMPONENT_BUILD_ARGS but not COMPONENT_BUILD_GMAKE_ARGS?[21:16:59] <leoric> it's a supported way[21:17:21] <leoric> and yes, the choice of variable was wrong[21:17:30] <wacki> So it seems as if I misunderstood xenol.[21:17:56] <xenol> hmm?[21:18:13] <wacki> BTW: Would it be possible to run several package builds in parallel?[21:18:14] <xenol> I use COMPONENT_BUILD_GMAKE_ARGS to pass -j10[21:18:19] <xenol> yes[21:18:36] <leoric> xenol: try building perl ;)[21:19:25] <wacki> Using COMPONENT_BUILD_GMAKE_ARGS fails for some packages. For some time I changed the Makefiles to unset it. But that was tedious work.[21:19:28] <xenol> it doesn't work everywhere[21:19:42] <xenol> but I am not responsible for the fact that perl build system doesn't handle it[21:20:00] <wacki> mongodb build failed on my both machines.[21:20:00] <leoric> I mean, build server uses COMPONENT_BUILD_ARGS for this[21:20:25] <leoric> and as it does, this was fixed for known-to-fail components[21:20:54] <leoric> wacki: in what way?[21:21:29] <wacki> When using COMPONENT_BUILD_GMAKE_ARGS=-j18 (-j8 on my ws).[21:21:42] <xenol> leoric: you are mixing things[21:21:47] <wacki> If I remember correctly it fails during link phase.[21:21:51] <xenol> for building multiple components in parallel -> export COMPONENT_BUILD_ARGS=-j4[21:22:26] <xenol> if I want to build one component with multiple jobs -> export COMPONENT_BUILD_GMAKE_ARGS=-j10[21:22:42] <xenol> or what am I misunderstanding?[21:23:17] <leoric> we have '$(GMAKE) $(COMPONENT_BUILD_GMAKE_ARGS) $(COMPONENT_BUILD_ARGS) $(COMPONENT_BUILD_TARGETS)' in our make-rules/*.mk[21:23:34] <leoric> so both are passed to gmake[21:23:43] <wacki> xenol: You mean COMPONENT_BUILD_GMAKE_ARGS should be unset instead of COMPONENT_BUILD_ARGS in failing packages?[21:24:23] <leoric> but COMPONENT_BUILD_ARGS are undefined when parallel build fails, as -jN (4?) used on build server[21:24:35] <xenol> wacki: if component fails because of multiple make jobs, any variable containing -jX should be unset[21:25:27] <wacki> I am puzzled.[21:25:33] <leoric> but please, don't create PRs, unsetting COMPONENT_BUILD_GMAKE_ARGS ;)[21:25:54] <leoric> everything is clear ;)[21:26:29] <wacki> So what is the difference between COMPONENT_BUILD_ARGS and COMPONENT_BUILD_GMAKE_ARGS?[21:26:42] <xenol> good question :)[21:27:04] <wacki> And when to use what?[21:28:32] <leoric> COMPONENT_BUILD_ARGS are passed not only to $(GMAKE) , but also to ant, for example[21:28:32] <wacki> One thing I can say at least: Setting COMPONENT_BUILD_GMAKE_ARGS=j18 fails several package builds.[21:29:03] <leoric> so, it shouldn't have been used the way it's used now[21:29:10] <leoric> but it's used as it's used[21:29:18] <wacki> I am not familiar with ant. Do gmake and ant share options?[21:29:31] <leoric> unlikely[21:30:00] <wacki> So passing COMPONENT_BUILD_ARGS to both of them doesn't make sense to me.[21:31:11] <leoric> yes, this is why we have 'COMPONENT_BUILD_ARGS =' in each ant.mk-based makefile[21:31:36] <leoric> briefly: this was a wrong choice initially[21:32:47] <leoric> but now it's supported by many crutches, so if you don't want to look through all this crutches and fix them, use it ;)[21:34:55] <wacki> So, if I want a parallel build (in packages) I should set COMPONENT_BUILD_ARGS=-jN and don't use COMPONENT_BUILD_GMAKE_ARGS?[21:35:26] <leoric> wacki: or you could convince xenol to fix it...[21:35:32] <leoric> wacki: yes[21:36:42] <wacki> Ok, and building multiple packages in parallel is not supported by our build system?[21:37:05] <leoric> it will do it[21:37:58] <wacki> COMPONENT_BUILD_ARGS will do both, parallel build in a package and parallel builds of packages?[21:38:08] <leoric> don't think so[21:38:33] <leoric> but you can pass -jN just to gmake publish in top level dir[21:39:12] <leoric> jenkins has export COMPONENT_BUILD_ARGS=-j4[21:39:19] <leoric> gmake publish -j8 -k[21:39:36] <leoric> xenol: BTW, why -k ???[21:39:42] <wacki> Ah ok, I will try that next time I will rebuild everything. For this month my power bill is high enough from the last run...[21:39:43] <leoric> xenol: BTW, when did it appear ???[21:39:54] <xenol> it was there from the beginning I think[21:40:58] <leoric> I'm just surprised that jenkins job doesn't finish with failure when gmake publish fails[21:41:01] <leoric> (as now)[21:42:38] <leoric> will it exit with 0 when something is wrong?[21:42:45] <xenol> it should[21:43:08] <leoric> do we want it?[21:43:41] <xenol> I dont mind[21:43:55] <leoric> I see advantages (and disadvantages) in both cases, I just don't know[21:45:16] <xenol> Use the Force, leoric.[21:46:40] <wacki> Hehe[21:49:01] <xenol> anyone except tomww at 33c3?[22:01:54] <leoric> wow...[22:02:08] <leoric> Packages to update: 260[22:02:08] <leoric> Services to change: 5[22:02:15] <leoric> finally I made this[22:02:43] <xenol> powerful jedi you will become ;)[22:02:54] <leoric> xenol: any desire to look at drm patch?[22:03:03] <leoric> (gfx-drm)[22:03:19] <xenol> from the email?[22:03:22] <leoric> yes[22:03:39] <xenol> sure[22:04:04] <leoric> I don't know if I can push it without Gordon, but to try I want at least one reviewer[22:04:19] <xenol> the change looks good[22:04:39] <xenol> but again, I haven't read the whole DRM code, so..[22:04:44] <xenol> I would wait for gordon[22:05:40] <tsoome> depends on how big is the problem it is trying to solve.[22:05:41] <leoric> OK, let's wait for one day... I'm worried, because it breaks oi-userland build[22:06:32] <leoric> tsoome: https://www.illumos.org/issues/7692[22:06:56] <tsoome> also note that the commits are not written in stone. you can reverse them, you can update them. having buffer time is goos anyhow.[22:07:02] <tsoome> good*[22:07:30] <leoric> Some headers in gfx-drm were moved from /usr/include/libdrm to /usr/include/drm and I didn't catch it.[22:07:53] <leoric> Also it delivers 64-bit libdir in pkgconfig file[22:08:45] <tsoome> ah, last one is from 64bit only solaris project, i guess;)[22:09:13] <leoric> no, just from insufficient testing[22:09:28] <tsoome> that for sure[22:10:13] <xenol> Alasdairrr: here?[22:14:47] <leoric> xenol: when you have free time and nothing to do, you can look at https://github.com/OpenIndiana/oi-userland/pull/2700 ;)[22:15:35] *** leoric <leoric!~leoric@46.147.243.108> has quit IRC (Remote host closed the connection)[22:15:42] <xenol> today, before I go to bed[22:15:47] <xenol> bye..[22:24:13] *** mooney <mooney!~mooney@dogbert.cc.ndsu.NoDak.edu> has joined #oi-dev[22:25:11] *** wacki <wacki!~wacki@p548FF7A3.dip0.t-ipconnect.de> has left #oi-dev[22:30:56] *** MarcelT <MarcelT!~marcel@85-135-149-26.adsl.slovanet.sk> has quit IRC (Remote host closed the connection)[23:13:53] *** tozhu <tozhu!~Thunderbi@112.95.165.146> has joined #oi-dev