**** BEGIN LOGGING AT Wed May 20 02:59:59 2015 May 20 07:07:12 hi all! May 20 07:08:29 i'm trying to add qt to the edison yocto image, i downloaded meta-qt5 from git and add this layer to the bblayers.conf, but when i'm selecting machine from the list in hob, i'm getting this error http://pastebin.com/bvAysSeA May 20 07:08:45 anybody can advice? May 20 07:10:23 if i delete this file qtmultimedia_5.4.1.bb, i can start building process but the fail on do_configure in qt_base package May 20 07:10:33 sorry for my english May 20 07:15:54 woah_dude: on a first guess, have you checked that you're using the right branch of meta-qt5, e.g. the one that targets the release of yocto that your edison build is also on? May 20 07:16:27 woah_dude: and *hint*: just deleting things is way more likely to break stuff even further instead of tfixing them magically. May 20 07:16:49 i know) but i need only 3 packages from qt, not all May 20 07:17:36 that doesn't mean that the build process doesn't need some other, less obvious files implicitly May 20 07:19:46 how can i understand which branch of meta-qt i need for edison? May 20 07:22:14 in terminal: poky git:(c4f1f0f) May 20 07:25:49 ok, i google it, it seems like daisy branch) i get daisy branch from qt git, and error is gone! May 20 07:26:26 LetoThe2nd thanks for your helps May 20 07:28:39 good morning May 20 07:32:19 woah_dude: sry, i'm not here all the time. IRC is rather asynchronous May 20 07:33:05 woah_dude: basically, check the documentation of your edison stuff (where did you get it from? what git branch are you on there?) and then select the corresponding one in the qt5 layer May 20 07:33:08 nonono, your advice actually fixed this error) May 20 07:33:17 ah ok? nice! May 20 07:33:23 yeah) thanks) May 20 07:33:51 woah_dude: basically be aware of the fact that the layer mix-n-match mechanism doesn't work too well across different releases May 20 07:34:23 ok, i'll be May 20 07:51:10 Hello together. Can anyone tell me how I can load some wifi-drivers at boot? May 20 07:59:32 zwerch: take a look at linux-firmware*.bb May 20 08:01:19 mckoan: Yeah, I found that, but they're installed at /lib/modules/[kernel_version]/kernel/drivers/net/wireless and I couldn't find any recipe / script that installs them there. May 20 08:01:50 zwerch: the proper driver knows where to get them May 20 08:02:30 zwerch: And how do I load some of them at boot time? May 20 08:02:42 Oops. I meant mckoan :D May 20 08:03:14 zwerch: add your driver to the kernel image or add the kernel module May 20 08:03:32 Ah, okay May 20 08:03:34 Thanks May 20 08:03:48 zwerch: yw May 20 08:16:20 Is there a way to write a bbappend for all linux-${MACHINE}_%? Via a wildcard? So I don't need to write an append for every machine. May 20 08:16:20 Or is this considered bad practice? May 20 08:25:16 zwerch: that sounds like an odd use-case, why is there a kernel for each machine? May 20 08:26:23 zwerch: However you could dod "linux-%.bbappend, and have an annoymous method that checks PN and does a SkipPackage bit like: https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-kernel/linux/linux-yocto-dev.bb#L22 May 20 08:28:12 zwerch: why don't you write a single append and use overrides in it? May 20 08:29:58 Maybe I wasn't clear enough: We have a few different machines, and some use different kernel recipes. What I need is a bbappend that matches all of them and appends some stuff to it. May 20 08:31:51 zwerch: does it matter if you append to a kernel that you are not using? May 20 08:32:02 the normal way would be a .bbappend for each recipe / kernel-type May 20 08:32:17 nrossi: I don't think so? :D May 20 08:32:33 ant: okay May 20 08:32:47 zwerch: as long as you are using machine overrides i see no issues with ant___'s suggestion May 20 08:33:15 see this: http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-handheld_4.0.bb May 20 08:34:09 that's standalone, the old 3.14 was done with .bbappend May 20 08:34:10 http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-yocto_3.14.bbappend May 20 08:36:01 So, I would do a .inc with my code for all machines, and then a bbappend for each machine, like "linux-imx_%.bbappend" and "linux-rpi_%.bbappend"? Or just one and declare all my machines in it? May 20 08:36:28 remember that the .bbappend will be parsed by anyone having your layer in .conf so even i.e. qemu would get the customization if it isn't done per-machine with override May 20 08:37:13 Okay, so my suggestion would be working, but is bad practice? May 20 08:37:50 I don't get it yet...what's PREFERRED_PROVIDER_virtual/kernel for your machines? May 20 08:38:30 I don't know :O May 20 08:39:41 I lost the crystal ball :/ May 20 08:43:19 Hi, is it possible to read lvds screen vendor from cmdline? i'm using mxc/ldb.c driver on imx6 May 20 08:43:22 Sorry, I think I don't understand the system completely yet. Just started working with it. I guess I try some things out, thanks to you all anyway. May 20 08:44:07 * nrossi hears the crystal ball smash the ground spilly the magic everywhere May 20 08:44:27 * LetoThe2nd hands nrossi a vacuum cleaner May 20 10:10:12 anyone knows how to build Qt 5.4 for Edison? May 20 10:11:35 When building stuff like qtdeclarative, qtquick, qtwebkit, make sure that May 20 10:11:35 you have required PACKAGECONFIG options enabled in qtbase build, see qtbase.inc May 20 10:11:35 for detail. May 20 10:11:39 on the qt meta git i see thus May 20 10:11:57 what should i do with PACKAGECONFIG? May 20 11:36:05 good morning May 20 11:43:22 I am a bit confused why busybox passwd does not work with daisy. It used to work with dylan. May 20 11:43:47 passwd: applet not found - is something wrong with the busybox maintainer script? May 20 11:44:00 busybox pwd for instance works fine. May 20 11:44:10 but using other applets like that, too. May 20 11:46:03 and this does not seem to be in the migration guide either, so I presume that I am doing something wrong, but what exactly? May 20 11:46:54 busybox passwd works just fine on my desktop, too. May 20 11:47:40 to be complete, "passwd" does work (without the busybox prefix), but that is not what I am aiming for. I am always trying to be explicit because I always want to use busybox's applet, no matter what. May 20 12:56:08 anyone had a chance to look into the book : https://www.packtpub.com/hardware-and-creative/yocto-beaglebone# ? May 20 12:56:31 was interested to read some sample chapter or review before buying May 20 13:05:18 hitlin37: nope, but I suggest this https://www.packtpub.com/virtualization-and-cloud/embedded-linux-projects-using-yocto-project-cookbook May 20 13:06:30 hmm..from the same publisher. btw, the ebook there is more expensive than book May 20 13:06:40 hitlin37: or if you are interested to BBB rather than Yocto, http://derekmolloy.ie/beaglebone/ May 20 13:07:22 hitlin37: Derek uses Debian though :-( May 20 13:07:39 i use debian as well :) May 20 13:08:21 hitlin37: so this is more than a book, is a complete encyclopedia ;-D May 20 13:09:37 its just the software changes so fast that these manual are hard to keep track of updated code. May 20 13:10:10 the way you compile yocto 6 months back is probably different than how you would do now... May 20 14:01:57 hi all May 20 14:02:43 hi May 20 14:08:37 is it possible to generate the sdk (populate_sdk) with kvm/qemu enabled instead the built qemu? is it better to run kvm in the host with the created rootfs outside the SDK? May 20 14:15:14 here is a random question for you all. In the output of bitbake -e, do you ever look at the pre-expansion value of a variable? If so, what for? May 20 14:23:48 yes, to see how a value ended up in a variable (e.g. via a different variable, etc) May 20 14:25:11 belen: see, it's not just me and RP :) May 20 14:26:02 neverpanic: good to know. Thanks! May 20 14:26:08 belen: absolutely, yes - same usecase as neverpanic May 20 14:26:24 thanks joshuagl May 20 14:27:08 rburton: fine, you win ;) May 20 14:31:50 bluelightning: My bitbake build has compilation error for samhain-server. I see a strange Warning all through [[ "cc1: warning: include location "/usr/include" is unsafe for cross-compilation]] May 20 14:32:30 Any idea why it is picking "/usr/include/sys/socket.h" from system path instead May 20 14:33:23 belen: so we're not that strange? :) May 20 14:33:58 RP: I wouldn't push it … ;) May 20 14:36:13 belen: ;-) May 20 14:38:13 milan_: it'll be specific to the samhain build system - if it has a configure script, maybe there is a missing argument May 20 14:38:29 milan_: or alternatively it may need patching to use the proper sysroot May 20 14:40:24 ok May 20 14:44:27 * lpapp is sad: http://lists.openembedded.org/pipermail/openembedded-core/2015-May/105140.html May 20 14:47:53 Hello ! May 20 14:48:30 lpapp: i'm curious, why run busybox directly rather than the symlink? May 20 14:48:35 * kergoth yawns, morning all May 20 14:50:31 I have a question, i am trying to build mplayer2 with directFB support to stream the video into a framebuffer but the sources of directFB are not found, i added the dependancies and enabled directFB in the mplayer2 recipe , am i missing somehing ? like telling where to find the directFB sources ? sorry i am new to yocto i don't know a lot and i didn't find the solution on my own, hope you can help me , thanks ! May 20 14:50:54 kergoth: I have just answered that on the mailing list. May 20 14:51:00 ah, k May 20 14:56:35 nobody ? :/ May 20 14:58:13 happycat: well for starters you will need to check the existence of framebuffer support in kernel May 20 14:58:40 from what I know directfb uses it :D May 20 15:00:03 Hi, yes i made a driver creating three framebuffers, they are working , but then a DMA allow a FPGA to read them and send the output via HDMI port, i know for sure framebuffer are enabled in kernel, (i can run a Qt app and output it to my framebuffer) the problem now is for a video :/ i just need mplayer with directFB support from yocto :/ May 20 15:01:03 so you have omapfb driver inserted May 20 15:01:49 i'm working on a Xilinx board , the framebufferDriver is the one from Xilinx but maybe that's not what you are talking about ? May 20 15:01:57 and if you write something from /dev/urandom to /dev/fb* an output appears on your screen? May 20 15:02:07 yes May 20 15:03:12 i can display raw images or start Qt4embeded applications inside it May 20 15:03:51 it may only be a mplayer2 problem or a yocto misconfiguration May 20 15:04:05 but I am not sure May 20 15:04:45 did you checked the tasks source code run.do_compile for example or some of the log files? May 20 15:05:38 kergoth: I would very much like the idea of dropping privileges for undedicated applets instead. May 20 15:06:03 yeah.. busybox has that capability built in, not sure why we're not using it, unless its paranoia :) May 20 15:06:06 it is also more future proof as some processes may gain access and then yocto will get in the way. May 20 15:06:15 i know mplayer2 has no directFB support on my build (mplayer -vo help list the available outputs but there is no fbdev) , i am trying to build it with directFB but now after 3 days i'm a little lost :/ , yes after enabling directFB support in mplayer2 recipe i have an error , the task do_configure executes perfectly but the compile fail because it cannot find directFB sources :/ May 20 15:06:35 i know at one point folks used busybox with the separate tinylogin project when they didn't want to use busybox priv dropping, but of course tinylogin is pretty much unmaintained, so i can see why they changed it May 20 15:06:41 still, you'd htink the split would be a PACKAGECONFIG May 20 15:07:12 sorry I will be out of office for the rest of the day, but maybe the other guys could help May 20 15:07:20 well, dropping privileges properly does not sound complex to me. May 20 15:07:36 not sure what maintenance exactly it requires, but for the time being, I cannot see it a complex patch May 20 15:07:39 Ok, thanks for your time :) May 20 15:07:56 of course, this needs to be maintained over time, so is it in Yocto anyway; now it is just IMHO maintained in the wrong place. May 20 15:08:13 if you think it would be useful I could take a look in private May 20 15:09:14 either a private chat or an email to vaduva.jan.alexandru@gmail.com May 20 15:09:48 but I do not guarantee it :D May 20 15:09:50 lpapp: busybox upstream already supports dropping privs, so it'd just be a matter of teaching the recipe to use it in a single binary rather than two when the user wants that. no patches necessary, other than to the recipe May 20 15:09:52 hmm May 20 15:10:18 kergoth: so why is that not done then? May 20 15:10:59 Ok i'll mail you tomorow , thanks a lot :) May 20 15:11:06 does the splitting predate the priv dropping logic? May 20 15:11:15 the splitting logic was merged two years ago now May 20 15:11:22 lpapp: i haven o idea :) May 20 15:12:01 rburton: nope, it's been there for many years May 20 15:12:39 * rburton shrugs May 20 15:12:41 patches welcome! May 20 15:13:22 i don't remember why we never used it, i suspect it was just paranoia about making busybox suid May 20 15:13:24 * kergoth shrugs May 20 15:13:28 well, if it is so, I guess it is just the matter of looking into distros' busybox to see how they implemented it? May 20 15:13:36 I am sure distros like debian looked into it if it is so. May 20 15:24:06 * nerdboy gets ready for wed gsoc mtg May 20 15:32:04 Hi, I'm using the meta-qt5 layer and I am doing a patch (in my own layer using a bbappend) that applies over a meta-qt5 patch. My patch tries to apply before the meta-qt5 layer's patch therefore, when yocto run my patch it cannot find the file that needs to be patched since it doesn't exist yet. meta-qt5 is a priority 7 and my layer is priority 8. Any idea how I could fix that? May 20 16:17:15 Do I file bugs for 'core' on Yocto bugzilla? May 20 16:17:20 or somewhere else? May 20 16:18:05 gabrbedd: you mean openembedded-core? May 20 16:18:11 meta/, etc? May 20 16:19:01 Right. meta/conf/layer.conf names the layer "core". I found a FTBFS in oprofileui-server_git.bb May 20 16:19:27 yes, that is Yocto bugzilla material, I would say. May 20 16:19:35 lpapp: ok, thanks. May 20 16:45:23 RP: tmp/work/x86_64-linux/opkg-native/1_0.2.2-r0/temp/run.sysroot_stage_all.23387: line 109: sysroot_stage_dirs: command not found — ever seen this? we've seen it in the past, with this or other variables, but have never managed to nail it down. this particular case is dizzy, though. May 20 16:46:04 hmmm May 20 16:46:16 * kergoth digs through bitbake logs to see if it was fixed at some point May 20 16:48:31 kergoth: I just closed a bug about this May 20 16:49:03 kergoth: I have a suspicion about where the problem is but no more than that May 20 16:50:15 kergoth: have a read of https://bugzilla.yoctoproject.org/show_bug.cgi?id=6477 May 20 16:50:16 Bug 6477: normal, Medium, 1.9, richard.purdie, RESOLVED FIXED, do_populate_sysroot failed: sysroot_stage_dir: command not found May 20 16:51:16 kergoth: Personally, I think backporting the later codeparser changes may well fix it May 20 16:51:45 kergoth: I think I hit something like this once I started using frozenset so if you wanted to test on the existing code, thats how I'd do it May 20 16:52:44 okay, thanks, will try that May 20 16:54:00 kergoth: could be something else entirely too, thats just my best guess. I couldn't make it reproduce on master May 20 17:29:02 hmm, /sbin is no longer in the PATH by default? May 20 17:29:47 my executable used to be in /sbin and it was enough to type myfoo with dylan, apparently not with daisy? May 20 17:30:18 should be for root May 20 17:31:21 it is for root, but not for a regular user like before. Is this expected? May 20 17:31:37 I cannot see it in the migration section. May 20 17:33:43 every linux distro i've ever used, since 1996, has had the sbin dirs in root's PATH only, not the user, and i end up having to add it to it in my user's profile May 20 17:33:48 * kergoth shrugs May 20 17:34:33 Archlinux is different, but my concern is breaking compatibility with documenting it. May 20 17:34:40 but let me put the dylan image back for a quick test. May 20 17:39:07 yeah, that's definitely a concern, compatibility breaks need to be documented somewhere May 20 17:40:50 * kergoth wonders how much work it'd take to get an arch install back to non-systemd again like it was May 20 17:47:14 so I wonder if it is best to extend my exec_exists function with /sbin as fallback that currently check an executable name against the PATH ... or I should extend PATH explicitly. May 20 17:47:14 perhaps the former would leave the system more vanilla. May 20 17:47:14 or would that be bad practice? It is not a yocto question though ^_^ May 20 18:35:22 should PR server handle AUTOREV-ed packages properly? I'm seeing "Package version went backwards" QA issue and the only change is in git hash AUTOINC+abcdef1234.0, the newer being lower of course May 20 18:46:05 denix: the AUTOINC is part of SRCPV, which is part of PV, which should be way before the pkgr which the pr server increments, so afaik you'd be best off looking into the autoinc number coming from fetch rather than the pr server, but i may be missing something May 20 18:46:13 hmm May 20 18:48:17 kergoth: full message - Package version for package ltp-ddt went backwards which would break package feeds from (0:1.0.0-r2+gitrAUTOINC+586d320b13.0 to 0:1.0.0-r2+gitrAUTOINC+2ab12eafbc.0) May 20 18:48:56 kergoth: so, yes, pkgr is not the problem - .0 in both cases. but why would it choke to detect lower hash as newer? May 20 18:49:34 it shouldn't even get to that point May 20 18:50:00 autoinc should be replaced with an integer, no? May 20 18:50:01 at which point the rest of hte version won't matter, one will be newer earlier on in the ersion string May 20 18:50:02 * kergoth shrugs May 20 18:55:26 * kergoth grumbles May 20 19:11:40 So I was trying to debug a thing, and I found a fascinating interaction-of-things. May 20 19:11:45 Imagine, if you will, an RPM postinstall script which does something idiomatic like "if [ -n "$D" ] then; exit 1; fi" May 20 19:11:47 Now, what happens if you put "set -x" at the top of the postinstall script? May 20 19:11:59 The answer is that do_rootfs fails because it sees "exit 1" in the log file output. May 20 19:13:36 kergoth: it seems prrserv.bbclass is require for that, though is not mandatory for PR server per se... May 20 19:14:11 otavio: does libepoxy build on fsl-arm? May 20 19:14:15 huh, that's interesting. without the autoinc replacement, there'd be no sane upgrade handling for git recipes, you can't tell which commit hash is newer.. May 20 19:14:47 seebs: haha, that's amusing. i guess it shoudl be exluding lines with the expected prefix from a set -x May 20 19:16:33 damnit, how do i get the depends out of an rpm? -qi doesn't seem to show tha tinfo May 20 19:16:44 * kergoth checks the man page May 20 19:18:36 ah, -R May 20 19:38:29 Oh, hey. That's a really good idea. May 20 19:38:31 I bet I can make that. May 20 19:38:43 whoops, foot brushed cat by accident, now I must spend an hour comforting her since she is hurt and betrayed. May 20 19:38:59 rpm --qp --requires or something like that? May 20 19:39:05 I look it up periodically. May 20 19:40:42 i have a console-image failing for rpm indicating something is trying to pull in 'libgcc', not 'libgcc-s1', but it doesn't tell me which freaking package wants it May 20 19:40:49 * kergoth find . -name \*.rpm | while read i; do rpm -qRp "$i" | grep -v libgcc.s | grep libgcc && printf "%s\n" "$i"; done May 20 20:13:41 kergoth: huh, not even INHERIT+=prserv replaces AUTOINC in resulting ipks... what am I missing? May 20 20:15:05 rburton: not yet May 20 20:15:15 rburton: people is working in a fix May 20 20:15:33 otavio: ok, glad that's known May 20 20:16:12 denix: not sure. looks like the PR server *is* what replaces it under normal circumstances, but if the pr server isn't used, it should be replaced by package.bbclass, so AUTOINC should never end up in the binary package, PKGV should have it replaced one way or the other, but i could be remembering wrong May 20 20:16:17 seebs: don't suppose you had any more thoughts on the reading hardlinked files created outside pseudo problem? May 20 20:16:23 sadly not very familiar with that code May 20 20:17:29 denix: are you using pr server or not? As kergoth says, AUTOINC shouldn't make it into the final packages May 20 20:17:45 kergoth: as I see from package.bbclass, it supposed to replace AUTOINC retrieved from PR server, but I still get packages with AUTOINC in the name/version May 20 20:17:50 Been thinking about it some. I suppose in theory if we don't care whether we get the database values, we could just not be running under pseudo to begin with, since it's presumably not very relevant. May 20 20:18:11 We could turn off that warning, but it's fairly often useful as a diagnostic in cases where something is actually wrong. May 20 20:18:19 seebs: not true, we care about some set of files, we don't care about some other set May 20 20:18:41 RP: I had PRSERV_HOST="localhost:0" only, then added INHERIT+="prserv" too, as I see that code referenced from package.bbclass May 20 20:18:43 seebs: the only way I can see to avoid this is to have some kind of path whitelist/blacklist May 20 20:19:41 denix: package.bbclass inherits prserv May 20 20:20:24 denix: dizzy again? May 20 20:20:38 RP: ok, missed that. explains why nothing changed :) doesn't explain why AUTOINC is not replaced May 20 20:20:48 RP: no, not that ancient :) it's daisy May 20 20:21:10 oh, hmm. May 20 20:21:39 Well, my canonical answer would be "if the files are expected to be accessed under pseudo, and are linked to files that pseudo knows about, they should probably be created under pseudo so there's a way to be sure it's not database corruption May 20 20:21:40 ". May 20 20:21:47 RP: I do get .X suffix incremented on rebuilds from PR server May 20 20:21:49 But that would be sort of expensive. Hmm. May 20 20:22:04 Although it might actually be cheaper overall because the "wait, that's suspicious" code is sort of expensive too. May 20 20:22:09 denix: http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=a9102e5bf9ea2d342cd09ccc603ec160f18a355a ? May 20 20:23:04 seebs: I really don't want to mark do_packageinfo as needing to run under pseudo :( May 20 20:23:15 hmm. May 20 20:23:40 I suppose you could do it for just one recipe, but probably expensive. Why does that recipe have to make hard links to a bunch of pseudo-managed files, and then access the hard links instead of the originals? May 20 20:24:10 seebs: its the generic sstate installation code which makes hardlinks as its faster and uses less diskspace May 20 20:24:18 Ahh. May 20 20:24:24 hmm. May 20 20:24:48 seebs: its not so much one recipe as needing to do this for that task in all recipes May 20 20:25:50 I may need to look at the actual specific case to understand this. May 20 20:25:51 RP: thanks!! I must move to the latest code base ASAP - tired of stepping on already fixed issues... :) May 20 20:26:01 what the hell. i have libgcc in IMAGE_INSTALL, and the libgcc-external recipe has RPROVIDES_${PN} += "libgcc". the resulting libgcc-s1 rpm does provide libgcc. yet an attempt to build the image fails saying it can't find libgcc. May 20 20:26:33 but only with rpm May 20 20:26:35 So as I understand it, we have a lot of files which are managed by pseudo. We make hardlinks to those files. Then we end up, running under pseudo, accessing the hardlinks, but we don't care about the ownership-or-mode of the hardlinks, so it'd be fine if pseudo just didn't recognize them? May 20 20:26:35 opkg works fine May 20 20:27:10 kergoth: debian.bbclass renaming not being accounted for? May 20 20:27:25 seebs: yes May 20 20:27:40 it's not a mapping / renaming issue, it's not obeying RPROVIDES May 20 20:27:44 What are we accessing them for? May 20 20:28:05 it was renamed from libgcc-external to libgcc-s1, but renamed or not, it still rprovides libgcc May 20 20:28:06 Alternatively: What's the smallest/least-dependency recipe that hits this? May 20 20:28:16 seebs: we don't care abuout the ownership/mode of them at all ever. There are other files we do want to track under pseudo though May 20 20:28:37 kergoth: master? I think there is an open bug about that :( May 20 20:28:40 Ohhh, so even the originals, we don't actually care about these particular files? May 20 20:28:47 seebs: right May 20 20:28:50 master, yeah, just with rpm May 20 20:28:54 k, will check the bugzilla, thanks May 20 20:29:06 verifying with pure upstream without mel now, to check sanity May 20 20:29:19 Any reason not to delete the original links (under pseudo) before people start looking at the hardlinks? May 20 20:29:44 The only reason it's coming up is that pseudo knows about those inodes under a different path name. If it didn't know, it wouldn't care. May 20 20:29:45 ah, right, https://bugzilla.yoctoproject.org/show_bug.cgi?id=5024 May 20 20:29:47 Bug 5024: normal, Medium, 1.9 M4, hongxu.jia, IN PROGRESS REVIEW , RPM backend cannot handle RPROVIDES in IMAGE_INSTALL May 20 20:29:50 seebs: yes, several good ones May 20 20:29:54 Drat. May 20 20:30:59 Hmm. May 20 20:33:55 Well, the sanity-checking could definitely be cleaned up some. May 20 20:35:06 And it might make sense to have a "careless mode" where some of the database integrity stuff gets skipped. May 20 20:35:40 seebs: another option is that we could run some code to tell pseudo "wipe files matching this expression from the db" May 20 20:36:04 Hmm. May 20 20:36:11 Oh, hey, that's a thought. May 20 20:36:44 Huh, that's odd. May 20 20:36:54 Why do I have both -r and -R for chroot? May 20 20:37:03 I am thinking something like May 20 20:37:21 pseudo -r /path => drop everything in the database with '/path%' as its path. May 20 20:37:46 seebs: we could certainly make that work I think May 20 20:37:55 *pondering* Might make sense to have some kind of 'ignore this' setting, too. Will ponder. May 20 20:38:21 It wouldn't be horrible, probably, to change the pseudo_diag message there to pseudo_debug(PDBGF_FILE May 20 20:39:48 AFK a bit, will be back later. May 20 20:47:27 RP: I also needed this from dizzy - http://cgit.openembedded.org/openembedded-core/commit/?id=865d001de168915a5796e5c760f96bdd04cebd61 May 20 20:47:52 denix: right, makes sense May 20 23:56:26 Hi, does anyone has an idea on how to prevent a package to end up in sstate ? May 20 23:57:25 I have this recipe that generates a file that summarize versions of layers / kernel / ,,, and it's not updated everytime my build runs. **** ENDING LOGGING AT Thu May 21 02:59:58 2015