**** BEGIN LOGGING AT Thu Dec 06 02:59:59 2012 Dec 06 07:54:35 the udev-164 tarball seems to have disappeared from kernel.org Dec 06 07:55:06 http://www.kernel.org/pub/linux/utils/kernel/hotplug/ Dec 06 07:56:15 Zagor: get it from yoctoproject.org Dec 06 07:59:45 onoffon: right, thanks Dec 06 08:23:22 good morning Dec 06 08:46:41 morning all Dec 06 09:40:02 morning all Dec 06 10:35:42 Hello everybody. I disabled 'debug-tweaks' option (because I doesn't like the blank password) but at the same time, I cannot find the default root password... Any help ? Dec 06 11:40:26 vadmeste: there is no such probably Dec 06 11:44:34 jo hrw Dec 06 11:57:39 vadmeste: there is none without debug-tweaks; if you want to be able to log in as root you need to set a root password in a postprocessing function and add the function to ROOTFS_POSTPROCESS_COMMAND Dec 06 12:34:38 does it happen only here, or takes do_package now significantly longer? E.g. do_package of kernel took previosly 300s, now it is 1100s Dec 06 12:40:35 ensc|w: when was "previously"? Dec 06 12:40:38 ensc umh thats fast Dec 06 12:44:29 Zagor: two days ago (I merged recent .core in the meantime) Dec 06 12:44:49 disk io has been increased between both versions: Dec 06 12:44:57 1224 Dec 06 12:45:00 (old) Dec 06 12:45:05 201112 Dec 06 12:45:08 (recent) Dec 06 12:46:33 I enabled the prserv stuff but thsi should not make such a difference Dec 06 13:24:28 bluelightning: okay thanks Dec 06 13:35:51 is it a common problem that broken versioned dependencies will be generated with PRSERV? e.g. acl-dev has 'Depends: acl (= 2.2.51-r3.1)', but acl only 'Version: 2.2.51-r3' Dec 06 13:37:05 is anything common about PRSERV yet? :) Dec 06 13:52:27 image.bbclass has write_image_manifest() but I do not see *.manifest files in deploy/images/ - there are some license related ones in deploy/licences/IMAGENAMEDATE/ dir Dec 06 13:52:45 do I have to set some extra vars to get them? Dec 06 14:00:17 hrw: I think you'd need to prepend that function to ROOTFS_POSTPROCESS_COMMAND... however I think that's somewhat poorly implemented at the moment Dec 06 14:00:22 only works for ipk for example Dec 06 14:00:53 bluelightning: manifest from license.bbclass is even better so I will use that one Dec 06 14:01:24 there is also buildhistory as well... depends on what you want it for Dec 06 14:02:00 bluelightning: I need a simple list of what is in image - manifest from license.bbclass gives that Dec 06 14:02:55 one day I have to check what all those 'new' classes do Dec 06 14:03:16 documentation is a little lacking for some of them unfortunately Dec 06 14:03:35 bluelightning: I am used to lack of OE docs Dec 06 14:03:36 I hope to set aside some time to address that in this development cycle Dec 06 14:27:20 argh... whole distribution gets rebuilt when I change a value in BB_DISKMON_DIRS :( Dec 06 14:33:13 we need a vardepsexclude there apparently Dec 06 14:33:15 :/ Dec 06 14:45:10 bluelightning: but that can not be the solution. Why is a package rebuilt although only a completely unrelated variable has been changed? There is probably something broken with the oehash generator Dec 06 14:46:20 stamps are not very useful either because bitbake-diffsigs ends somewhere in m4 where no difference will be found Dec 06 14:48:05 do_package_write_ipk_setscene has same hash for different runs, but do_populate_sysroot_setscene another one Dec 06 16:25:41 ensc_: for what its worth, BB_DISKMON_DIRS isn't in any of my signatures. nor should it be, nothing in the metadata uses it Dec 06 17:11:48 Is anybody having problems to build openjdk-7 on danny? I've got this: http://paste.debian.net/214757/ Dec 06 17:52:17 kergoth: I know; there is something else going wrong. Giving out basehash data (_builddata in bitbake/lib/siggen.py) shows stray gitpkgv_ functions: http://pastebin.com/bTFF53JR Dec 06 17:52:28 dunno, where these functions are coming from... Dec 06 17:55:57 i'd guess the gitpkgv class, no? Dec 06 17:56:50 kergoth: yes; but is not used by m4 or any of the other recipes showing such random differences Dec 06 17:57:16 the 'inherit gitpkgv' is used within .bb files only; not in configuration files or so and not in environment Dec 06 18:05:35 hm.. is there any pandaboard es owner online? Dec 06 18:05:51 * Jay7 have question about pandaboard es Dec 06 18:06:11 a bit offtopic here :) Dec 06 18:17:17 well, I've found answer on my question already :) Dec 06 19:11:55 kergoth: it seems to be a race which is triggered by the order in which .bb files are read. When a file with 'inherit gitpkgv' is read, 'gitpkgv' will be added to known classes and later recipes will register gitpkgv_. But when later recipes are read later, this does not happen and the gitpkgv_ variable won't be set Dec 06 19:12:47 perhaps, the cache comes into the game too, but code is too complicated for now... Dec 06 19:17:01 fwiw, relevant function is class ExportFuncsNode in ast.py; the 'classes' variable given to __init__ can contain 'gitpkgv' for non-gitpkgv packages and setVarFlag is called for gitpkgv_do_configure Dec 06 19:42:01 What are the "danny" and "denzil" branches ? Dec 06 19:48:50 Anyone using latest oe-core master? I'm getting a lot of sstate cache failrues currently.. Dec 06 21:46:52 hey. which part of OE-Core renames packages that contain libraries to something like libqtbearer1 ? Dec 06 21:47:00 debian.bbclass Dec 06 21:47:14 meta/classes/debian.bbclass specifically Dec 06 21:48:10 thanks, fray Dec 06 21:48:12 i found it Dec 06 21:48:17 how can i disable this behavior? Dec 06 21:49:39 let me elaborate: i'm trying to split qt-mobility-x11 because my app doesn't use most of it (just the multimediakit module). however, because of the rename to libqtmultimediakit1, the package conflicts with the one exposed by qt-mobility-embedded. Dec 06 21:50:11 furthermore, for some reason definining preferred_provider_libqtmultimediakit1 doesn't seem to work Dec 06 21:50:39 and the qt-mobility-embedded names its library libQtMultimediaKitE, so the .inc is no longer usable Dec 06 21:51:23 the rename only affects the filename, it doesn't change the IMAGE_INSTALL = ... parameters.. Dec 06 21:51:31 so you are having filename conflicts, leading to package conflicts.. Dec 06 21:52:01 two solutions, one is don't rename.. the other is those two items are mutually exclusive.. Dec 06 21:52:28 (I'm not terribly familiar with QT to say either way.. but it seems odd that you'd want both qt emmbedded and full qt) Dec 06 21:53:07 hmm.. not really. in my original writings i used package names like ${PN}-multimediakit, which resulted in qt-mobility-embedded-multimediakit, and qt-mobility-x11-multimediakit. in the work folder I could see folders for my package named, but the in the ipks folder they were renamed as libqtmultimediakit1 and such Dec 06 21:53:27 ya, the later is the filename stuff.. Dec 06 21:53:36 fray, i do not want both - i just want the X11. but the under-the-hood rename confuses bitbake in selecting which package i want Dec 06 21:53:48 but when you do IMAGE_INSTALL = ... you'd put "qt-mobility-x11-multimediakit, and oe would rename that as well for install Dec 06 21:53:56 fray, that doesn't happen Dec 06 21:54:00 why are you -building- both? Dec 06 21:54:02 the package is not installed in the image Dec 06 21:54:04 i am not Dec 06 21:54:18 there are two .bb files depending on an .inc Dec 06 21:54:31 then where is qt-mobility-embedded-multimediakit and qt-mobility-x11-multimediakit coming from? Dec 06 21:54:35 so when i change the .inc, the changes go both to qt-mobility-x11 and to qt-mobility-embedded Dec 06 21:54:52 what I'm saying is if they rename to the same rthing.. they are mutually exclusive and really should never both be built at the same time on the same system.. Dec 06 21:55:06 heh; that's what i'm trying to achieve, fray Dec 06 21:55:10 if they're not intended to be mutually exclusive, thats another thing Dec 06 21:55:23 ok.. blacklist one of the two recipes and figure out what keeps calling it Dec 06 21:56:18 ok; can i say something like "don't rename packages in this recipes" with some variable? Dec 06 21:57:25 fray, thanks for the info - i got a new idea from talking to you Dec 06 21:58:12 there is a no-rename flag.. Dec 06 21:58:24 but I'd first start with figuring out why both are being built and stop that from happening Dec 06 21:58:39 when you blacklist a recipe.. you get diagnostics fi something tries to use it Dec 06 21:58:48 (thats how I resolve these kinds of problems usually) Dec 06 22:01:37 fray, i think it's because the package libqtbearer1 does not exist at the time the preferred_provider entries are processed; only later the debian.bbclass makes the rename, so bitbake has no idea which recipe to put in the runqueue when starting the build Dec 06 22:01:55 though that idea has its weak points Dec 06 22:02:03 ohh yes, the name you have to use is the one in 'PACKAGES' -not- the rename.. Dec 06 22:02:13 whenever you work with OE recipes, you need to more or less ignore the renames Dec 06 22:02:39 they really only show up for the package manager.. anything within OE itself only sees the 'full' name of the package.. Dec 06 22:03:08 The way I usually describe this to people.. recipes -> oe-packages (-> debian rename) Dec 06 22:03:26 may i ask - why the rename? Dec 06 22:03:42 (BTW the rename can be globally disabled as well) Dec 06 22:04:08 it's historic.. much of the development came from people familiar with Debian systems, and they liked the way the rename made it more clear to them which libraries were in which packages Dec 06 22:04:15 yes, but it works for qt4-x11-free Dec 06 22:04:18 I come from the RPM world, so I generally dislike it Dec 06 22:04:24 i see Dec 06 22:04:49 it's pretty unorthogonal to the rest of the build system; thanks for making it clear for me Dec 06 22:04:50 when I develop stuff like this, I often disable the debian rename class until it's working properly.. then enable it and deal with those problems (if any) separately Dec 06 22:05:32 but ya, bitbake/oe really doesn't know [or care] what the renamed items are.. you never specify them in OE variables, recipes, etc.. since rename is optional.. and the system is supposed to do all of the necessary renames automatically if you choose to enable it Dec 06 22:05:50 mhm - the qt4.inc has some python code to generate packages that mimic that behavior Dec 06 22:06:12 Ya, I'm unfamiliar with that part.. sorry Dec 06 22:09:44 well, in that recipe the PACKAGES variable is appended a list of names like "libqtcore4" and such, so everything works just fine; i was quite surprised to see that the same happens in my recipe just by putting each lib in a separate package Dec 06 22:10:56 however, something is messed up: in my original scenario i consistently used ${PN}-multimediakit in rdepends of other packages, and it was not installed after the rename in the image Dec 06 22:11:35 using ${PN}-... shouldin runtime depends should have also been renamed to match whatever the package result was Dec 06 22:14:40 i guess it should; if it worked i wouldn't have had these problems Dec 06 22:15:28 Turn off the debian rename and get it working w/o it first.. Dec 06 22:15:31 in your local.conf: Dec 06 22:15:40 INHERIT_DISTRO = "devshell sstate license" Dec 06 22:15:46 (the default also includes 'debian') Dec 06 22:17:35 ok; thanks for the hint **** ENDING LOGGING AT Fri Dec 07 02:59:59 2012