**** BEGIN LOGGING AT Mon Mar 26 03:00:02 2018
Mar 26 07:56:38 <jww> Hello !
Mar 26 08:02:29 <Guest29986> How should I enable an initscript?
Mar 26 08:02:45 <Guest29986> I'd like to enable checkroot.sh
Mar 26 08:04:47 <pinksnake> hi all, i would like to know how to blacklist a driver with Yocto because i don't have /etc/modprobe.d folder ...
Mar 26 08:06:33 <yocti> New news from stackoverflow: Yocto: How to check list of installed packages to stop the build process conditionally <https://stackoverflow.com/questions/49486575/yocto-how-to-check-list-of-installed-packages-to-stop-the-build-process-conditi>
Mar 26 08:28:16 <pinksnake> hi all, i would like to know how to blacklist a driver with Yocto because i don't have /etc/modprobe.d folder ...
Mar 26 08:28:52 <LetoThe2nd> pinksnake: why do you even build the driver then?
Mar 26 08:29:33 <pinksnake> @LetoThe2nd because i want to load this driver manually and not during init :)
Mar 26 08:29:37 <nayfe> Guest29986: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#new-recipe-enabling-system-services
Mar 26 08:30:20 <LetoThe2nd> pinksnake: then here you go: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-KERNEL_MODULE_AUTOLOAD
Mar 26 08:31:59 <pinksnake> @LetoThe2nd thx i'm going to take a look but do you think it's possible to use minus instead of + ? KERNEL_MODULE_AUTOLOAD -= "module_name"
Mar 26 08:32:44 <nayfe> <LetoThe2nd> <pinksnake> if I remember correclty, you're using an old Yocto version without KERNEL_MODULE_AUTOLOAD support right?
Mar 26 08:33:04 <LetoThe2nd> pinksnake: i personally favor _remove, but technically thats the idea. plus, do not blindly tinker. first, evaluate where it is actually set (bitbake -e is your friend)
Mar 26 08:33:48 <LetoThe2nd> nayfe: *shrug* if asker fails to specify that, AND fails to overread the corresponding note (it is directly next to the linked paragraph), then... not my problem. :)
Mar 26 08:36:39 <nayfe> pinksnake: you have to understand how autoload works on your linux version and how it is generated by Yocto. So maybe it uses /etc/modules-load.d ?
Mar 26 08:38:24 <pinksnake> @nayfe thx for info, but i don't have /etc/modules-load.d, i'm able to manage my own custom driver, but for drivers from kernel all are autoloaded  and i don't know why ^^
Mar 26 08:39:13 <nayfe> in /etc/modules ?
Mar 26 08:39:42 <nayfe> pinksnake: as it is probably for debug purpose, you can always patch your rootfs with ROOTFS_POSTPROCESS_COMMAND
Mar 26 08:40:54 <pinksnake> @nayfe no /etc/modules folder, modules are in /lib/modules/4.6.0-xilinx/kernel/ and no it's not for debug purpose tha'ts why i'm looking for a "proper" way to do that :)
Mar 26 08:55:34 <Guest29986> nayfe: the S06checkroot script is installed inside /etc/rcS.d but I cannot figure out how to creater links to in the rcX.d directories
Mar 26 08:57:06 <nayfe> <Guest29986> : did you look at the url ? You don't have to do that yourself, Yocto recipe does it for you
Mar 26 09:00:33 <Guest29986> I looked at the url but in my case the checkroot service is already installed
Mar 26 09:01:09 <Guest29986> I've already written recipes that use update-rc.d to add a startup script
Mar 26 09:02:35 <Guest29986> I'm looking for a way to enable the script installer for my execution level (level 5)
Mar 26 09:02:47 <Guest29986> installed*
Mar 26 09:04:38 <Guest29986> this is very simple
Mar 26 09:06:46 <yocti> New news from stackoverflow: CMake and Qt based Image and SDK generation in Yocto <https://stackoverflow.com/questions/49487458/cmake-and-qt-based-image-and-sdk-generation-in-yocto>
Mar 26 09:15:36 <nayfe> Guest29986: What did you put in INITSCRIPT_PARAMS ?
Mar 26 09:15:49 <Guest29986> "default 6"
Mar 26 09:17:27 <Guest29986> but running /etc/init.d/checkroot.sh just outputs "EXT4-fs (mmcblk0p1): re-mounted. Opts: (null)"
Mar 26 09:17:57 <nayfe> Guest29986: default or defaults?
Mar 26 09:18:34 <Guest29986> defaults sorry
Mar 26 09:19:50 <Guest29986> but I should specify the script if I want to configure more than one script
Mar 26 09:20:15 <nayfe> Guest299986: Ah, it is in MASKED_SCRIPTS
Mar 26 09:21:14 <Guest29986> yes that's right
Mar 26 09:21:41 <Guest29986> what is it?
Mar 26 09:22:00 <nayfe> nvm, its for systemd compatibilité
Mar 26 09:22:12 <Guest29986> ok
Mar 26 09:23:29 <nayfe> I assume you'r using only sysvinit and no systemd?
Mar 26 09:24:25 <Guest29986> yes
Mar 26 09:25:59 <nayfe> the following line in initscripts_1.0.bb should be enough "update-rc.d -r ${D} checkroot.sh start 06 S ."
Mar 26 09:26:43 <Guest29986> it's not executed
Mar 26 09:26:50 <Guest29986> I assume
Mar 26 09:27:09 <Guest29986> because the script isn't present in the runlevel directories
Mar 26 09:27:20 <Guest29986> only in /etc/rcS.d
Mar 26 09:27:22 <mcfrisk> hmm, getting this from poky master. any ideas? ERROR: Configuration has been re-parsed over 20 times, breaking out of the loop...
Mar 26 09:29:21 <nayfe> Guest29986> btw, what is your Yocto version & target machine?
Mar 26 09:30:28 <Guest29986> morty branch (2.2.3) and UDOO neo board
Mar 26 09:30:44 <Guest29986> https://github.com/graugans/meta-udoo
Mar 26 09:34:18 <tasslehoff> I removed debug-tweaks from my image. Shouldn't that disallow empty root and ssh passwords?
Mar 26 09:36:47 <rburton> yes
Mar 26 09:38:54 <tasslehoff> rburton: bah. just remembered that my upgrade script keeps sshd_config :)
Mar 26 09:39:00 <nayfe> Guest29986: I'm not sure why checkroot is not running at startup on your config, it should work without overriding anything ...
Mar 26 09:40:45 <Guest29986> nayfe: it is not present in the runlevel directory for runlevel 5 (/etc/rc5.d)
Mar 26 09:41:21 <Guest29986> a symlink should point to /etc/init.d/checkroot.sh as /etc/rc5.d/S06checkroot
Mar 26 09:44:35 <nayfe> <Guest29986> you can always append  initscripts_%.bbappend and do_install_append () { update-rc.d -r ${D} checkroot.sh start XX 5 . }
Mar 26 09:46:28 <Guest29986> nayfe: yes I'll try :)
Mar 26 09:56:01 <tasslehoff> rburton: is there a default root password?
Mar 26 09:56:23 <rburton> tasslehoff: without debug-tweaks (or the setting that debug-tweaks sets), no
Mar 26 09:56:44 <rburton> a default root password would be bad practise
Mar 26 09:57:31 <tasslehoff> rburton: true. but now I'm locked out :)
Mar 26 09:58:01 <tasslehoff> I have an EXTRA_USERS_PARAMS = "usermod -P <pass> root;" in my recipe
Mar 26 09:58:08 <tasslehoff> but that password is not accepted
Mar 26 09:58:34 <rburton> theres something on the wiki about setting a default root password, i always just use debug-tweaks...
Mar 26 09:59:48 <tasslehoff> rburton: yeah. that is what I followed earlier, so I'm not sure what happened here.
Mar 26 09:59:55 <tasslehoff> oh well. I'll manage.
Mar 26 10:00:20 <LetoThe2nd> my $.02: i don't ship telnet, ssh, or any other remote accessible things. and once somebody has physical access to the serial pins, the device is compromised anyways. -> no pw for me anyways.
Mar 26 10:07:01 <yocti> New news from stackoverflow: How to increase default Yocto kernel memory <https://stackoverflow.com/questions/49488444/how-to-increase-default-yocto-kernel-memory>
Mar 26 10:15:29 <jww> is it normal that my recipe install files in build/tmp/sysrootfs-components ? it should not go to build/tmp/sysrootfs/ ? it's for a lib I need to compile another recipe.here is my recipe : http://dpaste.com/2E2W8WT
Mar 26 10:18:26 <rburton> yes, sysroots-components is where the sysroots are constructed from
Mar 26 10:19:16 <Guest29986> nayfe: it does nothing :/
Mar 26 10:21:17 <jww> rburton: thanks, do you know how I'm supposed to include sysroots-components/cortexa7hf-neon-vfpv4/ecsw-lib/usr/include/escwlib/ASICamera2.h ? I don't understand well why there is the package name and version in the path, I thinked it would like a regular sysroot ...
Mar 26 10:21:40 <rburton> you don't, you put ecdw-lib in your DEPENDS and it will appear
Mar 26 10:21:56 <rburton> its the *components* that make up the per-recipe sysroot
Mar 26 10:22:11 <jww> oh
Mar 26 10:22:58 <jww> let's try it !
Mar 26 10:24:36 <jww> yes that it ! thanks again rburton .
Mar 26 10:24:42 <rburton> if you don't have it in DEPENDS then previously you've been lucky that it was present at all
Mar 26 10:25:01 <rburton> with recipe-specific-sysroots you get *exactly* what you ask for, no more and no less
Mar 26 10:25:41 <jww> I had it in DEPENDS, but I was building the dependency not the finale recipe.
Mar 26 10:25:48 <jww> I'm new to yocto.
Mar 26 11:37:17 <yocti> New news from stackoverflow: bitbake rootfs large for core image minimal <https://stackoverflow.com/questions/49490009/bitbake-rootfs-large-for-core-image-minimal>
Mar 26 12:16:45 <flying_sausages> Hey guys, I'm making a .bb file to deploy some scripts. The package is called shellmanager. But I also want to be able to make a shallmanager-test which will include extra scripts to test it.
Mar 26 12:17:42 <flying_sausages> Now, I'm looking at the tslib bb file as a reference, but I'm just a bit confused what the difference between do_install, dio_insteall_prepend and do_install_append, and if this is omethign I should be using for the separation of normal and -test
Mar 26 12:17:54 <LetoThe2nd> flying_sausages: nope
Mar 26 12:17:56 <flying_sausages> Or basically, how can I make the distinction ebtween what goes into normal and -test?
Mar 26 12:18:19 <LetoThe2nd> flying_sausages: use FILES_${PN}-your-funny-addition
Mar 26 12:18:24 <flying_sausages> I'm sure this is in the mega maunal but I cannot seem to find it
Mar 26 12:18:35 <LetoThe2nd> and extend PACKAGES accrodingly.
Mar 26 12:18:52 <flying_sausages> LetoThe2nd, sorry can you elaborate on the last message?
Mar 26 12:19:04 <flying_sausages> so I'm making a bbappend for the /test?
Mar 26 12:19:08 <flying_sausages> *-test
Mar 26 12:19:35 <LetoThe2nd> nope
Mar 26 12:19:37 <LetoThe2nd> -> https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#splitting-an-application-into-multiple-packages
Mar 26 12:19:52 <flying_sausages> ah perfect let me read this
Mar 26 12:20:31 <zzeroo> Hi, does anyone know since when `oe.utils.conditional` was added to poky master? I ask because of that question: https://github.com/rust-embedded/meta-rust-bin/pull/32#issuecomment-376139237
Mar 26 12:21:00 <LetoThe2nd> zzeroo: git log not telling?
Mar 26 12:21:45 <zzeroo> LetoThe2nd: http://git.yoctoproject.org/cgit.cgi/poky/log/?qt=grep&q=oe.utils.conditional
Mar 26 12:21:55 <zzeroo> http://git.yoctoproject.org/cgit.cgi/poky/log/?qt=grep&q=base_conditional
Mar 26 12:23:22 <flying_sausages> LetoThe2nd, wait, if I define the files I want separated in the FILES, do I need to specify them in the do_install?
Mar 26 12:23:50 <LetoThe2nd> flying_sausages: specify them?
Mar 26 12:26:52 <LetoThe2nd> zzeroo: ac023d775b6 says at least since apr 30, 2010
Mar 26 12:27:33 <zzeroo> flying_sausages: In do_install you tell what and where should it installed. In FILES you tell what should be packed. Often this are the same, but not always
Mar 26 12:28:38 <flying_sausages> zzeroo, did I get this right in that case? https://pastebin.com/8TiSGr16
Mar 26 12:28:44 <flying_sausages> LetoThe2nd, specify as in?
Mar 26 12:28:49 <zzeroo> LetoThe2nd: Thank you, I think my question was odd. Have you read @nastevens question here: https://github.com/rust-embedded/meta-rust-bin/pull/32#issuecomment-376139237
Mar 26 12:28:54 <flying_sausages> do you mean SRC_URI ?
Mar 26 12:29:23 <LetoThe2nd> flying_sausages: you said: "12:23 < flying_sausages> LetoThe2nd, wait, if I define the files I want separated in the FILES, do I need to specify them in the do_install?"
Mar 26 12:29:40 <LetoThe2nd> flying_sausages: and i have no idea what you mean with "specify" here.
Mar 26 12:29:47 <flying_sausages> oh right, by that I meant install them
Mar 26 12:29:59 <flying_sausages> sorry stillgetting used to the terminology
Mar 26 12:30:24 <LetoThe2nd> flying_sausages: yes, you need to have them installed.
Mar 26 12:31:13 <LetoThe2nd> zzeroo: i've read it, but i don't know about the details. just did 2 minutes of git log inspection.
Mar 26 12:31:33 <flying_sausages> LetoThe2nd, but if I install them using do_install aren't the test-only paclages also make their way into the target if I just install the normal flavour?
Mar 26 12:31:55 <LetoThe2nd> flying_sausages: have you actually gone ahead and tried it?
Mar 26 12:32:04 <LetoThe2nd> flying_sausages: you can inspect the packages
Mar 26 12:32:32 <flying_sausages> not yet, I'm still trying to wrap my mind around the idea of the way these recipes work
Mar 26 12:32:44 <flying_sausages> I'll try bake it now
Mar 26 12:33:17 <LetoThe2nd> flying_sausages: again. do_install() tells bitbake what the recipe (*RECIPE* is the keyword!) installs, and FILES_* tells bitbake how to split what the recipe installs into pakcges.
Mar 26 12:45:54 <nayfe> flying_sausages : it misses ${S} in do_install() left part
Mar 26 12:48:10 <nayfe> install ${S}/... ${D}/...
Mar 26 12:50:57 <flying_sausages> ahh yes
Mar 26 12:51:06 <flying_sausages> also a " at the very end :p
Mar 26 13:26:13 <peacememories> hey everyone. i've got a bit of a problem building core-image-minimal for x86. i'm using meta-intel and poky, both on the rocko branch, and using the machine intel-corei7-64. it complains that nothing provides "initramfs-module-install"
Mar 26 13:46:15 <tomi_> hello
Mar 26 13:46:26 <tomi_> Can you guys please help me?
Mar 26 13:46:38 <tomi_> I have a yocto issue with license_create_manifest
Mar 26 13:47:05 <tomi_> ERROR: Error executing a python function in /workspace/git/ehajtam/wr8/platform/meta-ericsson/meta-ericsson-vre/recipes-core-image/core-image-vre.bb:  The stack trace of python calls that resulted in this exception/failure was: File: 'license_create_manifest', lineno: 110, function: <module>      0106:      0107:                        os.link(pkg_license, pkg_rootfs_license)      0108:      0109:  *** 0110:license_create_manifest(d)  
Mar 26 13:47:21 <tomi_> Sorry. that is not really informative
Mar 26 13:47:45 <tomi_> So yocto failes with Exception: KeyError: 'LICENSE_kernel-module-i40evf'
Mar 26 13:48:08 <tomi_> although I specified the LICENSE in my recipe
Mar 26 13:48:15 <tomi_> has anyone seen such a thing before?
Mar 26 13:59:05 <rburton> tomi_: pastebining your actual recipe would be a lot more useful
Mar 26 14:05:28 <tomi_> SUMMARY = "I40E v1.6.42 device driver"  LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=d181af11d575d88127d52226700b0888"  require ../uri.inc inherit module  PR = "r0"  DEPENDS = "virtual/kernel"  do_configure[depends] += "linux-wolf_int:do_configure"  B = "${S}/src"  SRC_URI = "${URIPREFIX}/${PN}-${PV}.tar.gz"  EXTRA_OEMAKE += "\     BUILD_KERNEL=${KERNEL_VERSION} \     KSP=${STAGING_KERNEL_DIR} \     VSP=${STAGING_KERNEL_DIR
Mar 26 14:05:39 <kergoth> google for 'pastebin'
Mar 26 14:06:44 <tomi_> ohh sorry about that
Mar 26 14:08:49 <tomi_> https://pastebin.com/YXAu5Aum
Mar 26 14:09:46 <tomi_> this was the recipe
Mar 26 14:09:57 <tomi_> and this is the ERROR i have
Mar 26 14:10:00 <tomi_> https://pastebin.com/hRRaPx8F
Mar 26 14:12:51 <tomi_> The recipe compiles fine, but sadly the whole image build is not succesfull
Mar 26 14:20:30 <tomi_> I am trying to install the i40e driver 1.6.42, but looks like an earlier version is also compiled by yocto
Mar 26 14:20:47 <tomi_> How can I install the newer one?
Mar 26 14:22:47 <tomi_> https://lists.yoctoproject.org/pipermail/yocto/2015-June/025326.html
Mar 26 14:22:53 <tomi_> this might be a similar issue
Mar 26 14:25:47 <tomi_> Please, Can anyone help me?
Mar 26 14:37:54 <yocti> New news from stackoverflow: OEToolchainConfig.cmake is not installed by cmake recipe Yocto <https://stackoverflow.com/questions/49487458/oetoolchainconfig-cmake-is-not-installed-by-cmake-recipe-yocto>
Mar 26 15:16:37 <armpit> RP, ping.. morty.. are we still trying to sort out glibc .27 issues ?
Mar 26 15:22:16 <nayfe> For those using Poky CROPS, is there a  better way than bindmounting ~/.ssh folder to docker container to access protected git repos ?
Mar 26 16:00:39 <RP> armpit: yes, sdks aren't working yet
Mar 26 16:02:26 <armpit> k
Mar 26 16:14:23 <RP> rburton: interesting stap sanity fails with module version problems :(
Mar 26 16:14:31 <rburton> yeah didn't look good
Mar 26 16:33:51 <khem> RP: I was thinking about our release schedules and idea came up, why dont we slate YP releases say at same time as fedora releases ?
Mar 26 16:34:15 <khem> RP: Ubuntu releases in Apr/Oct Fedora in May/Non-Dec
Mar 26 16:34:41 <khem> so its shift of 1 month but it gives us sometime to support the new releases.
Mar 26 16:34:45 <armpit> khem, what about window releases ?
Mar 26 16:35:17 <khem> windoze :)
Mar 26 16:35:52 <RP> khem: We had to pick something and I like our Apr/Oct. If we wait to Dec to support we'd have to release in Jan and that would suck :/
Mar 26 16:36:52 <fray> Dec/Jan can have issues with corporations as well..  so from a YP (corporate sponsored) Nov of before works better..  one problem (in the US at least) is Thanksgiving holiday in Nov.. so October is 'better'..  but that really is only a US problem...
Mar 26 16:38:11 <khem> RP: no dec, but Nov
Mar 26 16:38:14 <fray> but ya, fall release (the one I care the most about)  Oct/Nov is my personal preference..
Mar 26 16:39:33 <RP> khem: but you need some time after they release to sort our stuff out...
Mar 26 16:39:58 <khem> currently we have to push quite a few fixes to support newer host distros immediately after release, which is not ideal either
Mar 26 16:40:30 <fray> that says we have a testing issue -- we should be testing with the dev versions of these new distros.. assuming they are available of course... [I'm ignoring resource constraints)
Mar 26 16:41:21 <armpit> that is only an issue for stable releases and we list only the then currently release, don't we ?
Mar 26 16:41:21 <khem> fray: yes that works too for my case, I can then let people know that f28 is going to be supported with Sumo
Mar 26 16:42:19 <fray> I know we -try-.. but the testing for not-yet-released versions is less then stable..
Mar 26 16:42:23 <fray> (we = WR)
Mar 26 16:42:36 <fray> but then again, I've not had commercial customers ask me for Fedora support..
Mar 26 16:43:18 <khem> for commercial reasons, centos/debian/suse is what folks target and really old versions
Mar 26 16:43:30 <armpit> (yp/OE) stable releases feel the wrath of new host OS for 1.5 yrs after release so its a none issue for me
Mar 26 16:43:35 <fray> exactly..  usually centos/ubuntu/suse
Mar 26 16:43:36 <khem> however, devs can run newer distros on their VMs
Mar 26 16:43:51 <khem> so there is a increased demand for more modern distros
Mar 26 16:44:02 <fray> (I personally gave up on Fedora.. it 'moves too fast, and breaks too often..'  kind of like the latest Ubuntu..
Mar 26 16:44:33 <khem> fray: you are being double standard its relesase schedule is no different than ours :)
Mar 26 16:45:24 <fray> I also pretty much only use master (in development) or fall release [stable]..
Mar 26 16:45:49 <khem> world should just use archlinux for host distro and and incarnation of poky-bleeding, CI/CDed everyday, life becomes simple
Mar 26 16:45:53 <fray> I can't afford a day to re-install my workstation....  thats just reality..
Mar 26 16:46:22 <fray> I don't like how ancient CentOS is..  and I don't like how 'wild' Fedora is... but I've not found a solution to that problem.. :)
Mar 26 16:46:58 <khem> fray: my archlinux install was in 2013, it has been smooth upgrade eversince.
Mar 26 16:47:22 <khem> fray: ubuntu LTS is somewhere in middle
Mar 26 16:47:45 <fray> ya, but then I have to learn the 'debian way' of doing everything.. (ubuntu LTS).. but I agree.. the ubuntu way seems a little nicer..
Mar 26 16:48:56 <kergoth> i stopped using arch when they switched to systemd.. maybe i should try it again
Mar 26 16:50:00 <khem> kergoth: heh, you should. systemd is not bad its solving a tough problem
Mar 26 16:50:57 <kergoth> i hate the concept more than the implemetnation. yes, it does the job, but it bugs me that it sucks up the damn world to do so :) also lost some of that explicit non-complexity at the core of arch, i.e. editing a single variable to control the services started
Mar 26 16:51:00 <kergoth> tradeoffs, but..
Mar 26 16:51:19 <kergoth> i do <3 pacman, though
Mar 26 16:52:29 <khem> kergoth: I would have liked it to put limits on itself too or become more modular but seeing how osx has done its init etc. systemd makes an argument for better boot experience
Mar 26 16:53:53 <khem> RP: in a way our release schedule kind of covers ubuntu since its almost same time as yp, a week here and there, I just have fedora users who want to stay on top
Mar 26 16:54:45 <RP> khem: I'll give it some thought
Mar 26 16:56:01 <khem> and I know we cant end world hunger, but we can try
Mar 26 16:58:38 <khem> oh btw. if folks are daring they could try my gcc-8 updates here https://github.com/kraj/openembedded-core/commits/kraj/master
Mar 26 17:19:10 <peacememories> hmm, does bitbake kill ssh-agent forwarding? i'm trying to build a recipe on our private git, and am forwarding my agent to a build host. `git clone`ing the repo in the shell works, but running bitbake i get the error that i do not have the correct permissions
Mar 26 17:25:12 <peacememories> adding "SSH_AUTH_SOCK" and "SSH_AGENT_PID" to "BB_ENV_EXTRAWHITE" does not seem to have helped :/
Mar 26 17:31:34 <peacememories> and adding anything to "BB_ENV_WHITELIST" causes a sanity check error O.o
Mar 26 17:34:13 <kergoth> setting env whitelisdt will override the default
Mar 26 17:34:19 <kergoth> extrawhgite is correct
Mar 26 17:34:33 <peacememories> using extrawhite does sadly not change a thing :/
Mar 26 17:34:57 <peacememories> (meaning it still tells me i don't have the correct permissions)
Mar 26 17:35:23 <kergoth> i use agent forwarding to auth bitbake fetches every day, not sure why it wouldn't be working for you
Mar 26 17:35:26 <peacememories> is `export BB_ENV_EXTRAWHITE="SSH_AUTH_SOCK SSH_AGENT_PID" correct?
Mar 26 17:35:43 <peacememories> (missing ` at the end there, but you get the point^^)
Mar 26 17:36:54 <kergoth> technically that too is removing vars that were there by default. first source oe-init-build-env, then export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE SSH_AUTH_SOCK SSH_AGENT_PID" to append to the existing variable
Mar 26 17:37:05 <kergoth> but iirc those are whitelisted by default anyway, so i htink you've got somethinge lse going on
Mar 26 17:37:15 <peacememories> but my BB_ENV_EXTRAWHITE was empty before^^
Mar 26 17:37:15 <kergoth> i'd suggest doing a bitbake -c devshell on some recipe and then running ssh-add -l in the devshell
Mar 26 17:37:22 <kergoth> oe-init-build-env sets it
Mar 26 17:37:28 <kergoth> so that seems unlikely
Mar 26 17:37:33 * kergoth shrugs
Mar 26 17:38:07 <peacememories> hmm
Mar 26 17:38:49 <peacememories> okay yeah, you're right
Mar 26 17:38:55 <peacememories> just reinitialized my build env
Mar 26 17:40:32 <peacememories> okay, i'm sure i didn't touch that var before i tried it first O.o it's working now *hides*
Mar 26 17:40:44 <peacememories> well "working" the build still fails, but that's expected with my current recipe^^
Mar 26 17:40:49 <peacememories> thanks :)
Mar 26 17:40:52 <kergoth> np
Mar 26 17:43:31 <laplante> is there any way to use a MultiStageProgressReporter with a task'
Mar 26 17:43:41 <laplante> * with a task's 'progress' varflag?
Mar 26 17:45:18 <laplante> looks like only 'outof' and 'percent' are supported
Mar 26 19:32:12 <seebs> just a heads up for those curious, i went looking, and it looks like writing a "correct" syscall wrapper is much harder than it looks.
Mar 26 19:32:43 <seebs> But I have thought of an incredibly ugly workaround for one of the things.
Mar 26 19:33:31 <seebs> So basically, the syscall() wrapper will end with: close(-3); errno = ENOTSUPP; return -1;
Mar 26 19:33:48 <seebs> because that sets the separate register used to indicate whether a syscall succeeded.
Mar 26 19:34:08 <seebs> ... huh. come to think of it, i should possibly be thinking about that in other cases also, because this could be a general problem with the ABI, it's just one that normally doesn't show up in code.
Mar 26 19:34:27 <seebs> Because there are lots of cases where we're going to return -1 from a syscall-like-thing, but the actual last syscall called by pseudo will have succeeded.
Mar 26 19:34:28 <seebs> whee.
Mar 26 19:36:32 <seebs> also renameat2() is a pain to implement. but also I see why they want it, it allows things that were actually previously impossible.
Mar 26 20:31:52 <otavio> rburton: mesa upgrade is important. It fixes a lot of problms with AMD and Intel platforms
Mar 26 20:56:20 <JPEW> seebs: Whats the close(-3) for?
Mar 26 22:31:34 <noway96> I'm trying to setup rc.local on my image
Mar 26 22:36:14 <itsfemme[m]> is yocto suitable for building desktop distros?
Mar 26 22:39:16 <noway96> I'm getting QA issue: Files/directories were installed but not shipped in any package
Mar 26 22:39:48 <noway96> I have install -d                          ${D}/etc/
Mar 26 22:39:54 <noway96> install -m 0755 ${S}/rc.local       ${D}/etc/rc.local
Mar 26 22:43:51 <clsulliv> noway96: do you have FILES_${PN} = "/etc/rc.local" in your recipe?
Mar 26 22:49:42 <noway96> clsulliv, https://pastebin.com/75PLpwsw
Mar 26 22:50:08 <noway96> lol wait
Mar 26 22:51:05 <noway96> oh my goodness . . . what a dumb mistake
Mar 26 22:51:29 <noway96> I had FILES_${PN} overwritting a previous declaration in the same file
Mar 26 22:54:03 <noway96> so what is FILES_${PN} anyway?
Mar 26 22:55:06 <clsulliv> noway96: the files that go into the package ${PN}
Mar 26 22:55:20 <clsulliv> if your recipe made multiple packages you could further separate it
Mar 26 22:55:39 <noway96> so do_install() does the actual installation, but FILES_${PN} tell it what to expect?
Mar 26 22:56:11 <clsulliv> so like in your recipe, your do_install could remain the same, but you could do FILES_${PN}-usb = "/usr/local/bin/remount-usb.sh" for example
Mar 26 22:56:30 <clsulliv> with PACKAGES += "${PN}-usb"
Mar 26 22:56:53 <clsulliv> (not recommending this, just an example)
Mar 26 22:58:18 <noway96> clsulliv, also that fixed it, thank you
Mar 26 22:58:47 <noway96> oh, why would I want multiple packages?
Mar 26 22:59:58 <clsulliv> noway96: in your example you wouldn't, just a quick example of why FILES is useful
Mar 26 23:00:11 <clsulliv> but in the general case, more granularity
Mar 26 23:01:39 <clsulliv> so your FILES_${PN} should have both the remount-usb and rc.local files, in case I wasn't being clear
Mar 26 23:03:31 <noway96> ok thanks
Mar 26 23:03:43 <clsulliv> np
Mar 26 23:12:35 <noway96> is there a way to install a directory tree instead of just the directory
Mar 26 23:12:41 <noway96> some variant of install -d
Mar 26 23:16:51 <seebs> JPEW: apparently syscall(2) does extra magic if the syscall "failed", so simulating a failed syscall may prevent some errors.
Mar 26 23:17:01 <seebs> I should probably be doing this for all the things which are syscall wrappers.
Mar 26 23:25:04 <clsulliv> noway96: there's always cp -r, but you then might have extra work dealing with ownership/permissions
Mar 26 23:25:09 <clsulliv> https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#ref-tasks-install
Mar 26 23:28:02 <clsulliv> could also do put 'find foo/ -type d
Mar 26 23:28:07 <clsulliv> through a for loop
Mar 26 23:32:52 <kergoth> generally folks use cp but arrange to not retain ownership, via whatever means, or chown after the fact. i.e. cp -R --no-dereference --preserve=mode,links
Mar 26 23:32:59 <kergoth> grep -w cp oe-core :)
**** ENDING LOGGING AT Tue Mar 27 03:00:03 2018