**** BEGIN LOGGING AT Thu May 08 02:59:58 2014 May 08 03:14:44 nm, missed the inherit part... May 08 03:19:52 no wonder, it's way past beer time May 08 07:52:19 good morning May 08 08:17:28 morning! what's the reason that bitbake doesn't like '@' to be part of OEROOT? In jenkins, if you allow builds of the same job to run concurrently, the default path to the workspace will contain '@'... May 08 08:45:06 morning all May 08 08:53:50 hey bluelightning May 08 08:53:57 hi koen May 08 09:05:50 hi bluelightning, koen, all May 08 09:06:18 hi mckoan May 08 09:06:19 hey mckoan May 08 11:24:18 what would be the correct way of forcing OE to re-download all sources? if I wipe my downloads dir, it doesn't trigger a download. if i run "bitbake -f -c fetchall core-image-minimal". I need to do this because I've enabled BB_GENERATE_MIRROR_TARBALLS and want it to make tarballs of the repos May 08 11:31:20 mago_: so, why do you need to do that? May 08 11:32:37 bluelightning, because i need the tarballs of the git repos so i can upload them to my local mirror. otherwise we are getting 404 not found because the build system is trying to access git2_somerepo.tar.gz, and then falls back to the normal mirror. my downloads/ dir only contains a git2 subdirectory with the repos May 08 11:33:34 mago_: you don't need to re-download everything to do that, just the recipes that fetch from git May 08 11:34:06 unfortunately I suspect -c fetchall -f doesn't do what you might think it should do, but -c fetch -f should May 08 11:34:10 so i'd go bitbake -f -c fetch for each pkg which uses a SCM? May 08 11:34:22 I would think so yes May 08 11:34:43 okay, thanks May 08 11:48:16 Couple months ago we managed to solve "Could not initialize GLX" error when launching Qt quick apps by adding "mesa-dri" into our IMAGE_INSTALL. I am updating a bunch of layers now and noticed that "mesa-dri" is no longer available. I have tried all kinds of mesa packages/libs but I am still getting the error. Any hints? May 08 11:49:39 muppe: mesa-dri was simply renamed to mesa May 08 11:52:18 bluelightning: ok. I read something like that from somewhere and that was the first thing I tried. When I changed mesa-dri to mesa, the generation of the root filesystem fails saying "unknown package 'mesa" and "opkg_install_cmd: Cannot install package mesa". May 08 11:52:47 it compiles/builds ok though. May 08 11:54:03 ok, I don't know a lot about the mesa packaging but you'd get that error if the package named "mesa" was empty and thus not produced May 08 11:54:16 which may be expected, I'm not sure May 08 11:56:01 so one of the packages it does produce has the file you need in it, which one I'm not sure May 08 11:56:44 I've pinged someone to come here who might be able to actually help May 08 11:56:58 :) May 08 11:57:07 mesa is a library, it's not meant to get included directly May 08 11:57:26 I am such a n00b with yocto/bitbake so any help is appreciated May 08 11:57:29 you set a preferred provider and your app will link to libgl.so May 08 11:57:45 so if you install a GL app, it drags in mesa automagically May 08 11:58:21 so that might be the reason I am seeing all the mesa files in the work directory May 08 12:00:57 muppe: having mesa issues? May 08 12:01:30 anyway, I am running a modified arago distro on ARM. Before the update we had xvfb with GLX running on the device but it seems that something is missing after I updated oe-core, meta-openembedded, meta-ti etc. to use dylan branch. May 08 12:01:36 rburton: yes, indeed. May 08 12:02:10 if you were using glx on arm, you want to build mesa-gl now May 08 12:02:27 that will give you mesa with pure-software GLX May 08 12:03:09 ok. That sounds good. Couple of months ago we manged to solve a similar issue by adding "mesa-dri" into our image. But I already learned it was renamed (and stuff) May 08 12:03:23 yeah, mesa-dri was renamed to just mesa May 08 12:03:38 and to help BSPs that just need mesa for the pure-software GLX, mesa-gl was added May 08 12:04:16 ok, I'll try with mesa-gl and see what happens. May 08 12:05:09 This hassle is all because of opengl requirement of Qt5 (QtQuick) May 08 12:06:36 and the next issue popped up: Nothing RPROVIDES 'mesa-gl' May 08 12:09:24 rburton: which thingy should provide mesa-gl then? May 08 12:15:30 muppe: oh, dylan didn't have mesa-gl May 08 12:15:45 in that case whatever used to work with mesa-dri should just say mesa May 08 12:16:47 sorry, forgot when mesa-gl was added May 08 12:16:58 When I changed mesa-dri to mesa, the generation of the root filesystem fails saying "unknown package 'mesa" and "opkg_install_cmd: Cannot install package mesa". May 08 12:31:37 muppe: that's probably because there isn't a package called mesa, and mesa-dri was practically empty. you want libmesa-gl and so on. May 08 12:31:45 have a look at what the mesa package generated May 08 12:50:40 rburton: Thanks for the tips. Had to leave the office but I will take a look at the generated libs. Do you know what is crucial for this glx issue? Xvfb seems to be initializing glx but qt quick app is not happy. (Sorry about the change in nickname. Using cell phone now) May 08 13:30:35 Marex: tbh, if you're on arm i'd look at disabling that in qt somehow May 08 13:30:51 GLX is likely to be software on that, so performance will be terrible anyway May 08 13:31:48 rburton: I think your tab completion for Marko failed as he went offline May 08 13:32:24 hm, yes, it did :) May 08 13:33:36 :-) May 08 14:55:57 koen: I added the kernel workflow doc to the new Angstrom site, so its now directly under our control May 08 14:57:09 XorA: thanks! May 08 14:57:37 koen: Crofton khem do we know any arty types to Angstromize the theme? May 08 15:45:59 koen: any objection to me adding signed-off: koen to the two numpy patches? you created them both in oe-classic circa 2008. May 08 15:47:56 * XorA always reads that as "numpty" :-) May 08 15:48:53 sounds about right May 08 16:53:14 "look, he's dropped a shoe!" "it must be a SIGN" May 08 16:53:30 lol May 08 16:53:38 and now i need to watch that film again May 08 16:53:43 * nerdboy follows the rubber chicken guy in the sailfish direction... May 08 16:54:28 rburton: me too... May 08 16:58:17 what is the container stufff that starts with a D? May 08 16:58:21 and how many hangover movies? May 08 16:59:36 Crofton: docker? May 08 17:05:07 bluelightning, thanks May 08 17:05:46 paulbarker, has a blog article about using lxc. May 08 17:23:04 rburton: no, go ahead May 08 19:16:49 someone needs to compare the qemu build time from here http://suihkulokki.blogspot.com/2014/05/arm-builder-updates.html May 08 19:16:55 with one via cross May 08 19:23:44 is that just qemu package built in 2 hrs May 08 19:24:12 I can build full X image in 52 mins that includes qemu as well May 08 19:24:22 qemu prolly takes 5 mins May 08 19:24:35 I am guessing May 08 19:24:51 :) May 08 19:25:08 why are they torturing those cute little arm machines May 08 19:25:13 rofl May 08 19:26:19 seems there is only one way of doing debian May 08 19:27:26 the systemd way May 08 19:27:54 yeah thats another one but thats intergalactic highway May 08 19:40:10 say it with me: "let's all depend on a no-so-mature piece of lennart code to boot our systems.." May 08 19:40:48 the nicest thing i can say is that makes my face wrinkle May 08 19:48:12 what's the default for FILESPATH? May 08 19:48:32 I'm using FILESEXTRAPATHS_prepend := "${THISDIR}/${MACHINE}-3.14:" May 08 19:48:48 and would like to avoid specifying it May 08 20:02:16 shouldn't it default to something like ${THISDIR}/files ? May 08 20:02:50 in a "normal" bb recipe... May 08 20:03:11 * nerdboy waits for a correction May 08 20:08:06 Crofton: never understood why people still think native arm building is a good idea May 08 20:08:31 OBS can do arm builds inside a qemu too May 08 20:16:09 rburton: because it's painfully slow on low-end devices? May 08 20:16:37 oh, i mean "because you can" ? May 08 20:16:39 i totally expected this feedback here :D May 08 20:16:53 haha May 08 20:17:04 actually some things are not bad at all May 08 20:17:25 bout the same as native-on-low-end-x86 hardware May 08 20:17:34 maybe better even May 08 20:17:39 yeah but why would you do that too, unless you had no choice May 08 20:17:53 i r a gentoo dev May 08 20:18:20 considering <$1000 buys you a rather respectable x86 desktop that can do a full sato in 1h May 08 20:18:26 and that's usually how i figure stuff out May 08 20:18:53 don't worry, i don't do gentoo-pi on the pi May 08 20:19:04 as little as possible actually... May 08 20:19:12 mostly because most debian developers don't care enough to make their packages crossbuild May 08 20:19:36 and i do have a cheap 6-core build box which is mostly busy building oe May 08 20:19:46 also 1h sato build runs what testsuites? May 08 20:19:56 suihkulokki: sure, no tests, that's just the compile. May 08 20:21:10 ptests seem to give the best of both worlds, but don't seem to be run by many May 08 20:21:26 and it goes with my orthogonal lifestyle May 08 20:21:35 * nerdboy should've started with that one May 08 20:22:10 suihkulokki, more lava May 08 20:22:12 suihkulokki: yocto qa will be automatically running them nightly "soon" May 08 20:24:17 Crofton: i had a look at doing ptest with lava - not hard May 08 20:25:02 nerdboy: I went for renting a dedicated server, fairly reasonable after accounting for how much electricity I was using running a build machine May 08 20:25:12 Crofton: but lava doesn't quite scale to the tens of thousands results ptests spew May 08 20:25:34 ptest probably needs to be agregated when ran in lava May 08 20:25:46 so glib has a single result, instead of the 10k individual tests May 08 20:26:01 that would work yes May 08 20:26:37 Crofton: i can give you a tour of some Icelandic volcanoes if you want... May 08 20:26:45 at any rate, we all need to keep working on this test stuff May 08 20:26:50 working together May 08 20:27:25 fast builds are nice.. tested builds better :) May 08 20:27:45 several large magma chambers could spew any minute... May 08 20:27:51 I should try resending my patch to add ptest support to python3, I never worked out why it failed on the autobuilder though May 08 20:28:54 something to do with the paths files were installed to, but I pretty much just copied what was in the python 2 recipe May 08 20:30:11 paulbarker: the 6-core amd was pretty cheap May 08 20:30:20 just needs a bit more ram... May 08 20:30:31 runs some vms and stuff too May 08 20:31:59 but watch the airflow... May 08 20:32:26 webkit-gtk is a potential source of thermal shutdown... May 08 20:32:46 ha May 08 20:33:16 * nerdboy not kidding May 08 20:33:22 nerdboy: I got a 4c/8t i7, 16GB RAM, 2x 3TB disks in RAID 1, 1 Gbps internet for 39EUR/month (£33, don't know the $ equivalent) May 08 20:33:31 thermal issues are now someone elses problem :) May 08 20:34:21 compare that to electric usage of around £15-£20 per month, plus the cost of hardware maintenance and upgrades May 08 20:34:27 just needed a fan in the right place to suck hot air from underneath the GPU May 08 20:34:33 paulbarker: that's interesting. i wonder how much my energy bill is for something a fair bit slower than that. where was that from? May 08 20:34:52 rburton: Hetzner in Germany May 08 20:35:04 this is still a 95W processor i believe... May 08 20:35:12 not too bad... May 08 20:35:26 https://robot.your-server.de/order/market May 08 20:35:33 I cant waste an engineering 100/hr wait for 2 hrs to finish a build thats way more expensive then xeon server eating power May 08 20:36:49 i don't have a choice until more cash flows in... May 08 20:38:37 so, another good deal is the low-power triple-core where several motherboards will let you unlock the 4th core May 08 20:39:08 ^^ the wife's recent upgrade ^^ May 08 20:39:59 khem: hey, sorry to bothering you again... ;) May 08 20:40:22 khem: have you seen the mips32r2 stuff? May 08 20:40:31 yes I did May 08 20:40:38 it looked ok to me May 08 20:40:42 what issue do oyu see May 08 20:41:51 any yet but I'm unsure about packaging/conflicts May 08 20:42:20 i.e. TUNECONFLICTS[mips32r2] = "n64 n32" May 08 20:42:42 thats ok May 08 20:42:54 mips32 does not support n64/n32 May 08 20:43:00 ABIs May 08 20:43:03 secondly, seems there is no need for the non-fpu variant May 08 20:44:40 why ? May 08 20:45:16 I have read there is always fpu on R2 May 08 20:45:24 ? May 08 20:45:34 http://pastebin.com/RHqZLTuh May 08 20:45:43 anyway, this is the tune file now May 08 20:46:04 should I send a patch to oe-core ML? May 08 20:46:26 any obvious error? May 08 20:47:46 well, yes... "Enable mips32 .."-> mips32r2 May 08 20:51:56 ant_home: OK yes r2 does have FPU May 08 20:52:06 so you can disable nofpu May 08 20:53:14 ok May 08 20:53:39 looks ok to me May 08 20:56:00 great, thx May 08 21:44:19 JaMa|Off: now all B != S patches I sent are applied do you have them queued up or should I resend May 08 21:45:59 is there one of those for sqlite? May 08 21:46:20 khem: binaries mips32r2el running ok on device May 08 21:46:42 ant___: cool May 08 21:46:53 nerdboy: no May 08 21:47:10 make: *** No rule to make target `Makefile.linux-gcc'. Stop. May 08 21:47:21 seems suspicious... May 08 21:47:47 just hit that on last night's master pull May 08 21:53:32 khem: all from you should be applied now May 08 21:53:39 khem: few from other people are in master-next May 08 21:57:53 * nerdboy gets jiggy with git merge May 08 22:11:49 kergoth: is your MentorPoky just a mirror, or staging area, or? May 08 22:12:31 MentorPoky? you mean the poky that's under the MentorEmbedded org on github? May 08 22:12:38 yeah May 08 22:13:29 I think we had a couple cases where we needed a fork to hold cherry picks from master for release updates. mainly bitbake, since you can't very well override that ini a layer May 08 22:13:52 we don't use that for anything else. any changes we have that are intended for upstream are staged in the meta-mentor-staging layer under meta-mentor May 08 22:14:37 how do you deal with pulling in the same changes from upstream? May 08 22:15:07 reset/revert/other? May 08 22:15:48 adhoc? May 08 22:15:54 you lost me. if a change in meta-mentor-staging hits upstream, we rm our bbappend and call it a day May 08 22:16:22 no need to back up history, just remove the content and commit. revert is an option, too, if i feel like tracking down the original commit May 08 22:16:23 okay, so your changes are added that way? May 08 22:16:53 how else would they be added? as i said, it's in a layer. there are only so many ways a layer can add changes on top of oe-core May 08 22:16:53 ie, as appends so you can do exactly that? May 08 22:17:12 i meant in the poky mirror part May 08 22:17:16 we don't maintain long term poky forks. everything goes in our layers, the only exception is bitbake changes when we're on a release May 08 22:17:21 i just told you, we don't stage changes in the poky fork May 08 22:17:39 its only for releases, for changes we couldn't do in a layer so were forced to fork, e.g. bitbake fixes May 08 22:18:03 and thats isolated to the release branch in question, so that branch never has to pull down newer content from upstream May 08 22:19:13 okay, that makes more sense... May 08 22:19:52 long term fork maintenance is a recipe for pain :) May 08 22:20:06 best to avoid it entirely where possible May 08 22:21:35 i'm just talking "place to stage fixes locally and pull from upstream" May 08 22:22:01 sounds simple May 08 22:22:18 like i said, we do that in a layer with bbappends or class overrides. you can't exactly cherry pick to poky, since the form is different, but it's not too painful May 08 22:22:46 and its nicely self contained. since all the staged changes are in their own layer, its easy to distribute submission upstream amongst the internal team, they don't have to determine what should go and what not May 08 22:23:10 but there's lots of ways of doing it, depends on your needs May 08 22:24:31 i think what i should do is stage/patch/mail/reset/pull May 08 22:24:52 otherwise not so clean... May 08 22:25:49 i don't put the bits i intend to go upstream into an oe-core repo until i'm seconds from git send-emailing it. pull the bits over from the layer, check them in, clean up, sanity check, push to a branch on my fork, submit the request / send-email the patches, then kill the local repo and go back to using the normal layers until it gets merged/accepted May 08 22:28:23 kergoth: in this case it's my repo with an upstream remote for pulling May 08 22:28:37 pretty close more-or-less... **** ENDING LOGGING AT Fri May 09 03:00:01 2014