**** BEGIN LOGGING AT Wed Feb 13 02:59:58 2013 Feb 13 07:11:21 anyone know if someone has blogger or otherwise written about their experiance on collaborating on a project using yocto? If there's some "lessons learned" that might be useful before starting up a project Feb 13 07:16:16 While building yocto, some packages seem to have build dependencies to the build host: dos2unix and libsdl1.2-dev for example. Is there a way to add 'build host' dependencies in .bb files? Feb 13 08:01:58 good morning Feb 13 09:21:43 morning all Feb 13 11:12:15 sigh, this thing really is driving me crazy, kernel-module-vivante is included in the final image but module_autoload_vivante doesn't make the module loaded on boot, no matter where I put it Feb 13 11:18:03 i wish cmake.bbclass used the same variables as autotools.bbclass as you can't PACKAGECONFIG a cmake recipe :( Feb 13 11:21:43 where is module_autoload_* supposed to reside exactly? Feb 13 11:33:08 erbo: what you mean about experience? Feb 13 11:33:36 erbo: you can scan though my http://marcin.juszkiewicz.com.pl/ - maybe will find something Feb 13 11:40:21 hrw: I'm already a frequent reader of your blog :) Feb 13 11:40:35 :D Feb 13 11:41:55 hrw: I'm looking for some info on how to have 10-20 developers working on a product based on yocto. Should everyone use a build server or their own local setup, maybe trigger rebuilds on git-commits etc Feb 13 11:43:27 maybe replicate some of the autobuilder functionality internally, or maybe just script something more minimalistic Feb 13 11:45:39 erbo: a central server doing autobuilders and sharing the sstate over the network would mean everyone else can re-use that build output Feb 13 11:45:59 erbo: if developers work on apps then give them sdk (meta-toolchain) and let they work on code Feb 13 11:46:05 erbo: if you're all working on the same project, you'll all have very similar configurations Feb 13 11:46:20 erbo: central autobuilder would build their apps from scm HEAD Feb 13 11:46:50 and like Ross said - central sstate-cache + sources mirror Feb 13 11:47:36 erbo: it will be different for different roles - distro engineers will need to rebuild the distro, app engineers can take the nightly distro build and use the SDK generated Feb 13 11:47:41 sdk/images/etc Feb 13 11:49:05 erbo: when I worked for Buglabs we had autobuilder doing fresh and incremental builds (like OH autobuilder did years ago) and used output for testing. app/lib developers were using SDK and pushed to svn. autobuilder fetched from svn Feb 13 11:49:39 ~curse bugs which appear under 12.04 but not under 13.04 uubntu Feb 13 11:50:49 hrw, rburton: thanks for the hints, now I have a pretty good idea of what I should be aiming for! Feb 13 11:51:09 erbo: once implemented write a blog post about it Feb 13 11:52:48 hrw: I should definately do that :) Feb 13 11:53:07 I think that it would get some readers Feb 13 11:59:37 is it ok to change packaging backends without rebuilding? switched to ipk from rpm and the resulting image doesn't mount /dev and /proc, should I rebuild some packages (all?) Feb 13 12:00:06 afaiu, it's ok to do it, I'm just wondering if I'm missing some detail Feb 13 12:00:48 -I/usr/include argh.... Feb 13 12:48:42 Reposting this q: While building yocto, some packages seem to have build dependencies to the build host: dos2unix and libsdl1.2-dev for example. Is there a way to add 'build host' dependencies in .bb files? Feb 13 12:51:04 mcfrisk: DEPENDS ? or do I misunderstand the q Feb 13 12:53:15 eFfeM_work: I had build errors that were fixed by installing tools and headers to the build host, a Debian wheezy box. Feb 13 13:11:15 mcfrisk: was afk, there are a few utils that need to be there Feb 13 13:12:03 mcfrisk: see http://www.yoctoproject.org/docs/1.0/yocto-quick-start/yocto-project-qs.html section "The Packages" Feb 13 13:12:48 these are core host packages that are needed on the host in order to get things going Feb 13 13:15:19 hi folks, does anyone know if there is an easy way to have yocto not build any kernel recipe at all? Feb 13 13:27:36 can I tell bitbake to delete older images in tmp/deploy/images _properly_? there is a README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt file in that dir, but I need to clear up some space Feb 13 13:34:10 markos_: you can delete images you won't be using anymore, just don't delete the kernel images(bzimage*, zimage*, uImage* etc) Feb 13 13:34:30 ah cool, good to know Feb 13 13:34:32 markos_: look here for more info: http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html Feb 13 13:34:46 markos_: section 5.2.14. build/tmp/deploy/images/ Feb 13 13:35:28 right, thx Feb 13 13:35:35 markos_: read that well before deleting :) Feb 13 13:37:09 markos_: you might want to use rm_work Feb 13 13:37:43 and you can always just nuke all of tmp and rebuild, sstate will cause that rebuilding is reasonably fast Feb 13 13:38:16 eFfeM_work, already using rm_work, but rebuilding everything takes way too long here :) Feb 13 13:41:26 markos_: deleting just tmp but leaving sstate means you can rebuild from nothing to an image in a few minutes Feb 13 13:41:47 markos_: something like 5 minutes from just sstate to a core-image-sato image Feb 13 13:42:33 ok, will try that Feb 13 13:42:34 thanks Feb 13 13:44:26 cristianiorga: ping Feb 13 13:47:52 eFfeM_work: thanks, libsdl1.2-dev was there. One of our packages also needed dos2unix so that's why asked if these can be written down as dependencies on build host. But I guess the answer is no. Feb 13 13:49:05 mcfrisk: the majority of them in are vast numbers of recipes Feb 13 13:49:31 mcfrisk: the sanity checker should be checking for them though Feb 13 13:50:28 rburton: I'm newbie with yocto, could you share a link to example or documentation? Feb 13 13:52:26 rburton, takes slightly more than 5 minutes, I think it will take more likely 20min, but yeah it's faster than I thought :) Feb 13 13:55:32 depends on your machine i guess Feb 13 13:57:53 mcfrisk: if you don't have say patch installed, the santiy checker (meta/classes/sanity.bbclass) will error on startup Feb 13 13:58:15 possibly there are host-dependencies which are not enforced, as some depend on what you build Feb 13 14:01:02 ignus: use linux-dummy as provider of virtual/kernel Feb 13 14:02:01 markos_: do sstate-cache builds in tmpfs Feb 13 14:02:19 good tip Feb 13 14:02:49 markos_: that's tmp in tmpfs, not sstate, obviously :) Feb 13 14:02:55 yes Feb 13 14:03:09 http://marcin.juszkiewicz.com.pl/2013/01/11/doing-openembedded-builds-in-ram/ Feb 13 14:03:20 rburton: got it, thanks! Feb 13 14:03:51 http://marcin.juszkiewicz.com.pl/2008/07/01/packaged-staging-and-what-it-gives/ is one of oldest blog posts about sstate-cache like functionality Feb 13 14:04:50 hrw: thanks! i just figured that out :D Feb 13 14:05:14 hrw: ah packaged staging Feb 13 14:05:26 rburton: eons... Feb 13 14:18:34 what might be at fault when for the same target, rpm backend makes a bootable image, but ipk and deb backends fail because both /dev and /proc are not mounted on boot time? Feb 13 14:18:58 only change is PACKAGE_CLASSES var in local.conf Feb 13 14:19:43 that's distressing Feb 13 14:19:55 extract the generated root filesystems, and do a diff on them? Feb 13 14:20:09 (i use ipkg all the time, i wouldn't trust deb though) Feb 13 14:21:02 weirdly enough, fstab includes both /proc and /dev Feb 13 14:21:49 actually just /proc Feb 13 15:51:39 hmmm. packagegroup-core-boot won't install due to conflicts with init-ifupdown. anyone else seeing that in master ? Feb 13 15:51:54 * zeddii is just trying to boot test 3.8 and is hitting this. Feb 13 15:54:07 hello i am trying to copy a file to the /etc/ dir of the rootfs i am creating but my recipe dose not seem to worke ... any help ??? : SUMMARY = "copy the os-release file" Feb 13 15:54:08 LICENSE = "TPLINO" Feb 13 15:54:08 SRC_URI = "file://os-release/os-release" Feb 13 15:54:08 do_install() { Feb 13 15:54:08 cp ${WORKDIR}/os-release ${D}/etc/ Feb 13 15:54:09 } Feb 13 15:55:21 you didnt' create the etc directory first. Feb 13 15:55:27 install -d or mkdir -p ${D}/etc Feb 13 15:55:36 also, you should use ${sysconfdir} rather than /etc Feb 13 15:55:37 oh thx Feb 13 15:55:48 and add the package name of taht recipe to the IMAGE_INSTALL of the image Feb 13 15:56:52 do i have to create the directory before if i use ${sysconfdir} Feb 13 15:57:01 yes Feb 13 15:57:21 you have to create every directory under ${D}, as its empty to start with Feb 13 15:59:50 should the IMAGE_INSTALL be located in the distro config file Feb 13 16:00:48 wfailla: or local.conf, or whatever. Feb 13 16:01:38 rburton: thx Feb 13 16:05:51 it throws back an error that the file could not be fetched ... the file os-release is located in the same directory as the .bb file how can i make copy it ? Feb 13 16:06:26 your SRC_URI is wrong Feb 13 16:06:35 just file://os-release Feb 13 16:07:07 i think that will change the location it gets unpacked to, which will cause problems in install Feb 13 16:09:04 well then my whole recipe is bad ... what i want to do is to copy that file (os-release) to the rootfs /etc/ can i do that like that or is there a better way ?? Feb 13 16:09:22 apart from that you're good Feb 13 16:09:46 fix the SRC_URI, add a mkdir -p Feb 13 16:09:56 will do Feb 13 16:10:49 still an error: os-release: Recipe file does not have license file information (LIC_FILES_CHKSUM) Feb 13 16:11:26 i thought that was a warning Feb 13 16:12:46 LIC_FILES_CHKSUM="file://${WORKDIR}/os-release;md5sum=[the checksum]" Feb 13 16:12:54 that's going to be a bit annoying though Feb 13 16:13:33 you could put a file next to the os-release that says "os-release is [whatever license]", and checksum that Feb 13 16:14:17 or LICENSE = "CLOSED" Feb 13 16:14:18 * rburton looks at what other packages do in this case Feb 13 16:14:19 im new to all this how do i create a md5 checksum Feb 13 16:14:33 if the package is just adding a single file Feb 13 16:14:33 wfailla: put 1 and bitbake will tell you, or run "md5sum [filename]" Feb 13 16:15:27 ah, oe-core tends to set LICENSE=MIT and then checksum the top-level license file Feb 13 16:15:31 that works Feb 13 16:17:44 JaMa: are you the meta-qt5 maintainer? Feb 13 16:20:03 sort of Feb 13 16:20:36 JaMa: there's beer in it for you if you turn on wayland support Feb 13 16:21:41 hey a new error : cp: omitting directory ... btw LICENSE = "CLOSED" worked best thx jackmitchell Feb 13 16:22:32 what dose omitting mean Feb 13 16:22:44 "leaving out" Feb 13 16:22:53 rburton: first I have to fix sstate interaction, then upgrade to 5.0.1 and wayland is next step Feb 13 16:23:12 wfailla: do bitbake -c clean [your package name], i suspect as you've been messing with SRC_URI you've got a messed up builddir. Feb 13 16:23:13 rburton: not sure if I manage to fix all that before ELC Feb 13 16:23:25 JaMa: you'll have to wait for ELC-E anyway Feb 13 16:23:38 rburton: i will try that Feb 13 16:23:40 ah ok, plenty of time Feb 13 16:23:57 JaMa: i'd like to see it supported for the 1.4 release. do you have any plans to push qt5 into oe-core, replacing qt4? Feb 13 16:24:33 not sure about replacing, but the plan is to add it to meta-oe or oe-core when it's ready Feb 13 16:24:54 JaMa: just think of the prestige when oe-core/qt5 supports wayland before gtk3 does. Feb 13 16:25:22 rburton: don't tell me you're joining the other side now... ? ;) Feb 13 16:25:46 bluelightning: just hoping the psychological battle will encourage jama ;) Feb 13 16:25:51 rburton: well now it does not even parse correctly for me and I don't have time to fix that :/ Feb 13 16:25:58 JaMa: awww Feb 13 16:26:01 rburton: did not work Feb 13 16:26:06 not meta-qt5.. systemd.. Feb 13 16:26:12 JaMa: eh? Feb 13 16:26:23 wfailla: pastebin your recipe pls Feb 13 16:26:54 rburton: incompatibility between systemd.bbclass from oe-core and meta-systemd.. Feb 13 16:27:01 (yocto needs its own pastebin, and then kergoth can add a pastebin command to bb) Feb 13 16:28:00 rburton: that would be awesome Feb 13 16:28:14 rburton: http://pastebin.com/VATdRKzm Feb 13 16:29:01 and something like old oestats-client.bbclass Feb 13 16:29:10 wfailla: I think it should just be: cp os-release ${D}/etc/ Feb 13 16:30:07 or maybe: cp ${S}/os-release ${D}/etc/ Feb 13 16:30:17 in do-install, cwd is $B (so, $S) Feb 13 16:30:42 wfailla: where is this os-release file? Feb 13 16:30:56 wfailla: i'm probably making bad assumptions about your recipe's contents Feb 13 16:31:10 rburton: i did a cleanall befor but still no price Feb 13 16:31:33 rburton: the os-release file is in the same directory as the bb file Feb 13 16:33:17 wfailla: you should make a directory called files, and put the os-release file in there, like so: https://github.com/openembedded/oe-core/tree/master/meta/recipes-support/libassuan Feb 13 16:34:18 wfailla: that error sounds like its finding a directory called os-release instead of a file Feb 13 16:34:52 have a look in tmp/work/[machine]/[recipe name] Feb 13 16:36:23 rburton: say i create a directory in the same directory the .bb file is and call it files then place the os-release in there the SRC_URI should then read "file://files/os-release" ? Feb 13 16:36:38 do _append tasks work additively (eg, can I have do_install_append() in a recipe and then add a 2nd do_install_append() in a .bbappend and it will add itself to the first?) Feb 13 16:36:44 no, just file://os-release Feb 13 16:36:48 halstead: for future info, that patch needs to go to the oe-core list with a SOB line and commit message matching the guidelines (correct summary line) Feb 13 16:36:55 markos_: yes, they'll all pile up in the parse order Feb 13 16:36:59 rburton, cool, thanks Feb 13 16:37:11 halstead: It does look like a good fixup for the abs though so I can fix it up if appropriate Feb 13 16:37:39 wfailla: the directory name is for separating files per recipe/version. bitbake will look in a number of directories for the filename. Feb 13 16:38:00 jackmitchell: say i create a directory in the same directory the .bb file is and call it files then place the os-release in there the SRC_URI should then read "file://files/os-release" ? Feb 13 16:38:36 wfailla: no, just file://os-release Feb 13 16:38:45 files, is the default directory that files:// looks in Feb 13 16:38:55 jackmitchell: well, it's actually the last but one Feb 13 16:39:05 jackmitchell: pn-pv, pn, files, . iirc Feb 13 16:39:40 rburton: files is _one_ of the default directories that files:// looks in ;) Feb 13 16:39:43 :) Feb 13 16:41:36 jackmitchell: rburton: new error: cp: cannot stat `os-release': No such file or directory Feb 13 16:41:51 wfailla: do you still have WORKDIR in the cp? Feb 13 16:43:59 rburton: no new pastebin: http://pastebin.com/Lg5bNyWE Feb 13 16:44:25 wfailla: you need workdir in that cp Feb 13 16:44:41 wfailla: that's trying to copy a file called os-release from the root directory of your build machine Feb 13 16:44:47 rburton: why??? Feb 13 16:45:17 wfailla: because you do. current directory isn't WORKDIR, but somewhere else Feb 13 16:45:43 rburton: yes saw your text to late ^^ Feb 13 16:46:46 rburton: now its working thx Feb 13 16:48:15 wfailla: np. the big problem was your SRC_URI, which put the file in a directory for you Feb 13 16:58:11 rburton: wow now if done it ... the build is total junk now ^^ Feb 13 17:10:06 hi everybody. Does anybody know a way to apply all the patches in a bundle with pwclient like: http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/ Feb 13 17:10:34 Thanks RP. I'll get that patch done properly. Feb 13 17:11:22 halstead: Its ok, I reworded and merged it Feb 13 17:11:29 * RP is running out of time to get these things in Feb 13 17:11:48 RP, Is there anything left for me to do with it? Feb 13 17:11:58 halstead: no :) Feb 13 17:12:09 RP, Thanks again. Feb 13 17:20:41 resending because xchat did something weird and I'm not sure it went through: Feb 13 17:20:44 I am having trouble with bitbake re-running a bunch of tasks on each build. How do I debug what is going on? It is re-running my custom 'copy_image' task each time I build for each of my custom packages as well as the tasks that run after it. Feb 13 17:20:49 this is a new problem I'm having with 1.3, I was previously on 1.2 and it didnt do this. Feb 13 17:20:59 can I do something like this: RDEPENDS_${PN} = "gst-plugins-good*" ? Feb 13 17:22:54 halstead: np, thanks for debugging it :) Feb 13 17:23:23 my custom task is: http://pastebin.ubuntu.com/1644936/ Feb 13 17:23:44 ftonello: no, you'd usually create a package to contain those things, then depend on it. perl-modules is an example of a "catch all", the kernel has one too Feb 13 17:24:43 michael_e_brown: is there some kind of DATE or TIME usage in there which changes? Feb 13 17:24:56 no Feb 13 17:25:23 the entire task is simply creating a cpio of the image directory/ Feb 13 17:25:57 is it ${sysconfdir} (for /etc in target image) or ${D}/${sysconfdir} ? Feb 13 17:26:00 michael_e_brown: if it generates different stamp hashes, try comparing two hashes with bitbake-diffsigs Feb 13 17:26:11 markos_: in a do_install? Feb 13 17:26:17 RP, yes Feb 13 17:26:23 ${D}${sysconfdir} Feb 13 17:26:28 well, in a do_install_append, but yeah Feb 13 17:26:35 ah the / is appended then Feb 13 17:26:36 cool Feb 13 17:26:37 thanks Feb 13 17:26:50 markos_: sysconfdir = "/etc" Feb 13 17:27:00 lol Feb 13 17:27:33 ok, at least I didn't do rm -rf ${sysconfdir} :) Feb 13 17:28:47 RP, I've tried 'bitbake -S myimagename' and I get: Feb 13 17:28:50 ERROR: Bitbake's cached basehash does not match the one we just generated (/home/michael_e_brown/build-cmc-admin/build-yocto-cmc/../meta-plasma/recipes-dell/cmc/plasma.bb.do_rootfs)! Feb 13 17:28:50 ERROR: The mismatched hashes were c39f3f89df6ef3809104c706fed68b47 and 020de7dbb00c77620fd82098833e5784 Feb 13 17:28:50 NOTE: Tasks Summary: Attempted 0 tasks of which 0 didn't need to be rerun and all succeeded. Feb 13 17:29:09 and I've not been able to figure out where to go from there despite some code reading and googling Feb 13 17:30:38 michael_e_brown: easiest thing is to go into tmp/stamps and find the ones for this task Feb 13 17:30:59 michael_e_brown: than bitbake-diffsigs michael_e_brown: -S just saves out more info files without building anything Feb 13 17:31:38 markos_: that is one reason not to build as root :) Feb 13 17:31:57 RP, yeah, building as normal user Feb 13 17:35:54 RP, ok Feb 13 17:40:38 RP, I built the same package twice in a row and bitbake-diffsigs gives no output between the two siginfo files Feb 13 17:40:41 * zeddii watches gcc rebuild for the 2nd time today. Feb 13 17:42:57 is there anyway to tell a bitbake (from a recipe) that I always want to build the recipe from scratch? Feb 13 17:43:06 michael_e_brown: its odd it would build it again without a different stamp file :/ Feb 13 17:43:14 i mean, ignore the states cache Feb 13 17:43:30 ok, I see 'do_package' is giving me a different sig that I dont understand... sec. Feb 13 17:43:59 rp: http://pastebin.ubuntu.com/1645089/ Feb 13 17:44:25 I don't quite understand how to interpret the output or if it matters at all Feb 13 17:45:46 for the second, I did a bitbake -c clean -c cleansstate cfgmrd and then rebuilt it. not sure if this is what is causing it to redo my tasks or not. Feb 13 17:45:52 michael_e_brown: they have the same hash yet its showing differences so I don't understand that either. Are those different machines? Feb 13 17:45:59 nope Feb 13 17:46:01 same machine Feb 13 17:46:07 same dir, etc Feb 13 17:46:12 michael_e_brown: if you cleansstate, it would rebuild? Feb 13 17:46:52 michael_e_brown: what is cfgmgrd1 verses cfgmgrd2 ? Feb 13 17:47:27 I saved the contents of tmp/stamps/ppc603e.../cfgmgrd-* to two different dirs for each build Feb 13 17:47:55 you'll have to excuse me if I'm not doing it write, I've tried googling around a lot to fix this, but I still feel lost Feb 13 17:48:00 *right Feb 13 17:50:16 michael_e_brown: I'd have expected two different hashes if this was the problem Feb 13 17:50:45 michael_e_brown: I don't understand why you run cleansstate though since that will wipe out all previous build data and force a rebuild Feb 13 17:51:16 ah, ok, let me explain, maybe I'm not getting the data I think I need. Feb 13 17:52:08 when I do a "bitbake plasma" (my image target), it rebuilds do_copy_image and do_package_write_ipk steps for all my custom packages (not the poky ones upstream, though) Feb 13 17:52:50 so to get some data for diffsigs, I re-built cfgmgrd (a random component) to see, by forcing it (I have some wrappers that just do that automatically) Feb 13 17:53:08 maybe I should just run 'bitbake plasma' twice. i'll try that, sec. Feb 13 17:57:46 RP, so: if I run 'bitbake plasma' twice, it re-does the do_copy_image and do_package_write_ipk steps for all my packages. I did this twice in a row and saved the stamps for "cfgmgrd" (random component). There are absolutely no differences in the sigs afaict: Feb 13 17:58:18 rp: http://pastebin.ubuntu.com/1645179/ Feb 13 18:01:17 is it possible to rename files while installing them into multiple packages in one bb recipe? Feb 13 18:02:01 PACKAGES += "${PN}-a ${PN}-b" Feb 13 18:02:43 now I want to package file ${S}/a.txt into ${PN}-a as text.txt Feb 13 18:03:01 and ${S}/b.txt to ${PN}-b also as text.txt Feb 13 18:03:32 LunohoD, but then you'd have a file conflict between the two packages... Feb 13 18:05:01 michael_e_brown: so the question is why does it redo do_package_write_ipk Feb 13 18:05:07 michael_e_brown: since that happens before your task Feb 13 18:05:20 RP, yes, that's what I'm trying to figure out Feb 13 18:05:24 michael_e_brown: need to step afk I'm afraid Feb 13 18:05:25 thus far, unsuccessfully. Feb 13 18:05:43 and why does it do it only for my packages... i'm obviously doing something wrong/wierd Feb 13 18:05:50 *weird Feb 13 18:06:06 michael_e_brown: well, I'd like to have mutually exclusive packages with different sets of settings for the application Feb 13 18:06:53 LunohoD, what I would personally do is look at the package.bbclass Feb 13 18:08:05 michael_e_brown: thanks! Feb 13 18:08:25 you may be able to _append one of those functions or redefine to do your thing, but it's not likely to be pretty Feb 13 18:09:40 LunohoD, do_package runs all the functions in PACKAGEFUNCS variable. You should be able to add a function which mangles the files to your liking. Feb 13 18:09:48 LunohoD: try installing them as a.txt, b.txt, and then using update-alternatives to maintain a text.txt symlink. the advantage there is that you can install all configurations at once, and switch a single update-alternatives command Feb 13 18:10:09 LunohoD, I'd second rburton's comment Feb 13 18:18:59 rburton: please take a look at v6 of my patch Feb 13 18:19:01 rburton: http://patches.openembedded.org/patch/44213/ Feb 13 18:19:17 rburton: if you get a chance Feb 13 18:45:33 anyone seeing | useradd: cannot lock /etc/passwd; try again later. Feb 13 18:45:33 | WARNING: useradd command did not succeed. Retrying... Feb 13 18:45:33 | ERROR: tried running useradd command 10 times without success, giving up Feb 13 18:45:42 messages todays master ? Feb 13 18:45:50 its when building openssh Feb 13 18:48:14 I wonder if Feb 13 18:48:14 pseudo_git.bb: Bump to pseudo 1.4.4. Feb 13 18:48:20 is to blame Feb 13 18:49:03 khem: Internally we reverted the pseudo 1.4.4 Feb 13 18:49:18 seebs, ^^ Feb 13 18:49:27 khem: As far as I know seebs is actively looking at it. Feb 13 18:49:48 He is examining all sort stuff stuff at the moment related to this. Feb 13 18:50:13 Obviously you should revert the pseudo 1.4.4 locally, and possibly upstream as well for now. Feb 13 18:50:16 well it should be done externally first Feb 13 18:50:19 :) Feb 13 18:50:33 or atleast a quick message about issue would help Feb 13 18:50:56 The issue was only uncovered ~ 5hours ago, and still under investigation. Feb 13 18:50:58 ok I can confirm that reverting that commit helps Feb 13 18:51:04 so thats the right commit to blame Feb 13 18:51:28 it seems no one build openssh these days Feb 13 18:52:21 khem: Because there is other things broken with it? I do know we are building this on a regular basis. Feb 13 18:52:22 jstashluk: been on my todo list, sorry Feb 13 18:52:56 I have my own layer providing my own image. how can I use a static IP instead of DHCP? Feb 13 18:53:07 Oh, hey. Saves me the trouble of asking whether anyone had seen that. Feb 13 18:53:34 I am ... very confused by that. I am pretty sure that the change in 1.4.4 shouldn't be able to break anything that wasn't broken in 1.4.3 also. Feb 13 18:54:31 Obviously, I have missed something. Currently trying to reproduce it. A casual effort suggests that useradd is ending up trying to create links in /etc, as though it expects to be rather more chrooted than it is. Feb 13 18:54:34 *blink* Feb 13 18:54:47 Oh, wait. When I say it like that I see an obvious design flaw. Feb 13 18:56:22 Ah-hah! Feb 13 18:57:05 I think I see something that would adequately explain this. I bet that if you happened to try it on a system old enough not to have *at() functions it'd be fine. Feb 13 18:57:12 And I need to add more chroot test cases. Feb 13 18:57:24 seebs: ubuntu 13.04 here Feb 13 18:57:49 and even happens on 12.04 Feb 13 18:58:10 Yeah. It's OLD systems that would be working still. Feb 13 18:58:16 Like, RHEL4 or something. Feb 13 18:59:08 At this point, I have a very likely explanation, the one thing left bugging me is that I want to know why I thought I wanted to call linkat() on these paths before doing the path expansion dance. Feb 13 18:59:31 I think it was just an unconsidered assumption that the linkat() wrapper should call linkat(). Feb 13 19:05:11 I have a trivial reproducer and a probable fix. Feb 13 19:24:06 Well, that's an amusing oversight. Feb 13 19:24:30 Basically all of the *at() function implementations are calling an underlying *at() function with dirfd and an absolute path. Which is sort of pointless. Feb 13 19:24:57 I tried to avoid that when I was writing linkat(), for reasons not adequately explained, and of course it didn't work. Feb 13 19:25:20 So, on the to-do list: At some point, I should clean that up in all the other cases, which are currently working but slightly redundant. Feb 13 19:51:19 otavio: ping Feb 13 19:51:38 jstashluk: pong Feb 13 20:07:34 building core-image-sato from HEAD for beagleboard fails for me at do_rootfs: http://pastebin.com/BiTAzw2v Feb 13 20:08:13 the update_font_cache feature looks fairly new (jan 31) Feb 13 20:09:17 I've changed fontcache.bbclass to make it output some more, because it failed silently. Feb 13 20:10:01 I have no idea what the pseudo: Couldn't chdir to server directory message means. Any ideas? Feb 13 20:35:13 Okay, so. Feb 13 20:35:22 I have *in theory* sent the 1.4.5 pseudo update to the oe-core list. Feb 13 20:35:58 If no one sees it in a few minutes, please let me know, and I can go make puppy eyes at management and see whether they will let us use the flamethrower in future discussions with IT about our sporadic outgoing mail problems. :) Feb 13 21:03:40 Huh. The oe-core list archive page shows that message, but it hasn't shown up in my mailbox. Feb 13 21:24:31 otavio: ping? Feb 13 21:24:52 seebs: 1.4.5? :/ Feb 13 21:25:10 Yeah, basically, linkat() was a giant minefield. Feb 13 21:25:38 I now actually have a *coherent explanation* though -- I know what was wrong, why it was wrong, and how it managed to escape comprehension previously. Feb 13 21:25:44 RP: pong Feb 13 21:25:52 And then I showed the proposed patch to fray and had him grill me about the logic and history until he was happy. Feb 13 21:26:11 otavio: are we anywhere closer to fixing the meta-fsl failures? Feb 13 21:26:26 RP: For the headers? yes Feb 13 21:26:34 RP: partial patch in my machine Feb 13 21:26:48 otavio: great :) The red on the AB is beginning to get to me ;-) Feb 13 21:27:09 RP: I am sorry Feb 13 21:27:28 RP: I still need to fix the %$UF Qt plugin to build Feb 13 21:28:26 otavio: Ok, as long as its going to get fixed sometime soon... Feb 13 21:29:57 seebs: have a pointer to the patch? Don't want to wait on the list... Feb 13 21:30:26 contrib should have it as seebs/pseudo145, and it's the top patch in the pseudo git repository if you want to see the changes. Feb 13 21:30:28 seebs: this has just broken the weekly build, will pull it in and restart Feb 13 21:32:24 Ugh. Sorry. It turns out I had a fundamental misunderstanding of how my *at() wrappers worked in general which just *happened* to never previously produce broken code. Feb 13 21:33:08 seebs: happens, I pulled this last minute thinking it was safe... Feb 13 21:33:34 I *thought* it was safe. Feb 13 21:34:43 it was pseudo-safe Feb 13 21:36:19 I have added a todo item to go back and fix all the wrappers. There is a historical error. Feb 13 21:37:04 So far as I can tell, when I first did the general conversion of all the wrappers to shunt everything to a single "real" implementation, I made the non-at() varieties call the at() varieties because it was easier to do it that way than to do it the other way. Feb 13 21:37:29 I mean, conceptually, it's easier to return openat(AT_FDCWD, file, mode, flags); than it is to do all the setup and teardown to allocate paths and so on. Feb 13 21:38:25 Then another pass occurred, in which I made the wrappers do the path-fixup automatically. Feb 13 21:38:52 And now I have all these functions which are carefully expanding a path to an absolute path, then calling fooat(AT_FDCWD, path) with an absolute path. Feb 13 21:39:55 So really, what I *ought* to do, almost certainly, is change it so the *at() wrappers are the ones which call the plain ones. Feb 13 21:40:04 This would simplify the heck out of a lot of code. Feb 13 21:40:31 Doubtless, it shall be accomplished during my Copious Free Time. **** ENDING LOGGING AT Thu Feb 14 02:59:59 2013