**** BEGIN LOGGING AT Mon May 05 03:00:00 2014 May 05 07:26:22 good morning May 05 10:32:12 Hi all, have anyone successfully build qt5 with Wayland enabled instead of x11? I get errors with opengl headers when compiling qtbase. I tried both desktop and es versions but same results(fatal error: GLES2/gl2.h and cups/cups.h: no such file or directory). My distro features are : opengl alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g ipv4 ipv6 pulseaudio ${DISTRO_FEATURES_LIBC}" , DISTRO_FEATURES_append = May 05 10:53:02 hi yocto. I added libiconv as dependency for my custom image. But it affects the build of rpm package and i m getting the error http://upaste.me/a02112199d3a71cf6 May 05 10:54:05 i am trying to fix that by adding an bbappend using the variable EXTRA_OECONF += "--disable-nls". but didnt help May 05 10:54:23 anyone familiar with these packages? May 05 12:53:23 hi. I want to pass LIBS flag in configure. I am doing this in bbappend by EXTRA_OECONF += "LIBS=\"-liconv\" . but giving me parse error May 05 13:04:14 vicky: You're missing a closing " in that string May 05 14:14:57 something strange with BAD_RECOMMENDATIONS (ipk backend). if I set it to "udev-hwdb" it excludes udev-hwdb as expected. if I set to "udev-hwdb wpa-supplicant-cli" it excludes only wpa-supplicant-cli. if I set to "wpa-supplicant-cli udev-hwdb" it excludes only udev-hwdb. any ideas? **** BEGIN LOGGING AT Mon May 05 14:20:12 2014 May 05 14:42:41 Hi all. I would like to run entirely from RAM. I am thinking something like unionfs, but just not writing back to the disk. Somebody suggested making a ramdisk and "pivoting" to it. Can anybody give me tips on how to accomplish this? May 05 14:46:16 BTW... I basically want a read-only root filesystem, but I have several layers that do not appear to play nicely with this image feature, and I am thinking that this may be a work-around. May 05 15:39:00 bryan: there is a read only rootfs option that provides some areas with ramfs May 05 15:39:32 bryan: if other layers run into problems that seems to be more a bug May 05 15:42:18 bryan: what does not play nice with the ro-rootfs? May 05 15:53:57 I have https uri with username/password what is correct syntax for bb/fetcher to be happy ? May 05 15:57:16 no idea, i think i set it in the netrc file for jenkins... May 05 15:57:32 but then switched to keys May 05 15:58:26 yeah, netrc is about the only option really, unless it's a git repository, in which case you can use a git url insteadOf + ssh keys May 05 15:58:56 i *think* you can speicyf hte username/pass in the url in the recipe, but don't, that'd be bad :) May 05 16:00:33 a url should work, but i wouldn't put it in a recipe either... May 05 16:01:00 although i'm pretty sure we don't need to tell khem *that* May 05 16:01:26 indeed :) May 05 16:01:56 so i'm gonna say you were at the top of my list of people who didn't show up that i wanted to see May 05 16:02:47 I didn't talk to my manager in time to get approval to hit ELC/OEDAM this year, sadly :( I went to ELC a year or two ago, but need to make it a habit, and set some damn alarms on the calendar May 05 16:03:06 * kergoth rolls eyes at self May 05 16:04:52 Somehow most conferences seem to be on the west coast or las vegas. May 05 16:08:54 kergoth: you mean .netrc in builder's home May 05 16:09:22 yeah May 05 16:10:02 kergoth: whats the syntax for SRC_URI ? SRC_URI = "https://..;user=xx;password=yy" did not work May 05 16:10:20 no, it's the part of th scheme, like a url in your browser May 05 16:10:29 http://foo@bar.com/ http://foo:bar@baz.com/ May 05 16:10:32 s/th/the/ May 05 16:10:33 yup May 05 16:10:52 works fine as jenkins user May 05 16:10:54 erm, part of the netloc, technically May 05 16:11:52 I am going through the slides of mcroYocto and the Internet of Tiny. Are there any real world examples how it can be used? May 05 16:11:53 so when do you want your reminders to start? today? May 05 16:12:43 Aside: does anyone know if the yocto documentation states anywhere that a bsp layer should use machine overrides, and a distro layer should use distro overrides, to avoid impact just due to layer inclusion rather than opting into its configuration? May 05 16:12:53 thats the general policy i follow, but i'm not sure if thtere'ps an officail stance on that May 05 16:12:57 blah, can't type today May 05 16:13:56 no idea May 05 16:15:56 kergoth: putting it in .netrc would mean its global right May 05 16:16:07 not sure what ou mean by global May 05 16:16:08 now if I have two different https servers to fetch ffrom May 05 16:16:11 no May 05 16:16:15 for that user, yes May 05 16:16:16 .netrc format includes host May 05 16:16:18 host/user/password May 05 16:16:25 ah May 05 16:16:35 you can have multiple stanzas May 05 16:17:03 is it like .ssh/config syntax May 05 16:17:45 https://www.gnu.org/software/inetutils/manual/html_node/The-_002enetrc-File.html May 05 16:19:07 * nerdboy assumes tlwoerner is back in the great white north again May 05 16:20:13 machine login password May 05 16:20:20 thats all good May 05 16:23:38 ssh keys are better, but not always doable. netrc is easy and painless. don't forget to chmod 0600 ;) May 05 16:23:54 yeah he May 05 16:27:37 https://www.youtube.com/watch?v=C1TxX-gLdL4 haha May 05 16:46:56 I am compiling samba as native package. To accomplish that I had to remove one line from the autotools CONFIGUREOPTS (--exec_prefix). Now it seems like ${prefix} get's expanded to much more as expected to --prefix=/home/data/yocto/poky/build/tmp/sysroots/x86_64-linux/usr May 05 16:47:26 is this due of the -native? May 05 16:51:04 you shouldn't have to remove anything. native.bbclass should take care of the majority of what's needed May 05 16:51:07 and eys May 05 16:51:08 yes May 05 16:51:18 native.bbclass sets prefix May 05 16:51:37 kergoth: CONFIGUREOPTS is from autotools. --exec-prefix has to be removed for samba4 (because else ./configure fails). May 05 16:51:57 that really doesn't make any sense May 05 16:52:18 the problem I run into is that the entire system is not packaged and in the ${D}/image folder is the image/home/data/yocto/poky/build/tmp/sysroots/x86_64-linux/{etc,usr,var} May 05 16:52:28 s/system/package/ May 05 16:52:54 kergoth: get samba4, run ./configure --exec-prefix=/bla May 05 16:53:25 you get then 'waf: error: no such option: --exec_prefix' May 05 16:53:25 why would anything be packaged? -native recipes are by definition not packaged. they're built for the build host, to be run on the build host, as a part of hte build process for the things for the target May 05 16:53:46 you shouldn't be inheriting autotools.bbclass if the configure script isn't autotools, IMO :) May 05 16:54:33 kergoth: so I will never get an .ipk/.deb/.rpm out of an -native? May 05 16:54:44 that's correct. that's not what native is for. May 05 16:54:58 it sounds like you're taking the wrong approach to begin with. what exactly are you trying to accomplish? May 05 16:55:57 kergoth: I want samba4 as package. Cross-compiling samba4 is... let me phrase it this way: not the way you want to go May 05 16:56:27 kergoth: so configure+compile via -native and then pack the stuff together May 05 16:58:05 that's not a supported use case today. OE/Poky don't support building a distro natively. the native class is to build tools which are then used by the target recipes to build for the target. I *think* someone might have started looking at a native MACHINE at some point, but that's not really something that's supported today May 05 16:58:38 kergoth: some packages use -native to get them build May 05 16:58:54 that's correct, yes May 05 16:59:19 kergoth: so thats all I want for the samba package May 05 16:59:20 as i said before, that's to build tools which are then run/used by the cross build May 05 16:59:27 you're still misunderstanding what native is for in oe May 05 16:59:32 lets take an example May 05 16:59:45 to build ncurses, ncurses wants to build tic, and then run it May 05 16:59:52 if you cross-compile ncurses, that's obviously not going to work May 05 17:00:05 so we build ncurses-native, to get an identical version of tic that's runnable on the build host May 05 17:00:16 then we get the regular ncurses bulid to use that, rather than building its own May 05 17:00:25 thereby getting around that cross-compilation issue May 05 17:00:41 all the others are similar cases, or are to avoid build dependencies on the host May 05 17:00:45 * nerdboy trying a 12 MB graph in the g+ image uploader May 05 17:00:59 just for shits 'n grins of course... May 05 17:01:15 kergoth: so I can't get a package that is compiled native? May 05 17:02:12 oe assumes cross-compilation. it has zero support for a case where build==host==target, other than the limited native class, which again, isn't packaged, and only puts things in the sysroot for other recipes to use May 05 17:02:31 ouch, that's not good May 05 17:02:39 even the sdk creation uses crosscompilation, it emits a crosscompiler from build to SDKMACHINE, and then builds the target bits as canadian cross May 05 17:03:07 there are cases where cross compilation is just a pain, that where -native would be a win if you can package it May 05 17:03:22 cross-compilation is almost *always* a pain, we just deal with it :) May 05 17:03:40 kergoth: yes, but there are low pain, and there are infinit pain packages. May 05 17:03:44 okay, i'm somewhat impressed May 05 17:03:58 volker-: python/perl/etc are all likely much more difficult than samba is May 05 17:03:59 it took the whole thing and didn't choke May 05 17:04:07 volker-: and we got all of them going :) May 05 17:04:20 but I agree, nowadays there'd be value in supporting the native case, as target machines are better performing than they used to be, and emulation is much faster than it used to be May 05 17:04:40 e.g. qemu, particularly if you use distcc to call out to a cross-compiler on the host transparently, the way aboriginal linux does May 05 17:04:47 kergoth: yes, and I am sure there is a good reason why some (recent) packages are not available because you just don't want to deal with their cross compilation issue. May 05 17:07:12 kergoth: why torturing yourself when there could be an easy way? May 05 17:07:52 if you want natively built stuff, install debian :) May 05 17:08:11 oe was cross-compilation capable from the start, it was half its reason for existing, and there are good reasons for it May 05 17:08:20 wasn't my choice to use yocto. May 05 17:08:57 kergoth: and I think debian is more open to cross compilation. fedora only "accepts" native builds (so they had to build a build cluster of raspberry pi's to get a distro version out of it) May 05 17:08:58 I really don't think complaining about its capabilities here is going to solve anything. I'm certain folks would be open to adding support for what you're asking, but it doesn't exist today May 05 17:09:27 So you'll either need to add support for that, get samba4 to crosscompile, or talk someone into letting you use something else May 05 17:09:30 * kergoth shrugs May 05 17:10:49 I just took about 5 minutes and checked another project which does crosscompilation, buildroot, and they have samba4. so clearly getting it to crosscompile must not be as impossible as you seem to think it is, if they've already done so. presumably you could leverage what they have to create a recipe May 05 17:11:28 http://buildroot.net/ May 05 17:12:00 so that's waht i'd suggest, create a samba4 recipe based on both our samba 3 recipe and their samba4.mk bits if necessary May 05 17:12:21 looks like waf has built in support for presupplying test results for crosscompilation May 05 17:12:22 --cross-compile \ May 05 17:12:22 --cross-answers=$(@D)/cache.txt \ May 05 17:12:26 is in samba4.mk May 05 17:12:41 hmm May 05 17:14:37 looks like oe-core has a waf.bbclass. really minimal, though. could likely use some improvement May 05 17:18:30 ah, those cross args might be specific to samba4, don't see them mentioned in the waf book May 05 17:18:36 yes, with the 4.x you can provide an answer table, but that is just an hack for cross compilation issues May 05 17:19:09 kergoth: look at the available samba recipe and you see how much had to be modified to get it even run ./configure May 05 17:19:11 Again, either enhance yocto to support native, or *deal iwth the crosscompilation issues* May 05 17:19:16 whining about it here isn't solving anything May 05 17:19:48 buildroot has it crosscompiling, so getting a recipe going shouldn't take long based on what they have May 05 17:25:10 I don't wine, I just don't understand why it is only semi-supported May 05 17:26:46 Sorry, I did not know what trying to understand things and expressing confusion is wrong here. May 05 18:43:20 volker: I have 4 scripts in "rpm-postinsts" that want to run on first boot: connman, gnome-panel, polkit, udev-hwdb. I need udev for interacting with a specific piece of hardware we are using. The others I think are getting pulled in because I am building with an XFCE desktop (I am starting with the configuration files and recipes for the Gumstix DuOvero module) May 05 18:49:11 connman seems a bit odd, woudlnt' think that'd be necessary May 05 18:50:43 someone at elc claimed the newest version was better... May 05 18:51:19 whatever got built in the sato image a few months ago was annoying as hell May 05 18:51:48 *whatever version of connman May 05 18:52:38 bryan: if these scripts don't really have to run, you should be able to remove these postinstall snippets on the image. May 05 18:54:56 I see. Presumably, connman is for connection manager? I don't think that is necessary for us. polkit I guess is for policyKit? What would be the effect of removing that? I would guess that gnome-panel could be removed safely. What about udev-hwdb? May 05 18:56:50 x11-sato as image feature will pull in connman May 05 18:57:11 * nerdboy thought maybe xfce would pull in networkmanager instead May 05 18:57:31 bryan: you can try IMAGE_INSTALL_remove = " connman" (I don't know if _remove is supporte dhere, but I found it in the bitbake code snippet next to _append and _prepend) May 05 18:57:46 really needs a virtual for that, unless there already is one... May 05 18:58:13 nerdboy: what does that mean exactly? May 05 18:58:57 one could make a PREFERRED_PROVIDER_netman or something May 05 18:59:11 bryan: alternatively you can also link some files to the RW area if only a few files are affected May 05 18:59:35 because you could have sysvinit satisfy the basic case, or connman or networkmanager May 05 19:02:03 maybe it's one of the other init recipes for the basic case, but you certainly don't require a networkmanager to support networking unless the desktop depends on it May 05 19:03:04 if you're going to hack it by hand, i'd leave the udev-hwdbs in there May 05 19:04:05 If I leave it there, I can't finish building. bitbake seems to check to see if there are any files in rmp-postinsts. If there are it fails. May 05 19:04:18 packagegroup-core-x11-sato uses NETWORK_MANAGER variable, but that doesn't seem to be used acrosst he board, and it should really be VIRTUAL-RUNTIME like the other runtime virtuals May 05 19:04:22 from a quick grep May 05 19:05:23 sounds right to me May 05 19:06:03 as far as ro-rootfs, you can still have volatile support and tmpfs mounts without enabling ro-root May 05 19:06:18 A more generic question: If I run with a read-only root filesystem and run our code as root, there is not a need for polkit... right? May 05 19:06:35 what exactly is volatile support? May 05 19:06:36 Shouldn't bitbake complain if it can't find a listed PREFERRED_PROVIDER ? May 05 19:07:28 bryan: there's a process-volatiles.sh init script and some config files that define what gets mounted to tmpfs May 05 19:08:03 it also creates files/dirs/symlinks in /run and whatnot May 05 19:08:43 depending on what the code does, i'd think hard about making it run as a normal user May 05 19:09:07 you can give it the right ownership/perms using the above volatile config May 05 19:09:17 look at mpd for example May 05 19:09:25 but what harm can be done if the root filesystem is read-only? May 05 19:09:42 you have to have it read-only? May 05 19:10:01 then volatile mounts are all you get that's writable May 05 19:10:44 Well, "have to" is a bit strong. It seems like the safest way to prevent filesystem corruption due to unexpected power failures. May 05 19:10:55 volatile meaning tmpfs or some other ram-based block device May 05 19:11:24 is it flash with jffs2? May 05 19:11:50 if not then don't worry about it May 05 19:12:31 i've been running my pi in the car for months with countless hard power-offs and no troubles May 05 19:12:48 Right now it is a flash SD card with etx3. May 05 19:13:06 mount options, volatile stuff, and no ro-rootfs May 05 19:13:23 i use ext4 but same thing May 05 19:13:46 4 is a bit faster and more tolerant May 05 19:14:53 Are you saying "jffs2" is less resilient than ext for power failures? May 05 19:15:59 probably that too, but i was referring to jffs2 on flash with it's fairly heavy overhead requirements May 05 19:16:37 and not-so-good error-checking depending on various factors May 05 19:16:50 ubifs is what you want for flash May 05 19:17:22 but like i said, ext4 is fine with sd/micro cards May 05 19:20:14 My expectation is that the system we are using will essentially never be powered down "properly". If using a filesystem that is not aware of the flash erase block size/alignment, then after enough power cycles it would seem that corruption is inevitable. May 05 19:24:24 I expect aufs combined with r/o / might be an easy option for you, otherwise to use our normal r/o rootfs option you have to deal with software that expects to be able to write to the filesystem on a case by case basis. May 05 19:27:23 i'm still running the same sdcard i deployed over 6 months ago May 05 19:28:56 nerdboy: Roughly how many power cycles do you think you have gone through? May 05 19:29:58 several per day until i stopped commuting a few weeks ago May 05 19:30:10 here's my fstab: https://github.com/sarnold/meta-alt-desktop-extras/blob/master/recipes-core/base-files/base-files/raspberrypi/fstab May 05 19:30:35 every time i hit the power button in the car May 05 19:31:01 i just leave i plugged into the lighter port for power May 05 19:32:18 kergoth: aufs is abandoned, right? From their website: Note: it becomes clear that "Aufs was rejected. Let's give it up." According to Christoph Hellwig, linux rejects all union-type filesystems but UnionMount. May 05 19:33:43 Thanks nerdboy. The event I am worrying about may be more rare than I realized. May 05 19:34:45 looks like about 1000 power cycles over 10 months May 05 19:34:57 approximate May 05 19:35:51 stopping for coffee and gas, etc May 05 19:37:14 kergoth: That is not to say I am opposed to using it still. Do you know of a tutorial or example using it in Yocto? May 05 19:37:36 isn't unionfs the newer one? May 05 19:38:59 no May 05 19:39:02 unionfs is largely dead. May 05 19:39:06 aufs continues on. May 05 19:39:08 It looks like aufs was actually a re-write of UnionFS, but I am just reading what I see online May 05 19:39:22 I see. aufs is still used a lot? May 05 19:40:04 I have it in all the Yocto kernels, Wind River uses it, as have Ubuntu and other distros over time. union filesystems are a 10 year saga. May 05 19:40:32 Ok. Thank you. May 05 19:41:38 the answer to "which one is dead, or which one will merge" changes about every 6 months ;) May 05 19:42:06 What is required to actually use aufs with an image? Is this just a change to a conf file somewhere? May 05 19:42:19 lol May 05 19:43:23 depends on the kernel you are using. the tools are in meta-fileystems last I checked, but you need a matching kernel. May 05 19:55:09 unionfs is a genkernel option May 05 19:55:24 i'd have to go bug someone to find out why... May 05 19:58:58 It's sad that no unioning filesystem ever gets merged May 05 19:59:08 There's clearly cases where it's valuable May 05 19:59:44 jjm: vmeson and seebs wanted those SECURITY_CFLAGS in the wr-security layer, not the wr-tools-profile layer. They rejected the earlier change May 05 20:00:17 dlerner: Should this be on the other IRC server? Not that it's company-confidential or anything, just probably of marginal interest to general #yocto folks. May 05 20:00:30 sorry May 05 20:03:07 heh May 05 20:04:55 http://stilldrinking.org/programming-sucks <-- this now comes to mind every time I see someone suffer from "this computer program did not do what I thought I was asking it to do". May 05 20:05:10 hehe May 05 20:05:22 that article is so true May 05 20:56:27 that guy is hilarious May 05 21:13:11 Am I correct in thinking we don't need to retain do_package sstate archives when we have do_package_ipk_write sstate, unless the user needs to repackage? Or are both necessary to make bitbake happy? May 05 21:13:44 Hm, damn, my build seems to want both. that's a bit odd. May 05 21:33:46 Hey, how do I figure out what is pulling a particular package into my image? May 05 21:37:43 bryan: The shortest path I've found is to add PNBLACKLIST[package] = "i have a kitty", then try to build. May 05 21:38:02 This should give a backtrace of the chain of packages which caused it to be brought in. Note that I'm not sure the blacklist is enabled by default. May 05 21:38:55 Excellent. Thanks - I will try this. May 05 21:41:27 seebs: that's a good idea May 05 21:41:43 bryan: if it's a build dependency, thats what bb-whatdepends is intended to do, but it can't handle runtime dependencies yet :( May 05 21:45:22 Ok. Thanks kergoth. May 05 21:46:07 bryan: https://github.com/kergoth/bb#examples for that, but i expect the PNBLACKLIST approach will be more versatile due to the aforementioned limitation May 05 22:01:15 khem: around? Are you looking at the fsl-ppc ICE issue? May 05 22:08:50 fray, wondering if you can help with a packaging problem. I build a 3.15 kernel recipe earlier, have since done a "cleanall" on it and am now building a 3.14 kernel. When I build my images, they are installing 3.15 kernel-module* packages. I don't see 3.15 anything in tmp/deploy/ipks. Do you know where it might be getting them and what I have to do to purge them so it will use the 3.14 versions I'm building? May 05 22:43:01 dvhart: if it's installing 3.15 packages then they must be there to install May 05 22:43:06 dvhart: stupid question but you are looking in the right directory, right? ;) May 05 22:43:56 bluelightning_, if I move tmp to tmp-old and try again I get 3.14 modules - so I'm clearly NOT looking in the right spot May 05 22:44:00 where should I be looking? May 05 22:44:20 dvhart: well, tmp/deploy/ipk/ if you are indeed using ipk packaging for the image May 05 22:44:36 I am and there are no 3.15 named packages there May 05 22:44:46 is it possible that they have 3.15 meta-data but 3.14 names? May 05 22:45:26 hmm May 05 22:45:44 it's unlikely but possible you have 3.15 kernel modules inside 3.14 named packages May 05 22:45:58 $ find tmp-old/deploy/ipk -name "kernel-modules*" May 05 22:45:58 tmp-old/deploy/ipk/corei7-64-intel-common/kernel-modules_3.14.0+git0+6201e4c7c6_35c6cfd269-r0_corei7-64-intel-common.ipk May 05 22:46:02 do you have package management enabled on the target? May 05 22:46:06 yes May 05 22:46:19 opkg list-installed lists the 3.15 packages May 05 22:46:43 hmm May 05 22:46:51 you definitely reflashed / installed the new image? May 05 22:47:02 definitely :-) May 05 22:47:26 ok so this shouldn't be possible... May 05 22:47:35 Glad it isn't just me :-) May 05 22:48:33 the manifest file for your new image - which versions does that have in it? May 05 22:48:47 and now that the image looks right... RCU kernel stalls..... fanfriggintastic May 05 22:48:56 bluelightning_, where is the manifest file? May 05 22:50:50 should be a .manifest file next to the image file in tmp/deploy/images// May 05 22:52:12 old and new both only list 3.14 May 05 22:52:44 I'm starting to feel like the guy who hears voices :/ May 05 22:53:45 so that kind of suggests to me that the image on the target isn't the same as the image you built... May 05 22:54:02 yeah, sounds like it May 05 22:54:23 not sure how it could not be since I'm copying it over to the device (mkefidisk.sh) May 05 22:54:33 including recreating and formating each partition May 05 22:57:01 if I can reproduce, I'll let you know - evidence is disappearing despite my best efforts :-/ May 05 22:57:20 hmm, ok May 05 22:58:22 I hate these kinds of issues :-/ I seem to run into them more than many May 05 22:59:02 yes it's particularly annoying when they come up when you're trying to troubleshoot something else :/ May 05 23:01:25 aha, that's handy. you can search for a specific filename in github by adding in:path. e.g. conf/machine/foo.conf in:path May 05 23:01:29 (OT) May 05 23:09:12 bluelightning_, indeed! May 05 23:48:15 * kergoth wonders if there's a way to tell bitbake to exit after fetching/checking all the sstates May 06 00:07:10 strace it, wait until a short period after you stop seeing opens-for-read of sstate files, SIGKILL? May 06 00:07:29 ... hmm. I think the thing where I start getting bad ideas if I don't have dinner is kicking in. May 06 00:07:36 I'd sooner just patch bitbake to add a new argument ala -p (exit after parsing) :) May 06 00:07:50 alternatively, use an event handler. e.g. exit at BuildStarted May 06 00:07:59 hmm May 06 00:08:10 not sure if that fires before or after the scenequeue, actually :) May 06 01:02:08 does anyone have some suggestions on how to find why an X11 wouldn't have keyboard when started from init, but when the init.d is restarted later everything just works? **** ENDING LOGGING AT Tue May 06 02:59:58 2014