IRC log for #oe on 20140116

00:17.37*** join/#oe dos11 (~dos@unaffiliated/dos1)
00:25.44*** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey)
00:42.12*** join/#oe Shawn286 (~Shawn@unaffiliated/shawn156)
00:48.54*** join/#oe blindvt_ (~brf@91-119-234-102.dynamic.xdsl-line.inode.at)
00:58.10*** join/#oe Leatherface- (~leatherfa@2001:470:dd7d:0:ad74:62b3:4e66:4c08)
01:02.37*** join/#oe blindvt_ (~brf@91-119-92-143.dynamic.xdsl-line.inode.at)
01:23.30*** join/#oe anunnaki (~anunnaki@hellsgate.pl)
01:29.16*** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net)
01:30.49*** join/#oe anunnaki (~anunnaki@unaffiliated/anunnaki)
01:40.33*** join/#oe dv_ (~quassel@chello080108009040.14.11.vie.surfer.at)
01:40.58*** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey)
01:44.52tlwoernerit was good while it lasted...
01:45.42tlwoerneri found out about, and subscribed to, the automated-testing mailing list yesterday
01:45.48tlwoernerthen today...
01:46.01tlwoernerhas been unsubscribed from the automated-testing mailing list
01:48.29Crofton|workheh
01:48.34Crofton|workI just got subscribed
01:48.38Crofton|workhalstead, ping
01:54.13*** join/#oe KNERD (~KNERD@cpe-68-203-225-117.gt.res.rr.com)
02:39.40*** join/#oe nitink1 (~nitink@134.134.139.76)
03:01.44*** join/#oe silviof1 (~silviof@unaffiliated/silviof)
03:04.38*** join/#oe fray (U2FsdGVkX1@gate.crashing.org)
03:17.05*** join/#oe ohama (ohama@cicolina.org)
03:45.13*** join/#oe ohama (ohama@cicolina.org)
03:54.30*** join/#oe nitink (nitink@nat/intel/x-blonzezxucjwtdcz)
04:21.53*** join/#oe nitink (nitink@nat/intel/x-wjkfwynhoetdycch)
04:39.19*** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net)
05:09.26*** join/#oe n|west (~nathan@commlabbuild.ceat.okstate.edu)
05:25.05*** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net)
05:54.34*** join/#oe ohama (ohama@cicolina.org)
06:13.26*** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net)
06:19.30*** join/#oe kbart (~KBart@213.197.143.19)
06:28.46*** join/#oe clio (~andrej@85.159.109.222)
06:30.07*** join/#oe SorenHolm (~quassel@5634f347.rev.stofanet.dk)
07:13.54*** join/#oe florian (~fuchs@Maemo/community/contributor/florian)
07:28.04*** join/#oe SorenHolm (~quassel@cpe.ge-0-2-0-950.faaqnqu1.dk.customer.tdc.net)
07:45.07*** join/#oe thaytan (~thaytan@113.94.233.220.static.exetel.com.au)
07:57.46*** join/#oe woglinde (~henning@fb-n15-11.unbelievable-machine.net)
07:59.18*** join/#oe SorenHolm (~quassel@cpe.ge-0-2-0-950.faaqnqu1.dk.customer.tdc.net)
08:18.37*** join/#oe ant_work (~ant__@host54-128-static.10-188-b.business.telecomitalia.it)
08:22.31*** join/#oe eballetbo (~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net)
08:23.02*** join/#oe stefan_schmidt (~stefan@p4FC74D02.dip0.t-ipconnect.de)
08:25.03*** join/#oe roric (~roric@134.191.244.57)
08:26.53mckoangood morning
08:27.03*** join/#oe anarsoul (~anarsoul@178.124.194.242)
08:32.08*** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029)
08:40.57*** join/#oe n|west (~nathan@commlabbuild.ceat.okstate.edu)
08:46.52woglindehi mckoan
08:48.37*** join/#oe blitz00 (stefans@unaffiliated/blitz00)
09:09.51*** join/#oe Vutral (~ss@mirbsd/special/Vutral)
09:14.14*** join/#oe mihai (~mihai@80.97.15.150)
09:30.09*** join/#oe panda84kde (~diego@host65-246-static.10-188-b.business.telecomitalia.it)
09:30.14*** join/#oe florian_kc (~fuchs@port-217-146-132-69.static.qsc.de)
09:30.14*** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian)
09:42.54*** join/#oe bluelightning (~paul@83.217.123.106)
09:42.54*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
09:47.23*** join/#oe roxell (~roxell@c-853670d5.07-21-73746f28.cust.bredbandsbolaget.se)
09:47.24*** join/#oe roxell (~roxell@linaro/roxell)
09:50.56*** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka)
09:51.51*** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst)
09:56.18fahad_koen: ping
10:00.49bluelightningmorning all
10:01.58woglindehi bluelightning
10:02.05bluelightninghi woglinde
10:04.57*** join/#oe phdeswer (~phdeswer@194.157.27.2)
10:05.45*** join/#oe ao2 (~ao2@2001:1418:117::1)
10:06.27*** join/#oe denix (~denix@pool-108-18-138-84.washdc.fios.verizon.net)
10:07.21*** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst)
10:08.57*** join/#oe rob_w__ (~bob@93.104.205.194)
10:48.06*** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka)
10:55.27*** join/#oe roric (~roric@212.114.200.69)
11:00.09*** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029)
11:14.34pb_hi bluelightning, woglinde, all
11:14.39bluelightninghi pb_
11:15.34woglindegm pb
11:19.22Crofton|workok, today will be stupid question from me day
11:19.36Crofton|workI have an odroid-xu + lcd panel
11:19.52Crofton|worksplash seems to work
11:19.55Crofton|workbut X isn't
11:20.09Crofton|workstartx says I am missing some programs
11:20.14Crofton|workxterm twm etc
11:20.40Crofton|workhmm, would those come in via x11-base?
11:21.41jackmitchellRP: 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
11:22.44RPjackmitchell: at a guess make sure you specify git push git@... master:refs/heads/master
11:22.49jackmitchellRP: I have added git@git.openembedded.org/openembedded-web-frontpages
11:23.07RPjackmitchell: spell out refs/heads/master as the destination
11:23.16*** join/#oe diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it)
11:26.56*** join/#oe diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it)
11:44.34jackmitchellRP: git push git@git.openembedded.org/openembedded-web-frontpages master:refs/heads/master is still failing...
11:45.02jackmitchelldoes not appear to be a git repository, apparently
11:46.01*** join/#oe Crofton (~balister@pool-71-171-41-155.ronkva.east.verizon.net)
11:47.00RPjackmitchell: git push git@git.openembedded.org:openembedded-web-frontpages master:refs/heads/master ?
11:48.16jackmitchellRP: that did it, thanks
11:48.55jackmitchellRP: is it going to be added to cgit, or is there somewhere that it is viewable online?
11:49.18jackmitchellthe site it'self and code
11:51.23RPjackmitchell: 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
11:52.45jackmitchellok
11:52.55Crofton|workjackmitchell, you  and I need to talk with ka6sox
11:53.02Crofton|workHave you talked to him at all about this?
11:53.21jackmitchellI'm going to try hard to get something people are happy with so we can launch before  fosdem
11:53.37jackmitchellCrofton|work: I spoke to him a few weeks ago, but haven't spoken since
11:54.03*** join/#oe Vutral (ss@mirbsd/special/Vutral)
12:01.48pb_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.
12:02.26Crofton|workI enabeld x11 and qt4-pkgs in IMAGEFEATURES
12:02.37Crofton|workthis gets me startx that tries to start those
12:02.44pb_I don't think we even have recipes for those, at least not in oe-core.
12:03.11Crofton|workI am sort of debugging what happens to idiots trying to build x11 images :)
12:03.22Crofton|workI should file a bug
12:04.04woglindeX11 image for embedded is bad
12:04.08woglinde*g*
12:04.29Crofton|workI want to get to qt embedded eventually
12:04.45*** join/#oe Daemon404 (~who_knows@cpc50-newt31-2-0-cust38.19-3.cable.virginm.net)
12:04.47pb_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.
12:05.25Crofton|workin this case, I amde an inmage by adding x11
12:05.31XorACrofton|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
12:05.33Crofton|workI suppose I should find that file also
12:05.40Crofton|workyeah
12:05.59Crofton|workI would prefer better messages for lusers though
12:06.01pb_I don't think that just adding x11 is likely to achieve anything very useful.  You need to pick some actual programs to run.
12:06.09Crofton|workyep
12:06.31XorACrofton|work: I thought we had most of LXDE in OE
12:06.35pb_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.
12:06.52woglindepb it doesnt say how to start the xterm
12:07.10pb_woglinde: what doesn't?
12:07.18Crofton|workok
12:07.28woglinde-> core-image-x11 claims to be "A very basic X11 image with a terminal".
12:07.35Crofton|workcore-imae-x11 uses x11-base :)
12:07.38Crofton|worknot x11
12:07.41Crofton|workrebuilding
12:08.15pb_woglinde: doesn't mini-x-session start it automatically?
12:09.03*** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka)
12:09.26woglindedont know did not need it so far
12:09.49woglindebut you can start X and xterm withput xsession foo
12:09.56woglindefrom cmdline
12:13.04*** join/#oe RP (~richard@dan.rpsys.net)
12:13.36bluelightningXorA: there is a meta-lxde, but the maintainer hasn't added it to the layer index :(
12:15.31Crofton|workNext stupid question
12:15.33Crofton|workhttp://pastebin.com/LYVRHugK
12:15.48Crofton|workapparently I have a pointing device issue that will not let the server start
12:17.42pb_that is a bit odd.  does the server just hang there?
12:18.11Crofton|workseems to
12:18.23Crofton|workI do not get the background pattern I eexpect
12:19.41Crofton|workreplacing image with one with x11-base installed
12:21.01Crofton|worktrying to get a gnuradio app running on this over screen for FOSDEM
12:21.38Crofton|workthe lcd screen :)
12:21.58pb_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.
12:22.11Crofton|workyeah
12:22.19Crofton|workthe new image should start
12:22.28Crofton|workif core-image-x11 works :)
12:25.59woglindecrofton at least we can fix it in brussel
12:26.37Crofton|workheh
12:26.44Crofton|workI'd like to avoid that :)
12:26.49Crofton|workeventhough it would be fun
12:27.10Crofton|workfixing demos at the stand stresses everyone
12:32.50*** join/#oe darkschneider (~gab@93-32-63-210.ip32.fastwebnet.it)
12:36.05*** join/#oe Vutral (ss@mirbsd/special/Vutral)
12:42.09*** join/#oe tarnzwerg (~tarnzwerg@a89-183-123-59.net-htp.de)
12:42.09*** join/#oe tarnzwerg (~tarnzwerg@unaffiliated/tarnzwerg)
12:51.50Crofton|workgah no pulseaudio
12:52.05woglindecrofton sound is needed?
12:52.14Crofton|workapparently
12:52.28Crofton|workI thought the gnuradio sink would work without it, but it seems to get sucked in
12:52.46Crofton|workand the image doesn't have the binary for some reason
12:53.02Crofton|workgotta run
12:53.03Crofton|workmore later
12:56.21*** join/#oe rburton (~rburton@35.106.2.81.in-addr.arpa)
12:56.48rburtonRP: you called?
12:57.01RPpb_: rburton has just noticed that eglibc appears to dlopen libgcc in pthread_cancel. Are we missing a dependency?
12:57.32rburtonpb_: context being that something in the glib test suite calls pthread_cancel
12:57.43rburtonbut this image doesn't actually have libgcc installed
12:58.29rburtonmaybe 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)
12:59.04*** join/#oe Vutral (ss@mirbsd/special/Vutral)
12:59.15RPrburton: is pthread_cancel in ${PN} or a sub package?
12:59.45RPI guess its libpthread so it is the main package?
12:59.52rburtonyeah
12:59.58rburtonits standard posix threading
13:00.40RPrburton: I think we need to uncomment that line (and fix the comment)
13:01.35RPpb_: btw, that "appear as a file" problem was in fact a deletion race
13:04.16pb_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.
13:04.52pb_RP: there have been a variety of threads on the mailing list about it, let me find a link
13:07.09pb_http://patches.openembedded.org/patch/49633/ has some discussion
13:08.10jackmitchellRP: I had some issues with pthread_cancel
13:08.16jackmitchellI had to RDEPEND on libgcc
13:08.23rburtonturns out using gdb to break on pthread_cancel is tricky
13:11.31pb_the two irc links (from 2008!) that I mentioned in that email thread have quite a lot of background discussion on the issue.
13:12.08pb_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.
13:12.28rburtoni haven't read the irc log but splitting out libpthread seems sane
13:12.52pb_right, that would be a sane thing to do in any case.
13:14.10pb_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.
13:18.30*** join/#oe JoFo (~Jean-Fran@ptra-178-50-69-252.mobistar.be)
13:18.58woglindeuclibc lalallaaaaa
13:19.02rburtonpb_: after reading all of that i'm none the wiser :)
13:20.27pb_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.
13:21.04pb_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.
13:21.11rburtonaha
13:21.21rburtoni was about to dig out the source and check for something like that
13:22.06rburtonah called via pthread_exit()
13:22.24rburtonthat's why i didn't find it in the glib source
13:22.34pb_huh, that is a bit odd.
13:22.57pb_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.
13:23.17pb_so in that case, putting libpthread.so in its own package and making that one rdepend on libgcc_s sounds like a fine solution.
13:23.35rburtonpb_: http://pastebin.com/6XKwF66k
13:24.58pb_oh, right, yes.
13:25.26pb_I guess pthread_exit() obviously does need to unwind.
13:27.09pb_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.
13:27.30pb_so yeah, I think adding libgcc_s as a dependency for all libpthread-using programs is the right thing to do.
13:28.02*** join/#oe Daemon404 (~who_knows@pdpc/supporter/student/Daemon404)
13:28.44*** join/#oe DJWillis (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net)
13:28.45rburtonsplit the package out or magic "you linked to pthread" dependencies addition?
13:29.00pb_splitting the package up would be easiest.
13:29.50pb_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.
13:31.30rburtonbest be careful of the wrath of JaMa
13:31.53pb_breaking on-target upgrades, you mean?
13:32.00rburtonyeah
13:32.46pb_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.
13:33.55*** join/#oe n|west (~nathan@commlabbuild.ceat.okstate.edu)
13:33.56JaMapb_: why isn't it already catched by shlibs providers?
13:34.19rburtonglibc uses dlopen
13:34.24pb_JaMa: because there isn't any shared library linkage, it's dlopen()ed.
13:34.58JaMa"spot libpthread in NEEDED" then it's not there, is it?
13:35.05pb_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.
13:35.12pb_JaMa: no, that's a different library.
13:35.27pb_libpthread is linked, and is in NEEDED, and the shlibs code does do the right thing with it.
13:35.29JaMaok, I'll read more of backlog first :)
13:35.37RPJaMa: libpthread dlopens libgcc
13:35.53pb_but libpthread doesn't link -lgcc_s, does not have a NEEDED for it, and so shlibs doesn't add a dependency
13:36.16RPJaMa: currently libpthread is in libc6. We should probably split libpthread into a separate package and add an explicit libgcc dependency
13:36.31pb_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
13:37.10RPJaMa: 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
13:37.12pb_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
13:38.01pb_right, exactly.  distros can just put RDEPENDS_libc6 = "libpthread6" or something in their configuration as an interim workaround.
13:38.55JaMaafter reading backlog it looks sane and fine solution
13:39.29pb_good-o
13:39.37pb_let's make it so, then
13:39.49JaMawell assuming that opkg doesn't use libpthread :)
13:40.01pb_heh
13:40.04pb_I'm fairly sure it doesn't
13:40.29JaMabecause then it would nicely upgrade libc6 to package without libphtread and then fail to install libphtread dependency :)
13:40.56*** join/#oe tarnzwerg (~tarnzwerg@unaffiliated/tarnzwerg)
13:40.57*** join/#oe JoFo (~Jean-Fran@host-213-213-224-210.brutele.be)
13:41.06JaMabut I volunteer to test such upgrade-path once patch is on ML
13:41.17pb_excellent
13:41.24pb_lunchtime now
13:41.39JaMaassuming that I'll make shr images from master bootable again soon
13:53.15JaMais 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
13:53.25JaMaI'm adding new url to fetcher test
13:53.39*** join/#oe anunnaki (~anunnaki@hellsgate.pl)
13:55.25*** join/#oe n|west (~nathan@commlabbuild.ceat.okstate.edu)
13:55.48*** join/#oe anunnaki (~anunnaki@unaffiliated/anunnaki)
13:58.06pb_JaMa: yeah, that decodeurl regexp is teh suck
13:58.19pb_I started rewriting those bits of bitbake to use a proper url parser the other week.
13:59.59JaMawell 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
14:00.09pb_heh
14:00.38ndecyou should then ask that 'someone' to fix it ;-)
14:01.42JaMaasking 'architect' to fix it, isn't always best way to solution :)
14:02.14bluelightningJaMa: once fixed in master that sounds like a good candidate for a backport
14:02.20ndecright. let's them fix the architecture instead!
14:06.56JaMabluelightning: 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 @
14:07.24bluelightningJaMa: right, I was thinking of the regex fix
14:08.11bluelightning(not to cast any shadow over improving the URL parsing in master, of course)
14:10.03woglindeI need the backport of archiver
14:10.26woglindeunfornatly my simple try did not work because of tasks rework
14:10.58JaMawoglinde: the one from poky-contrib patchset?
14:12.09JaMabluelightning: 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) :/
14:12.54JaMaI'll test with proper url parser if it does the right thing I can at least check how they do it
14:18.17JaMapb_: testing your patch with bitbake-selftest shows failure on different URL, did it pass for you?
14:18.20JaMa- ('http', 'www.google.com', '/index.html', None, None, {})
14:18.25JaMa+ ('http', 'www.google.com', '/index.html', '', '', {})
14:19.25JaMa+ few errors before that like:
14:19.26JaMa<PROTECTED>
14:19.26JaMa<PROTECTED>
14:19.26JaMaTypeError: first argument must be string or compiled pattern
14:20.03woglindejama yes
14:21.45JaMaI was forward-porting that RFC for archiver I've sent earlier and IIRC it was only about sstate-name varflags
14:22.26JaMabut I plan to backport his patchset as well to test it in our dylan build, so I can ping you later
14:24.02faboRP: ping
14:25.24*** join/#oe Vutral (ss@mirbsd/special/Vutral)
14:28.31abellonihum, that one, shouldn't it go to oe-core ?
14:28.33abellonihttps://lists.yoctoproject.org/pipermail/poky/2014-January/009499.html
14:29.09faboRP: I've got build stuck on etex txiversion.tex
14:29.18faboRP: does it sound familiar?
14:30.14faboRP: it takes 100% CPU
14:30.33RPfabo: We've see this occasionally but don't understand why
14:30.45*** join/#oe mromero (~mromero@69.6.172.82)
14:31.21faboRP: it didn't happened before and now it's happens pretty often
14:31.38woglindejama thanks
14:37.25*** join/#oe exosyst (~exosyst@2.26.91.1)
14:48.33*** join/#oe joaohf (~jfreitas@187-072-184-065.static.ctbctelecom.com.br)
14:50.20JaMaslash is good character for separating username and location :)
15:01.44*** join/#oe anarsoul (~anarsoul@178.124.194.242)
15:13.27*** part/#oe joaohf (~jfreitas@187-072-184-065.static.ctbctelecom.com.br)
15:14.32*** join/#oe Vutral (~ss@mirbsd/special/Vutral)
15:35.34Crofton|workwhat's state of the art for figuring what triggers a recipe/package getting built?
15:36.41pb_JaMa: ah yes, right.  I did fix that as well but apparently I forgot to send an updated patch.
15:37.10pb_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.
15:38.21pb_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.
15:39.02Crofton|workqt4 wants pulseaudio?
15:40.33bluelightningCrofton|work: it depends on it directly IIRC
15:40.57Crofton|workwhat installs the pulseaudio "server"
15:41.48Crofton|workmy fedora box has /usr/bin/pulseaudio, but not the image OE builds
15:43.31rburtonCrofton: "pulseaudio-server"
15:43.38Crofton|workheh
15:43.46Crofton|workI wonder that doesn't end up in the image
15:49.55*** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst)
15:51.30*** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net)
15:55.32*** join/#oe Jefro1 (~jefro@50-0-152-82.dedicated.static.sonic.net)
15:58.17*** join/#oe Vutral (~ss@mirbsd/special/Vutral)
16:11.23JaMawoglinde: do_deploy_archives[sstate-name] = "deploy_archives"
16:11.52JaMawoglinde: 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
16:19.07*** join/#oe galak_pb (~galak@99-51-185-173.lightspeed.austtx.sbcglobal.net)
16:25.09*** join/#oe kristoffer (~kristoffe@c-28dfe555.010-30-6c6b7012.cust.bredbandsbolaget.se)
16:38.23woglindejama ?????
16:38.58woglindejama did you just copy the archiverclass?
16:39.09woglindeand removed the three otherone?
16:42.43JaMawoglinde: yes and added this line
16:43.01JaMa+ updated archiver config of course to match with new local.conf.sample.ext
16:43.09woglindehm okay thanks
16:43.13woglindeI will try it
16:43.49JaMaCurrently 6 running tasks (1474 of 10980):
16:45.24woglindejama did you add it in the and?
16:46.16woglindeups I mean at the end of archiver.bbvlass?
16:46.51*** join/#oe stefan_ (~stefan@p4FC75E8E.dip0.t-ipconnect.de)
16:48.24woglindehm seems to work
16:48.24woglindenice
16:48.44woglindeat least I do not get the python errors
16:49.47ndechalstead: 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?
16:51.28woglindejama hm okay it patches native packages too
16:51.55woglindejama args I meant it package native stuff too which is maybee not needed
16:52.46halsteadndec, You can resub at https://lists.yoctoproject.org/listinfo/automated-testing a good of users was manually unsubscribed by accident. Sorry.
16:53.17ndechalstead: ok. just did.
16:53.48ndechalstead: hmm. i got this: "An attempt was made to subscribe your address to the mailing list
16:53.49ndecautomated-testing@yoctoproject.org.  You are already subscribed to this mailing list"
16:54.01ndecso, i guess i wasn't really removed..
16:54.46woglindejama ah okay could be all tweaked
16:54.48woglindeexelcent
16:55.01*** join/#oe SorenHolm (~quassel@5634f347.rev.stofanet.dk)
16:56.30woglindetill later
17:00.23*** join/#oe Vutral (ss@mirbsd/special/Vutral)
17:05.01halsteadndec, We tried to add everyone back who was accidentally removed. We must have restored your subscription last night.
17:05.23ndecok. thanks!
17:06.42*** join/#oe n|west_ (~nathan@commlabbuild.ceat.okstate.edu)
17:10.35*** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey)
17:12.08*** join/#oe Vutral (~ss@mirbsd/special/Vutral)
17:15.03*** join/#oe SorenHolm (~quassel@5634f347.rev.stofanet.dk)
17:23.55*** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy)
17:28.27*** join/#oe WielkiTost (~dos@unaffiliated/dos1)
17:30.39*** join/#oe JoFo (~Jean-Fran@212.71.20.109.res.static.edpnet.net)
17:30.44tlwoernerso... has everyone been looking through the bugzilla to pick which bugs they're going to be working on this weekend? ;-)
17:42.19kergothI need to find the gumption to join the bug squashing first :)
17:45.44bluelightningI've been staring at my bug list
17:48.36*** join/#oe roric (~roric@port-212-202-245-234.static.qsc.de)
17:49.46*** join/#oe fray (U2FsdGVkX1@gate.crashing.org)
17:51.28tlwoernercheers
17:51.58tlwoernerand joins in the search for gumption
17:56.35*** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka)
17:59.01kergothYou 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
17:59.20kergothwould take some grunt work, going through each recipe, but that would really be nice
18:00.01tlwoernerkergoth: i'm not sure what you mean, "doc generation distro features" (?)
18:00.13mr_sciencekergoth: bring that one up again in a few weeks
18:00.27kergothI mean allow toggling documentation generation for recipes. Ideally via packageconfig at the recipe level and distro features at a config level
18:00.54tlwoernerah yes, like the xorg stuff
18:00.55kergothany use of makeinfo, help2man, etc..
18:01.12mr_sciencethe packageconfig stuff isn't all tied to distrofeatures, is it?
18:01.13kergothnot sure if we'd want one feature or multiple, e.g. for man page vs actual emitted documentation like html files
18:01.35kergothnot technically, no, but in some cases the default packageconfig value for a recipe will be set based on distro features
18:01.36mr_sciencethinking of recipes with only packageconfig options
18:01.45tlwoerneras 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
18:01.54kergoththe packageconfig would be the most important piece, distro features would just let you toggle it for all recipes rather than one at a time
18:02.39kergothtlwoerner: 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
18:02.44kergothshrugs
18:03.10tlwoerneryes, and the results could be transformed into PACKAGECONFIGs :-)
18:05.44kergothI 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
18:05.46kergothoh well..
18:07.02kergothsome days i think it'd be fun to recreate oe-core from scratch, slowly and with care
18:07.09kergothbut i may be weird that way
18:07.13kergoth:)
18:09.38tlwoernerkergoth: 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?"
18:10.03kergothhttps://gist.github.com/kergoth/8424665
18:11.04tlwoerner*bookmarked*
18:12.34kergothjust some stuff i'd be interested in seeing in such a recreation, personally
18:12.35kergothheh
18:23.33*** join/#oe KNERD|2 (~KNERD@cpe-68-203-225-117.gt.res.rr.com)
18:30.07*** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029)
18:34.10*** join/#oe hillct (~hillct@c-71-192-246-150.hsd1.ma.comcast.net)
18:43.13*** join/#oe _chase_ (~a0271661@nat/ti/x-jxwgvpwyqzlcmfqa)
18:50.12*** join/#oe mwester2 (~mwester@184-158-83-224.dyn.centurytel.net)
18:50.47*** join/#oe phdeswer (~phdeswer@a88-112-199-213.elisa-laajakaista.fi)
18:51.10*** join/#oe tlwoerner (~trevor@linaro/tlwoerner)
18:51.59*** join/#oe mwester2 (~mwester@184-158-83-224.dyn.centurytel.net)
18:57.21*** join/#oe mromero (~mromero@69.6.172.82)
18:58.03*** join/#oe nitink (~nitink@134.134.137.75)
19:07.04Crofton|workdenix, I also need to complain about meta-ti sucking
19:08.06denixCrofton|work: there is a special place for complains - it's called /dev/null :)
19:09.52Crofton|workERROR: 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.
19:09.52*** join/#oe nitink (~nitink@134.134.137.75)
19:09.53Crofton|workI just found out I should add the meta-ti layer to my sdr manifest
19:09.54Crofton|workhttps://github.com/balister/oe-gnuradio-manifest/commit/33604da98c0993b505f9e0fd870cfffee6f336eb
19:10.06denixCrofton|work: arago server has limited resources, so sometimes it refuses connections when under heavy load. I'm working on the upgrade now...
19:10.13Crofton|workok
19:10.16Crofton|workso restart build?
19:10.29denixshould work now
19:10.51*** join/#oe nitink (nitink@nat/intel/x-egkbfstapsxihtxz)
19:10.52Crofton|workk
19:11.52*** join/#oe nitink1 (~nitink@134.134.137.75)
19:13.43mr_sciencewth?
19:14.12mr_sciencethat's two days in a row this stupid laptop has gone molten-hot for no reason
19:15.16JaMaOE build on background? :)
19:16.48mr_sciencenope
19:17.04mr_scienceit's idling with all cores over 90 C
19:17.48mr_sciencerebooting should at least get back to normal for a while...
19:21.14tlwoernerCrofton|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 :-)
19:21.30Crofton|workrofl
19:21.42tlwoernershould i file a bug for it? ;-)
19:21.42Crofton|workI need to fix my upload script and bug ka6sox
19:24.58*** join/#oe mr_science (~sarnold@net-cf9a4e93.cst.impulse.net)
19:24.58*** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy)
19:27.08*** join/#oe blilly (~blilly1@c-67-161-99-149.hsd1.wa.comcast.net)
19:29.52mr_sciencehmm, maybe 3.12.6 wasn't the best choice for corei7...
19:39.07JaMa3.13.0-rc8-00005-ga6da83f sounds like much better option
19:46.36mr_sciencebecause it's more bleeding-edge?
19:52.05*** join/#oe WarheadsSE (~WarheadsS@c-50-164-31-62.hsd1.pa.comcast.net)
19:53.40WarheadsSEHello. Could someone offer insight to the choice in bitbake's sstate_install calling to oe.path.copyhardlinktree ?
19:54.58WarheadsSEI 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.
19:57.11*** join/#oe nitink (~nitink@134.134.137.71)
20:00.26WarheadsSEHrm, looks like this condition is attempted to be caught.
20:00.43WarheadsSEhttp://git.openembedded.org/openembedded-core/tree/meta/lib/oe/path.py?h=dora#n87
20:10.51mr_sciencetests both the camera system *and* lunch
20:11.01mr_sciencesimultaneously even...
20:12.51*** join/#oe KNERD|2 (~KNERD@cpe-68-203-225-117.gt.res.rr.com)
20:12.57WarheadsSEerk.. looks like its  problem with the lxc container mount issues.
20:24.13*** join/#oe woglinde (~henning@g225017108.adsl.alicedsl.de)
20:29.06*** join/#oe pb_ (~pb@mail.pbcl.net)
20:41.19*** join/#oe SorenHolm (~quassel@5634f347.rev.stofanet.dk)
20:43.34*** join/#oe tastycactus (~aaron@ip68-106-248-219.ph.ph.cox.net)
20:46.11WarheadsSEgot it.
20:47.05WarheadsSEos.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.
20:47.22WarheadsSEhave to walk the path backwards to find the mount
20:48.15kergothaha, interesting
20:48.57WarheadsSEhttp://pastie.org/pastes/8640241/text
20:49.14*** join/#oe KNERD|2 (~KNERD@cpe-68-203-225-117.gt.res.rr.com)
20:49.51WarheadsSEdigs for patch submittal
20:53.30*** join/#oe KNERD (~KNERD@cpe-68-203-225-117.gt.res.rr.com)
20:59.46*** join/#oe mwester (~mwester@184-158-83-224.dyn.centurytel.net)
20:59.48*** join/#oe mwester (~mwester@nslu2-linux/mwester)
21:04.08WarheadsSEand viola. that did indeed work.
21:04.53*** join/#oe bluelightning (~paul@167.127.187.81.in-addr.arpa)
21:04.53*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
21:05.37*** join/#oe KNERD (~KNERD@cpe-68-203-225-117.gt.res.rr.com)
21:11.06*** join/#oe JoFo (~Jean-Fran@host-213-213-224-210.brutele.be)
21:16.36*** join/#oe ant_home (~ant__@host18-227-dynamic.11-79-r.retail.telecomitalia.it)
21:21.50*** join/#oe JoFo (~Jean-Fran@host-213-213-224-210.brutele.be)
21:39.01*** join/#oe KNERD (~KNERD@24.175.253.226)
21:48.05*** join/#oe bluelightning (~paul@167.127.187.81.in-addr.arpa)
21:48.07*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
22:09.11WarheadsSEthere are days I hate the corp email server...
22:10.20ndecyou say this as if there are days, you like it ;-)
22:10.39WarheadsSEOWA has decent cert.. the TLS port does NOT.
22:10.52WarheadsSEso I have to go remembering where the hell the right way to bypass ssl cert checks is..
22:11.25WarheadsSEeitherway, patch dropped to oe-core.
22:11.48WarheadsSEeven if it screwed my message into .
22:12.24*** join/#oe GusBricker (~GusBricke@CPE-120-148-198-99.heum1.vic.bigpond.net.au)
22:14.50XorAsmtpsslcertpath = "" :-D
22:15.04WarheadsSEyeah, i remember NOW that I did it :P
22:15.11XorA.gitconfig for the win
22:15.14XorAfire and forget
22:15.34XorAalthough it took me hours of searching to find that undocument feature
22:16.52WarheadsSEyeah
22:16.58WarheadsSEtook me about 15 minutes of annoyed
22:17.11WarheadsSEthen opened the perl script and lo-and-behold
22:17.16WarheadsSEmash/win
22:17.40XorAnukes F20 for forgetting the certs
22:23.14WarheadsSEwhats the config item though
22:23.22WarheadsSEsmtp.sslcertpath?
22:23.34XorA[sendemail]
22:23.51XorAsendemail.smtpsslcertpath
22:25.00XorAwhich is annoyingly not consistant with http.sslVerify :-(
22:25.16WarheadsSEof course.
22:25.27WarheadsSEbut I would rather not disable what I don't have to.
22:26.17XorAyeah, it all seemed to work until F20
22:34.57WarheadsSEAh, well, not a Fedora user.... so
22:43.30*** join/#oe SorenHolm (~quassel@5634f347.rev.stofanet.dk)
22:52.12*** join/#oe phdeswer (~phdeswer@gprs-internet-bcee84-213.dhcp.inet.fi)
23:01.00*** join/#oe espiral (maze@unaffiliated/espiral)
23:02.45*** join/#oe nitink (nitink@nat/intel/x-aiiqqltmkenouidz)
23:13.58*** join/#oe fray (U2FsdGVkX1@gate.crashing.org)
23:14.35*** join/#oe DJWillis (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net)
23:16.37*** join/#oe scot (~scot@130.164.62.126)
23:18.12*** join/#oe Jay7 (jay@176.15.149.233)
23:35.16*** join/#oe Shawn286 (~Shawn@unaffiliated/shawn156)
23:41.42*** join/#oe bluelightning (~paul@167.127.187.81.in-addr.arpa)
23:41.42*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
23:53.48*** join/#oe ensc|w (~ensc@fedora/ensc)
23:53.59*** join/#oe nitink1 (~nitink@134.134.137.71)
23:56.34*** join/#oe JoFo (~Jean-Fran@host-213-213-224-210.brutele.be)
23:57.29*** join/#oe nitink (~nitink@134.134.137.71)
23:59.15*** join/#oe Crofton|work (~balister@pool-71-171-41-155.ronkva.east.verizon.net)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.