**** BEGIN LOGGING AT Fri Jan 10 02:59:58 2020 Jan 10 03:07:15 I wonder if pseudo rewrites syscalls ? archlinux enabled seccomp in their file utility package and now file fails with SIGSYS however running file -b on same file on normal cmdline works fine, so I am guessing its happening when file utility is being intercepted by pseudo Jan 10 03:08:43 error seen is here http://ix.io/26Zw Jan 10 03:11:01 ah yes I can confirm that http://ix.io/26Zx fails in exact same way Jan 10 03:16:23 here is strace output http://ix.io/26Zy Jan 10 08:16:13 hey folks is there any way to track what patches yocto applies in which order etc? :/ Jan 10 08:22:01 i'm not shure but i think it is listed in the do patch log Jan 10 08:37:03 and where can i find that? Jan 10 08:41:31 $WORKDIR/temp/log.do_patch Jan 10 09:00:35 New news from stackoverflow: Bitbake list of targets Jan 10 10:15:28 hum, what provides the fullblown ip command? Jan 10 10:41:47 hmm where do I see output of bbnote/bb.not? Jan 10 10:42:30 Yatekii: probably in the log of the task in question Jan 10 10:45:53 LetoThe2nd: hmm where do I find that? Jan 10 10:47:09 Yatekii: tmp/work/yourrecipe/version/temp/log_doXXX , or something alike Jan 10 11:11:50 a bit ot: can busybox mount mount overlay ? Jan 10 11:12:03 from the command help seems not Jan 10 11:24:47 If in recipe I have to tell where shared libraries of another package are with "export LIBPATH=/path/to/usr/lib", what should I use in the path? Jan 10 11:27:27 stuom1: ${STAGING_DIR_TARGET}${libdir} ? Jan 10 11:45:09 that is same as STAGING_LIBDIR? Jan 10 11:46:24 it still claims nothing is found, is it possible to see inside those directories? Jan 10 11:47:25 because it doesnt exist (after bitbake?) Jan 10 11:48:51 stuom1: and the lib is in DEPENDS? Jan 10 11:49:06 yes Jan 10 12:10:02 pkg1 and pkg2 have the same DEPENDS, the .so is found in (...)/pkg1/recipe-sysroot/usr/lib/ but not in (...)/pkg2/recipe-sysroot/usr/lib/, why is that? Jan 10 12:10:38 they both need it so how can I make sure they both have it in their sysroot Jan 10 12:45:48 stuom1: could it be that you DEPENDS on the wrong package? but the lib is gotten from another DEPENDS that is specific to pkg1 and not pkg2? Jan 10 12:52:35 they DEPENDS on same library. With find command in my build environment I can find it in the sysroot of pkg1 but not pkg2 Jan 10 13:03:44 stuom1: what I meant is that, are you sure this package provides the library? and it's not another package providing that library which would be in the DEPENDS of pkg1 and not pkg2? Jan 10 13:04:21 ok, yes im sure Jan 10 13:05:37 bitbake pkg2 -e | grep ^DEPENDS. Is your lib depends in there? Might be that DEPENDS is overriden somewhere else Jan 10 13:07:29 it is there Jan 10 13:08:07 but it is in DEPENDS_${PN} Jan 10 13:08:25 with pkg1 it is just in DEPENDS Jan 10 13:09:17 maybe that is the mistake Jan 10 13:09:33 that is Jan 10 13:09:51 DEPENDS is always just DEPENDS. RDEPENDS needs the _${PN} suffix Jan 10 13:10:12 thanks guys, I'll test! Jan 10 13:13:43 stuom1: more specifically. DEPENDS applies only to the whole recipe. Even if you have only one .bb, you can have multiple implicit "recipes" (whatever is in BBCLASSEXTEND for example), it usually is something like class-target, class-native, class-nativesdk, etc. Most of the time, you don't care that much about those "implicit recipes". RDEPENDS applies to packages which provided by a recipe so you need to Jan 10 13:13:49 specify to which package the runtime dependency applies. Jan 10 13:14:23 I don't know if that's not confusing though... Fridays... Jan 10 13:16:21 just that as "if you write DEPENDS_${PN} and your name is neither RP, kergoth nor khem, then you're doing it wrong." :) Jan 10 13:16:26 *just read Jan 10 13:19:17 LetoThe2nd: I've been telling the world about your Twitch stream, you may be famous soon Jan 10 13:20:14 tgamblin: hehe Jan 10 13:21:13 tgamblin: thanks. i'm just having a rough time getting started this year. i'm fighting a cold, and twitch gave me headaches lately Jan 10 13:21:37 so no new session at least until jan 21st Jan 10 13:26:59 khem, any idea why vgdb from valgrind segfaults on target in glibc? Jan 10 13:28:31 let me produce some diagnostics Jan 10 13:50:44 root@qemux86:~# vgdb Jan 10 13:50:45 Using vgdb standalone implies to give -D or -l or a COMMAND Jan 10 13:50:45 args error. Try `vgdb --help` for more information Jan 10 13:50:45 Segmentation fault Jan 10 13:50:59 [ 16.730022] traps: vgdb[755] general protection fault ip:410696f4 sp:bf9470a4 error:0 in libc-2.30.so[41050000+14c000] Jan 10 13:51:27 Program received signal SIGSEGV, Segmentation fault. Jan 10 13:51:27 0x410696f4 in __run_exit_handlers (status=1, listp=0x412103bc <__exit_funcs>, run_list_atexit=true, run_dtors=true) at exit.c:114 Jan 10 13:51:28 114 exit.c: No such file or directory. Jan 10 13:51:28 (gdb) bt Jan 10 13:51:28 #0 0x410696f4 in __run_exit_handlers (status=1, listp=0x412103bc <__exit_funcs>, run_list_atexit=true, run_dtors=true) at exit.c:114 Jan 10 13:51:30 #1 0x41069961 in __GI_exit (status=1) at exit.c:139 Jan 10 13:51:32 #2 0x08049c43 in parse_options (commands=0xbffffc10, p_last_command=, p_port=, p_check_trials=, p_arg_pid=, Jan 10 13:51:35 p_show_list=, p_show_shared_mem=, argv=0xbffffd54, argc=1) at ../../../../../../../workspace/sources/valgrind/coregrind/vgdb.c:1477 Jan 10 13:51:38 #3 main (argc=1, argv=0xbffffd54) at ../../../../../../../workspace/sources/valgrind/coregrind/vgdb.c:1501 Jan 10 14:07:53 We've someone hit by a build which fails only for one machine: ERROR: Fakeroot process (14457) exited unexpectedly (0), shutting down... Jan 10 14:07:56 Any idea? Jan 10 14:07:58 (thud) Jan 10 14:22:58 Hi, I'm trying to change the debug console for u-boot on my custom board based on sabresd. I have changed the settings in myboard.c and myboard.h. I have read that you are also supposed to change the IOMUX pads for the corresponding GPIO but I'm not sure how. Should I just replace the KEY_ROW and KEY_COL with the GPIO for the new uart? thanks in Jan 10 14:22:58 advance Jan 10 14:24:04 ifan: ask on #u-boot :) Jan 10 14:24:39 ifan: see https://elixir.bootlin.com/u-boot/latest/source/board/freescale/imx8qxp_mek/imx8qxp_mek.c Jan 10 14:24:46 specifically setup_iomux_uart Jan 10 14:24:53 Sorry and thank you! Jan 10 14:25:42 ifan: no problem, it's just that you'll usually have better and quicker answers from maintainers/contributors of the project in the project's IRC channel :) Jan 10 14:28:16 I think I have the setup in myboard.c and myboard.h correctly. But where I'm getting confused is in mx6q_pins.h Jan 10 14:29:11 Do I need to replace the old KEYs with the GPIO for the new uart? Jan 10 14:30:13 I do not understand your question :) Please reformulate and/or send source code if you can Jan 10 14:30:43 that does not make sense, let me rephrase. UART1 was configured by GPIO4. There is a line with KEY_ROW1__GPIO4_IO09 and KEY_COL2__GPIO4_IO10. I assume I need to make some changes here since UART2 is controlled by GPIO5 and GPIO6 Jan 10 14:31:54 I can get the source hold on Jan 10 14:39:11 https://pastebin.com/cYYevNVH Jan 10 14:46:28 Hey there, I built an image with the xfce feature enabled, but can't seem to get a graphical output/desktop environment. Any advice? Jan 10 14:49:06 nhartman: you probably didn't actually build the xfce image Jan 10 14:49:40 core-image-minimal-xfce is the example image that should boot into xfce directly Jan 10 14:50:00 rburton: Sorry, I should have mentioned I'm using Wind River linux, with a xfce template Jan 10 14:50:11 oh right, no idea ask wind river :) Jan 10 14:50:25 And it does appear to be installed. Running startxfce4 says it's already running Jan 10 14:50:56 on a different vt maybe? Jan 10 14:51:42 I've checked through the various tty's if that's what you mean Jan 10 14:51:46 right Jan 10 14:52:01 On bootup it says starting Xserver without display manager. That seems relevant Jan 10 14:53:58 that just means its not doing a login prompt, just going straight to the environment Jan 10 14:54:58 Ah, rip. I can kill the Xsession process and relaunch it Jan 10 14:55:08 But it just sits there, and no desktop launches Jan 10 14:57:35 i have DEPENDS = "pkg" and I get error nothing PROVIDES pkg-native, why is that? Jan 10 14:58:58 because you're doing that in a recipe that does bbclassextend so all the depends turn into native? Jan 10 15:00:17 so I have to create a -native version for all the DEPENDS and the DEPENDS of the DEPENDS etc etc? Jan 10 15:00:33 right. Jan 10 15:00:45 a target libfoo is no good to build a native bar, if bar depends on foo Jan 10 15:00:52 BBCLASSEXTEND is your friend Jan 10 15:01:00 Ok. That made me cry a little Jan 10 15:01:51 i'm guessing what your problem is, of course Jan 10 15:01:52 maybe wrong Jan 10 15:03:02 yes there is BBCLASSEXTEND = "native nativesdk" and I added couple DEPENDS to that recipe Jan 10 15:03:12 and you're building the native form of that recipe? Jan 10 15:03:37 yes it was needed by some other recipe Jan 10 15:03:49 but obviously if package foo depends on bar, and you want to build foo-native, then you need bar-native to exist Jan 10 15:07:07 Generally, in what case I need to make a -native package? Jan 10 15:07:58 I dont understand what it is, some recipes have them and some not, and even without they seem to build Jan 10 15:08:44 Or I mean, in what case I need to DEPENDS on native version and not the non-native? Jan 10 15:08:55 because it wants to *run* the code in that dependency Jan 10 15:09:08 eg a target package might depend on both glib and glib-native Jan 10 15:09:24 because it wants to link against libglib (thus, glib) but also wants to run the glib tools (thus, glib-native) Jan 10 15:09:51 so if package really DEPENDS on native package, it should not build with the non-native version? Jan 10 15:10:31 its absolutely fine to depend on one or the other or both Jan 10 15:10:39 it entirely depends on what it needs the dependencies for Jan 10 15:11:03 I started now questioning the native package in DEPENDS, instead of making new native packages of all the dependencies heh Jan 10 15:17:19 rburton: Is there a WR Linux channel by chance? Jan 10 15:17:58 dunno, sorry. there are WR people here if they're awake Jan 10 15:18:00 vmeson: ^^^ Jan 10 15:18:55 there used to be wropenlabs, but no one is there :D Jan 10 15:22:13 stuom1, are you aware, that native packages are built for the host machine, not the target one? Jan 10 15:23:01 MarcMann yeah I guessed so Jan 10 15:23:29 no offence, I was just not sure Jan 10 15:23:59 it wasnt offensive :D Jan 10 15:24:46 I wish there was a easy way to add BBCLASSEXTEND = "native" to the whole dependency chain, do i really have to manually hunt all recipies and go add it? Jan 10 15:25:15 Looking at the boot process I'm also getting a 'GPIO interrupt error, pins misconfigured" error. Could that be part of the issue perhaps? Jan 10 15:26:15 stuom1: you can, if you set it in a global config file, as it'll flow down into the recipes that don't define it. that said, it'll have an effect on parse times, as bitbake is internally generating all the variant recipes, their metadata, finalizing that metadata, and including it in the cache and considering it when generating the runqueue Jan 10 15:28:08 LetoThe2nd: If you write DEPENDS_${PN} you're not RP ;-) Jan 10 15:28:44 now im down to "Nothing RPROVIDES 'cpp-native'" and i dont even have a bb file for cpp. Maybe its time to go home and try something new on Monday :D Jan 10 15:36:36 stuom1: that would normally be provided by the host? Jan 10 16:18:38 ifan: AFAICT no, this is the declaration of a pad. This just means that KEY_ROW1__GPIO4_IO09 represents this set of reg with this set of bits. Jan 10 16:20:35 ifan: basically, KEY_ROW1 pad can be muxed into GPIO4_IO09 Jan 10 16:21:40 ifan: and you're using those pad declarations in imx_iomux_v3_setup_pad Jan 10 16:23:05 see MX6_PAD_DECL as a #define if you'd like. All muxing possibiilties should be defined by #define. You don't want to change the meaning of one #define, you want to use the correct one. Jan 10 16:48:49 LetoThe2nd: I don't know if someone answered already, but most likely iproute2 is the one providing the full-featured `ip` command Jan 10 16:49:13 http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/iproute2/iproute2.inc?h=master Jan 10 17:09:15 vmeson: I was trying to silence the getty not stating on hvc0 warning on qemuarm, I see that we do not create hvc0 when nographic is used. I wonder why Jan 10 17:09:46 if I use 'runqemu nographic serial' it is created Jan 10 17:24:23 RP: If autobuilders are running cold over weekend then throw glibc 2.31 at them I have updated the patch here https://git.yoctoproject.org/clean/cgit.cgi/poky-contrib/log/?h=kraj/glibc-2.31 Jan 10 17:25:01 khem: ok. I'm struggling to get clean builds and patches are building up but I'll keep it int mind Jan 10 17:25:19 rburton: -next is mostly heading green, any concerns on anything there? Jan 10 17:25:20 RP: if thats not enough then I also have gcc10 patches Jan 10 17:25:36 khem: er, great :) Jan 10 17:26:01 JPEW: obvious idea: package trydiffoscope and optionally use it in the selftest to submit differing files Jan 10 17:26:52 rburton: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jpew/reproducible :) Jan 10 17:27:01 Need to clean it up Jan 10 17:27:10 hah Jan 10 17:27:32 Also, it was generating *way* too much output (GB's) until we got the reproduciblility under control Jan 10 17:27:37 i was just going to use trydiffoscope, much easier to build (tiny bit of py) Jan 10 17:27:45 and then the output is just the URLs on the server Jan 10 17:27:49 Ah Jan 10 17:27:52 pushed here https://git.yoctoproject.org/clean/cgit.cgi/poky-contrib/log/?h=kraj/gcc10 for fun loving people Jan 10 17:27:53 caveat being that it uploads to the internet Jan 10 17:28:13 Ya, my branch would include the results in the resultool report for easy viewing Jan 10 17:28:28 just fixed the perl bug btw Jan 10 17:28:31 Cool Jan 10 17:28:58 This is the tool I wrote that is most useful: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible&id=268cfbe290d6c5527e96e344268e988d9ac874e5 Jan 10 17:30:09 rburton: As, sorry I was mistaken, that branch doesn't include the diffoscope output in the result report, it just adds repro-diffoscope Jan 10 17:30:37 neat Jan 10 17:31:28 rburton: Had to patch diffoscope though; it choked on our debug splitting: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible&id=f7e39c5eda3c161f0ac44c01aaf5e433334d183d Jan 10 17:31:35 rburton: do you prefer collecting patches from ml or pw or from contrib trees Jan 10 17:32:15 khem: for a big series, git repo somewhere Jan 10 17:32:38 khem: small series, C-u C-a C-c is fast to type and gets the patch on the clipboard :) Jan 10 17:32:53 rburton: I have created scripts which push assorted ones to kraj/pu on poky contrib now a days Jan 10 17:33:13 cool Jan 10 17:34:23 do we test qemumips regularly, I have sent a fix to help it boot into weston with core-image-weston Jan 10 17:35:00 khem: we do, maybe not with weston Jan 10 17:35:33 OK now you can :). both mips/mips64 were not booting with systemd Jan 10 17:36:02 khem: we probably need to improve the test matrix. My worry is I can barely cope with the failures we get now Jan 10 17:36:16 khem: I end up having to deal with far too many of them already :( Jan 10 17:37:11 RP: agreed, Jan 10 17:39:12 rburton: I find it easy to deal with git remotes, ml is my least preferred method Jan 10 17:39:30 khem: I find ml easiest to review :/ Jan 10 17:39:49 also have .gitconfig settings to fetch github pull requests as branches which I can then cherry-pick from Jan 10 17:40:51 * RP just saves an mbox of all the patches to apply to "/tmp/1" and them "git am -s /tmp/1" Jan 10 17:41:24 RP: review perhaps ok, but lifting patches is suboptimal although git format-patch, git send-email has made it better that patches are not mutilated but it needs a specific setup for ml patches Jan 10 17:51:44 git cherry-pick doesnt go wrong :) Jan 10 17:54:44 khem: but its a lot slower than my git am ;-) Jan 10 17:55:36 rburton: just seen the perl patch. I'll not comment :) Jan 10 17:56:46 rburton: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=1ac917d15ca35710d516fe41468d6bb73727f3de - meson/glib potential fix Jan 10 18:04:40 RP: have you seen this on AB http://errors.yoctoproject.org/Errors/Details/306044/ Jan 10 18:05:07 I see it with gcc8 gcc9 and gcc-trunk occasionally on arm/aarch64 Jan 10 18:05:50 its a build race, I have been seeing it for atleast a year now Jan 10 18:05:57 khem: no. I do remember that error from a long time ago Jan 10 18:06:30 rburton: confirmed to fix FWIW Jan 10 18:08:18 https://patchwork.ozlabs.org/patch/785236/ perhaps is reason Jan 10 19:08:04 RP: *yet another* race Jan 10 19:08:20 RP: nice fix, thanks :) Jan 10 19:42:49 in the logs I do not see xgcc being built but xg++ is Jan 10 19:44:14 qschulz: ah great, thanks. nah, nobody had answered so far. Jan 10 19:46:42 Hi, how does /etc/default/postinst get created? Jan 10 19:47:07 with systemd the process never finishes on the first boot and I'd like to log to a serial console to figure out where it gets stuck. Jan 10 20:48:19 I was unable to get stdout working for some reason, but I was able to write to flash. The last entry is "Enabling service", which is less than helpful. Jan 10 20:48:37 It might not be the last entry -- I had to reboot the board and the write may not have been flushed yet. Jan 10 20:49:13 I've seen references to systemd + opkg doing stuff twice so I'm building with rpm this time to see if it makes any sort of difference. Jan 10 20:52:28 This is now a monday morning problem. Have a great weekend, everyone! Jan 10 21:14:48 fullstop: serial console should give info about what systemd is doing Jan 10 22:54:49 can I boot typical qemux86-64 core-image-minimal.hddimg on typical intel x86_64 laptop? Jan 10 22:55:48 s/typical//g Jan 10 23:14:11 might want the genericx86 or genericx86-64 machines for that. uncertain Jan 10 23:30:13 ok I'll go with that, thanks **** ENDING LOGGING AT Sat Jan 11 03:00:53 2020