**** BEGIN LOGGING AT Fri May 16 02:59:58 2014 May 16 06:09:55 hi guys, one question. I'm getting following erro during do_rootfs task: KeyError: "filename './control' not found" May 16 06:10:11 any ideas what to do next (rebuild, clean something)? May 16 07:00:44 mbelisko, maybe post a little more context on pastebin ? May 16 07:13:51 good morning May 16 07:56:42 just giving the autobuilder a first try, yocto-start-autobuilder runs into http://paste.ubuntu.com/7471774/ May 16 07:56:49 anybody seen that already? May 16 08:35:05 morning all May 16 08:35:25 howdy bluelightning May 16 08:35:34 hey LetoThe2nd May 16 08:35:55 bluelightning: aren't you also involved in the autobuilder a bit? May 16 08:37:03 hi bluelightning, LetoThe2nd, all May 16 08:37:03 hi mckoan May 16 08:37:03 howdy mckoan May 16 08:37:08 LetoThe2nd: not really directly, that's pidge's domain of expertise May 16 08:37:30 bluelightning: yeah, for advanced stuff ;) May 16 08:41:31 Which assumption is correct: "a recipe A that depends on another recipe B can use users/groups that B creates" or "all recipes must create the users/groups they require themselves"? May 16 08:44:23 i'm just trying to ti give it a first try, clean git clone, source the setup file, and then yocto-start-autobuilder breaks with http://paste.ubuntu.com/7471774/ May 16 08:44:23 bluelightning: in case it rings a bell please scream, otherwise i'll wait for pidge to poke May 16 09:57:33 hi everyone, I am having trouble building yocto for the omap5 evm May 16 09:57:52 I am trying to add the omap5-sgx package May 16 09:58:08 but I am getting erros during build May 16 09:58:18 error: file /usr/lib/libGLESv2.so.2 conflicts between attempted installs of omap5-sgx-ddk-um-linux-1.9.0.10-r1.armv7a_vfp_neon and libgles2-mesa-9.2.5-r0.armv7a_vfp_neon May 16 09:58:59 anyone an idea how to tell bitbake to use only the omap5-sgx stuff instead of the mesa? May 16 10:07:28 use PREFERRED_PROVIDER May 16 10:07:36 is this your own bsp, or eg meta-ti? May 16 10:08:49 basically you need to set PREFERRED_PROVIDER_virtual/libgles2 to omap5-sgx, or whatever the recipe is calle May 16 10:08:52 called May 16 10:16:28 meta-ti May 16 10:17:15 I set PREFERRED_PROVIDER_virtual/libgles2 = "omap5-sgx-ddk-um-linux" May 16 10:17:22 in conf/local.conf May 16 10:18:45 could it be that there are some tmp files I need to delete? May 16 10:25:57 in this case tell meta-ti they've broken something May 16 10:26:08 you'll need to use the *recipe* name May 16 10:28:04 which receipe name do you mean? is there one for libgles? May 16 10:35:30 the recipe that generates omap5-sgx-ddk-um-linux-1.9.0.10-r1.armv7a_vfp_neon May 16 10:36:47 ok, will try that May 16 10:40:29 is there a way to print all PREFERRED_PROVIDER ? May 16 10:41:14 grep will do it :) May 16 10:41:14 or bitbake -e May 16 10:42:17 :) thanks i'm already greping the hell out of my ssd :) May 16 10:52:16 default definition is in meta/, there should be another in meta-yi May 16 10:52:18 meta-ti May 16 11:21:36 Trying this again since I got no answer the first time. Which assumption is correct: "a recipe A that depends on another recipe B can use users/groups that B creates" or "all recipes must create the users/groups they require themselves"? May 16 11:34:04 Saur: in my experience only a few programs/demons add specific users/groups May 16 11:34:34 I can't imagine how to generalize May 16 11:37:50 ant_work: Well, the problem for us is that we have a lot of recipes that do. And if the first assumption is correct then the useradd.bbclass needs to be corrected so that it adds a dependency from do_install to base-passwd:do_populate_sysroot and base-passwd:do_populate_sysroot_setscene, because if either of those tasks execute they will overwrite /etc/passwd and /etc/group, effectively removing any users/groups that were created before... May 16 11:50:04 Saur: I see, it is not obvious May 16 11:51:18 ant_work: Nope, I agree. On the other hand, if it is the second assumption that is correct, then there should be QA tests in place to make sure all recipes create the users/groups they use. May 16 11:51:49 I think that any recipe should care itself May 16 11:52:23 same in Gentoo: "..If your ebuild requires a user or group to be added for a daemon, for example, this should be performed via the functions available in user.eclass.." May 16 11:52:55 ant_work: I would prefer that as well. However, then you end up with the problem that the first recipe that creates a user "wins", which means that you must make sure that the user definition is exactly the same in all recipes... May 16 11:55:24 Saur: see the interesting check done http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/user.eclass?view=markup May 16 11:55:52 at first, check that we are in preinst/postinst May 16 12:05:23 exactly that May 16 12:05:25 if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ] May 16 12:57:35 hi May 16 12:58:36 master-next, core-image-minimal build for imx6, libudev do_configure: "configure: error: "udev support requested but libudev not installed"" May 16 12:59:01 but udev.inc:DEPENDS = "acl glib-2.0 libusb usbutils pciutils gperf-native libxslt-native util-linux" May 16 12:59:07 circular dependency? May 16 12:59:42 building libusb with --disable-udev works May 16 13:00:58 libusb was updated yesterday, libusb1: Update to 1.0.18 May 16 13:25:09 simmel80___, http://lists.openembedded.org/pipermail/openembedded-core/2014-May/092651.html May 16 13:27:31 thanks, kroon May 16 13:33:02 kroon, i am not very experienced in yocto/OE, so cannot judge if it is right, but does it work around the circular dependency that i think there is, when udev is part of the build May 16 13:33:38 then udev depends on libusb, and libusb would try to build against libudev.h, or do i misunderstand? May 16 13:40:46 simmel80___, hmm good q.. I'm not sure about that problem. Target libusb1 build fine on my laptop, I only had a problem with nativesdk-libusb1 May 16 13:43:25 kroon, for my case, target libusb1 failed to build, on "bitbake core-image-minimal", i did not try nativesdk May 16 13:50:24 kroon, and this was from scratch, i think it would maybe work if the udev would already have been built previously May 16 13:52:09 simmel80___, aha. yeah theres a difference, i did an incremental build, with the libusb1 update. on the other hand I dont see anyhing changed in the recipe with regards to DEPENDS May 16 13:52:55 my guess is that the source changed, to now depend on libudev.h by default May 16 13:53:24 yeah could be May 16 15:46:01 seebs: FYI, was getting XATTR_CREATE not defined building pseudo, seems like you need a #include May 16 15:46:43 i don't suppose anyone knows how to have a spec file without a source: in May 16 16:00:58 arg. switched my emails on the mailing lists and managed to disable "receive emails" May 16 16:01:06 heh, oops May 16 16:01:20 DarkKnight: but what a productive week! May 16 16:01:28 yep. I knew my inbox was suspiciously empty. May 16 16:02:11 rburton: hehe, there's more than one DarkKnight / darknighte hanging around here these days... May 16 16:02:30 oh damnit adium May 16 16:02:36 * darknighte wonders who that masked DarkKnight is May 16 16:03:15 DarkKnight: it's Evil Sean from the darkest timeline May 16 16:03:19 did it again!! May 16 16:03:33 adium's completion algorithm is actually malicious May 16 16:07:02 darknighte: cloning yourself? May 16 16:26:36 LetoThe2nd: Hey, ab stuff. You pinged? May 16 16:27:22 pidge: kind of. didn't want to poke you directly until i digged it a bit deeper. just asked paul as he joined the time i was stuck May 16 16:27:54 pidge: turned out (just 5 minutes ago) that it was just missing dependencies that made it fail kind of ungracefully May 16 16:28:20 LetoThe2nd: which one? May 16 16:28:50 pidge: about all of them. when trying such stuff i usually start with a clean slate machine, in this case ubuntu May 16 16:28:55 LetoThe2nd: In theory all the deps for the ab should be there. if they aren't, lemme know. May 16 16:29:12 oh, was this an oe dep? May 16 16:29:27 pidge: then git pull, . ./yocto-autobuilder-setup, then ./yocto-start-autobuilder both May 16 16:30:26 starting then breaks if the things needed for building are not installed, like make May 16 16:30:40 pidge: check http://paste.ubuntu.com/7471774/ May 16 16:31:29 LetoThe2nd: Ah, yeah. that is a dep generally satisfied by oe. May 16 16:32:01 LetoThe2nd: If you'd like to open up a bug that would help me. May 16 16:32:27 pidge: sure, but i took the super dumbass approach and went like "hey, whatever it needs, it should be noted in the readme" May 16 16:33:02 as there was nothing noted there, i thought "probably it starts, just won't do anything useful" May 16 16:33:11 which it then didn't May 16 16:33:15 LetoThe2nd: Yeah, I think there are two bugs here. 1. A big more docs on deps. 2. Some better error condition handling May 16 16:33:43 pidge: yeah, interpreting it that way is certainly right (no offense meant) May 16 16:33:48 Huh, I shouldn't need to include , because in general as I understand it user code shouldn't need to include linux/anything because kernel headers are mostly for kernel stuff. May 16 16:33:58 I will have to investigate more. May 16 16:35:10 LetoThe2nd: none taken at all. The ab rewrite is relatively new (just over 16 months). There's still a bit of spit and polish that's needed around docs/dev experience. May 16 16:36:55 pidge: i see! well i got it basically working right now and will dig a bit to find out whats really the needed stuff for reproducing an AB machine. if you're interested i can file some ideas for docs as a bug or send them to you May 16 16:37:23 LetoThe2nd: No, sure, file away. May 16 16:38:03 pidge: will do once i carved out what was just cargo cult and what was actually needed :) May 16 16:39:29 LetoThe2nd: Yeah, it's sometimes difficult finding holes as it's kind of surprising the different ways people use it. May 16 16:40:22 pidge: hehe i guess i'm the super trivial use case. box sitting in a corned producing root fs and sdks when needed for coworkers nothing more. May 16 16:40:30 s/corned/corner May 16 16:40:50 LetoThe2nd: Nah, no such thing as a trivial use case. May 16 16:41:27 pidge: too bad, i like being trivial May 16 16:45:42 pidge: kicked off first build, seems to be working :) thanks for repsonding, i'll let you know when i have something worthwhile reading/discussing :) May 16 16:45:59 LetoThe2nd: kewl. May 16 16:46:40 remember to have a nice weeked so far ;) May 16 17:15:56 Hello. Guess I'll just simply ask my question :) I've built an image with Yocto, but I've closed my terminal. When I open a new terminal, what do I need to run to set up everything correctly? bitbake is not in my path, although it was when I created my first image. May 16 17:16:01 So it took all of yesterday, but I can now explain why packages-split might have any of the following modes: 777, 755, 775, 700. May 16 17:16:43 Xooch: You'll need to . ./oe-init-build-env again May 16 17:16:57 Xooch: I don't know off the top of my head, but in case you aren't aware, you may sometimes need to hang around for a few hours before answers show up. Unless pidge is around. May 16 17:17:12 I thought so, but was a bit afraid that might "do more", since it created some directory structures and such. May 16 17:17:38 Xooch: Nah, it only does that if they don't exist the first time around. May 16 17:17:41 seebs - yeah, I figured that might be the case, but it appears I got lucky today! May 16 17:17:56 Thanks for the help. May 16 17:18:03 Xooch: np. May 16 17:18:22 seebs: I'm almost never around :P May 16 17:18:38 seebs: you can't leave that hanging! May 16 17:19:59 I think I left too early. running ". oe-layertool-setup.sh" closes my terminal! May 16 17:20:13 Huh, that's odd. May 16 17:20:28 My suggestion: May 16 17:20:31 $ sh -x May 16 17:20:35 $ . ./oe-layertool-setup.sh May 16 17:20:42 I don't think I'm current with the new release. I didn't start with poky, but with something from TI, and I think I'm on "dylan" if that makes any difference. May 16 17:20:46 then if that exits, you'll see what it executed. May 16 17:21:04 rburton: You would be amazed at what I can forget I started to talk about when I'm doing something else while chatting. :P May 16 17:21:23 Still closes that terminal. May 16 17:21:30 ... That's very odd indeed. May 16 17:21:36 Because it shouldn't be able to close the parent shell. May 16 17:21:53 Hmm. What if you ssh in to localhost and run it there? May 16 17:22:00 Then it shouldn't have any clue about the terminal. May 16 17:22:07 wait May 16 17:22:24 "oe-layertool-setup.sh"? Shouldn't it be "oe-init-build-env"? May 16 17:22:35 Okay, so, packages-split modes. May 16 17:22:41 Good idea. It says "ERROR: You must either use this script with the -i or -f options", prints usage, then closes the ssh connection. May 16 17:22:54 oooo.... May 16 17:23:00 Xooch: Yeah, is this a different thing you're trying to do? May 16 17:23:09 Yeah, I think layertool-setup.sh is the wrong thing, it's a command you'd invoke, not a thing to source into a shell to get your environment set up. May 16 17:23:44 populate_packages() calls umask(0) before iterating through making the directories for each package. It then uses bb.utils.mkdirhier() to make .../packages-split/pkgname. May 16 17:24:04 This creates packages-split with mode 777 if it did not already exist. And unfortunately, it does this BEFORE trying to make packages-split with a reasonable mode. May 16 17:24:14 So it is fairly common for packages-split to end up with mode 777. May 16 17:24:50 There is another path through this, which I'm not sure where it is but I found it once, which ends up running similar stuff only with umask 2; you can find this by looking for a warning note about running something with umask 002. May 16 17:24:59 That gets you the 777 and 775 cases. May 16 17:25:32 * kergoth chuckles May 16 17:25:37 755 appears to come from processing this with your regular 022 umask, or possibly unpacking an archive which includes that directory when you're not running under pseudo. May 16 17:25:41 700. Well. May 16 17:25:49 i agree it would be a good idea to add a mode argument for mkdirhier :) May 16 17:25:57 you're right, wrong script. The correct one is in sources/oe-core/oe-init-build-env it appears. I ran this from the top level dir and from the build directory, but I get an error about /home/steve/src/tisdk/sources/oe-core/bitbake not existing... Which directory should I be in to run it? May 16 17:26:21 If GNU tar thinks you're root, instead of creating directories with their desired mode, it creates them with mode 700, then does a delayed set of the file permissions. May 16 17:26:30 The delayed set goes through and eventually calls fchmodat(). May 16 17:27:05 There's a comment in the code, though, pointing out that Linux will always reject fchmodat(..., AT_SYMLINK_NOFOLLOW). So if the initial call fails with errno = ENOTSUP, it then tries again. May 16 17:27:33 Problem is: pseudo naively passes on the original fchmodat() arguments to the kernel, then discards any reported failures in case you were doing something like setting setuid bits, which pseudo wants you to think you could do. May 16 17:28:02 So the fchmodat(..., AT_SYMLINK_NOFOLLOW) doesn't "fail" for GNU tar, but the attempt to call fchmodat() on the underlying filesystem does. So the mode never gets changed from 0700. May 16 17:28:42 And that is why packages-split ends up with any of *four* different modes, in ways that are fairly unpredictable and not completely consistent within any given package. May 16 17:29:26 My proposed fix to bitbake is to add ", mode = 0755" to mkdirhier, and pass the mode to os.makedirs, because I am pretty sure we never *wanted* 0777 & ~umask as a default. May 16 17:30:17 For pseudo, my current plan is to add a static flag for whether I think AT_SYMLINK_NOFOLLOW should fail. Try normally once, but if I get -1/ENOTSUP from an fchmodat with AT_SYMLINK_NOFOLLOW, set the flag, and future calls will bail early if AT_SYMLINK_NOFOLLOW is set. May 16 17:31:00 That way, at least I don't do two database round trips per file for GNU tar's surreal decision to dutifully keep trying an unsupported thing for every single file just in case the user upgrades to a 4.x or later kernel which has implemented support for a new feature sometime during the extraction. May 16 17:31:31 (To be fair, if it were implemented per-filesystem, it would be conceivable for an archive extraction to cross a mount point...) May 16 17:35:16 FYI, I had to run ". conf/setenv" from my build directory. I'm working now. May 16 18:41:50 seebs: https://gist.github.com/kergoth/05cf40b0ea7782287a3b — if we ignore the username/id mapping from pseudo, those files listed as xuser are really uid 1000, which is the uid of the user doing the bitbake build. that ls -l was done under a devshell, of course. May 16 18:42:15 so you can see it was fine at ${D} after do_install, but the owner got lost as it got thrown into /package/ for use by do_package May 16 18:42:43 not sure if it's a pseudo problem or not, just throwing it out there, because i'm running out of ideas May 16 18:45:20 I'm gonna go with "I bet it's user error" in the sense that it could well be bitbake doing something with pseudo that doesn't work. May 16 18:46:17 kergoth: hey! I noticed one "unwanted" behavior of your copyleft. It will happily symlink a git repository. So every time I build a new kernel revision (e.g. 3.10.x) I will have to put ~700mb of data on our download site (sure I could turn on dedup on ZFS for that area). Do you know if the archiver is fixed in master or have you considered to create a tarball from the git repository? May 16 18:47:09 zecke: both copyleft_compliance and archiver will use a git mirror tarball if one exists. see https://github.com/openembedded/oe-core/blob/master/meta/classes/copyleft_compliance.bbclass#L42-L45 May 16 18:47:25 Okay, just to clarify, since I've never gotten to the message clarification thing. May 16 18:47:28 pseudo: path mismatch [2 links]: ino 5770631 db '/var/jenkins/workspace/drew/build/tmp/work/dbfp3-mel-linux/hostap-utils/0.4.7-r4/package/usr/sbin/hostap_rid' req '/var/jenkins/workspace/drew/build/tmp/work/dbfp3-mel-linux/hostap-utils/0.4.7-r4/package/usr/src'. May 16 18:47:38 does someone know a nice overview of kernel modules required for various iptables featurs? May 16 18:47:51 zecke: just enable BB_GENERATE_MIRROR_TARBALLS = "1" and you'll be fine May 16 18:48:03 What this means is that inode 5770631, which currently has two links, was in the database with the name ".../usr/sbin/hostap_rid", and showed up in a request attached to ".../package/usr/src". May 16 18:48:21 kergoth: okay. This will use "git archive" on the checkout to create the tarball? May 16 18:48:41 kergoth: thanks for the info. Let me re-build all images overnight and have a look. :) May 16 18:48:47 And that means that, at some point, usr/sbin/hostap_rid got noticed by pseudo and added to the database, and then it got unlinked *outside* of the pseudo environment. May 16 18:48:49 no idea, this is the standard bitbake mechanism for archiving the repository for use on mirrors, the fetcher supports downloading and using such a mirror tarball May 16 18:48:53 And something else reused the inode. May 16 18:49:12 seebs: huh, i don't see how that'd even be possible, all the packaging tasks run under pseudo May 16 18:49:21 weird May 16 18:49:49 Well, it's possible that some other task isn't running under pseudo because it doesn't need to. May 16 18:49:50 *thinks* May 16 18:50:09 Presumably, usr/sbin/hostap_rid got deleted. When did it get deleted? May 16 18:50:20 Is it possible that the thing which deleted it wasn't considered "a packaging task"? May 16 18:50:34 it should never have been deleted during the packaging process. that ls -l was after the build, so clearly it still existed there May 16 18:50:46 ls says its there after those tasks ran May 16 18:50:56 * kergoth shrugs May 16 18:51:12 again, it shouldn't have been deleted at all, ever. and if it was deleted, then why is it back again after the tasks ran? May 16 18:51:12 Okay, that is very odd. Because presumably it *somehow* got deleted-and-recreated or something. May 16 18:51:20 I assume it has a new inode now? May 16 18:51:21 odd indeed May 16 18:51:57 BTW, if you're using pseudo 1.6, the debug options are MUCH improved. May 16 18:52:18 No longer do you face the horrible nightmare of verbosity that was PSEUDO_DEBUG=2. May 16 18:52:52 Now you can do things like PSEUDO_DEBUG=f and get file creation/deletion notes, but not other stuff. May 16 18:53:01 oh! right, i see. do_package did its split out the debug info stuff May 16 18:53:17 so it got rereated without that May 16 18:53:23 but that should all have been done within do_package May 16 18:53:35 * kergoth scratches head May 16 18:54:21 Huh. May 16 18:54:24 Well, there's a possibility. May 16 18:54:50 One time we started seeing stuff like this, and the reason turned out to be that there was a path into the library that could make syscalls that pseudo wasn't intercepting. May 16 18:56:05 Wait. May 16 18:56:10 I bet I know. May 16 18:56:12 You're at MG, right? May 16 18:56:16 Are you using a binary toolchain? May 16 18:56:24 what's odd to me is the two dir errs are both the same /package/usr/sbin/hostap_rid, but neither of those inode numbers are the one it ends up being after the debug split. so it's existed with 3 different inode numbers during the packaging process, not 2 as one would expect May 16 18:56:31 Is it a ... 32 bit binary toolchain? On a 64-bit host? May 16 18:56:52 Because by default oe-core won't try to make a 32-bit pseudo library. And then the 32-bit binary toolchain components don't actually run under pseudo at all. May 16 18:57:01 And that can cause things like objcopy to wreck the pseudo database. May 16 18:57:35 meta-sourcery forces NO32LIBS = "0" in its tcmode May 16 18:57:47 * kergoth ponders May 16 18:57:48 Oh, right. And you'd be getting a ton of errors if that didn't work. May 16 18:58:15 You might want to try to run objcopy and such under pseudo in a test directory, see whether they work as expected and produce the right database entries. May 16 18:58:28 I suppose in theory there could be a statically-linked binary in there or something? May 16 18:58:30 good idea, I'll look into that. that does make sense, it would explain this behavior May 16 18:58:43 thanks for the help, need food now :) May 16 18:58:51 kergoth: hmm. It just tars the .git/ directory. But then again so did the archiver I used in edison May 16 18:59:33 zecke: ah, you want the opposite? would probably need to enhance it further May 16 19:23:02 seebs: so, yeah, I'm an idiot. I forgot that a while ago I disabled pseudo during toolchain binary execution. Horribly stupid, in retrospect. Course, at the time I didn't know how to deal with it. The toolchain created a lockfile in /tmp including the user id, so if multiple users built both under pseudo they'd step all over each other with the same naming but diffferent ownership. I should have seen this coming when I did that, that was stupid. I May 16 19:23:02 guess I hoped that writing the files into ${B} with wrong ownership would be corrected by do_install, which it is in 90% of cases, but objcopy kicked me right square in the ass :) May 16 19:26:18 seebs: so thanks again for helping me identify my foolishness :) May 16 19:26:22 * kergoth rolls eyes May 16 19:26:54 iptables on yocto does not accept '--dport' on my system\ May 16 19:27:09 never seen that before May 16 19:29:29 Oh, good. At least it makes sense. May 16 19:29:46 I actually spent a month or so ignoring lots of "unable to load libpseudo.so" messages because I somehow concluded they probably didn't matter. May 16 19:30:05 It was exactly that -- objcopy wasn't getting pseudo. It's the only part of the toolchain that usually runs in an environment where this matters. May 16 19:51:01 halstead: ping May 16 20:25:20 Okay, I am sure there's people here with use cases I've never thought of. May 16 20:26:08 ugh, I was adjusting the aeropress after I had put 100ml of near-boiling water from the kettle in it, and the cylinder slid out instead, dumping it directly onto my left hand. note to self: be more careful when making coffee May 16 20:26:10 pseudo does not store files on disk with exactly the same permissions they have in the database; right now, that just means it adds 0600 (or 0700 for directories) to the on-disk file, so you can write to files that have no write permission in the database. Because you're presumably root. May 16 20:26:17 Ow! May 16 20:26:36 So, after this mkdirhier thing and such, I am thinking that I wish to also mask *out* some write bits. May 16 20:27:07 And I'm currently leaning towards 022, but if someone can make a really good case for needing the on-disk files to be group-writeable, I'm willing to consider it. May 16 20:27:15 Pretty sure I want 002 masked out no matter what. May 16 20:42:56 Huh. There were two patches in oe-core for pseudo that never made it into upstream, now added to 1.6.0. May 16 20:46:34 ... May 16 20:47:00 So the URL in the pseudo recipe (https://www.yoctoproject.org/downloads/pseudo/pseudo-1.5.1.tar.bz2) goes to a very pretty web page, but does not actually give me a tarball? May 16 20:50:40 heh, that's not good May 16 20:51:40 downloads.yoctoproject.org seems to work. May 16 20:52:22 FWIW, I'm hoping to send out a patch shortly to add the fchmodat thing to pseudo 1.5.1, because I really want that fixed. I don't know when I'll have time to do an uprev to 1.6, but this one's small and nicely-contained. May 16 22:47:22 Crofton/Crofton|work: http://hackaday.com/2014/05/16/isee-3-ready-to-come-home/ COOOL. The SDR is running an oe built os, yes? May 16 22:49:18 pidge, no May 16 22:49:29 they will use a USRP attached to a laptop May 16 22:49:31 Crofton: Awwww May 16 22:49:37 yeah May 16 22:49:42 but still cool May 16 22:49:49 either way. very very cool May 16 22:49:49 Balint is pooping himself May 16 22:50:08 he is very excited May 16 22:50:59 I bet! May 17 00:23:58 did prelink git repo got rebased on yp org ? May 17 00:24:22 whatever SHA is locked in for dora branch is no more fetchable May 17 00:24:40 and I dont see that in the git repo anymore whats up here ? **** ENDING LOGGING AT Sat May 17 02:59:59 2014