**** BEGIN LOGGING AT Fri Oct 03 03:00:00 2014 Oct 03 06:02:07 hi all. sorry, real new-user question: i've modified the splash picture, and i can see bitbake knows about the bbappend, but if i simply rerun "bitbake rpi-hwup-image" i don't get a new image built. Oct 03 06:12:33 ah found it - bitbake psplash -c clean Oct 03 06:59:13 good morning Oct 03 07:34:31 good morning Oct 03 07:35:17 I can't find CONFIG_REGMAP in the kernel config for 3.10.31-yocto-generic, nor in the menuconfig Oct 03 07:35:37 if I set it anyway, I get a check kernelconfig error from bitbake Oct 03 07:36:08 but according to the Internet, the kernel config option DOES exist Oct 03 07:36:19 so the question is - why me? Oct 03 07:36:20 ;) Oct 03 07:44:52 xerent: doesn't look like it's supposed to show up in menuconfig, http://lxr.linux.no/linux/drivers/base/regmap/Kconfig Oct 03 07:45:24 xerent: I think it's supposed to be pulled in by the thing that needs it Oct 03 07:45:42 which in my case is a stand-alone driver Oct 03 07:45:52 so I need it anyway Oct 03 07:46:56 it says it "depends on: ( CONFIG_REGMAP_I2C || CONFIG_REGMAP_SPI || CONFIG_REGMAP_SPMI || CONFIG_REGMAP_MMIO || CONFIG_REGMAP_IRQ )" Oct 03 07:47:07 do you have any of those enabled as well? Oct 03 07:47:17 yes, I set all of them to appropriate y or m Oct 03 07:48:08 except, SPMI - that isn't in 3.10 Oct 03 07:49:48 no clues from the error msg? Oct 03 07:54:43 http://pastebin.com/0PDq3nx3 Oct 03 08:03:22 hmm, I have no good ideas :( Oct 03 08:19:06 what causes a package to be listed in PACKAGES multiple times? Oct 03 08:19:59 i have one .bb file for psplash, and in the layers i am using, there are only .bbappend files Oct 03 08:21:30 i copied the psplash files from the meta-raspberrypi layer into mine, but bitbake gives that error when i include my psplash-git.bbappend in the build Oct 03 08:33:05 hi guys Oct 03 08:33:22 anybody else missing the dbus service for the session bus? Oct 03 08:33:52 I'm on dbus 1.8.2 Oct 03 08:33:54 from poky Oct 03 08:47:48 morning all Oct 03 08:47:57 morning Oct 03 08:48:06 bluelightning, quick question Oct 03 08:48:15 hi bluelightning, all Oct 03 08:48:19 isn't dbus supposed to have a session bus systemd service? Oct 03 08:48:45 can't find it when building from poky Oct 03 08:48:53 gebreselaisi: I'm not sure to be honest... rburton? Oct 03 09:22:24 iirc, it doesn't have a session bus out of the box. if you're trying to do a user session managed by systemd, then you should know that they're currently a bit broken. Oct 03 09:33:48 hm Oct 03 09:34:02 a bit? in what sense? Oct 03 09:35:35 a 1 should be a 0 somewhere Oct 03 09:36:02 erbo: I'm still clueless about CONFIG_REGMAP Oct 03 09:36:47 it gets unset by bitbake/scripts no matter what I do Oct 03 09:38:49 gebreselaisi: "doesnt work" Oct 03 09:39:29 gebreselaisi: the tizen guys made it somewhat work with patches to everything, we've patches on the list to do wayland in a user session, but vt switching is messed up Oct 03 09:39:46 gebreselaisi: if you want to do a user session in dbus, be prepared to patch systemd upwards Oct 03 09:54:24 Hi. Im trying to build meta-toolchain-qt5, but I can't relove the error I'm getting during do_populate_sdk: error: file /lib/libthread_db-1.0.so conflicts between attempted installs of libc6-thread-db-2.20-r0.cortexa9hf_vfp_neon and libthread-db1-2.19-r0.cortexa9hf_vfp_neon Oct 03 09:54:29 Can anyone help? Oct 03 09:54:41 resolve Oct 03 10:28:22 frsc: which branch and machine? Oct 03 10:29:31 hi. is it possible to automatically detect the kernel version that (e.g.) linux-raspberrypi is using, then download the right realtime patch and apply it? Oct 03 10:30:10 ^ i mean in my new layer for a realtime raspberry pi image Oct 03 10:32:16 KevinZA: in theory you could do a bbappend that used a wildcard for the version (e.g. linux-raspberrypi_%.bbappend) and in there you could use ${PV} as a substitute for the actual version, provided that that version only ever represents the kernel version Oct 03 10:33:09 woah, there are way too many kernel versions in meta-raspberrypi... Oct 03 10:34:13 thanks bluelightning. so "best practice" might be for my layer to specify a kernel version by git, and i will actually manually download the appropriate patch in the files directory? Oct 03 10:34:28 haha yes Oct 03 10:35:16 mckoan: it's a custom imx6 board and I tried with the fsl-release repo. I'm now trying with the community meta-qt5 layer (master) and see if that works. Oct 03 10:36:08 KevinZA: that would be harder because then you don't know what version of the kernel you are building until you unpack the source, which happens after fetching... Oct 03 10:36:40 KevinZA: honestly I would poke the meta-raspberrypi maintainer to drop the outdated kernel versions, I can't believe all of those are needed Oct 03 10:38:07 will do - btw when an irc has a "name:", is that a private reply? I don't want to spam the channel... but i've never used irc... Oct 03 10:40:13 KevinZA: no, it's just a message aimed at someone else, that everyone else can see Oct 03 10:41:04 KevinZA: https://www.yoctoproject.org/irc/%23yocto.2014-10-03.log.html is the publicly archived log. everyone sees what is in this room. Oct 03 10:41:34 KevinZA: in most IRC clients mentioning a person's name causes that line to be highlighted by that person's IRC client, so it's a way of getting their attention Oct 03 10:42:16 ok thanks Oct 03 11:59:39 bluelightning: have you any experience with kernel configurations gone berserk in Yocto? I'm trying to build with CONFIG_REGMAP, but it gets unset in do.log_kernel_checkconfig Oct 03 12:01:28 frsc: using the community meta-qt5 layer ( Oct 03 12:01:42 JaMa|Off: we've found a pseudo bug which might explain those pseudo permissions issues you reported, particularly if it was on xfs with 64 bit inodes Oct 03 12:01:45 frsc: using the community meta-qt5 layer (daisy) works Oct 03 12:21:37 rburton, can you point me to the patches in the mailing list for the wayland user dbus session? Oct 03 12:56:49 gebreselaisi: search for patches by valentin, the oe-core patchworks has a search button Oct 03 12:56:51 How do I enable eglfs support for Qt 5.2.1 (Yocto version Daisy) from my local.conf? When I look in my config.summary it says QPA backend EGLFS no. I have disabled x11 and wayland and added qtbase-plugins to IMAGE_INSTALL_append. What else am I missing? Oct 03 12:58:47 thanks Oct 03 13:08:34 TRoGd0R: have a look at this layer: https://github.com/ndechesne/meta-qt5-emulator/. i use that to build an image with qt5/eglfs for x86 and arm targets. Oct 03 13:09:06 the 2 important files are https://github.com/ndechesne/meta-qt5-emulator/blob/master/recipes-qt/qt5/qtbase_5.%25.bbappend, and https://github.com/ndechesne/meta-qt5-emulator/blob/master/conf/local.conf.sample Oct 03 13:13:19 ndec: interesting, but which image are you building here? Oct 03 13:14:01 i have a test image in recipes-core Oct 03 13:14:46 the image has enough to play html5 video on youtube for example. that was my use case.. Oct 03 13:15:07 ndec: probably would be interesting to see which qt packages you are using too Oct 03 13:15:20 what do you mean/ Oct 03 13:15:21 ? Oct 03 13:16:09 ndec: I mean that your meta-qt5-emulator is not enough to understand how to properly build qt5 Oct 03 13:16:31 well, it should be enough. what's missing? Oct 03 13:16:33 ndec: would be useful to see your image Oct 03 13:17:22 ndec: for examlpe what thete is in IMAGE_INSTALL_append = Oct 03 13:18:03 ndec: qtbase, etc Oct 03 13:18:24 qtbase is in qt5-example-image.bb Oct 03 13:18:45 so there is no way to add the eglfs support option into my IMAGE_INSTALL_append var in my local.conf? Oct 03 13:18:47 ndec: fine so you are using qt5-example-image, thx Oct 03 13:19:14 TRoGd0R: no. i don't think. Oct 03 13:19:43 ndec: and where is qt5-example-image.bb located? Oct 03 13:19:45 you need to bbappend qtbase Oct 03 13:20:03 recipes-core/images in the layer above Oct 03 13:20:31 ndec: uh, I've missed that sorry Oct 03 13:21:08 ndec: as far as you know would be possible to enable Qsqlite ? Oct 03 13:21:55 mckoan: how is it normally enabled? Oct 03 13:22:24 ndec: ./configure Oct 03 13:22:57 The weird thing is this all worked before I upgraded to Daisy. I had eglfs by default, anyone know what changed? Oct 03 13:23:19 mckoan: qtbase has 2 PACKAGECONFIG: sql-sqlite and sql-sqlite2, you can enable easily in bbappend the one you want. Oct 03 13:24:07 ndec: I expected it was PACKAGECONFIG_append = "sqlite" that may be the reason of my failure Oct 03 13:25:10 TRoGd0R: i think the default in qtbase has always been gl, not gles2 in PACKAGECONFIG. so i don't see how eglfs could have been enabled by default Oct 03 13:25:41 Ok so I have a qtbase_5.2.1.bbappend file created. What do I need to add into again. Sorry I'm a noob Oct 03 13:25:43 PACKAGECONFIG_GL = "gles2" Oct 03 13:25:44 ? Oct 03 13:25:54 yes. Oct 03 13:26:02 cool, I'll try it now Oct 03 13:26:05 mckoan: check qtbase.inc for the exact PACKAGECONFIG names. Oct 03 13:26:16 and mckoan don't forget the " " when using _append Oct 03 13:27:09 ndec: indeed! incredible, it was an oversight Oct 03 13:27:22 ndec: thanks Oct 03 13:27:26 TRoGd0R: if you set PACKAGECONFIG to gles2, then qtbase will be built with "-opengl es2 -eglfs" Oct 03 13:27:45 Is that what I want? Oct 03 13:28:19 ndec: maybe do you mean PACKAGECONFIG_GL = "gles2" ? Oct 03 13:28:29 yes.. Oct 03 13:28:34 ndec: ;-) Oct 03 13:28:49 eventually it's used to set PACKAGECONFIG ;-) Oct 03 13:29:13 TRoGd0R: which platform/target are you building for? Oct 03 13:29:40 I made the change in my bbappends file and tried to bitbake but it said there was nothing needed to be rerun. Do I have to force it to build? Oct 03 13:30:12 I am building for a custom board that has an am335x Oct 03 13:30:41 hmm. i would expect it to detect the change... can you check with "bitbake -e qtbase | grep ^PACKAGECONFIG" Oct 03 13:30:45 TRoGd0R: I added sql-sqlite to my PACKAGECONFIG_append and it was rebuilding Oct 03 13:30:54 to ensure you've set the value correctly. Oct 03 13:33:35 ndec: I've noticed you have may projects in github, I wonder if you have ever been able to run Qt5 on AM355x-EK using YP daisy Oct 03 13:34:29 i have had qt5/eglfs on many other arm soc/boards, but not this one ;-) Oct 03 13:35:12 ndec: it's the only one I have not working :-( Oct 03 13:36:03 ndec: however you gave me the idea to test qemux86 with vmdk, just for fun in the weekend Oct 03 13:36:44 hehe.. that's actually quite nice, we did that for a project based on qt5/eglfs so that we could develop/test on emulator.. Oct 03 13:37:12 actually the whole idea and most of the implementation details were based on JaMa|Off's stuff.. Oct 03 13:42:25 It's weird, it won't notice the change and rebuild just that part. I guess I am going to have to do a clean build unless there is a way to just force the qt part to build Oct 03 13:43:04 ndec: of course JaMa|Off stuff rocks! Oct 03 13:44:16 Would this work bitbake -c cleanall base-files qt5 core-image-base? Oct 03 13:47:44 TRoGd0R: have you tried the bitbake -e command above? you need to make sure you did the .bbappend right first. Oct 03 13:49:09 yeah Oct 03 13:49:31 I just kicked off a clean build Oct 03 14:20:28 Is someone looking at 1.7 toolchain issues? We managed to reproduce same error in 1.6 and 1.7 SDKs Oct 03 15:06:03 RP: yes I was reading your chat with seebs, unfortunately in my case it was on ext4, but I'll re-check with the pseudo changes as well Oct 03 15:09:56 ndec: you don't need .bbappend, you can just use _pn-qtbase in your local.conf Oct 03 15:10:34 JaMa|Off: right. he wanted to be able to do it with IMAGE_INSTALL, actually. Oct 03 15:14:47 What do I add to _pn-qtbase in my local.conf? Oct 03 15:18:58 JaMa|Off: its possible on large filesystems you could have hit 64 bit inodes Oct 03 15:30:45 ndec: despite I see /usr/lib/libsqlite.so.0.8.6 in my rootfs I can't find any libqsqlite* Oct 03 15:31:28 how can be generated libqsqlite with qt5 ? Oct 03 15:33:13 PACKAGECONFIG_append = " sql-sqlite" seems doesn't have any effect Oct 03 15:34:30 mckoan: well, it has the effect to add "-sql-sqlite" to qtbase configure options... Oct 03 15:41:20 mckoan: i am not familiar with that part.. but looking at http://qt-project.org/doc/qt-5/sql-driver.html, it seems that -sql-xxx has been rename -qt-sql-xxx... Oct 03 15:42:07 rburton: I am debugging the mesa failure in fsl-arm Oct 03 15:42:50 ndec: thx, I am not familiar with qt :-) Oct 03 15:42:52 and it looks to be a bug in pkgdata. It is generating the files for 'empty' packages. In the mesa case, openvg is already disabled in mesa and it outputs the pkgdata anyway Oct 03 15:43:22 rburton: i will have lunch and be back in 1h or so Oct 03 15:44:03 ndec: BTW in meta-qt5 we are still using 5.2.1 Oct 03 15:44:12 otavio: interesting and easy to replicate. can you file a bug? Oct 03 15:44:51 is there an easy way to see why postinst scripts are not working as expected? I have a custom bitbake package. I have an image that installs two rpm packages from it, both with postinst scripts. But neither appear to fire at all. Oct 03 15:45:32 another postinst from the same custom package works just fine in another image that only installs one rpm package from the problem bitbake package. Oct 03 15:45:39 blloyd: the rootfs log should have the output of them when executed at rootfs time, and if they're delayed then there should be something in /var/log with the output there Oct 03 15:46:17 ndec: looks like qtbase-opensource-src-5.2.1 uses -qt-sql- ... Enable a SQL in the Qt SQL module Oct 03 15:46:43 so the recipe in meta-qt5 needs a patch Oct 03 15:48:08 I'm trying PACKAGECONFIG[qt-sql-sqlite] = "-qt-sql-sqlite,-no-sql-sqlite,sqlite3" Oct 03 15:48:57 where is the rootfs log at? Oct 03 15:49:37 rburton: #6795 Oct 03 15:49:41 Done. Oct 03 15:51:46 nm, found it. Oct 03 16:20:56 mckoan: you don't need to change the packageconfig name, just need to configure options. otherwise you are breaking existing recipes.. Oct 03 16:24:27 ndec: ok Oct 03 16:26:41 otavio: so RP has a hunch, can you make a patch :) Oct 03 16:26:58 well, testing it would be good too! Oct 03 16:27:05 yeah that too :) Oct 03 16:29:34 seebs: could we have a release of pseudo please? :) Oct 03 16:29:52 halstead: around? Oct 03 16:31:07 halstead: I'd like to wipe sstate and run a build from scratch of master-next on the abs Oct 03 16:35:21 have a nice rest of the day Oct 03 16:37:30 huh, just got an OSError traceback from a setscene Oct 03 16:37:37 thats new Oct 03 16:48:39 and using sstate locked sigs just gave me a traceback too Oct 03 16:49:45 also looks like you can't use -S printdiff to figure out why the locked sigs aren't being used when you're including the locked sigs file, it checks them even though I'm not trying to build anything Oct 03 16:53:02 hi, anyone here is creating or implementing certain web services for their projects ?, if so, please ping me back as I am collecting some information as we as open source organization have some plans for a generic Yocto Web Service so your input would be valuable. Oct 03 17:00:36 edsiper: what's a generic yocto web service? Oct 03 17:02:37 rburton, specific web service exposing certain interfaces and information. For a generic case: CPU, Memory Storage, plus something more specific (that I am trying to discover) like: metrics, serial input, HW stuff, etc Oct 03 17:03:12 RP, I'll clear sstate now. Oct 03 17:03:13 rburton, so anyone building a OS using Yocto, be able to install this package and have those informational features enabled Oct 03 17:03:20 I'm still studying some other diagnostics I'm getting from pseudo, but I *think* the huge spam of filesystem name changes I was seeing may have been a diagnostics issue. Specifically, the speculative-unlink code is working perfectly, I think, except that the path name mismatch reports are useless if the operation is did_unlink. Oct 03 17:04:15 Because then it's sort of expected. Oct 03 17:04:22 seebs: makes sense Oct 03 17:04:28 edsiper: system stats over http, basically? Oct 03 17:04:48 Anyway, I have a patch to suppress those errors in that case, and my plan is to rerun the build that generated those messages with that change and see what happens. Oct 03 17:04:53 It may well be that there's still issues. Oct 03 17:05:09 seebs: the tricky issue is that we're now in release mode and at the very least I'd like to fix the 64 bit truncation issue Oct 03 17:05:16 Yeah. Oct 03 17:05:23 RP, While I am thinking, should ASSUME_PROVIDED_remove = "git-ntive" work? Oct 03 17:05:37 I need to try it Oct 03 17:05:40 I just want to make sure I'm not missing something else horrible. And actually, I have a suspicion that there may be a way to break things with did_unlink still. Oct 03 17:05:53 seebs: we have a little time but not much until the next rc so its really just a headsup that we will need to do it Oct 03 17:06:04 How much time is "not much"? Oct 03 17:06:11 Crofton: in theory, its not well tested Oct 03 17:06:26 Crofton: git from a buildtools-tarball is the other alternative Oct 03 17:06:33 rburton, more than stats, but yes. Oct 03 17:06:38 seebs: next rc is Tuesday Oct 03 17:08:27 RP, my problem is the uhd cmake detects a git binary so it can bury a git hash in the binary Oct 03 17:08:45 and the cmake setup is grreat at preventing cmake from finding the host git Oct 03 17:08:46 Okay. The error message fix removes several of the problems, although I am very curious about one of the remaining messages. Oct 03 17:08:52 which is in general a good thing Oct 03 17:09:03 and trying to run git-native fails since it is provided Oct 03 17:09:05 Because I'm getting create messages about a thing which somehow came into the database with no path. Oct 03 17:09:27 I checked that removing git-native from AP solves my "problem" Oct 03 17:09:38 seebs: meanwhile, halstead has wiped out our sstate, we'll retry a complete build from scratch Oct 03 17:09:43 I am looking for a good way to do this without hand modifying oe-core conf files Oct 03 17:10:07 Ah-hah! Oct 03 17:10:09 Crofton: hang on, what are you trying to do here Oct 03 17:10:10 * Crofton also has a low opinion of people who freak out over not having the git hash in the binary :) Oct 03 17:10:13 There is an actual bug to be had involving DID_UNLINK. Oct 03 17:10:18 Crofton: do you want git-native or not? Oct 03 17:10:22 yes Oct 03 17:10:33 Crofton: right, ok Oct 03 17:10:39 and it needs to be in the oe space, not build system Oct 03 17:10:43 The sanity-checks that do things like unconditionally wipe out a database entry if we get a file/directory mismatch aren't conditional on that. Oct 03 17:10:59 cmake will not find it on the build system (which is good) Oct 03 17:12:11 Crofton: right, makes sense Oct 03 17:12:20 Crofton: I suddenly wondered if you were trying to do something else Oct 03 17:13:02 halstead: do we need to wait for a while for the sstate removal to happen? Oct 03 17:13:06 *pondering* Oct 03 17:13:26 Actually they may be adequately conditional already, because this applies only when we find a match by path. Oct 03 17:13:41 RP Just finished. Oct 03 17:13:43 basically, I'd like a proper way of overriding ASSUME_PROVIDED for cases like this Oct 03 17:13:58 I'll test the AP_remove way Oct 03 17:14:16 I jsut want to make sure this doesn't lead to subtle breakage Oct 03 17:14:31 RP, We're ready to build again. Oct 03 17:14:40 halstead: great, thanks Oct 03 17:14:56 halstead: I wasn't sure of the best way to clear it, I guessed from one of the builders over NFS would be nasty Oct 03 17:15:32 halstead: I've set a master-next away thanks Oct 03 17:15:41 RP, That works but takes awhile. I have sstate on it's own partition so I remake the filesystem instead. Oct 03 17:16:05 RP, And then check the NFS is happy on all the builders. Oct 03 17:16:06 Ah-hah! Oct 03 17:16:14 There is an actual failure mode that isn't the inode thing. Oct 03 17:17:02 halstead: small permissions issue ;-) Oct 03 17:17:28 So if you delete a symlink or directory, and around the time you're doing this you create an executable file... Oct 03 17:17:39 halstead: I've killed the builds Oct 03 17:17:42 Yeah. Oct 03 17:17:52 If the DID_UNLINK for the symlink or directory comes in after the executable file is created, it can nuke the database entry for the file. Oct 03 17:18:05 halstead: but I like the reformat, that is nicer Oct 03 17:18:23 seebs: I can see how that could be problematic Oct 03 17:19:12 RP, Permissions are fixed. Oct 03 17:19:27 halstead: thanks, I'll retry Oct 03 17:19:33 * halstead carefully checked nfs state but not directory ownership. Oct 03 17:19:39 doh. Oct 03 17:19:44 Woot. Okay, the failure case where I was getting hundreds of errors does appear fixed. Oct 03 17:20:24 halstead: when I saw the failures I was fully expecting it to be my fault on the branch :) Oct 03 17:21:44 :) At least that was a quick failure and recovery. Oct 03 17:22:09 There's something else I'd like to figure out but it doesn't look as significant. Oct 03 17:22:32 halstead: yes, could be worse :) Oct 03 17:23:55 * RP needs to head afk Oct 03 17:27:20 Okay, so. Retesting a couple of things, but I think this will turn into pseudo 1.6.2, with two fixes, one of which is just for xfs. Oct 03 18:13:09 gah Oct 03 18:13:18 I lose, there's still an actual bug producing real problems. Oct 03 18:14:06 Not sure what's happening, but at least I now have a patched-up pseudo that won't generate the errors I *don't* care about. Oct 03 18:14:21 It appears that rerunning "bitbake -f -c package util-linux" a couple of times produces the errors. Oct 03 18:14:53 sounds like a step in the right direction, at least. make it easier to diagnose Oct 03 18:17:43 hmm Oct 03 18:17:48 This is interesting. Oct 03 18:18:18 So, every time I get one of these, it seems to involve a no-path entry for an inode which was the inode of a previous did-unlink. Oct 03 18:40:00 ... silly question, is there a way I can point bitbake at a local git repo that isn't a git:// directory? Oct 03 18:40:33 the url scheme in bitbake just controls what fetcher is used, not necessarily what the underlying protocol used to fetch is Oct 03 18:40:38 Like, I can git clone /home/seebs/pseudo, but I can't put it in SRC_URI. Oct 03 18:40:43 git:// .... ;protocol=file will clone file:///home/seebs/pseudo Oct 03 18:40:48 ahh. Oct 03 18:41:35 it might've been nice for that to be opposite. e.g. file://${HOME}/foo;fetcher=git or something, but its a bit late for that now :) Oct 03 18:43:42 what i'd really like to see is support for schemes that combine the two, which seems to be showing up as a convention amongst upstreams Oct 03 18:43:55 e.g. git+ssh for git, so +:// Oct 03 18:44:09 * kergoth shrugs, minor cosmetic thing Oct 03 18:45:42 So I can't tell whether what I have now is purely cosmetic or an actual database corruption problem. Oct 03 18:46:32 But *something* is happening that's causing diagnostics which may be harmless or may indicate a serious problem. Oct 03 18:47:05 mkdir requests are complaining because they have a pathless DB entry with the same inode, which is the inode of a recently-deleted file. Oct 03 18:47:22 halstead, could you check the git server logs and see if the cause of https://autobuilder.yoctoproject.org/main/builders/nightly-non-gpl3/builds/64/steps/Git%20checkout%20of%20poky/logs/stdio is obvious if you have a moment please? Oct 03 18:47:26 * RP2 isn't really here Oct 03 18:49:05 Gladly RP2. Oct 03 19:30:15 Okay, no promises, but I *think* I found the source of a whole bunch of "how did that file get into the database with no name" problems. Oct 03 19:30:35 I feel really clever, because I am a pretty sharp programmer, but apparently I totally outsmarted myself. Oct 03 19:31:14 When processing a link, I was using the existing data from the database for a given inode, and then creating a link with the new path. Sensible, right? Oct 03 19:31:41 Only. The actual link creation uses a test on msg->pathlen to determine whether to link with msg->path or the fixed string 'NAMELESS FILE'. Oct 03 19:31:54 And the "existing data from the database" entry had no pathlen. Oct 03 19:32:20 (There's some weirdness because 'msg' is of a type with a flexible array member on the end, so *msg = by_ino doesn't actually change msg->path.) Oct 03 20:00:38 Oct 03 20:17:16 Hmm, not sure it's still possible to share target (but not native/cross) sstate between distros. i have target recipes being rebuilt even though bitbake-whatchagned and bitbake -S printdiff both show no differences Oct 03 20:17:23 * kergoth digs Oct 03 21:03:32 Hi everyone, Can any explain how I install just a set of shared libraries? The recipe only outputs dev & staticdev rpms. When try and build the image I keep getting: Computing transaction...error: Can't install SuiteSparse-dev-4.3.1-r0@cortexa9hf_vfp_neon: no package provides SuiteSparse = 4.3.1-r0. Does do I create a base SuiteSparse RPM? Oct 03 21:07:26 sounds like its recipe isn't installing anything in its do_install Oct 03 21:10:12 So the recipe inherits from autotools and so I haven't added a do_install method. Looking at the log and inspecting the created RPMs it build the libraries I need I just can't get it to build a rootfs or sdk without the above error. Oct 03 21:13:06 Well, I've definitely made progress. Oct 03 21:13:16 I've now established that I was wrong about what I thought was wrong with my fix for what I thought was wrong. Oct 03 21:14:11 It turns out my initial belief that the "by_ino" lookup wouldn't have the right path length was in fact incorrect. Oct 03 21:14:33 So I'm back to not being sure how the files are getting in as nameless files. But I have reversed the thing that made them MORE common. Oct 03 21:20:18 Is it a correct assumption that no SuiteSparse-4.3.1-r0@cortexa9hf_vfp_neon RPM would be created as no binary files were produced and the lib and includes files were just included into in the dev RPMs? Oct 03 21:24:34 Fivefootseven: the dev rpm is always created, empty or not. its far more likely that nothing was installed, though that is possible, yes Oct 03 21:26:49 So you would expect not to see a base RPM if nothing was installed. As this is a shared library I assume I would expect to see the same contents in the dev and then base RPM? Oct 03 21:34:41 I just added a do_install and touched the file image/usr/bin/AHH.txt and included it in the FILES_${PV} variable. This then created the missing base RPM and populated the SDK without error. This is clearly not the right approach. How to force the empty creation of the base RPM. Any suggestions? Oct 03 21:56:55 Woo! Oct 03 21:57:02 I think I found the actual underlying problems. Oct 03 21:57:11 There were two things that were conspiring to create a problem. Oct 03 21:57:40 First, if we found something in the database by inode, but not by path, I was creating a second database entry for it in some cases, which broke future attempts to unlink it. Oct 03 21:58:18 Second, when file renames got made smarter with the MAY_UNLINK stuff... The test for whether to create a dummy database entry to be the root of a rename operation was wrong. Oct 03 21:58:53 So it would request that a link be made for a thing which was already in the database, right before renaming it, and this was causing some of the strange behaviors like link requests for already-existing files. Oct 03 22:21:30 seebs: glad its making sense :) Oct 03 22:21:59 Fixing the links made most of the stuff I cared about go away, but I was still seeing suspicious messages. Oct 03 22:23:14 I think the issue is that the only times when it would come up would be when a rename operation was overwriting an existing object, and that's actually a rare use case; normally people explicitly unlink before calling rename. Oct 03 22:24:22 halstead: is nfs ok on the autobuilders? Oct 03 22:26:09 Awesome. With the new changes, I see only one of those "hey wait that's suspicious" messages, and it's specifically the reuse of a recently-may-be-deleted inode. Oct 03 22:29:38 * RP doesn't know why the autobuilder is showing new interesting failures Oct 03 22:37:54 * JaMa|Off is seeing couple new issues from last systemd upgrade Oct 03 22:51:57 JaMa|Off: :( Oct 03 22:52:10 Sent out patch for pseudo 1.6.2. Oct 03 22:53:06 For Sound Technical Reasons (read: "too lazy to investigate another thing right now") I wasn't able to put the tarball on the WRS server, so it's on https://www.seebs.net/tmp/pseudo-1.6.2.tar.bz2. Sent email to pidge, but I don't know who's still around this late on a Friday. Oct 03 22:54:21 afk a bit, back around in a while. Oct 03 23:02:42 seebs:can you mention this to halstead, pidge is out of action for a bit :( Oct 03 23:03:56 RP: hi there. It's weird, I'm seeing a very old -native failing strangely...http://pastebin.com/sVJB4cb7 Oct 03 23:04:19 I have to comment out COMPATIBLE_MACHINE to unbreak Oct 03 23:04:50 ahh, 'k Oct 03 23:05:33 ... Remind me of halstead's email? Oct 03 23:05:59 Mhalstead along c foundation.org Oct 03 23:06:24 Darn auto correct. Oct 03 23:07:17 seebs: mhalstead@linuxfoundation.org Oct 03 23:07:26 RP looks like no Oct 03 23:07:31 k. Oct 03 23:07:40 RP I'll check it out. Oct 03 23:09:37 RP: another way is setting COMPATIBLE_MACHINE_class-native = "" Oct 03 23:57:50 RP, Major problems with the NAS are repaired. It looked like kernel issues so I installed the newest supported HWE and we're back online. Oct 04 00:01:06 RP, Killing all builds in progress and rerunning yours. **** ENDING LOGGING AT Sat Oct 04 03:00:00 2014