**** BEGIN LOGGING AT Wed May 18 02:59:58 2016 May 18 05:52:31 hey hi, when I am adding multilib support in my local.conf I am getting compilation issues while building linux but the same works fine if I remove the changes May 18 05:53:00 anything obvious which I am missing here? May 18 05:53:53 I tried adding DEFAULTTUNE in my platform.inc file but nothing changed May 18 06:22:49 khem, any idea about the issue? May 18 07:23:43 Hi May 18 10:43:06 Hey what package can I add to have a QT5 IDE already built into my Yocto OS IMage ? May 18 10:49:15 Anybody here? May 18 10:53:37 cart_man: on the image itself ? I don't know... May 18 10:53:45 maybe there is a qtcreator target... May 18 10:54:13 Yea I would like an IDE on it if possible... I can not get the targeted QT Compiler thing right May 18 10:54:20 Or Eclipse May 18 11:00:23 I'm having some trouble with the mozjs recipe from meta-oe. Specifically, the build compiles a couple of small binaries that are used to generate some header files during the build. May 18 11:01:23 I would like to compile and run those using a bitbake-generated toolchain, which is not the target toolchain. May 18 11:03:42 Problem is that I can get it to compile using a "host" toolchain, but running the binary ends with it trying to use libraries from my build computer, which fails. May 18 11:04:07 if binaries are built during a build for use *during* the build then it should use the host compiler and libs May 18 11:04:12 aka BUILD_CC etc May 18 11:04:19 (The failure is due to /lib vs /lib64 on my build computer..) May 18 11:04:38 if that is breaking then the recipe and/or upstream is broken May 18 11:05:00 (some upstreams don't expect cross compilation and will pass target linker flags to native compilers) May 18 11:05:40 rburton: I think that's what's going on here... I'll investigate further. May 18 11:06:20 if upstream doesn't recognise that cross compiling happens then the usual solution is to build those binaries in a do_compile_prepend manually using BUILD_CC BUILD_LDFLAGS etc etc May 18 11:06:46 Hmm, that sounds like a good approach. May 18 11:06:47 ie pango has to do this May 18 12:22:01 cart_man, there is a qtcreator target as far as I remember May 18 12:22:39 present: Yea but there are soo manny bitbakes and stuff that has to be run before begin able to do that though? May 18 12:42:31 surely its just "bitbake qtcreator" May 18 12:42:42 I've added a busybox append layer and recipe so that it adds a config file in /etc and I've added a new working /etc/init.d script. However I can not get a link in rc?.d working. I do not get a link in any of the dirs to my new file. I added inherit update-rc.d, INITSCRIPT_NAME and INITSCRIPT_PARMS lines. May 18 12:44:09 davis: does your distro features include sysvinit? May 18 12:44:20 the parts which work are the do_install_append(), is it because the original.... May 18 12:44:35 rburton: i'm not sure. I know it does not use busybox for init May 18 12:45:02 one sec while i find the pkg which make init May 18 12:45:12 that's irrelevant May 18 12:45:19 it only cares about the value of DISTRO_FEATURES May 18 12:45:28 (bitbake -e | less) May 18 12:45:52 hmm. i used ntp as a model for how to add the init.d file and rc.d link May 18 12:47:50 i did the bitbake -e line, what am i looking for? DISTRO_FEATURES? May 18 12:48:20 that variable shows up a lot May 18 12:48:45 one of them shows ${DISTRO_FEATURES_LIBC} sysvinit" May 18 12:53:48 hmm. in sysvinit_d.288dsf.bb there is a diff from ntp. It does not inherit update-rc.d, nor does it do INITSCRIPT_NAME and PARMS, but instead doees update-rc.d -r $(D) foo start 07 S . in the do_install code. May 18 12:55:53 Anybody in here even used Yocto on an IMX6 board WITH the hopes of coding on a QT Ide "Targeted" to the IMX6 Board? May 18 13:04:16 hi May 18 13:05:17 can I somehow rebuild a project, but not entirely, instead like calling "make"? let's say I edit a file in build/tmp/work/..../ May 18 13:05:47 blotunga: not that way, no.... May 18 13:06:03 yocto assumest that tmp/work is his thing and isn't touched externally May 18 13:06:24 but if you want to develop/patch the source of a package, you should have a look at devtool May 18 13:06:24 boucman_work: then yocto completely unusable in development May 18 13:06:32 (grep in the user manual) May 18 13:07:03 and also externalsrc, but devtool wraps that for you May 18 13:07:37 so there is no way to quickly test changes in some module? May 18 13:07:41 blotunga: yocto is mainly for integration/distro developement. It does provide functionalities for devs, but that's not the main target. Still, devtool is what you are looking for May 18 13:07:52 blotunga: yes, devtool... May 18 13:08:32 it clones the source for you, transform it into a git repo if it's not a git source, apply whatever patches yocto has to apply and configure a bbappend to work with that source instead of tmp/work May 18 13:08:44 then you commit to the git repo and yocto can regenerate the patchset from that May 18 13:09:06 tweaking tmp/work is not the right way to do what you want, but it's definitely possible... May 18 13:09:07 i see May 18 13:09:32 blotunga: bitbake [recipe] -c devshell will give you a shell in the work directory of the recipe, so you can run make May 18 13:09:45 blotunga: that's good for experimenting with a broken build. May 18 13:09:57 blotunga: if you want to do proper development then devtool May 18 13:09:59 rburton: hmm, that might help May 18 13:10:07 but I'll look into devtool May 18 13:10:08 rburton: I personally don't like that, it's so easy to get confused and so hard to generate a patch.... May 18 13:10:14 don't give him bad habbits :P May 18 13:10:21 :D May 18 13:10:27 yeah devshell is very much for experimentation May 18 13:10:46 coming from buildroot I assumed there was an easier way :D May 18 13:10:48 (next you'll tell him to look at $WORKDIR/tmp/do_compile.sh) May 18 13:10:49 why does this build break, let me build some bits manually, make a experimental tweak before writing a proper patch May 18 13:10:53 oops, did I say that ? :P May 18 13:11:02 yeah running temp/run.do_compile will re-run the build! May 18 13:11:29 at that point bitbake -C compile works too. devtool is here to do it cleanly and easily generate patch May 18 13:11:52 the other are hackish, and mainly here to figure out what's going on. it quickly reaches its limits May 18 13:12:04 bitbake -C compile rebuilds from scratch May 18 13:12:24 In a project like qtwebkit for a small change that can take 30 mins + May 18 13:12:25 no it doesn't May 18 13:12:37 it will re-run make May 18 13:12:44 or whatever do_compile does May 18 13:13:17 rburton: I just tested, it does do_unpack, do_patch ,etc May 18 13:13:28 I've ran: bitbake -b qtwebkit_5.1.1 -C compile May 18 13:13:32 don't do tat May 18 13:13:52 there's almost no reason to use -b May 18 13:14:14 rburton: any feedback on these 2? http://lists.openembedded.org/pipermail/openembedded-core/2016-April/120813.html http://lists.openembedded.org/pipermail/openembedded-core/2016-April/120814.html or were they just missed in patch queue? May 18 13:14:17 * boucman_work had never heard of -b May 18 13:14:21 boucman_work: keep it that way May 18 13:14:46 rburton: i'm the yocto expert here, If I tell people not to use an option, I need to know about it :P May 18 13:14:47 JaMa: opened, will look shortly May 18 13:15:10 boucman_work: -b says "forget about preferences and dependencies and everyhting else, just open this recipe and do stuff" May 18 13:15:12 nope, still do_unpack-ing May 18 13:15:20 blotunga: do you have rm_work? May 18 13:15:35 rburton: rm_work? May 18 13:16:13 INHERIT+=rm_work somewher in your environement May 18 13:16:27 (run bitbake -e | grep INHERIT if you don't know) May 18 13:16:53 so I tried a different way to get this init script link in /etc/rc?.d but it still did not work. May 18 13:17:22 nope, no rm_work May 18 13:17:23 im using these pages as a guide May 18 13:17:26 https://lists.yoctoproject.org/pipermail/yocto/2012-December/010853.html May 18 13:17:39 http://docs.openembedded.ru/update-rc-d_class.html May 18 13:18:16 davis: why not the actual documentation, http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#ref-classes-update-rc.d May 18 13:18:29 davis: did you check DISTRO_FEATURES? May 18 13:19:15 i did the line you suggested, but did not know what i was looking for. May 18 13:19:31 bitbake -e | less, search for DISTRO_FEATURES= May 18 13:19:47 one sec, i'll try May 18 13:20:46 yes i have that line May 18 13:21:01 what am i lookin gor? May 18 13:22:07 "sysvinit" May 18 13:22:29 The Tories will make sysvinit grate again May 18 13:22:37 * Crofton|work crosses several memes May 18 13:23:08 not sure whether i want to applaud or shout at you for that ;) May 18 13:23:22 :) May 18 13:23:34 The lassie one was awesome May 18 13:24:18 yeah :) May 18 13:24:50 can I use devtool on an existing project like qtwebkit? May 18 13:25:26 blotunga: you can use it on antyhing May 18 13:25:52 blotunga: http://pastebin.com/V0npvzTj <— bitbake -C compile m4. see, no unpack. dont use -b unless you know what you're doing with it May 18 13:26:36 I wonder why it does unpack in my case then.. even without -b May 18 13:27:11 tenner says because you're using rm_work May 18 13:27:57 (your choice of DISTRO may be inheriting it for you) May 18 13:28:04 ah May 18 13:28:37 http://pastebin.com/29eGiiKM May 18 13:29:20 damns! May 18 13:34:25 I also wonder why some libraries (gstreamer plugins for example) are never packaged into the final tar.gz May 18 13:35:12 what recipe? (and what tar.gz) May 18 13:35:41 it's a custum yocto build, rdk and it generates a tar.gz image with the rootfs May 18 13:36:22 the recipe is for gstreamer plugins May 18 13:36:28 presumably becuase the recipe is broken then :) May 18 13:37:03 probably... I just got it from the rdk guys, and no have to make it work May 18 13:37:45 i endorse bb for rooting around stuff May 18 13:37:50 $ bb contents myrecipe May 18 13:37:56 will list the packages built and whats in them May 18 13:38:03 its on kergoth's github May 18 13:38:08 should it have a FILES-{PN} = "*.so" or something to copy the generated libraries in the rootfs May 18 13:38:44 blotunga: you'd get warnings if the files were not packaged at all, so its likely that the files are packaged, just not in packages that are in the rootfs May 18 13:38:46 nice May 18 13:39:14 i should say that bb contents is actually just a dumb wrapper around oe-pkgdata-utils list-pkg-files —recipe [recipe] May 18 13:39:22 but thats too much to type :) May 18 13:39:24 rburton: yes, it has sysvinit, at least i think so. May 18 13:39:39 davis: pastebin it? May 18 13:40:13 rburton: it does generate some ipk packages, those if I remember are some sort of installers, so maybe they are there May 18 13:40:27 but I'd prefer them in my rootfs directly May 18 13:40:40 fwiw, the last word in the variable is sysvinit, but one sec i'll pastebin it May 18 13:40:50 davis: that sounds right then May 18 13:41:14 blotunga: in yocto everything goes into a packages and rootfs are constructed from packages May 18 13:41:25 ah May 18 13:41:49 then can it be that some packages aren't moved to the rootfs? May 18 13:41:55 yes May 18 13:42:03 that's always the case May 18 13:42:24 when you build glibc you build the following packages: glibc glibc-dev glibc-dbg May 18 13:42:30 $ bitbake -e | less May 18 13:42:39 https://gist.github.com/netskink/7700c036eec034281bab009a7f68bc33 May 18 13:42:40 but you don't want -dev and -dbg in all images, only development or debugging ones May 18 13:42:46 its in notes7 May 18 13:42:59 blotunga: http://www.yoctoproject.org/docs/2.1/yocto-project-qs/yocto-project-qs.html <— image a page down May 18 13:43:27 davis: looks good. so the updatercd stuff should work. share the recipe? May 18 13:45:10 wlll do May 18 13:45:12 one sec May 18 13:48:15 rburton: its in the same file, notes7 May 18 13:51:07 https://gist.github.com/netskink/7700c036eec034281bab009a7f68bc33#file-notes7 May 18 13:51:20 heh, until now, i did not know you could link to specific files May 18 13:59:06 rburton: do you think maybe i should give up on the update-rc.d package and do something similar to update-rc.d -r ${D} bootlogd start 07 S . May 18 13:59:35 that is in the do_install() function of sysviinit and my do_install() works. May 18 13:59:55 davis: i guess the first question is what package contains the udhcpd file? oe-pkgdata-utils list-pkg-files -r busybox will list the file contents. May 18 14:02:05 interesting, i've not used this sub command before, i've used provides. May 18 14:02:39 that result shows that /etc/init.dudhcpd and /etc/udhcpd.usb0.conf is provided by busybox per my append May 18 14:02:53 but not the actual executable. wrong choice on my part i guess. May 18 14:03:47 one sec, while i find something May 18 14:04:35 ok this reminds me. here is why i used busybox May 18 14:04:43 $ oe-pkgdata-util find-path /usr/sbin/udhcpd May 18 14:04:56 says unable to find any package producing path May 18 14:06:05 erm there's a init script for uhdcpd already May 18 14:06:35 in the busybox-udhcpd package May 18 14:07:08 hmm. i did not have it in the /etc/init.d directory of my system May 18 14:07:17 the exe is there but the script to start it is not May 18 14:07:41 shouldn't my above line show the package which made the exe? May 18 14:08:05 which udhcpd shows it in /usr/sbin as I searched May 18 14:08:15 busybox-udhcpd/etc/init.d/busybox-udhcpd for me May 18 14:10:35 rburton: oddly, find . -name busybox-udhcpd shows ./poky-jethro-14.0.1/meta/recipes-core/busybox/files/busybox-udhcpd May 18 14:10:48 yes thats the init script that goes into busybox-udhcpd May 18 14:10:55 i wonder why oe-pkgdata-util did not find it May 18 14:11:19 ahh, i have this in my output dir May 18 14:11:32 ./.build-yocto/tmp/sysroots/anuvaaz/pkgdata/runtime-reverse/busybox-udhcpd May 18 14:11:33 it gets packaged as /etc/init.d/busybox-udhcpd May 18 14:12:03 that package just contains the init script, the busybox package itself on install generates the symlink from /usr/sbin/udhcpd to busybox May 18 14:14:08 i wonder what that reverse is May 18 14:14:18 that sounds like erase or undo to me May 18 14:17:47 davis: i'd suggest that if you want to change the udhcpd init script then override the file in your layer directly, or just package a /etc/udhcpd.conf which the existing init script tries to open May 18 14:18:53 rburton: i agree. May 18 14:19:04 do youhave any idea what this reverse bit is? May 18 14:20:04 in the busybox package they're just symlinks from recipe names to the runtime recipe name May 18 14:20:38 no idea why :) May 18 14:21:08 ooh library renaming May 18 14:21:12 lrwxrwxrwx 1 ross ross 19 May 18 15:05 libglib-2.0-0 -> ../runtime/glib-2.0 May 18 14:21:50 for packages which get renames runtime-reverse links from the *generated* name (libglib-2.0-0) to the recipe-space name (glib-2.0) May 18 14:22:02 this is just an implementation detail in the pkgdata framework, ignore it May 18 14:22:14 ok May 18 14:22:52 so if i want to add an append recipe i was trying to append to a pkg which provided the layer, but it was not found May 18 14:24:28 i guess i need to remove this new layer/recipe to busybox, find the busybox-udhcpd and clone an append layer/recipe and mod it. I at least know what the /etc/udhcpd.usb0.conf file and /etc/init.d/udhcpd file should look like. May 18 14:27:47 davis: so there's several problems with your append, my point is that its not needed May 18 14:28:15 davis: i'd write a tiny append for busybox that ships your udhcpd.conf into busybox-udhcpd May 18 14:29:26 ok, i will clone an append layer/recipe for ./poky-jethro-14.0.1/meta/recipes-core/busybox/files/busybox-udhcpd May 18 14:29:41 and remove my append layer/recipe for busybox May 18 14:30:16 you'll need to append busybox, as you bbappend to *recipes* May 18 14:30:34 i'd keep the existing init script if you can May 18 14:30:42 hmm. May 18 14:31:27 one sec, let me check my notes May 18 14:32:23 https://gist.github.com/netskink/7700c036eec034281bab009a7f68bc33#file-notes3 May 18 14:32:36 i used that as a model for doing my busybox May 18 14:33:36 https://gist.github.com/netskink/7700c036eec034281bab009a7f68bc33#file-notes4 May 18 14:33:40 err notes 4 May 18 14:36:32 $ recipetool appendsrcfile -W meta-JFD-BUSYBOX busybox-udhcpd /tmp/newinitscript May 18 14:39:24 ERROR: Unable to find any recipe file matching busybox-udhcpd May 18 14:39:43 "you'll need to append busybox, as you bbappend to *recipes*" May 18 14:40:01 haven't i done that already? May 18 14:40:07 yes May 18 14:40:14 that's how I created this May 18 14:40:38 $ recipetool appendsrcfile -W meta-JFD-BUSYBOX busybox /tmp/newinitscript May 18 14:40:51 is how i created started this endeavor May 18 14:41:05 sorry if i am dense May 18 14:41:31 assuming that your init script doesn't do anything special compared to the existing init script, i'd just open your append, delete the init bits, install your conf file to /etc/udhcpd.conf and set FILES so that it appears in busybox-udhcpd May 18 14:42:55 ok i'm looking and tryig to figure out what you are saying May 18 14:46:13 https://gist.github.com/netskink/7700c036eec034281bab009a7f68bc33#file-notes7 May 18 14:46:24 thsi now shows, my environment May 18 14:46:54 it shows which files i have in the poky busybox tree, the files in my appends and where busybox-udhcpd May 18 14:47:00 exists. May 18 14:48:04 file ./poky-jethro-14.0.1/meta/recipes-core/busybox/files/busybox-udhcpd May 18 14:48:11 is an ascii script May 18 14:49:04 however on my target /usr/sbin/udhcpd is a link to /bin/busybox.nosuid May 18 14:49:33 yes, busybox is a single binary and lots of links May 18 14:49:53 hm doesn't it need to be the suid form though May 18 14:50:16 that file i showed at 10:48 is a startup script, but its not installed on my system for some reason. May 18 14:50:49 its in my busybox-udhcpd package May 18 14:51:52 i'm tryig to modify a vendor provided yocto setup, there deviations are frustrating. why they provided a binary but not config script is beyond me. May 18 14:52:04 how they removed something which is in place is a mystery May 18 14:52:42 ross@flashheart /data/poky-master/tmp/work/corei7-64-poky-linux/busybox/1.24.1-r0/packages-split May 18 14:52:42 $ find busybox-udhcpd/ -type f May 18 14:52:42 busybox-udhcpd/etc/init.d/busybox-udhcpd May 18 14:53:27 it appears to error out unless you add /etc/udhcpd.conf yourself though May 18 14:54:40 in my init script i specify to start the binary with my /etc/udhcpd.usb0.conf file May 18 14:55:13 really to be honest my target works if I manually /etc/init.d/udhcpd start|stop|status May 18 14:55:32 its just that I could not get the rc5.d or any rc?.d links to install. May 18 14:57:09 note that your append was breaking all the busybox init scripts May 18 14:57:34 was it? i did not notice it May 18 14:57:44 where would i notice that? May 18 14:58:05 i'll remove it from .conf file and rebuild. May 18 14:58:24 see if there is anything there which is not there when i do my build May 18 15:00:42 you assign INITSCRIPT_PACKAGES, overriding the value set in busybox.bb May 18 15:01:37 is there a way to append initscripts? May 18 15:01:42 yeah += May 18 15:02:20 i thought about trying to do _append, but that email i posted as one of the guides did not do it May 18 15:02:43 https://lists.yoctoproject.org/pipermail/yocto/2012-December/010853.html May 18 15:02:53 i'm rebuilding without my layer May 18 15:03:01 when done i'll see if anything is missing. May 18 15:03:12 if so, i'll try your suggestion about += May 18 15:03:31 thanks for taking time to help me May 18 15:03:51 rburton: thanks for taking time to help me. I appreciate your expertise and I know hyou are busy. May 18 15:04:59 I'm using yocto on Arch where my default compiler is gcc-6, some native things in the poky layer do not compile with it, for example elfutils-native. Is there a way to tell it to use an older version of GCC? I already tried to set CC and CXX and CPP but it seems not to help May 18 15:05:50 Jeena: native stuff uses teh BUILD_ VARS May 18 15:05:56 i.e. BUILD_CC, BUILD_CXX May 18 15:05:58 aah May 18 15:06:41 thanks I will try that! May 18 15:06:54 absolute worst case could do the builds in a chroot, container, or vm of a distro using an older toolchain :) May 18 15:07:17 I am doing it in a vm but thats no fun May 18 15:08:17 VM is slightly irritating just because it's not very transparent. i.e. i don't want to set up my dotfiles and dev env both in and out of the VM May 18 15:08:36 chroot or container can be a bit more transparent, make it so all your bitbake commands run in there against the content in $PWD May 18 15:44:15 are there any known issues with concurrent fetches from the same svn repository, e.g. from different recipes? May 18 15:45:24 I feel like I've heard someone mention that before May 18 15:47:42 might've been someone from our team, e.g. neverpan1c :P May 18 15:48:03 or even me, but i don't remember mentioning it May 18 15:51:11 * Ulfalizer found https://lists.yoctoproject.org/pipermail/yocto/2014-August/021383.html May 18 15:55:47 how would I find out what a value $baselib_dir is in bitbake conf? May 18 15:56:24 JaMa: when you do builds in tmpfs, do you put the entire build dir in tmpfs or just bits of it? May 18 15:56:55 CTtpollard: do you mean ${baselib}? there isn't a baselib_dir May 18 15:57:45 rburton: I may be looking at something old then, however 'systemd_unitdir = "${base_libdir}/systemd"' May 18 15:58:03 export base_libdir = "${base_prefix}/${baselib}" May 18 15:58:30 CTtpollard: bitbake -e | grep ^base_libdir is an easy way May 18 15:58:37 (my default, that's /lib) May 18 15:58:41 or pipe it into 'less' and search for it May 18 15:58:49 that'll show you the expanded value too May 18 15:59:24 if you're interested in a variable for a particular recipe, then do bitbake -e instead. May 18 15:59:26 base means in / not the prefix May 18 15:59:36 so base_libdir is /lib and libdir is /usr/lib May 18 16:10:09 seebs_: around? May 18 16:14:51 sort of May 18 16:24:27 rburton: you might want to read my 2nd reply in "Fix mesa_populate_packages() when dri is disabled" thread May 18 16:24:46 rburton: depends on where, for world builds whole tmp-glibc, in local builds only tmp-glibc/war May 18 16:24:49 work May 18 16:38:54 seebs: I've sent emails. I'm wondering if anything can ever link against a "mknod" symbol with glibc... May 18 16:42:06 I'm not sure. Hmm. May 18 16:42:38 Oh, hey. I know where this came from. It came from the problems with actual calls to mknod() for named pipes. May 18 16:43:10 But the thing is, since I actually did successfully run tests of pseudo working with a rootfs that was done through userspace nfs server running under pseudo... I know that on the machine I tested it on, it worked. May 18 16:43:25 seebs: I have an untested suspicion that if you load pseudo with LD_BIND_NOW or whatever the parameter is that binds all symbols, it might break May 18 16:43:30 I wonder if this is one of those things where it moved to something like __mknod that I need to check. May 18 16:43:45 seebs: see the quote from stat.h in my emal May 18 16:43:47 But I successfully found the symbol SOMEWHERE. May 18 16:44:30 Oh, huh. That looks a lot like there WAS a mknod in older systems, but newer ones may not actually always have it. May 18 16:44:46 In which case I'll have to move it into ports, ala the new-clone/old-clone thing. Wheeeee. May 18 16:45:03 seebs: I'm wondering if a change to the dynamic loader is actually at fault, perhaps https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=7d45c163d00c88d5875a112343c4ea3e61349e6b;hp=258ec8abc1fb26b800cb22c374c242ea98111679 May 18 16:45:05 I can probably fix it, shouldn't take super long, but I think all my current machines are older. May 18 16:46:08 seebs: when I say "at fault", I mean triggers the problem May 18 16:47:07 yeah May 18 16:47:17 FYI the bug associated with that commit May 18 16:47:18 https://sourceware.org/bugzilla/show_bug.cgi?id=19509 May 18 16:47:19 Bug 19509: was not found. May 18 16:47:25 dlsym, dlvsym do not report errors through dlerror when using RTLD_NEXT May 18 16:47:38 Anyway, I have theories about what's happening, I just need to find a newish machine to reproduce it. May 18 16:48:37 seebs look at that URL.. there are comments about 'fakeroot' having problems May 18 16:48:47 no idea if it's related.. May 18 16:49:22 oooh May 18 16:49:31 so it appears that RTLD_NEXT does not do quite what I thought it did. May 18 16:50:15 In that it may mean "specifically only the libraries directly linked against" rather than "everything past me". May 18 16:50:56 So it looks like the fix may require changing the libraries requested. SCIENCE MUST BE DONE. May 18 16:51:42 seebs: so I just confirmed that if I used a libdl with that change, I see the error. If I back out the single line in dl-error.c, things "work" May 18 16:51:50 okay. May 18 16:51:57 seebs: that patch is clearly in the older libc in fedora23 May 18 16:52:37 seebs: the easy reproducer which works every time is "bitbake core-image-minimal" on a machine with that change in ld.so May 18 16:52:43 I'll experiment and figure it out. I *think* we probably just need an additional -l or something, but I'm not sure where mknod is coming from on those systems. Or whether it's even being compiled. May 18 16:52:44 it'll fail in do_rootfs May 18 16:52:50 Oh, I should be able to break it much earlier than that. :) May 18 16:53:01 seebs: just sharing what I have :) May 18 16:53:09 Thanks. May 18 16:55:03 seebs: if you want it to break on your local build I do have an easy way btw May 18 16:55:24 I think my problem is mostly just that my easily-available hosts are All Too Old. May 18 16:55:30 seebs: just add http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=ca635c3380ddd12f30461a175ea5445a5fae9733 May 18 16:55:45 seebs: that version of uninative has the change in it and breaks everything May 18 16:55:57 seebs: that will break even older hosts ;-) May 18 16:56:09 heh May 18 16:56:15 actually that's not a bad idea May 18 16:56:47 seebs: if you rebuild pseudo you just need to ensure it uses the uninative interpreter rather than system one May 18 17:14:34 seebs: let me know if I can help... May 18 17:15:00 Mostly I have too many things happening at once. May 18 17:15:48 seebs: a problem I know all too well. Trouble is our autobuilder and people's builds are breaking due to this so one way or another I'm going to have to come up with something :/ May 18 17:17:55 hmm May 18 17:18:04 one sec May 18 17:18:50 Okay, so, if you just take out the pseudo_diag(), does it *run* okay? May 18 17:19:15 Because if it does that should be fine. If it coredumps trying to execute null function pointers, then it's trickier. May 18 17:19:27 But I'm pretty sure the change is only affecting whether or not we print the message. May 18 17:27:46 seebs: that does indeed seem to let it work May 18 17:27:50 okay May 18 17:28:05 so the failure is the diagnostic message being interpreted as a failure, not an actual abort or whatever. weeeeeird. May 18 17:28:29 seebs: there are some cases we capture stdout and do processing on it so I can imagine things breaking May 18 17:28:36 yeah May 18 17:28:50 postgresql has at least some compiler tests that treat stderr as a failure and ignore $? May 18 17:29:05 which turns out to be because of hosts where the compiler does not indicate failure to compile through an exit status May 18 17:29:52 seebs: sad that people have to work around that rather that it getting fixed May 18 17:30:34 seebs: so should I push something disabling the message until such times as you can fix this properly? May 18 17:30:57 Sure. There's no possible way it could bite me to disable the diagnostic. :P May 18 17:31:14 seebs: :D May 18 17:31:38 What mystifies me is what I was thinking when I wrote this. The error message test is inexplicably contingent on a #ifdef that it shouldn't be contingent on, and also I don't check for failure to get the symbol unless dlerror() reports something. May 18 18:08:02 seebs: I decided there must be some good reason you did that which I was clearly missing :) May 18 18:08:12 which, the #else thing? May 18 18:08:17 seebs: yes May 18 18:08:34 I am pretty sure the reason is that **SFX: TRAIN ROARS PAST** and that is why it should be in the #else clause. May 18 18:09:46 seebs: we've all done it... May 18 18:11:10 Hi. Quiet new to yocto auto builder. Till now I'm building with google repo tool. Can I use repo tool with yocto auto builder May 18 18:11:11 ? May 18 18:18:20 I have to admit, the "SFX: TRAIN ROARS PAST" explanation has rapidly become one of my favorite idioms for explaining the lovely things I have left for myself in code. May 18 18:35:22 seebs: I've sent a patch to OE-Core and tried to document all the fun May 18 18:42:27 rburton: you still here? May 18 19:14:24 Huh. May 18 19:14:54 Okay, looking at the mknod stuff, it seems to me that the weird part is that we don't appear to have a parallel problem with stat, which in theory has the same trait, that everything's using __xstat or whatever. May 18 19:17:55 seebs: I wondered about that May 18 19:21:19 ... that's interesting. mknod isn't the only thing not being found, but apparently I never try to find fstat(), and I am not sure why. Ugh. Interesting. May 18 19:22:24 ah-hah! May 18 19:22:31 because they have "real_func=pseudo_stat" for some reason. May 18 19:23:02 Ahh, I get it. I fixed this already for those. I never noticed the need for mknod because it wasn't getting diagnosed because of the dlerror thing. May 18 19:23:13 So the actual fix is to use an existing mechanism for fixing exactly this problem, which I already thought of! May 18 19:23:28 seebs: cool :) May 18 19:29:00 huh May 18 19:29:02 that's odd May 18 19:29:25 why do i have a wrapper for "syncfs"? May 18 19:29:37 ... oh because the pseudo_fsync stuff needs to be able to bypass it. But apparently it's not present everywhere. May 18 19:30:43 This is odd, there's a syncfs() which is in _GNU_SOURCE or something in some man pages, but I can't find it anywhere now. May 18 19:31:18 huh. my ubuntu system has it, my centos doesn't. maybe it's newish. May 18 19:33:49 It was added in April of 2011, which sort of worries me because why does my build machine apparently lack a syscall from five years ago. May 18 19:34:18 ... because it's a 2.6 kernel. May 18 19:34:22 Okay, I'm gonna have to rethink this. May 18 19:34:37 your build machine has a 2.6 kernel? how old is that? May 18 19:35:27 Centos 6. May 18 19:35:34 But it was originally released, it appears, in 2010. May 18 19:35:46 So I need to add a test for whether or not syncfs exists, and move syncfs to be contingent on that. May 18 19:38:44 "writing preload libraries is easy" - said someone, wrongly :) May 18 19:39:46 oh boy building krogoth with distros using gcc6 is going to ensue a slew of package upgrades into release branch May 18 19:41:14 I was a happy camper until archlinux pushed the gcc6 update May 18 19:41:38 I am sure latest fedora will have same problem May 18 19:42:13 ouch May 18 19:42:34 use a chroot/container and call it a day? :) May 18 19:46:41 yeah I do use debian8 container on arch but its sort of sad May 18 19:47:51 some probably can be fixed with lowering the Werror bar May 18 19:48:32 however that may not be best solution since no host would have tested that combination May 18 19:48:45 so our native sysroot will be sort of unique May 18 19:56:28 for what it's worth, i believe i now have the proper fix for that stuff. whee. May 18 20:05:28 seebs: how is this going to work with our compile once and run against uninative situation? May 18 20:06:08 I am assuming pseudo will be compiled against uninative. So if that has syncfs, we'll have a syncfs wrapper, and at runtime we'll be running with uninative's glibc which has syncfs. May 18 20:07:19 seebs: even if the kernel doesn't? May 18 20:07:31 seebs: I guess that makes it glibcs problem? May 18 20:07:34 Yeah, pretty much. May 18 20:07:41 fair enough May 18 20:08:01 I don't know how our uninative will handle that. If it's been configured with a low enough minimal kernel version it'll probably have an alternative syncfs implementation that just does ENOSYS or something? May 18 20:08:35 seebs: one tricky thing to note is that things build against the host system, then run against uninative May 18 20:08:49 huh May 18 20:08:50 seebs: we assume uninative is always equal to or more recent May 18 20:09:01 Hmm. That should be okay. May 18 20:09:02 since glibc is backwards compatible May 18 20:09:15 The risk is that it's possible that we'll have stuff calling syncfs and not having it intercepted. May 18 20:09:19 But I don't actually CARE. May 18 20:09:39 seebs: I'm not overly worried, just wondering how bad it can break :) May 18 20:09:55 sync calls aren't a big deal, some other syscalls might be May 18 20:11:48 * RP switches terminals to see a sea of red ERRORs. I wonder what python3 did now :/ May 18 20:13:06 ah, its kergoth's patches :) Nice when its not me to blame for a change! May 18 20:13:15 hooray! :) May 18 20:13:42 kergoth: your patches to codeparser and friends change the checksums but don't invalidate the caches May 18 20:13:43 i swear every other patch i've sent recently has exploded, even though it worked fine when i tested it locally. one of those weeks May 18 20:14:00 ah May 18 20:14:21 kergoth: I'm guessing its that anyway. Blowing away caches seems to have made it happier May 18 20:17:14 .RP: you're right about the comment / code ratio in your patch. That's the most I've seen in a long time. :) May 18 22:03:07 khem: there was a hunk of a patch went missing in the glibc upgrade which has broken the uninative tarball :( May 18 22:04:03 kergoth: do you want me to add the relevant cache bumps? May 18 22:04:39 It's your call, I don't mind doing it, but it'd be more back and forth May 18 22:04:43 afk May 18 22:26:13 kergoth: I've put some bumps into -next May 18 22:27:51 RP: hmm which one ? May 18 22:28:26 khem: I've just merged a fix (I cc'd you on the patch) May 18 22:28:48 khem: I need to get this sorted so we can rebuild uninative and fix other issues blocking other testing etc. :/ May 18 22:29:06 * RP feels like he's stuck in a circular logic problem May 18 22:29:44 RP: yes I wonder how it got dropped seems my oversight May 18 22:32:38 RP: now I am using my own fork of glibc on github I updated it there too May 18 22:32:47 khem: I have a suspicion that patch wasn't well formatted and git did something odd to it May 18 22:33:05 using git fork of glibc helps a lot on merging May 18 22:33:18 so hopefully wont have such errors in future May 18 22:33:22 I did same for gcc May 18 22:34:04 RP: probably, I am quite happy with the new workflow I have for patches May 18 22:34:22 which is using git forks and not rlying on quilt workflow May 18 22:34:42 also helps in forward porting patches inbetween releases May 18 22:34:48 so we dont wait 6 months May 18 22:34:52 khem: using the git trees on the other hand is causing problems for the builds :( May 18 22:35:40 khem: the locking and time delays on the git fetcher updates are proving to be quite a bottleneck for build parallelism. Need to look at what exactly is going on May 18 22:50:30 RP: should be first time thing only ? May 18 22:54:57 RP: btw. I have pushed a fix for gpl2/elfutils in kraj/pu and also sent patches for qt4 for gcc6 May 18 22:55:33 RP: so with this all we would ne left with is kernel 4.1 which I have verified that latest top of 4.1 branch from upstream works with gcc6 May 18 22:56:09 so I will leave that to zeddii to upgrade linux-yocto-4.1 to latest tip and propose May 18 22:57:50 khem: sounds great, thanks for the work on that. Will try and queue gcc6 into a build once I have all the patches May 18 23:05:07 and systemd issue is also fixed May 18 23:05:11 in same tree May 18 23:05:17 meta-qt4 you need to grab from ml May 18 23:05:25 http://www.theregister.co.uk/2016/05/05/router_hackers_reach_for_the_fork_lede_splits_from_openwrt/ May 18 23:05:29 interesting development May 18 23:06:49 that reminds us how to bring more devs to OE May 19 00:01:55 khem: yeah I saw that too... but what do you mean exactly? **** ENDING LOGGING AT Thu May 19 02:59:59 2016