**** BEGIN LOGGING AT Sun Apr 15 03:00:01 2018 Apr 15 04:31:27 morning, how do I ignore the bitbake LICENSE of a package? I'm getting a license error and I actually just wanted to compile a tcpreplay in a project Apr 15 10:49:56 hey everyone Apr 15 10:50:05 i am in trouble Apr 15 10:50:14 with yocto Apr 15 10:52:25 Guest97013: general advice on freenode etiquette: you don't need to "ask to ask" Apr 15 10:52:44 Guest97013: it's absolutely ok to just come in to a channel and ask your actual question without so much as a hello Apr 15 10:52:51 Guest97013: and you're much more likely to get help that way Apr 15 10:53:59 this my error Apr 15 10:54:11 error: the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead. Apr 15 10:54:49 i am using bitbake Apr 15 10:55:05 to build Apr 15 12:21:22 Hello, I relative new to Yocto. I am trying to make a receipe for nzbget. nzbget requires libxml2. I have added libxml2, however running 'bitbake core-image-minimal' results info an error: "./nzbget-19.1/configure: line 6508: ` PKG_CHECK_MODULES(libxml2, libxml-2.0,'" Anyone an idea? Apr 15 14:42:10 this my error: the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead i am using bitbake to build Apr 15 15:34:20 hi Apr 15 16:08:27 i have question Apr 15 16:13:22 Guest69302: Just ask Apr 15 16:16:49 this my error: the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead i am using bitbake to build Apr 15 16:17:38 i am using bitbake Apr 15 16:17:39 That's one line from what will be a longer error message. Please post the full message here or to a pastebin Apr 15 16:17:54 i will Apr 15 16:18:13 ERROR: gnu-config-native-20150728+gitAUTOINC+b576fa87c1-r0 do_unpack: Fetcher failure: Fetch command export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/0/bus,guid=c0f9e8a179cb4aaf10023ab45ad1ee6f"; export SSH_AGENT_PID="911"; export SSH_AUTH_SOCK="/run/user/0/keyring/ssh"; export PATH="/home/the/workspace_agl/poky/scripts/native-intercept:/home/the/workspace_agl/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/the/workspace_agl/build/tmp/sysroot Apr 15 16:18:13 s/x86_64-linux/usr/bin/tar-native:/home/the/workspace_agl/poky/scripts:/home/the/workspace_agl/build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux:/home/the/workspace_agl/build/tmp/sysroots/x86_64-linux/usr/bin:/home/the/workspace_agl/build/tmp/sysroots/x86_64-linux/usr/sbin:/home/the/workspace_agl/build/tmp/sysroots/x86_64-linux/usr/bin:/home/the/workspace_agl/build/tmp/sysroots/x86_64-linux/sbin:/home/the/workspace_agl/build/tmp/sysroots/x86_64-linux/ Apr 15 16:18:13 bin:/home/the/workspace_agl/poky/scripts:/home/the/workspace_agl/poky/bitbake/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"; export HOME="/home/the"; git -c core.fsyncobjectfiles=0 branch --set-upstream master origin/master failed with exit code 128, output: Apr 15 16:18:15 Sounds like something is using obsolete arguments to git though Apr 15 16:18:19 fatal: the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead. Apr 15 16:18:22 ERROR: gnu-config-native-20150728+gitAUTOINC+b576fa87c1-r0 do_unpack: Function failed: base_do_unpack Apr 15 16:18:24 ERROR: Logfile of failure stored in: /home/the/workspace_agl/build/tmp/work/x86_64-linux/gnu-config-native/20150728+gitAUTOINC+b576fa87c1-r0/temp/log.do_unpack.13114 Apr 15 16:18:27 ERROR: Task (virtual:native:/home/the/workspace_agl/poky/meta/recipes-devtools/gnu-config/gnu-config_git.bb:do_unpack) failed with exit code '1' Apr 15 16:19:07 what's your host distro and version? what branch of yocto project are you using? Apr 15 16:20:01 i am following the steps in http://docs.automotivelinux.org/docs/getting_started/en/dev/reference/machines/qemu.html Apr 15 16:20:34 to build agl-demo-platform-qemux86-64.vmdk.xz Apr 15 16:21:03 but whene i run bitbake agl-demo-platform Apr 15 16:21:12 i get an error Apr 15 16:21:29 Ok, but what distro & version are you building on? Apr 15 16:21:59 linux Apr 15 16:22:06 kali linux Apr 15 16:22:25 Are you new to OpenEmbedded/Yocto Project? Apr 15 16:22:47 yes Apr 15 16:22:56 Getting the build to work on kali linux may not be simple, if you're new to the project I'd recommend switching to something tested like Ubuntu Apr 15 16:23:39 but kali is like debian Apr 15 16:23:52 I'd also recommend starting with the Yocto Project quick start https://www.yoctoproject.org/docs/2.4.2/yocto-project-qs/yocto-project-qs.html Apr 15 16:24:04 Then once you have poky building correctly move on to AGL Apr 15 16:24:37 The key work there is 'like'. There will be differences. Start with something tested and you'll have a much easier time Apr 15 16:25:02 what about raspbian Apr 15 16:25:24 RPi won't have enough free RAM to run a build anyway Apr 15 16:25:24 in fact i have to run agl in raspberry pi 3 Apr 15 16:25:47 What machine are you trying to run the build on? Apr 15 16:26:13 linux Apr 15 16:26:44 Are you trying to run bitbake on your raspberrypi? Apr 15 16:27:12 no i want to run agl in rpi Apr 15 16:27:31 so i want to build agl-demo-platform-qemux86-64.vmdk.xz Apr 15 16:27:34 first Apr 15 16:27:47 and boot it in rpi Apr 15 16:28:02 Ok. I think you're missing a few of the basic concepts of OpenEmbedded and Yocto Project Apr 15 16:28:22 I'd really recommend starting with the most basic task then working up to building AGL for raspberrypi Apr 15 16:28:36 Please start with https://www.yoctoproject.org/docs/2.4.2/yocto-project-qs/yocto-project-qs.html Apr 15 16:28:53 yes that is true Apr 15 16:29:08 but i dont have much time Apr 15 16:29:30 A *vmdk.xz file is not for raspberrypi anyway, it's for use with qemu or some other emulator Apr 15 16:30:33 the error said to replace --set-upstream with --set-upstream-to Apr 15 16:30:48 where can i find this to replace Apr 15 16:31:16 i spend a whole day to find this line Apr 15 16:32:55 Honestly, I think you need to start with the basics and spend a few days learning your way around Yocto Project following the quickstart and other documentation Apr 15 16:34:49 ok sir thank you for your time Apr 15 16:35:14 can i build the image in linux Apr 15 16:35:17 in windows Apr 15 16:41:57 My advice is to start with an Ubuntu installation on a machine or VM with a fast CPU, at least 4GB RAM and 50GB free disk space Apr 15 16:55:11 zeddii, if you're about: Where do I send patches for yocto-kernel-tools? Apr 15 17:00:23 Tried to run kernel_configcheck against linux-raspberrypi and ended up yak shaving Apr 15 17:02:39 yak shaving Apr 15 17:02:41 ? Apr 15 17:20:22 trying to convert the config mess we have in linux-raspberrypi into something you can control via KERNEL_FEATURES and instead ended up with a bunch of fixes to the kernel tools Apr 15 17:49:04 paulbarker, good to see someonw do that instead of just bitching Apr 15 17:51:22 paulbarker: heyla! great to 'see' you! Apr 15 18:57:50 paulbarker, send patches for yocto-tools to linux-yocto.. seems to be the closest Apr 15 18:58:42 that seems to have worked in the past Apr 15 19:05:09 armpit: Cheers. Might actually be a couple of days yet to clean these up for submission but will send them when they're ready Apr 15 19:24:02 paulbarker: note, that there are significant unpushed changed to the kernel tools. so integrating anything will take time. Apr 15 19:24:32 zeddii: ok, might be easier if I just point out to you the issues I found Apr 15 19:25:16 either way. I can probably integrate the spirit of any changes. But I have a big set of changes related to me moving work down to kernel.bbclass, that failed for this release. I’ll be re-submitting them once 2.5 goes out. Apr 15 19:26:06 These are pretty simple and low-level, probably easiest to just merge into what you're re-submitting Apr 15 19:26:43 yup. so totally fire them off. I’ll know at a glance if they break any use cases, and I’ll deal with conflicts. Apr 15 19:27:40 Two of them are typo fixes Apr 15 19:28:12 there’s more than two typos in there. hehehe. :D Apr 15 19:28:20 Then in `spp`, the default kconf type for defconfig files is set to 'non-hardware', so invalid/broken settings in the defconfig aren't reported Apr 15 19:28:34 I think for a defconfig that should be 'hardware' Apr 15 19:29:03 I don’t really audit defconfigs at all, since they are evil :D Apr 15 19:29:46 It'd be good to at least optionally be able to audit them, for rpi I can report upstream what I find Apr 15 19:30:05 I actually do have a patch to trigger something like that. so that’s definitely doable. Apr 15 19:30:20 Fixing that led me to 15 entries in the defconfig which are obsolete and don't even exist as options in recent kernels Apr 15 19:30:36 in fact, two ways. but once involves a script that I’ve never had in the tools. so I’ll stay away from that. Apr 15 19:30:56 ahah. yah. I run a scan on the base configs on most kernels and toss out invalid ones myself. Apr 15 19:31:02 and last issue is that symbol_why.py chokes on Kconfig lines like 'imply ...' Apr 15 19:31:06 i can see the use in triggering it for that. Apr 15 19:31:23 So would be good to be able to skip running symbol_why.py Apr 15 19:31:41 I have whole new version of symbol_why based on the new Kconfiglib, I can run it against a sample if you point one out to me. Apr 15 19:32:01 there could be a way to skip it, since yah, it can be nonsense at times. Apr 15 19:32:03 * zeddii_home ponders Apr 15 19:32:44 I didn't look too far into the symbol_why error Apr 15 19:33:14 wise. wouldn’t have been worth the time. Apr 15 19:33:35 the guy that writes it cc’d me ages ago on a new version of the library that is supposed to be better. but it kept falling down my priority list to integrate. Apr 15 19:33:42 * zeddii_home vows to do it for 2.6 Apr 15 19:34:19 Ok Apr 15 19:35:12 I may as well point out the typos while you're here Apr 15 19:35:13 * armpit wonders if zeddii_home would take an eclipse plugin for kernel-tools Apr 15 19:35:27 Rather than sending patches which aren't really suitable for 2.5 Apr 15 19:35:51 paulbarker: sure. I don’t mind. I can definitely just do them an add them to my stack Apr 15 19:36:04 armpit: that sounds kind of …. Apr 15 19:36:06 https://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-tools/tree/tools/kconf_check#n346 and the line above Apr 15 19:36:31 Checks non-hardware_frags.txt then reads hardware_frags.txt instead Apr 15 19:36:43 hah. yes. I see that. Apr 15 19:36:44 * zeddii_home fixes Apr 15 19:37:01 And https://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-tools/tree/tools/scc-cmds/kconf.cmd#n40 Apr 15 19:37:21 reads non-hardware.cfg into hardware_frags.txt Apr 15 19:37:22 * armpit knows that is not what zeddii_home really said ; ) Apr 15 19:38:36 bugger. Indeed. I re-factored that code when breaking the audit from the run, and definitely fat fingered it. Apr 15 19:39:47 paulbarker: very useful feedback. I’m hoping once I make the frags -> kernel.bbclass, + audit in kernel-yocto into 2.6, I can get a few more eyes on the bits. The warnings can be useful, just no one normally cares (but me) :D Apr 15 19:40:24 I'm ripping apart the mess we have in meta-raspberrypi and hoping to replace it with something which you can control via KERNEL_FEATURES Apr 15 19:41:19 cool. not a glamourous job. I have to take a deep breath each kernel version to motivate myself to look at similar things :D Apr 15 19:41:21 since we base on linux-yocto.inc we may as well use that instead of having a messy pre-processing step that rewrites the config file using sed and makes me cry Apr 15 19:42:16 There is stuff in our do_configure_prepend that's basically 6 years obsolete and needs to die Apr 15 19:42:33 paulbarker: indeed. and the changes I’m submitted to oe-core for 2.6, move the merge-config down (optionally) to kernel.bbclass, but nothing else changes. so anything you do, will work with any kernel after that. and the audit phase is visible via kernel-yocto. Apr 15 19:42:44 s/submitted/will submit/ Apr 15 19:43:10 Once I fixed up those typos in the kernel tools they're helpful for showing what is actually taking effect and what is being ignored Apr 15 19:44:13 cool. I also have another script that can “buketize” an entire kernel’s Kconfigs into “hardware” and “nonhardware”, and that can be used to tune the warnings. I should make that available for the defconfig cases. Apr 15 19:44:48 That would be really helpful Apr 15 19:47:27 For rpi we'll always use in the upstream defconfig and apply a few minimal tweaks. No point duplicating their work when they're on github and responsive to pull requests Apr 15 19:48:13 agreed! Apr 15 19:50:55 Taking a hatchet to our ~100 line do_configure_prepend is actually pretty theraputic Apr 15 19:51:19 I bet! Apr 15 19:51:58 I deleted so much of these tools about a year ago, and did enjoy it. so I know the feeling. I can still see the old creaky code and always have the urge to just kill it. Apr 15 21:36:02 can i ask a question Apr 15 21:59:01 hi Apr 15 22:40:45 hi Apr 15 23:13:24 hi Apr 15 23:15:19 is there anu one Apr 15 23:41:32 hi Apr 15 23:48:30 i have a question Apr 16 00:13:31 the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead. **** ENDING LOGGING AT Mon Apr 16 03:00:01 2018