**** BEGIN LOGGING AT Sat Oct 04 03:00:01 2014 Oct 04 04:22:58 good morning..:) Oct 04 08:20:12 mornin' Oct 04 11:44:07 halstead: It looks to me like the autobuilder is hung up :( Oct 04 11:44:25 core-image-sato-sdk - 10 hours? :/ Oct 04 14:59:03 RP: do you have any hint where to look for the packagedata behavior ? I am looking at the fsl-arm issue Oct 04 16:02:46 Hi! I have a problem (of course...): We have customer-specific layers with recipes whose packages should be available only for one customer. Having all customers' packages in the same repository is therefore not ideal. So I looked at package_ipk.bbclass, found PACKAGE_DIR_IPK and set that in the customer-specific recipes. Voila, the customer's packages are now put into tmp/deploy/customer instead of tmp/deploy/ipk/. So far, Oct 04 16:02:46 so good. But: To make that directory available as a repository, I need to create the package index. Setting PACKAGE_DIR_IPK in conf/local.conf to both paths gives me what I want, both indexes are updated on running "bitbake package-index". The problem is that now my builds fail in package_write_ipk ("ERROR: sstate variables not setup correctly?!", "ERROR: Function failed: sstate_task_prefunc") because I guess it is now unclear, in which Oct 04 16:02:47 path the built package should be put. Unfortuantely, I can not make "bitbake package-index" update the customer specific index by setting PACKAGE_DIR_IPK as an environment variable, even when adding it to BB_ENV_EXTRAWHITE. So, how can I have customer-specific packages be put into an extra directory and all indexes being updated without breaking the build process? Any hint would be much appreciated! Oct 04 16:18:11 otavio: did you read my update in the bug? Oct 04 16:23:19 hsychla: Why not set PACKAGE_ARCH to a different architecture in the customers recipes? Oct 04 16:23:54 hsychla: You'd have to add that arch to the list of comparible package architectures but it would otherwise work Oct 04 16:26:33 RP, that would still put the packages into the same repository (tmp/deploy/ipk) and same package index, would it not? Oct 04 16:27:35 RP: hi, sorry off-topic question. Do you autobuilders publish the sstate? E.g. for travis-ci it would be nice if I would rely on some existing state Oct 04 16:58:28 hsychla: they'd be in a different directory in DEPLOY_DIR_IPK Oct 04 16:59:09 zecke: they do happen to share it fwiw, I'm not sure we've ever suggested people use it though Oct 04 17:08:45 RP: do you build on ubuntu too? Oct 04 18:07:06 RP, exactly, so it would definitely be the same repo and package index. we could of course limit access to the subdirectories based on credentials but then all customers would still see the other customers' packages and get a 403 if they try to install them. but this feels very wrong. Oct 04 18:11:43 RP, no, wait, each sub directory is listed in /etc/opkg/base-feeds.conf. so this actually could work. where exactly would I set the compatible package architectures then? Oct 04 18:13:43 RP, ah, /etc/opkg/arch.conf, I guess? Oct 04 18:53:41 RP: no, Oct 04 18:55:46 RP: ok; testing Oct 04 19:04:46 halstead and/or RP, any issues with pseudo update? I ask because I have a desk and will likely be variously-not-very-online for a while soonish. Oct 04 19:05:43 seebs, Did you release a new version? Oct 04 19:05:56 1.6.2, you should have gotten an email I think about the tarball? Oct 04 19:06:04 https://www.seebs.net/pseudo-1.6.2.tar.bz2 Oct 04 19:06:23 Thank you seebs I see the e-mail. Oct 04 19:06:32 Fixes XFS problem and also probably fixes a much sneakier problem involving renames that's been causing weird errors to do with debuginfo splits since the MAY_UNLINK code went in. Oct 04 19:06:57 So if you rename(x, y), y is unlinked, and if x isn't already in the db, we create a link for x before issuing the rename. Oct 04 19:07:17 This is so that if x was a directory, and we somehow ended up with db entries for things under x, but not x itself, the entries get fixed up. Oct 04 19:07:37 Only. Actually, if y *was* already in the database, we create a link for x. Oct 04 19:08:41 And that's totally the wrong test. And then there's a logic bug elsewhere, such that in some cases we end up with two db entries for the file, one lacking a pathname, and then divers alarums and excursions. Oct 04 19:09:54 seebs, It's released now. http://downloads.yoctoproject.org/releases/pseudo/ Oct 04 19:10:19 k. I sent patches to the oe-core list. I would recommend a little burn-in on them and I may have botched them in some hilarious way, but they should be sane. Oct 04 19:12:18 seebs, Is http://is.gd/ytqxTw pulling in the same code that 1.6.2 is built from? Oct 04 19:14:35 seebs, It looks like we are testing 3 commits behind. Oct 04 19:15:05 Right. That's the XFS fix. But I was seeing weird problems on a 32-bit filesystem, so I started digging. Oct 04 19:15:37 And I found what turned out to be a diagnostic error, and a minor relatively harmless logic bug, and a slightly more significant logic bug, the net result of which was a possible serious bug. Oct 04 19:15:59 I think the short answer is: If you rename over a file that already exists and is in the database, pseudo can do some stupid stuff, which it will *almost* always recover from. Oct 04 19:16:46 Pseudo's paranoia is a mixed blessing from a debugging standpoint. It can be really hard to tell that something's going wrong. Oct 04 19:17:16 Wayyy back when there was a really silly logic error such that if you had multiple clients attached to a server, and they didn't disconnect in LIFO order, the server would segfault. Oct 04 19:17:25 I didn't notice for at *least* three weeks. Oct 04 22:32:05 halstead: I need to merge an update for 1.6.2 into master-next Oct 04 22:32:26 RP, I'm trying to get the builder working. Oct 04 22:32:40 RP, I can stop everything so you can kick it when you're ready. Oct 04 22:33:15 halstead: lets concentrate on getting the builders working properly Oct 04 22:33:29 halstead: I'll queue up 1.6.2 in master-next now its ready Oct 04 22:33:51 RP, I'm troubleshooting using master-next so when I fix it that's the build that will be running. Oct 04 22:35:05 halstead: the issue is if I push a new head whilst a build is running, bad things will happen :/ Oct 04 22:35:49 RP, Builds are stopped. Go for it. Oct 04 22:37:00 halstead: pushed, thanks! **** ENDING LOGGING AT Sun Oct 05 03:00:01 2014