**** BEGIN LOGGING AT Fri Jul 18 03:00:00 2014 Jul 18 06:43:37 JaMa: I've been signing patches as RP for years, they need a sign of authorship, not an SOB line, people just find an SOB line easier Jul 18 06:54:17 RP: do you have had any new idea about the meta-openembedded layers? Now it is half split and half under meta-oe Jul 18 06:55:46 we all appreciate granularity but I'm having the feeling there are too many layers in the meta-openembedded Jul 18 06:56:29 some one level beyond, under meta-oe Jul 18 06:56:56 I thought the plan was to extract all and empty/remove meta-oe subòayer Jul 18 07:20:20 ant_work: I suspect spreading it among several maintainers is a good thing Jul 18 07:20:41 ant_work: certainly meta-oe seems more "run down" than the other parts of meta-openembedded, at least with the issues I'm trying to fix Jul 18 07:21:17 heh, as you say we need one maintainer per-layer ;) Jul 18 07:21:21 at least Jul 18 07:28:06 imho we could expunge the recipes-navigation immediately Jul 18 07:29:33 with more care, even meta-multimedia Jul 18 07:29:55 could host meta-oe's recipes-multimedia Jul 18 08:10:00 Hi all Jul 18 08:25:01 First time here and don’t know if this is the right place to ask… Well has anyone managed to include Java in a yocto build? Jul 18 08:27:16 AlexanderTheLost: https://github.com/woglinde/meta-java should probably do fine Jul 18 08:28:07 I’m trying that one. Got many problems :-( Jul 18 08:28:40 "got many problems" is not really a helpful problem description or error message... Jul 18 08:29:38 the “meta-openembedded/meta-oe” layer (master branch) had a missing environment variable Jul 18 08:30:28 after fixing that Jul 18 08:30:57 HOB crashes with a huge stacktrace of an ExpansionError Jul 18 08:32:04 what about building manually without hob magic? Jul 18 08:33:54 I like magic ;-) — but I suppose it should do. HOB writes config in the same *.conf files Jul 18 08:35:16 the meta-java layer has a dependency on meta-oe and meta-openembedded layers, but I’m not sure wich branch to use. the meta-java README says “master” Jul 18 08:35:38 but there are also branches for “daisy” release of Poky Jul 18 08:35:47 morning all Jul 18 08:35:54 got a little confused about names Jul 18 08:35:58 good morning =) Jul 18 08:35:59 AlexanderTheLost: it should match up with the branch of poky you're using Jul 18 08:38:43 howdy bluelightning Jul 18 08:39:11 Tryto build again Jul 18 08:40:05 hi LetoThe2nd Jul 18 08:43:47 JaMa: I've just sent out another patch series. Hopefully this one gets rid of many of the remaining issues with the pending patches for oe-core Jul 18 08:43:58 rburton: I've fixed up most of the foreign issues Jul 18 08:44:55 JaMa: although it looks like somehow the SoB lines got lost :( Jul 18 08:51:30 RP: I just wonder if it's really better to have 50 patches in various recipes for foreign, than one in automake, but thanks Jul 18 08:51:52 * JaMa just started fixing our internal recipes for foreign Jul 18 08:52:06 This may sound like a silly question but I can’t get it: what is the difference between Poky and Arago (from Texas Instruments)? Jul 18 08:54:31 AlexanderTheLost: they are similar, and based on the same core Jul 18 08:54:32 AlexanderTheLost: both are 2 distro based on openembedded-core Jul 18 08:54:40 ;-) Jul 18 08:55:15 AlexanderTheLost: they are both distros (i.e. sets of policy about what to build and how to build it); on the other side they also both come with different sets of recipes out of the box Jul 18 08:56:20 JaMa: the trouble is that it this kind of problem leads to broken configure.ac files and the problem spreads. Its mostly old recipes that have the issue :/ Jul 18 08:56:35 JaMa: I'm torn too :/ Jul 18 08:57:16 and we have a lot of old recipes :) Jul 18 08:57:24 JaMa: when I started, I didn't know about the efl issues, that may have tipped the balance if had... Jul 18 08:57:40 RP: I'm not so strict in meta-oe, but your configure.ac patches don't have Upstream-Status: Jul 18 08:58:05 I guess all are "Pending" Jul 18 08:58:25 JaMa: ah, right, I didn't put descriptions in either. If you want me to do that I can but it will have to wait for a bit Jul 18 08:58:39 JaMa: yes, pending Jul 18 08:58:47 JaMa: in theory upstreams need to do this... Jul 18 08:59:17 right Jul 18 08:59:32 I'll include them in master-next to get them in next build Jul 18 08:59:46 if you find time to update them before I decide to merge them, then it would be great Jul 18 08:59:53 otherwise I'll merge them as-is Jul 18 09:00:24 JaMa: when will you start the next build? This night? Jul 18 09:06:14 I also wonder about this warning: Jul 18 09:06:15 | Makefile.am: installing './COPYING' using GNU General Public License v3 file Jul 18 09:06:15 | Makefile.am: Consider adding the COPYING file to the version control system Jul 18 09:07:20 is it also side effect of "foreign", I'm thinking of the case when it has all required files (so it doesn't fail) but this adds new possibly incorrect GPLv3 COPYING file in the configured sources Jul 18 09:07:22 Ok, I see. So this ‘meta-java’ layer that I’m trying to build should build in Arago also, right? Jul 18 09:08:11 ant_work: test-dependencies build is running 17hours already Building recipe: webmin (82/123) Jul 18 09:08:31 ant_work: then normal world builds will follow when it is finished (in next 24 hours maybe) Jul 18 09:08:57 JaMa: revert the patch and see i guess Jul 18 09:08:59 ah, sadly I could not yet send that little klibc-utils fix Jul 18 09:09:51 my pc has been abducted by the in-law visitors Jul 18 09:17:07 AlexanderTheLost: should do yes Jul 18 09:17:47 JaMa: the license checksumming happens after do_configure, so there'll be obvious errors if it actually replaced a license Jul 18 09:23:21 rburton: I'm talking about the case when COPYING didn't exist in original source (so it wasn't used in LIC_FILES_CHKSUM) Jul 18 09:24:26 so now there could be README which says Apache-2.0 and is used by LIC_FILES_CHKSUM and COPYING file with GPLv3 is added to configured sources Jul 18 09:25:18 our open source review comitee won't know that they can ignore COPYING file, because it was added only by our automake Jul 18 09:30:12 seems to me there ought to be a QA warning to highlight that Jul 18 09:31:56 hi rburton: are you working, or planing to work on mesa 10.2 upgrade in this release cycle? Jul 18 09:40:33 JaMa: this is why the archiver for source review shoud also use the downloaded sources, and not anything else Jul 18 09:41:05 ndec: i'm the current owner of a bug that says we need mesa 10.2.2 so probably yeah Jul 18 09:41:14 ndec: unless you have a patch already :) Jul 18 09:49:18 rburton: no... i have sent libdrm update which was more or less trivial. Jul 18 09:49:39 that was also on the list so thanks :) Jul 18 09:50:27 rburton: for libdrm, would you be opposed to "--enable-freedreno-experimental-api" Jul 18 09:50:37 we already enable the omap support Jul 18 09:51:07 ofc, i would need the freedreno support in mesa as well, eventually. Jul 18 09:52:43 no real objection, no Jul 18 09:53:50 ok. i will send a patch for libdrm then. i will do the mesa patch once mesa 10.2 is there ;-) Jul 18 09:54:17 do you want me to resend librdrm 2.5.54 update as 1/2 and freedreno as 2/2? Jul 18 09:54:48 ndec: please Jul 18 09:54:51 k. Jul 18 10:09:33 rburton: well, actually both changes are independent, since the freedreno patch only touches libdrm.inc, and they can be merged indepedently.. so i won't resend as a series, that's not even needed Jul 18 10:09:45 ndec: cool Jul 18 10:09:49 and freedreno was already supported in the current libdrm. Jul 18 10:10:20 there is a depends between mesa 10.2 and libdrm 2.5.54 though.. Jul 18 10:10:40 as in mesa 10.2 needs libdrm 2.5.54 Jul 18 10:10:41 ? Jul 18 10:11:30 oops.. wrong.. it's xf86-video-freedreno that has the depends... sorry . Jul 18 10:11:45 makes more sense.. Jul 18 10:19:14 rburton: talking about mesa... do you know why we have the mesa-mega-driver that has all drivers, instead of 1 package for each driver, like we have for libdrm? Jul 18 10:20:18 ndec: because that's what mesa does Jul 18 10:21:26 hmm. ok.. Jul 18 10:23:15 there was lots of duplication and inefficiency as drivers had to go through layers instead of just calling the right bits of mesa Jul 18 10:23:24 so they lumped it all into a single blob Jul 18 10:35:17 RP: heh.. I've fixed xfconf to unblock xfce recipes, then it was blocked by libxfce4ui fixed by you and now it fails on exo.. Jul 18 10:35:35 RP: that's the kind of hidden issues I was talking about Jul 18 10:43:11 how do these packages build from git? does xfce still have an autogen script that calls the tools one by one still? Jul 18 10:43:41 most of the fails in oe-core were from either 1) packages ten years old or 2) packages where there's a hand-crafted autogen Jul 18 10:43:44 iirc yes, but I'm just building it, never used that Jul 18 10:44:22 and this was caused by missing gtk-doc not foreign (at least first issue in it) Jul 18 11:12:49 JaMa: FWIW the numbers of remaining tasks are getting quite a bit lower on my builds so hopefully not too many more hidden ones Jul 18 11:13:06 JaMa: its hard to know which ones are key from my perspective since I don't know a lot of this software :/ Jul 18 11:26:04 RP: true, I also know it only from build logs.. but seems like exo was last in xfce blockers Jul 18 11:26:53 RP: and these build fixes are still pretty far from testing it in runtime :/ That's why I was always trying to get people actually using the software on their devices to do the fix and test it.. Jul 18 11:32:23 JaMa: there is only so far the small team we have can go :/ Jul 18 11:32:51 JaMa: its why I've been pushing for more automated testing. OE-Core is getting better there, hopefully meta-oe will follow Jul 18 11:33:35 RP: well testing is one part, but getting the manpower to fix found issues... Jul 18 11:34:00 RP: we already have a long list of issues found in world and test-dependencies builds.. Jul 18 11:39:08 JaMa: we are making some headway with them, slowly, but yes Jul 18 11:52:33 RP: it seems that debian.bbclass doesn't work with recent changes Jul 18 11:52:47 RP: all packagenames lost .so version suffix Jul 18 11:53:54 maybe package_name_hook exported from package.bbclass now somehow conflicts with the same function exported by debian.bbclass? Jul 18 11:54:28 rburton: ^ Jul 18 11:56:17 tmp-eglibc/work/arm920tt-oe-linux-gnueabi/libgcc/4.9.0-r0/temp/run.package_name_hook.14013: Jul 18 11:56:22 tmp-eglibc/work/arm920tt-oe-linux-gnueabi/libgcc/4.9.0-r0/temp/run.package_package_name_hook.14013: Jul 18 11:56:28 both show just empty function Jul 18 11:58:19 * JaMa again picked very bad day to do rebuild from scratch :/ Jul 18 12:03:18 JaMa: ouch :( Jul 18 12:07:02 * RP looks at the autobuilder problems Jul 18 13:03:08 JaMa: whaaaa Jul 18 13:03:17 i bloody tested that and it bloody worked :( Jul 18 13:04:02 Crofton: what is this Trolling group? Jul 18 13:05:03 embedded guys Jul 18 13:05:09 and friends Jul 18 13:05:29 I am reusing a name from a G+ group Jul 18 13:07:15 mainly an easy for linux cycling people to stay in touch Jul 18 13:29:33 RP: can we talk a bit about KERNEL_MODULE_AUTOLOAD ? Jul 18 13:30:31 I don't see how it supports modules where basename and package name don't match (usually - and _) Jul 18 13:31:11 and also the old implementation allowed to load modules in particular order (useful for incorrect dependencies between modules), e.g.: Jul 18 13:31:14 module_autoload_snd-soc-neo1973-wm8753 = "snd-soc-s3c24xx snd_soc_s3c24xx_i2s snd-soc-dfbmcs320 snd-soc-wm8753 snd-soc-neo1973-wm8753" Jul 18 13:31:15 JaMa: fwiw, my local builds have packages called libxrandr2 etc Jul 18 13:31:53 or simpler example: Jul 18 13:31:55 module_autoload_g_ether = "s3c2410_udc g_ether" Jul 18 13:33:01 and for -/_: Jul 18 13:33:02 module_autoload_bq27x00_battery = "bq27x00-battery" Jul 18 13:38:09 JaMa: hmm :/ Jul 18 13:39:07 maybe we can workarround it like KERNEL_MODULE_PROBECONF does Jul 18 13:39:28 if module_autoload_basename is specified with different value, then use that one instead of basename Jul 18 13:39:33 if it has the same value show warning Jul 18 13:41:06 I can prepare patch, but proper testing in runtime will be complicated as I don't have any usable image since daisy.. Jul 18 13:42:54 rburton: that was fast ;-) [the libdrm commit..] Jul 18 13:46:57 JaMa: usable image due to the various churn or something else? Jul 18 13:49:18 RP: if I manage to build it, then there is always some runtime issue :/ Jul 18 13:53:08 RP: http://bpaste.net/show/475085/ Jul 18 13:54:30 Hello everyone, I have a very unique problem right now. Could anybody help me? Jul 18 13:55:11 JaMa: the downside is that the kernel_module values won't get reflected in the sstate checksum Jul 18 13:55:24 JaMa: I don't have a better solution right now though Jul 18 13:56:42 aimetis0: ask, don't ask to ask Jul 18 13:59:40 oh this module autoload would be another point to keep in mind when upgrading beyond daisy Jul 18 14:00:21 Basically, I am buiding the customized linux image for my embedded device. I created a standalone package to overlay some system conf files and libraries. When I add this package in the image bb file, I get file conflict errors because the files exist. But I really need to replace those files or libraries with those in the package. How could I solve this problem? Jul 18 14:00:36 I hope we will start putting out migration document with releases atleast with respect to last version Jul 18 14:01:34 aimetis0: you could solve it in different ways Jul 18 14:01:44 khem: we have done this for a while Jul 18 14:02:23 RP: correspoinding "cleanup" http://bpaste.net/show/475101/ Jul 18 14:02:45 aimetis0: one is to create a recipe from your package and then write bbappends for all recipes to delete the files which will be replaced by this recipes Jul 18 14:02:52 JaMa: it does look better for that at least :) Jul 18 14:03:10 RP: cool, I must have missed it. is it in release notes ? Jul 18 14:04:10 RP: yes mostly nokia900 and om-gta02 are mixing -/_ and it's good to use simpler syntax for the rest Jul 18 14:04:28 aimetis0: another option is to divide your package and put the files into the original packages again using bbappends Jul 18 14:04:40 RP: and for my use-case I don't mind that the value isn't in signature Jul 18 14:04:40 I tried to put it in a separate layer and assign it higher priority but it didn't work Jul 18 14:04:55 khem: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#moving-to-the-yocto-project-1.3-release (sections on 1.3, 1.4, 1.5 and 1.6) Jul 18 14:05:41 ok its in ref manual Jul 18 14:05:53 JaMa: I will get complaints from others but it is at least fixable now we have a list Jul 18 14:08:16 RP: at least that behavior is now consistent with module_conf_%s Jul 18 14:08:17 khem: there are too many files and libs which need to be replaced and they are always changing. writing a bbappend file may be inefficient. I am wondering if there is any other way just allowing me to simply overlay them. Jul 18 14:09:35 aimetis0: there are things like ROOTFS_POSTPROCESS_COMMAND which you could use to copy things over the rootfs Jul 18 14:10:07 obviously its not good from a package manager perspective Jul 18 14:11:30 RP: that sounds a good option in my situation. could you provide me some more info on this command like a man page or something? thanks Jul 18 14:13:37 aimetis0: it lists a set of functions to call after the rootfs is constructed. add the name of your function and do what you need in that function Jul 18 14:13:51 aimetis0: there are examples in the codebase Jul 18 14:16:36 RP: ah that patch for gcc ICE was meant only for dora, I've resend it with PATCHv2 and [dora] tag few seconds after v1 Jul 18 14:16:49 RP: now I see that you were repliying on this first patch not 2nd Jul 18 14:18:31 JaMa: ah, ok. I was a bit confused by the commit message which explains that Jul 18 14:21:39 rburton: bitbake -e libgcc: http://bpaste.net/show/475166/ Jul 18 14:25:55 RP: thank you so much Jul 18 14:26:11 khem: thank you as well Jul 18 14:27:40 JaMa: how interesting Jul 18 14:27:48 Hm, when do you need to set IMAGE_BASENAME? Ive seen it done a couple of times but not sure why/when? Jul 18 14:28:19 JaMa: python package_name_hook () { Jul 18 14:28:19 bb.build.exec_func('debian_package_name_hook', d) Jul 18 14:28:19 } Jul 18 14:28:21 is what i hae Jul 18 14:28:26 inherit order? Jul 18 14:28:48 JaMa: how do you enable debian.bbclass? Jul 18 14:28:59 poky does INHERIT_DISTRO=debian blaa blaa Jul 18 14:30:34 rburton: the same without your patch http://bpaste.net/show/475181/ Jul 18 14:30:55 env.libgcc:INHERIT=" buildhistory buildstats buildstats-summary blacklist debian shr-mirrors package_ipk debian devshell sstate license blacklist sanity" Jul 18 14:30:58 env.libgcc2:INHERIT=" buildhistory buildstats buildstats-summary blacklist debian shr-mirrors package_ipk debian devshell sstate license blacklist sanity" Jul 18 14:31:36 $ grep -A 1 "^python package_name_hook" env.libgcc* Jul 18 14:31:36 env.libgcc:python package_name_hook () { Jul 18 14:31:36 env.libgcc- bb.build.exec_func('package_package_name_hook', d) Jul 18 14:31:36 -- Jul 18 14:31:36 env.libgcc2:python package_name_hook () { Jul 18 14:31:38 env.libgcc2- bb.build.exec_func('debian_package_name_hook', d) Jul 18 14:32:19 and enabled by: Jul 18 14:32:20 # append /OE/build/shr-core/meta-smartphone/meta-shr-distro/conf/distro/shr.conf:70 Jul 18 14:32:23 # "debian" Jul 18 14:35:43 maybe this is a distro-inherit vs inherit thing Jul 18 14:35:55 try using DISTRO_INHERIT for that? Jul 18 14:36:05 INHERIT_DISTRO even Jul 18 14:36:25 oh, that's just a variable that gets passed to INHERIT Jul 18 14:36:28 hm Jul 18 14:37:19 * JaMa needs to get back to fixing foreign flags.. this whole rebuild is doomed anyway Jul 18 14:42:42 JaMa: try moving debian after package_ipk Jul 18 14:42:51 (maybe we need an inherit package in debian)? Jul 18 14:44:48 sorry, I've already started different build Jul 18 14:46:40 np Jul 18 14:46:54 easily tested outside of a build, i'll have a go in a bit Jul 18 14:47:15 thanks Jul 18 14:47:26 it's also time to waste some time outside in sun :) Jul 18 14:48:01 yeah i spent most of my lunch mowing the lawn and pumping up the paddling pool for the kids Jul 18 14:48:06 JaMa: sunlight?! Sounds dangerous Jul 18 14:48:11 now i'm sitting in a very hot study Jul 18 14:48:15 Doing It Wrong Jul 18 14:49:51 rburton: you're not the only one Jul 18 14:51:16 how warm is it there? Jul 18 14:51:42 fray: warm enough for me Jul 18 14:51:54 fray: http://www.wunderground.com/personal-weather-station/dashboard?ID=ICAMBRID29 Jul 18 14:52:44 study is west facing and i'm struggling to get a breeze through Jul 18 14:52:51 ahh that was our weather about 2 weeks ago Jul 18 14:53:33 Ya, no Air Conditioning in my house.. but it's 75F/24C here today.. so not bad.. Jul 18 14:53:41 that's more like it for me Jul 18 14:53:56 I'm guessing it'll go up to about 80F by the end of the day.. Jul 18 14:53:57 pretty humid today. even my wife is moaning and shes normally got goosebumps unless its 30+ Jul 18 14:54:04 * RP is happy to have a very solid house that doesn't do "warm" on days like this Jul 18 14:54:05 ;) Jul 18 14:54:27 RP, problem with your solid house.. if it ever does "warm up".. it'll take forever to let go of the heat.. ;) Jul 18 14:54:57 fray: It would be interesting to see what it would take to warm it up, I have never known it get "hot" inside Jul 18 14:55:16 you've got a pretty continuous breeze off the sea though right? Jul 18 14:56:12 fray: yes, I tend to keep the windows shut for the insects even in the middle of summer there is little need to open them. If I needed ventilation, there are chimneys for that Jul 18 14:56:34 Ahh no screens? I'd die around here w/o window screens (and open windows) Jul 18 14:58:29 fray: no screens Jul 18 14:58:47 screens are rare in the UK Jul 18 14:59:11 the house we're moving to has a shaded study with a tiny window, so it's going to be a bit of a mancave but should be cooler :) Jul 18 14:59:12 fray: its usually not bad apart from a few weeks in early summer when there is some seaweed loving insect that goes everywhere Jul 18 14:59:20 I would have thought you'd have more bugs along the sea as well as farther north Jul 18 14:59:47 * RP noted the new white rendering turned a sea of moving black :/ Jul 18 15:00:00 in Minnesota, we have the state bird.. Mosquitos.. millions and millions of Mosquits Jul 18 15:00:20 fray: those live in Kielder/Scotland. Thankfully Jul 18 15:00:25 ;) Jul 18 15:00:54 Mosquitos aren't bad in the urban areas, but I'm outside of the Mosquito control district.. so they can be terrible here.. Jul 18 15:01:23 mosquito control district? Jul 18 15:01:29 fine for being a mosquito in the city? Jul 18 15:01:53 ya.. there is an area that they spary and treat for mosquito larve.. Jul 18 15:01:59 it really helps control the population.. Jul 18 15:02:03 ah Jul 18 15:02:15 best we can do is "yard fogger" here.. kills the adults, but doesn't do much to the larve Jul 18 15:02:19 i had an image of roving gangs of vigilantes with deet cannons and swats, mad max style Jul 18 15:02:28 ;) Jul 18 15:02:46 doesn't help we've had more rain then normal and I live near a marshy area.. Jul 18 15:05:48 Ok.. I've been looking at this now for 10 minutes and I'm drawing a blank.. Jul 18 15:06:01 (from gcc-multilib-config.inc) Jul 18 15:06:01 ml_list = ['DEFAULTTUNE_MULTILIB_ORIGINAL' if mlprefix else 'DEFAULTTUNE'] Jul 18 15:06:01 mltunes = [('DEFAULTTUNE_virtclass-multilib-%s' % ml) for ml in multilibs] Jul 18 15:06:04 there is a bug.. Jul 18 15:06:22 if we're going a multilib build, the ml_list needs to be seeded with both DEFAULTTUNE_MULTILIB_ORIGINAL and DEFAULTTUNE.. Jul 18 15:06:39 but it's not getting the second item.. (and multilibs needs to have the mlprefix removed) Jul 18 15:07:02 any suggestions? Jul 18 15:10:50 fray: to me it's the syntax that's making things awkward... what about just defaulting ml_list to ['DEFAULTTUNE'] and then only adding DEFAULTTUNE_MULTILIB_ORIGINAL afterwards if mlprefix? Jul 18 15:11:10 I suspect it's an ordering thing, but I'm not actually sure if that list has any type of anorder.. Jul 18 15:11:19 it is awkward.. :/ Jul 18 15:11:29 lists are ordered, so it depends on how it is used Jul 18 15:11:39 I'm trying to dump the contents of the list now... Jul 18 15:12:08 the issue that I'm having is that the currently (in use) multilib is getting added via the 'in multilibs' on the second line which is causing a problem.. I think Jul 18 15:12:42 as written, ml_list will end up as ['DEFAULTTUNE_MULTILIB_ORIGINAL'] if mlprefix has a value, otherwise it'll be ['DEFAULTTUNE'] Jul 18 15:13:30 ya, and thats what I think is problem.. but again, I'm not completely sure.. Jul 18 15:13:44 still waiting for the system to catch up to me and show me the current list.. ;) Jul 18 15:14:14 I'm getting a compliation error from the generated powerpc multilib list.. and just disabling the multilib code doesn't resolve it Jul 18 16:33:16 sorry but i need some advice. i created a bsp for a board which is supported by the yocto kernel.so my bsp doesn't focus in kernel patches or similar. how can i tell yocto to include the kernel defconfig for the board? i know there's several ways, which one would you prefer? Jul 18 16:42:34 We noticed locally that pseudo 1.6.0 doesn't build on at least some non-x86. I have a patch in tree, but before I go updating things, has anyone noticed anything *else*? Jul 18 16:51:01 seebs: do you see the message at the end of builds? Jul 18 16:51:15 seebs: NOTE: Executing RunQueue Tasks Jul 18 16:51:15 Pseudo server seems to be already offline. Jul 18 16:51:15 NOTE: Tasks Summary: Attempted 1655 tasks of which 1650 didn't need to be rerun and all succeeded. Jul 18 16:51:28 seebs: its annoying ;-) Jul 18 16:51:30 Hmm. That could be the result of an intentional change. Jul 18 16:51:45 In the case where you do "pseudo ", it now shuts the server off automatically when done. Jul 18 16:51:58 shall i post my question on the mailing list? Jul 18 16:53:51 seebs: what non-x86 specifically? x86_64? Jul 18 16:54:05 arm. Jul 18 16:54:22 I merged in the memcpy symbol version thing, and I can summarize the problem as follows: Jul 18 16:54:30 #else /* tentatively assume this means x86 */ Jul 18 16:59:39 microd: Might not be a bad idea, IRC can be erratic. Jul 18 17:02:02 seebs: thanks, which one? yocto or poky list? Jul 18 17:02:23 microd yocto Jul 18 17:02:32 I don't know. My mailing list skills are roughly at the level of "How did this get here I am not good with computers." Jul 18 17:03:13 seebs :-D, rburton: will do so Jul 18 17:13:04 mailing list are not quite what they used to be... Jul 18 17:16:32 and neither is my keyboard... Jul 18 17:18:45 but sometimes the only way to get the advice you need.... Jul 18 17:29:47 qt4-x11-free sure does take a while to build... Jul 18 17:43:43 Ah-hah. Jul 18 17:43:47 $ pseudo cmd Jul 18 17:43:58 if cmd doesn't actually cause a pseudo server to spawn, I get that message. Jul 18 17:46:47 Okay, I have two known issues in pseudo 1.6.0: non-IA32 builds failing because of the memcpy thing, and the uninformative "server already offline" messages. Jul 18 17:47:03 Anything else? If not I'll try to make a 1.6.1 pretty soon here. Jul 18 17:51:46 in vlc.inc, ac_cv_path_{MOC,RCC,UIC} are being set... where would these come from in default case? Jul 18 17:52:59 I'm pretty sure I saw this before the pseudo upgrade, and it might be a problem in the specific freescale recipe, but a couple of my packages have been created containing files with my user/group permissions instead of root/root. And after rebuilding, they have correct permissions Jul 18 17:54:14 I saw before the pseudo upgrade *aswell* Jul 18 17:58:57 I do a clean build and see if I can get some logs or something Jul 18 18:05:01 kroon: Okay. My default assumption is usually that there's a recipe error or something when that happens, but there have been surprises. Jul 18 18:05:23 I know kergoth and I have both had that happen when we (independently) had the clever idea of not worrying about the binary toolchain running outside of pseudo. Jul 18 18:05:33 (It turns out objcopy remakes files.) Jul 18 18:09:32 seebs, is there an easy rule to remember when something is running under pseudo ? all do_* functions ? Jul 18 18:09:59 I don't actually know exactly. At least some usually *don't* run under pseudo. Jul 18 18:10:08 I think it's mostly the install and later phases that are expected to? Jul 18 18:12:22 its a good question. in theory, the problem with only running it on install and later is that binaries written out is if the make install doesn't explicitly set the permissions, and using cp -a or similar, so the user owned binaries written out by do_compile get their user ownership retained Jul 18 18:12:25 * kergoth shrugs Jul 18 18:19:53 I believe you can look at the system for the 'fakeroot' flag being set of hte functions (or in the actual definition) Jul 18 18:20:34 base.bbclass: d.setVarFlag('do_install', 'fakeroot', 1) Jul 18 18:20:34 base.bbclass: d.setVarFlag('do_package', 'fakeroot', 1) Jul 18 18:20:34 base.bbclass: d.setVarFlag('do_package_setscene', 'fakeroot', 1) Jul 18 18:20:34 base.bbclass: d.setVarFlag('do_devshell', 'fakeroot', 1) Jul 18 18:20:50 those are the implicit ones.. (as well as the do_package steps) Jul 18 18:20:57 the others should be explicit.. iether ad: Jul 18 18:21:04 function[fakeroot] = '1' Jul 18 18:21:06 or Jul 18 18:21:10 fakeroot function() { Jul 18 18:28:17 so if any user owned files leak into the rootfs, either do_install isn't doing what it should, or there's a leak somewhere Jul 18 18:29:11 yup.. I thinkt he rule is that do_install is supposed to NOT cp w/ owner/group from the source Jul 18 18:29:21 it's supposed to 'install'.. or 'cp' w/o preserving owner/group Jul 18 18:35:24 * kergoth nods Jul 18 18:36:47 seebs, the recipe I mentioned is using "cp -a" in do_install(), i think this is the cause of the issue Jul 18 18:36:57 That is probably it. Jul 18 18:37:15 This is why my default response to anything that refers to a possible problem with pseudo is to say "Oh, I know that one, it's user error." Jul 18 18:37:19 yup, I'd consider that recipe broken for the most part Jul 18 18:37:21 It's right just often enough to look plausible. :P Jul 18 18:38:26 :) Jul 18 18:43:17 Hmm, we could arrange things such that 'cp' if called directly in do_install errors out, but cp called by make would be fine. set up an alias or shell function which is only defined for do_install. Not permanently, perhaps, since there are likely occasional valid cases, but we could use it with a world build to audit the recipes for broken do_install. alternatively, we could iterate over all recipes and dump do_install with bb show -r recipe Jul 18 18:43:17 do_install and grep for cp -a :) Jul 18 18:45:23 We could also check installed directories for non-root files. Jul 18 18:47:05 better yet, check for the uid of the build user explicitly Jul 18 18:47:10 good idea though Jul 18 18:47:13 hmm Jul 18 18:51:59 its odd that the files in my latest build _do_ have root/root though ... Jul 18 18:53:12 in the ipk, sometimes its jkroon/jkroon, sometimes 1000/1000 Jul 18 18:54:54 at least that whats emacs is showing Jul 18 18:55:15 That is odd. Jul 18 18:57:25 oh well. will try and fix the recipe Jul 18 19:20:51 It's important to get recipes fixed as soon as possible, there simply aren't enough shelters for all the orphaned files that result otherwise. Jul 18 19:45:01 otavio, ping Jul 18 19:54:38 seebs: i take it the new version solves your problem(s)? Jul 18 19:54:55 * nerdboy was absent... Jul 18 19:55:40 Yeah. The message was a result of not thinking something through quite carefully enough. Jul 18 19:56:03 Originally, pseudo_client_shutdown() occurred only from an explicit "pseudo -S", which means you're presumably looking for feedback or at least won't mind it. Jul 18 19:56:29 When I made it get called implicitly after the child process from "pseudo ", I didn't think about that, and since I only used it for commands that would make database calls, I never saw the message. Jul 18 19:56:35 "pseudo echo foo" produced it, though. Jul 18 19:57:18 That change came in originally because I was doing a lot of things like "pseudo setfattr -a foo -v bar file.txt; sqlite3 f/var/pseudo/xattr.db 'SELECT * FROM ...;'" Jul 18 19:57:37 And it turned out that having the daemon shut down immediately was important, else databases stayed locked. Jul 18 19:58:05 ... I still shudder a bit thinking about the endless difficulty of figuring out how long the fakeroot server should stay up when idle. Jul 18 19:58:22 15 minutes: You get a lot of database corruption from people shutting down machines before it exits. Jul 18 19:58:36 5 minutes: You get horrific errors when the server shuts down before a kernel build completes. Jul 18 20:00:39 ouch Jul 18 20:01:08 why would a machine shutdown cause database corruption? couldn't it catch SIGTERM? Jul 18 20:01:16 or am i missing something? Jul 18 20:07:21 fakeroot didn't store the database on disk until it shut down. Jul 18 21:31:57 fray, thanks for the tip about the 'fakeroot' flag **** ENDING LOGGING AT Sat Jul 19 03:00:00 2014