**** BEGIN LOGGING AT Wed Jul 16 02:59:59 2014 Jul 16 07:01:30 good morning Jul 16 07:36:10 morning all Jul 16 08:11:59 'morning Jul 16 08:13:02 bluelightning: caught by an yet unknown bug :/ Jul 16 08:14:21 /dev/null is not the black hole we expect Jul 16 08:15:35 tried with (busybox) cp and cat, it loses the char attribute and becomes a vulgar file, hogging devtmpfs finally Jul 16 08:42:14 hm, maybe some script with root privileges is incorrectly doing 'mv' Jul 16 08:42:33 that seems the most common cause Jul 16 08:44:23 yes Jul 16 08:44:25 it's just a file Jul 16 08:44:28 so root can break it Jul 16 08:44:42 I've been hit by that as well Jul 16 08:44:47 real cp and cat here on my server behaves correctly Jul 16 08:44:53 maybe it is busybox Jul 16 08:47:04 koen: now that I remember, I did rm and mknod it (as root) Jul 16 08:47:22 but after cp it becomes file again Jul 16 08:47:51 I even rerun udevadm and it fixes the permissions Jul 16 08:48:22 neverthless, doesn't survive to user cp/cat (not *mv*) Jul 16 08:48:39 same for /dev/zero fwiw Jul 16 08:48:54 there is surely a bug Jul 16 09:04:41 koen: an old thread could suggest busybox vs. toolchain issues Jul 16 09:04:43 http://lists.busybox.net/pipermail/busybox/2008-February/064174.html Jul 16 09:05:56 that's different however,... I don't find many matches Jul 16 09:08:59 fwiw there is a busybox patch for the opposite bug, copying from /dev/null ;) Jul 16 09:09:35 http://osdir.com/ml/linux.busybox/2004-05/msg00233.html Jul 16 09:10:00 I will test with regular utils, I have big suspects Jul 16 09:11:13 hah Jul 16 09:11:16 This is the Busybox feature ENABLE_FEATURE_NON_POSIX_CP Jul 16 09:11:40 https://forum.openwrt.org/viewtopic.php?id=27235 Jul 16 09:15:10 koen: it's that Jul 16 09:15:20 http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/busybox/busybox/defconfig#n113 Jul 16 09:15:59 "...ill-conceived feature" Jul 16 09:17:48 RP: ^ Jul 16 09:18:29 worth an RFC? Jul 16 09:19:33 hm yes non posix is evil Jul 16 09:20:57 I was measuring squashfs refinements and was always out of space..doh ;) Jul 16 09:23:43 woglinde: the only reason I may see is to avoid that an hacker could delete his bash history redirecting to /dev/null Jul 16 09:23:56 speaking of busybox, am I correct in understanding that it doesn't support "savedefconfig", creating minimal defconfigs ? Jul 16 09:24:36 ant_work: worth an RFC for sure Jul 16 11:08:00 Crofton|work: zeroc-ice is failing again http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.20140714_130534.log/2_max/failed/zeroc-ice.log Jul 16 11:08:58 Crofton|work: possibly caused by recent db upgrade to 6.0.30 Jul 16 11:09:07 yes Jul 16 11:09:19 I heard about that one Jul 16 11:09:34 this db6 update is a pain Jul 16 11:09:51 do we have more recipes impacted by this? Jul 16 11:11:09 so glad that is not a weird error :) Jul 16 11:11:23 Crofton|work: no idea with the mess we currently have in world builds Jul 16 11:11:30 bother Jul 16 11:12:18 JaMa: the do_package_qa you have logged for linux-kexecboot is also suspicious Jul 16 11:12:28 sems mixing 3.10 and 3.14 Jul 16 11:13:17 fwiw I see packagegroup-core-base failing when building 3.10 after 3.14 Jul 16 11:13:40 ant_work: that one is possibly resolved by http://git.openembedded.org/openembedded-core/commit/?id=fa325e44f5b429b4038022b31285af9c94672943 Jul 16 11:13:45 it still looks for 3.14 Jul 16 11:14:10 ant_work: because packagegroups aren't rebuilt when signatures of dependencies are changed Jul 16 11:14:34 yes, I rebuild it by hand Jul 16 11:14:48 I think the sstate are kernel-base and kernel-image Jul 16 11:14:50 iirc Jul 16 11:14:57 side effect of http://git.openembedded.org/openembedded-core/commit/?id=80b065ff46322ec0cad039dfd9eb2d010168dba6 Jul 16 11:15:16 Yes I have to do the same Jul 16 11:15:26 JaMa: going backwards is not normal... Jul 16 11:15:29 RP: ^^ Jul 16 11:15:38 I admit it ;) Jul 16 11:16:25 RP: I'm not sure if this exception for packagegroup is worth the need of manual rebuild (instead of just making more packagegroup recipes MACHINE_ARCH or TUNE_PKGARCH) Jul 16 11:17:03 RP: the same manual rebuild is needed for packagegroups which includes some library-only recipe which changed the name because of debian.bbclass Jul 16 11:17:17 JaMa: personally, I think the idea of having machine specific package groups is horrible, it suggests we're doing "bad things" in other areas Jul 16 11:17:30 RP: once you pull the kernel in one... Jul 16 11:17:54 both issues mentioned in https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970 Jul 16 11:18:46 JaMa: I'm trying to get to some of these bugs Jul 16 11:19:06 Unfortunately, I'm being asked to do 101 things and I just don't have time to do them all :( Jul 16 11:20:07 understood Jul 16 11:20:46 JaMa: and about klibc-utils deps, to me all seems ok Jul 16 11:21:07 last test-dependencies result: Jul 16 11:21:10 ERROR: 208 issues were found in these recipes:... Jul 16 11:21:21 yes, that one Jul 16 11:22:57 * JaMa trying to fix xfconf which was causing quite a lot of recipes to fail Jul 16 11:23:17 jama what is xfconf? Jul 16 11:23:27 something from xfce Jul 16 11:23:28 JaMa: in fact the source is the same so it is an implicit dep Jul 16 11:24:25 I can try to silence the warning, though Jul 16 11:24:35 woglinde: I don't know what it is, I just happen to fix stuff which is breaking world builds.. Jul 16 11:24:37 adding an explicit dep Jul 16 12:39:51 JaMa: was the last world build with or without the autotools change? Jul 16 12:40:02 JaMa: I'm concious of the meta-oe failures :/ Jul 16 12:41:22 RP: with and with insane qa improvement Jul 16 12:41:43 causing 700 QA warnings.. Jul 16 12:42:05 JaMa: ouch :( Jul 16 12:42:14 some are duplicates Jul 16 12:42:21 but we were down to ~100 before Jul 16 12:47:25 JaMa: probably better to know that not know though? :/ Jul 16 12:52:38 well whole qa.log was already unusable because of the amount of warnings there, so it doesn't make it significantly worse Jul 16 12:52:59 not sure how to solve this check complaining about missing eglibc* rdepends Jul 16 12:53:27 WARNING: QA Issue: libswscale rdepends on eglibc but its not a build dependency? Jul 16 12:53:27 WARNING: QA Issue: libavutil rdepends on eglibc but its not a build dependency? Jul 16 12:53:27 WARNING: QA Issue: libavresample rdepends on eglibc but its not a build dependency? Jul 16 12:53:27 WARNING: QA Issue: libavformat rdepends on eglibc but its not a build dependency? Jul 16 12:53:27 WARNING: QA Issue: libavformat rdepends on libbz2 but its not a build dependency? Jul 16 12:53:29 ... Jul 16 12:53:32 and 10 more Jul 16 12:55:49 all: do we have a volunteer to maintain meta-oe at least for few months? Jul 16 13:01:19 eglibc? Jul 16 13:01:23 shouldn't that be libc6? Jul 16 13:04:40 summer sucks Jul 16 13:04:47 everyone is on holiday Jul 16 13:05:30 crofon go on holiday too Jul 16 13:05:36 next week Jul 16 13:05:43 gone for like 2.5 weeks :) Jul 16 13:06:52 JaMa: that sounds like something may be wrong with the check :/ Jul 16 13:07:16 JaMa: or something went wrong with the package rename mappings Jul 16 13:08:11 RP: be aware that this was without your patch to move it after packagedata task Jul 16 13:08:59 * JaMa starting new incremental build now, results will be in 2 days or so Jul 16 13:09:21 but this time with Ross's autoconf stuff which I fear will break remaining half of recipes Jul 16 13:10:33 JaMa: ah, without that, it might have missed the dependencies which could explain tht Jul 16 13:10:54 JaMa: I'm going to hold that patch from Ross until we see how bad it is Jul 16 13:13:17 RP, how long before the win stuff is in master? Jul 16 13:13:32 I am hopeful I can take a quick look at it before I go Jul 16 13:13:40 it will be hard to compare 50 recipes failing now with N recipes failing with this autoconf patch (it's already hard to see what's caused by what) Jul 16 13:14:05 ugh. is it possible that ubuntu updated tar in 14.04 breaking oe? Jul 16 13:14:26 and a lot of issues is hidden by their failing dependencies Jul 16 13:15:07 heeen: master, daisy and dora are OK, for older you need to backport couple fixes Jul 16 13:15:28 Crofton: Good question. I'm drowning in patches causing breakage all over Jul 16 13:15:53 Crofton: Doing my best to work through them and figure out what is safe and what needs fixing Jul 16 13:16:06 JaMa: I was about to write to you :D Jul 16 13:16:15 well, I fear I an't poke them until after vacation anyway :( Jul 16 13:44:05 JaMa: the right fix for that kernel (PACKAGES = "") is to add do_packagedata[noexec] = "1" Jul 16 13:44:46 ant_work: please send patch if you have a fix Jul 16 13:45:21 it is just another task to be skipped by the recipe Jul 16 13:46:34 hope to send soon (parents in law inspection err.. visit) Jul 16 14:24:12 correct, thx Jul 16 14:47:22 stupid question Jul 16 14:47:25 gitAUTOINC+3814925d38 Jul 16 14:47:40 How do I get AUTOINC to become a number? Jul 16 14:47:47 it already is Jul 16 14:47:50 in the packaging process Jul 16 14:47:54 hmmm Jul 16 14:48:19 erm, i think its then. at any rate, its automatically done, you shouldn't have tow orry about it Jul 16 14:48:19 where does it keep the number? Jul 16 14:48:29 waiting for this to finish Jul 16 14:48:38 most likely the persist_data database Jul 16 14:48:41 I need ot understand this better Jul 16 14:48:50 the bits in tmp/cache/ hold all sorts of persistent information Jul 16 14:49:12 but, i haven't had my caffeine yet, so i could be remembering wrong Jul 16 15:01:51 kergoth: redefining the persist var to move that out of TMPDIR saves a lot of anguish Jul 16 15:02:02 agreed, we do that too Jul 16 15:03:02 postgres is fixed again ! Jul 16 15:03:36 crofton very good Jul 16 15:04:02 I mean yey another patch on the list fixing the binconfig issue Jul 16 15:04:05 I think Jul 16 15:08:01 I think we have enough issues and too many devs on holiday to further break things in the near future Jul 16 15:08:57 maybe it's bad luck but at least 4 commits of june/july have had negative impact on the few recipes I maintain :/ Jul 16 18:26:02 libgcrypt-native is failing with: | ../x86_64-linux-libtool: line 6001: cd: {libdir}: No such file or directory Jul 16 18:26:02 | x86_64-linux-libtool: link: cannot determine absolute directory name of `{libdir}' Jul 16 18:26:35 which is coming from: GPG_ERROR_LIBS='-L\{libdir\} -lgpg-error Jul 16 18:26:38 any ideas? Jul 16 19:27:29 moto-timo: missing a $ maybe? Jul 16 19:28:24 is that in a recipe or a makefile or what? Jul 16 19:31:02 and what branch? it didn't fail on master last night Jul 16 19:35:00 moto-timo: your chair is on fire Jul 16 19:55:13 master branch. The GPG_ERROR_LIBS is in the configure generated by autools for libgcrypt-native Jul 16 21:05:29 lemme check; all i got last night was "libgcrypt.so.20.0.1 has relocations in .text" Jul 16 21:06:44 moto-timo: you didn't already fix it, did you? Jul 16 21:07:09 * nerdboy got stuck in a side meeting with the prez for a while... Jul 16 22:00:26 I could use some tips with this.. Freescale ships binary .so files in their gpu-stack. One of the libraries is currently missing a RDEPENDS on libffi. I've checked this using readelf --dynamic | grep NEEDED Jul 16 22:01:10 JaMa: which mirror do I need to stop e17 failing to fetch in world builds? Jul 16 22:01:19 sounds like you don't need any tips Jul 16 22:01:31 kroon: i would add the redepend Jul 16 22:01:56 or are you asking patch vs. bbappend or something? Jul 16 22:03:10 If I add the RDEPEND, "libffi" is added, as expected. But sometimes, "libffi (>= 3.1)" is added instead Jul 16 22:03:49 It seems so jump back and forth between what I have stated explicitly, and what shlib dependency is detected automaticlly, I think Jul 16 22:04:23 Depending on wether I have libffi installed in the sysroot Jul 16 22:04:37 kroon: try DEPENDS += "libffi" Jul 16 22:05:38 RP, so that would make it a build dependency I guess. Thing is that this is a multi-package recipe. I think I tried that, but the libffi dependency seemed to get applied to all the packages then Jul 16 22:06:18 kroon: it should only apply it to things that link against it Jul 16 22:06:46 ok, let me try that again Jul 16 22:07:16 kroon: that just guarantees libffi is around at do_package time Jul 16 22:15:07 RP: which recipes are failing? svn ones? Jul 16 22:15:29 RP, thanks, indeed it seems to do the trick, I was confusing RRECOMMENDS with RDEPENDS Jul 16 22:17:37 JaMa: yes Jul 16 22:29:28 JaMa: I'm guessing there is some configuration I'm missing either to use fixed versions instead or something Jul 16 22:33:26 RP: http://build.shr-project.org/sources/ should have most of them Jul 16 22:34:45 RP: most of these weren't ever released or even moved to git when enlightenment switched from svn to git.. Jul 16 22:35:14 JaMa: ah, that would explain it, thanks Jul 16 23:08:40 Curious, why isn't something like this "NOTE: Couldn't find shared library provider for libffi.so.6, used by files: xxx" a fatal error ? Jul 16 23:16:07 kroon: probably combination of oversight and concern about breaking builds Jul 16 23:17:16 ok. right now, that note is hidden in log.do_package Jul 16 23:17:36 kroon: open to patches Jul 16 23:19:17 yes, perhaps I could make it into a warning ? Jul 16 23:25:33 But yeah.. I don't wanna flood peoples builds with warning messages either Jul 16 23:57:17 * nerdboy shakes his fist at moto-timo Jul 16 23:57:24 it's not failing for me Jul 16 23:57:34 oops, take that back Jul 17 00:45:38 moto-timo: can't seem to coerce autotools from the recipe, so will make a patch Jul 17 00:46:07 somebody better tell me if they've fixed it... Jul 17 01:21:17 okay, no patch but a slightly different work-around Jul 17 01:22:28 moto-timo: you can add this to the recipe for now, but i probably wouldn't bother to patch unless you're bored... Jul 17 01:22:34 export GPG_ERROR_LIBS="-L${STAGING_LIBDIR_NATIVE} -lgpg-error " Jul 17 01:23:31 actually, that should be native only... Jul 17 01:31:33 moto-timo: sending better one shortly Jul 17 02:13:12 okay, so i think i forgot how poorly the patch (manually) attaches to gmail... **** ENDING LOGGING AT Thu Jul 17 02:59:59 2014