**** BEGIN LOGGING AT Tue Dec 11 03:00:02 2018
Dec 11 09:04:56 <rokm> Hi, how to call do
Dec 11 09:05:20 <rokm> do_compile in my recipe to build library by cmake
Dec 11 09:05:22 <rokm> ?
Dec 11 09:05:38 <LetoThe2nd> what are you *ACTUALLY* trying to do?
Dec 11 09:06:00 <LetoThe2nd> if your recipe inherits cmake, all the bits and pieces are in place automatically.
Dec 11 09:08:06 <rokm> so I should remove do_configure and do_compile
Dec 11 09:08:08 <rokm> I will try
Dec 11 09:10:02 <LetoThe2nd> rokm: https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-configuring-the-recipe
Dec 11 09:10:14 <LetoThe2nd> and https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-installing
Dec 11 09:10:28 <LetoThe2nd> both have explicit information concerning cmake
Dec 11 09:10:30 <rokm> https://pastebin.com/JZHb1SLM
Dec 11 09:10:38 <rokm> here is my recipe
Dec 11 09:11:11 <LetoThe2nd> that loooks...... wrong.
Dec 11 09:11:18 <rokm> :(
Dec 11 09:11:50 <rokm> I need it it that ugly format because original is not ready for so
Dec 11 09:11:56 <rokm> So I got help here
Dec 11 09:12:05 <rokm> how to change recipe
Dec 11 09:12:41 <rokm> but it doesn't compile from bitbake and there are no *.so files in rootfs
Dec 11 09:13:03 <LetoThe2nd> here is a relatively simple cmake-based recipe to look at: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/libical/libical_2.0.0.bb?h=master
Dec 11 09:13:52 <LetoThe2nd> and "it doesn't compile" is not a very good error description either.
Dec 11 09:14:12 <rokm> doesn't start to compile
Dec 11 09:14:46 <LetoThe2nd> *sigh*
Dec 11 09:14:57 <LetoThe2nd> whane you do "what"?
Dec 11 09:15:31 <rokm> ?
Dec 11 09:15:41 <LetoThe2nd> "it doesn't start to compile".
Dec 11 09:15:45 <LetoThe2nd> when you do *WHAT*?
Dec 11 09:15:53 <rokm> bitbake libinih
Dec 11 09:16:29 <LetoThe2nd> when do you expect it to maybe ot thinks theres nothing to do?
Dec 11 09:17:10 <LetoThe2nd> bitbake -c clean libinih; bitbake libinih
Dec 11 09:17:43 <rokm> tried many times
Dec 11 09:18:29 <LetoThe2nd> i really find it very hard to understand your problem and what you are doing.
Dec 11 09:19:29 <rokm> trying to get libini.so
Dec 11 09:19:37 <rokm> from bitbake
Dec 11 09:19:44 <rokm> bitbake libinih doesn't work
Dec 11 09:19:59 <LetoThe2nd> "doesn't work" is not a valid error message
Dec 11 09:20:29 <rokm> there is no error
Dec 11 09:20:35 <LetoThe2nd> *sigh* sorry, but i really do not have the nerves for this right now. good luck.
Dec 11 09:20:36 <rokm> but there are no so files
Dec 11 09:20:52 <rokm> write this many times
Dec 11 09:20:56 <rokm> share recipe
Dec 11 09:21:02 <rokm> there are no error
Dec 11 09:21:06 <rokm> but there ar no so files
Dec 11 09:22:27 <rokm> when im doing this from devshell it work
Dec 11 10:10:09 <pepijndevos> ERROR: Nothing PROVIDES 'gstreamer1.0-omx'
Dec 11 10:10:16 <pepijndevos> https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.14.4.bb
Dec 11 10:10:21 <pepijndevos> What is going on here??
Dec 11 10:11:58 <derRichard> is there really no way to create an encrypted rootfs (ext4) with yocto?
Dec 11 10:27:46 <pepijndevos> I should learn to read: gstreamer1.0-omx was skipped: because it has a restricted license not whitelisted in LICENSE_FLAGS_WHITELIST
Dec 11 10:51:23 <RP> derRichard: If you know the command to do it from the commandline, bitbake can also do it. It might not be out the box.
Dec 11 11:00:01 <nacknick> Hello. Where Yocto saves the packages binaries for the image? I need to edit some of those binaries before deploying to the board...
Dec 11 11:02:11 <nacknick> And I need to know where can I put my python/bash script so it will run on those binaries before  creating the image
Dec 11 11:02:32 <rburton> nacknick: why don't you change the recipe to do what you want?
Dec 11 11:11:06 <derRichard> RP: yeah, i was a bit shocked that mkfs.ext4 cannot create a fscrypt enabled fs. and there is also no tool to create a dmcrypt offline ;-\
Dec 11 11:13:12 <rburton> derRichard: you mean the per-file crypt that ext4 can do?
Dec 11 11:14:27 <derRichard> rburton: yeah. fscrypt is very nice
Dec 11 11:14:37 <rburton> mkfs wouldn't need to be involved at all, surely
Dec 11 11:14:40 <rburton> its just a ext4
Dec 11 11:14:48 <derRichard> rburton: ???
Dec 11 11:15:35 <derRichard> i want to use mkfs.ext4 -d rootfs/ ..
Dec 11 11:15:46 <derRichard> and every file in rootfs should be encrypted
Dec 11 11:16:08 <derRichard> such that i can flash the fs image to my target and have an encrypted rootfs by default
Dec 11 11:16:40 <derRichard> i somehow expected mkfs.ext4 to support this use-case :D
Dec 11 11:16:57 <rburton> https://github.com/google/fscrypt
Dec 11 11:17:12 <derRichard> rburton: did you read what this tool does?
Dec 11 11:17:19 <rburton> sets up the keys and stuff
Dec 11 11:17:38 <derRichard> this is not what i'm asking for
Dec 11 11:18:26 <rburton> as i understand it the process would be mkfs, then setup the crypto keys, then populate the
Dec 11 11:18:48 <rburton> the catch being that we use mkfs's -d to populate a fs from a directory
Dec 11 11:19:06 <derRichard> the fscrypt tool is a tool to the fscrypt kernel interface
Dec 11 11:19:26 <derRichard> i want to create an encrypted ext4 _offline_
Dec 11 11:19:53 <derRichard> yocot does not run as root
Dec 11 11:19:55 <derRichard> *yocto
Dec 11 11:20:23 <rburton> pretty sure i've seen people do dm-crypt offline fwiw
Dec 11 11:20:39 <derRichard> rburton: do you remember which tool they used?
Dec 11 11:20:54 <rburton> ah it was dm-verity
Dec 11 11:20:57 <rburton> close
Dec 11 11:21:07 <derRichard> :)
Dec 11 11:21:09 * derRichard finds cryptsetup-reencrypt
Dec 11 11:21:13 <derRichard> maybe this can help me
Dec 11 11:22:55 <derRichard> https://wiki.archlinux.org/index.php/dm-crypt/Device_encryption#Encrypt_an_unencrypted_filesystem
Dec 11 11:22:59 <derRichard> looks good
Dec 11 11:23:11 <derRichard> if it works, i'll send a patch for yocto :)
Dec 11 11:26:41 <yocti> New news from stackoverflow: How to get Baud rate of Bluetooth interface of UNIX based gateway (Eurotech)? <https://stackoverflow.com/questions/53722647/how-to-get-baud-rate-of-bluetooth-interface-of-unix-based-gateway-eurotech>
Dec 11 11:43:12 <nacknick> rburton: what do you mean? I can change the recipe to edit the binary? I have to edit the binary itself and replace the original with mine
Dec 11 11:46:42 <rburton> nacknick: unless you're attempting to backdoor the image by replacing a built binary with some you provide, why not just change the recipe to do what you want
Dec 11 11:47:03 <LetoThe2nd> nacknick: the question reads as "why do you generate a binary that you don't want anyways?"
Dec 11 11:47:21 <rburton> (which could be replacing a binary, but at least it will happen every time and be clear in the recipe)
Dec 11 11:49:44 <derRichard> hmm, why is fixing/appending the recipe not an option?
Dec 11 12:03:33 <nacknick> maybe it's an option. I'm just trying to understand where the compiled binary is stored so I'l be able to run my script on it and replacing it
Dec 11 12:04:00 <rburton> in the work directory briefly during the build, and then the package is written to tmp/deploy
Dec 11 12:35:18 <kanavin_home> rburton: I am working on meson 0.49 update, should be ready soonish
Dec 11 12:41:45 <rburton> kanavin_home: nice
Dec 11 12:42:58 <rburton> kanavin_: in theory it means we can upstream/remove the qt patch we have, because it should be respecting native=true for pkgconfig calls if we set the PKG_CONFIG=pkg-config-native env var.  might need patches from git unless they've rolled a 0.49.1 already.
Dec 11 12:44:11 <kanavin_home> rburton: I didn't do anything with that patch, but I dropped two of yours as I understand they've been upstreamed in a tweaked form
Dec 11 12:44:49 <rburton> kanavin_home: sure we can leave the qt one for after the upgrade
Dec 11 12:45:33 <kanavin_home> rburton: I am also experimenting with virgl support in qemu. just found out how to prevent it from crashing, didn't run demos yet :)
Dec 11 12:45:42 <rburton> nice
Dec 11 12:45:59 <rburton> you know to talk to JaMa, pretty sure he has it actually working
Dec 11 12:46:09 <kanavin_home> rburton: I believe it should be supported and enabled by default, if mesa-demos or qt3d or whatnot work well
Dec 11 12:46:16 <kanavin_home> rburton: I took some of his patches :)
Dec 11 12:46:21 <rburton> good stuff
Dec 11 12:46:28 <rburton> it involves llvm right?
Dec 11 12:46:39 <rburton> the performance hit on builds is quite considerable :/
Dec 11 12:46:51 <kanavin_home> rburton: depends on whether you want the fancy software driver in mesa or not.
Dec 11 12:47:15 <kanavin_home> rburton: if you just want to use nouveau, or intel driver, no need for llvm
Dec 11 12:47:20 <rburton> RP: revised sdk qa patches on the ab now
Dec 11 12:47:28 <ernstp> damn, still getting a lot of random builderrors popping up after enabling useradd-staticids
Dec 11 12:47:49 <ernstp> and they get stuck in sstate cache unfortunately
Dec 11 12:48:07 <ernstp> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12107
Dec 11 12:48:08 <yocti> Bug 12107: normal, Medium, 2.7, JPEWhacker, NEW , useradd-staticids: groupadd: GID already exists
Dec 11 12:49:51 <ernstp> I'm thinking that perhaps everything that inherits useradd.class needs to depend on the contents of your USERADD_[GU]ID_TABLES
Dec 11 12:50:01 <ernstp> when you have staticids enabled
Dec 11 12:50:26 <kanavin_home> rburton: theoretically we can also link qemu to the host libGL
Dec 11 12:51:33 <kanavin_home> rburton: this would allow using nvidia's proprietary driver, and generally offload the issue of building mesa to the distributions
Dec 11 12:51:49 <RP> rburton: thanks, was getting around to looking at that
Dec 11 12:52:24 <rburton> kanavin_home: awooga dragons
Dec 11 12:52:47 <rburton> kanavin_: epic can of works. maybe as an opt-in packageconfig
Dec 11 12:52:56 <RP> kanavin_home: we've done this before once
Dec 11 12:53:38 <rburton> sdl used to have a lot less host deps, it was a nightmare
Dec 11 12:53:47 <rburton> erm, a lot more host, a lot less native
Dec 11 12:54:02 <kanavin_home> yeah, I remember :)
Dec 11 12:54:25 <pepijndevos> Eeeehm, I updated the raspi layer and now my gstreamer plugins are no longer being installed. dafuq?
Dec 11 12:55:19 <RP> rburton: we had gl passthrough once too
Dec 11 12:55:29 <rburton> yeah but that was evil
Dec 11 12:55:42 <rburton> pepijndevos: sounds like the rpi layer changed?
Dec 11 12:56:38 <pepijndevos> rburton, but the gstreamer recipes are in poky/meta. Meta-raspberrypi only adds a few bbapends to other recipes, but not to the plugins.
Dec 11 12:57:12 <rburton> pepijndevos: but does it control the image content too
Dec 11 12:57:17 <pepijndevos> It's really weird. I have plugins base show up, but good/bad doesn't. And then I add ugly and it also shows up.
Dec 11 12:57:55 <pepijndevos> No, I have my own image, and one of my main packages RDEPENDS on the plugins
Dec 11 12:58:15 <pepijndevos> They used to be there...
Dec 11 12:58:16 <RP> rburton: totally, no denying that!
Dec 11 12:59:03 <kanavin_home> the way things are going, useful GL in qemu will become a necessity, I think
Dec 11 12:59:03 <pepijndevos> Can I tell bitbake to rebuild those packages? Maybe it just confused itself...
Dec 11 13:01:07 <pepijndevos> huuuuuh??? I did bitbake -f gstreamer1.0-plugins-good and it did nothing...
Dec 11 13:02:11 <RP> pepijndevos: that would force the do_build task which would indeed do very little
Dec 11 13:02:57 <RP> pepijndevos: compared to say forcing it to rerun do_compile
Dec 11 13:03:16 <ernstp> pepijndevos: does it show up in tmp/deploy/images/machine/IMAGE.manifest ?
Dec 11 13:03:37 <rburton> pepijndevos: if you want to force a build, neatest way is bitbake gstreamer1.0-plugins-good -C unpack
Dec 11 13:03:49 <RP> pepijndevos: You can see if these things built by checking for the packages in tmp/deploy/<pkg>/*. I suspect they will have done and you want to look at what the image is including
Dec 11 13:08:34 <pepijndevos> Trying those things... side note: how do I get rid of those warnings from tainted packages?
Dec 11 13:12:48 <pepijndevos> ernstp, it seems to be there alright gstreamer1.0-plugins-good cortexa7t2hf_neon_vfpv4 1.14.2
Dec 11 13:13:40 <ernstp> rburton: do you have time to take a look at https://bugzilla.yoctoproject.org/show_bug.cgi?id=12107 ?
Dec 11 13:13:41 <yocti> Bug 12107: normal, Medium, 2.7, JPEWhacker, NEW , useradd-staticids: groupadd: GID already exists
Dec 11 13:15:47 <pepijndevos> RP, there is no tmp/deploy/<pkg>, only images, license, rpm. Neither
Dec 11 13:16:01 <pepijndevos> of them seems to contain a gstreamer folder
Dec 11 13:17:01 <ernstp> pepijndevos: you can check in the rpm folder
Dec 11 13:17:25 <RP> pepijndevos: you're presumably building rpms then which would be in the rpm folder
Dec 11 13:18:01 <pepijndevos> tmp/deploy/rpm/cortexa7t2hf_neon_vfpv4/gstreamer1.0-plugins-good-1.14.2-r0.cortexa7t2hf_neon_vfpv4.rpm
Dec 11 13:18:22 <pepijndevos> and a looot of other ones for every single plugin it appears
Dec 11 13:21:46 <pepijndevos> rpm -q -filesbypkg -p tmp/deploy/rpm/cortexa7t2hf_neon_vfpv4/gstreamer1.0-plugins-good-rtp-1.14.2-r0.cortexa7t2hf_neon_vfpv4.rpm
Dec 11 13:21:53 <pepijndevos> gstreamer1.0-plugins-good-rtp /usr/lib/gstreamer-1.0/libgstrtp.so
Dec 11 13:22:13 <pepijndevos> So the RPM is fine... but somehow it never gets installed.
Dec 11 13:23:26 <rburton> add gstreamer1.0-plugins-good explicitly to your image if you want all the plugins
Dec 11 13:23:36 <rburton> maybe meta-rpi used to pull it in via a dependency and doesn't anymore
Dec 11 13:24:24 <rburton> RP: problem was at no point was lzip being told to use the cross compiler so it was always just using the host :)
Dec 11 13:24:41 <RP> rburton: ouch
Dec 11 13:24:43 <ernstp> pepijndevos: you can check in tmp/work/machine-something/image/1.0-r0/rootfs/ also
Dec 11 13:25:00 <rburton> RP: i'll fix up the cpio test to do the same sanity check next
Dec 11 13:27:11 <pepijndevos> ernstp, ls tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/gstreamer1.0-plugins-good/1.14.2-r0/image/usr/lib/gstreamer-1.0/ has all the things I want
Dec 11 13:28:05 <ernstp> pepijndevos: yeah, but does tmp/work/YOURMACHINE-something/YOURIMAGE/1.0-r0/rootfs/ have it?
Dec 11 13:28:57 <pepijndevos> ls tmp/work/raspberrypi3-poky-linux-gnueabi/rove-image/1.0-r0/rootfs/usr/lib/gstreamer-1.0/ does not have it :(((
Dec 11 13:29:33 <pepijndevos> what is this madness...
Dec 11 13:29:39 <ernstp> and you build with bitbake rove-image right?
Dec 11 13:30:23 <ernstp> if you clean the image "bitbake -c clean rove-image" and then "bitbake -v rove-image" you can double check which packages are installed
Dec 11 13:30:54 <pepijndevos> Is it normal that rpm -q -R -p tmp/deploy/rpm/cortexa7t2hf_neon_vfpv4/gstreamer1.0-plugins-good-1.14.2-r0.cortexa7t2hf_neon_vfpv4.rpm does not list any deps on the other rpms that actually seem to contain the plugins?
Dec 11 13:33:52 <nacknick> LetoThe2nd: I don't generate a binary that I don't want. I have a tool that customizes some of the binaries that are generated and I need to run it on them and replace them with the customized binary
Dec 11 13:36:50 <nacknick> Any change of a single recipe's bb file requires a full rebuild of the image? Is there any way to avoid it?
Dec 11 13:38:33 <pepijndevos> ernstp, erm... not gstreamer plugins it seems... :)
Dec 11 13:38:35 <pepijndevos> :(
Dec 11 13:38:57 <rburton> pepijndevos: that should depend on all the plugins
Dec 11 13:39:36 <pepijndevos> so my rpms are broken?
Dec 11 13:40:48 <rburton> pepijndevos: oh, wait.  PN should recommend PN-meta and PN-meta depends on all the others
Dec 11 13:41:00 <rburton> might neaten than and remove the -meta package
Dec 11 13:42:14 <pepijndevos> rpmlib(CompressedFileNames) <= 3.0.4-1
Dec 11 13:42:14 <pepijndevos> rpmlib(FileDigests) <= 4.6.0-1
Dec 11 13:42:14 <pepijndevos> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Dec 11 13:42:14 <pepijndevos> rpmlib(PayloadIsXz) <= 5.2-1
Dec 11 13:42:23 <pepijndevos> No meta dependency
Dec 11 13:43:05 <pepijndevos> Oh actually, recommends. Yea... that's fine
Dec 11 13:43:47 <pepijndevos> So wtf... I put the plugins directly in the image IMAGE_INSTALL_append and that doesn't help either
Dec 11 13:48:48 <nacknick> in the recipe's bb file, where can I find the name of the binary that is created?
Dec 11 13:50:09 <rburton> nacknick: depends on the recipe.  if it just calls make, it doesn't know or care
Dec 11 13:51:36 <nacknick> under "do_install" I have "oe_runmake DESTDIR=${D} install". what "oe_runmake" means?
Dec 11 13:52:38 <nacknick> where can I found the compiled ELF file...? I could not find it under tmp/deploy
Dec 11 13:52:53 <nacknick> find
Dec 11 13:52:55 <nacknick> *
Dec 11 13:54:30 <nacknick> and what about my previous question? can I avoid rebuild of whole image if I change only single recipe' bb file?
Dec 11 13:55:26 <nacknick> rburton: ^^^
Dec 11 13:56:06 <ernstp> nacknick: short answer, no. if it's part of the image you need to rebuild the image...
Dec 11 13:57:25 <rburton> nacknick: oe_runmake is a function that runs make
Dec 11 13:57:44 <rburton> tmp/deploy will have the package
Dec 11 13:58:24 <nacknick> ernstp: if I change build/conf/local.conf and add more packages to "CORE_IMAGE_EXTRA_INSTALL" it does not rebuild the whole image, the building process is much quicker...
Dec 11 14:01:19 <nacknick> rburton: under tmp/deploy I have only three folders: image, ipk and licenses
Dec 11 14:01:45 <nacknick> do you mean ipk? because ipk it's no ELFs
Dec 11 14:01:48 <nacknick> not
Dec 11 14:08:28 <nacknick> rburton: I think I've found the binaries you meant
Dec 11 14:09:24 <fmns> are you interested in patches to have sstate binary reproducable?
Dec 11 14:09:51 <nacknick> are you asking me?
Dec 11 14:10:25 <fmns> nacknick, in general
Dec 11 14:11:31 <fmns> nacknick, ipk folder contains packages to be installed on the target which may be ELF
Dec 11 14:17:04 <rburton> nacknick: the elfs are inside the ipkg, obviously.  unpack it.  there will be transient elfs inside the work directory too, but altering those won't change anything
Dec 11 14:21:07 <nacknick> fmns: I'm not sure what do you ask, so I'll try to explain what I'm trying to do: I have a python script that runs on a binary, does some stuff and create a new binary that includes my customizations, I need that this customized binary to be included in the image instead of the original
Dec 11 14:21:35 <rburton> nacknick: just call it in the recipe
Dec 11 14:21:56 <rburton> curious what this stuff is though :)
Dec 11 14:22:25 <nacknick> fmns: I can't generate the customized binary in advance, the original binaries are not mine and my script works on binaries only
Dec 11 14:22:28 <fmns> nacknick, I started a different topic, but tried to reply to your question in between.
Dec 11 14:25:19 <nacknick> rburton: by mistake I searched the binaries under  build/tmp/deploy, there I found the ipk files
Dec 11 14:25:49 <rburton> nacknick: if you want your script to be run always and not just once then edit the recipe to call it in do_install
Dec 11 14:26:53 <nacknick> rburton: this staff is a protection to the binary, because the binary runs under unprotected embedded env
Dec 11 14:27:40 <tgoodwin> Is PREFERRED_VERSION intended to be used only at global scope (e.g., a recipe can't set a preferred version on one of its DEPENDS packages)?
Dec 11 14:28:17 <LetoThe2nd> tgoodwin: very much so. recipes cannot influence other recipes
Dec 11 14:29:16 <tgoodwin> LetoThe2nd: thanks; that's what I figured but the mega manual didn't call it out explicitly.  I just noticed that all other layers only ever use it in some global way like a distro.
Dec 11 14:29:48 <LetoThe2nd> tgoodwin: one thing to absolutely memorize when using anything OE is: "recipes are local, confs are global"
Dec 11 14:30:09 <eduardas_m> Hello, I get a do_populate_sdk: Postinstall scriptlets of ['util-linux-umount', 'util-linux'] have failed. when generating an SDK via -c populate_sdk
Dec 11 14:30:28 <LetoThe2nd> so when ever you need to do something that affects anything not right inside that very speicifc recipe you are in, then it needs to go into some form of conf file
Dec 11 14:30:30 <tgoodwin> LetoThe2nd: right.  The issue came up with two packages that required specific versions of one another.  I'm looking for a way to enforce that for a layer.
Dec 11 14:30:35 <eduardas_m> conflict seems between util-linux-umount and toybox umount
Dec 11 14:31:04 <eduardas_m> but the strange thing is that util-linux-umount does not even ship in my image
Dec 11 14:31:12 <eduardas_m> for which the SDK is generated
Dec 11 14:31:12 <fmns> eduardas_m, do you use update-alternatives with toybox?
Dec 11 14:31:22 <eduardas_m> fmns: yes
Dec 11 14:31:33 <rburton> tgoodwin: i'd like to see DEPENDS have a way of having version restrictions, but we can't do that right now
Dec 11 14:31:33 <eduardas_m> fmns: but perhaps not properly
Dec 11 14:31:43 <rburton> tgoodwin: i'd be happy with it throwing an error if the version didn't match
Dec 11 14:31:51 <fmns> could you provide more context?
Dec 11 14:32:17 <rburton> tgoodwin: if there's a preferred version for the recipe you're depending on you could check that in the recipe with some anon py and raise an exception if the version is wrong
Dec 11 14:32:19 <tgoodwin> rburton: Something like DEPENDS = "package-a_1.2"
Dec 11 14:32:47 <rburton> tgoodwin: well iirc DEPENDS = " foo (>1.2)" is already parsed, but ignored
Dec 11 14:32:56 <tgoodwin> (I realize that's probably not bitbakeable)
Dec 11 14:33:00 <eduardas_m> fmns: here is my toybox recipe: https://pastebin.com/1LRQQg8u
Dec 11 14:33:04 <tgoodwin> Interesting.
Dec 11 14:33:05 <rburton> same format as rdepends
Dec 11 14:35:42 <tgoodwin> Alright, thanks.
Dec 11 14:35:43 <Piraty> does yocto use ccache?
Dec 11 14:35:48 <rburton> Piraty: can do
Dec 11 14:35:59 <Piraty> thank god
Dec 11 14:36:14 <rburton> Piraty: but we have a higher level caching which means typically its not needed
Dec 11 14:36:24 <Piraty> you mean packages
Dec 11 14:36:29 <rburton> i mean sstate
Dec 11 14:36:39 <Piraty> have yet to look into that
Dec 11 14:36:44 <fmns> sstate >> ccache
Dec 11 14:37:00 <Piraty> but i doubt you have a mechanism spying into the build process of an upstream makefile
Dec 11 14:37:13 <rburton> ccache says "you want to compile foo.c with these flags, here's a binary you can have"
Dec 11 14:37:15 <Piraty> or even autohell products
Dec 11 14:37:22 <Piraty> i know what it does
Dec 11 14:37:29 <rburton> sstate says "you want to build a recipe with these sources/flags/patches, here's the resulting packages"
Dec 11 14:37:44 <Piraty> i understand
Dec 11 14:38:04 <Piraty> big software that only changes on little parts (say: a patch) would still not benefit from that
Dec 11 14:38:21 <rburton> sure, ccache is useful if you've a huge package with you're iterating on
Dec 11 14:38:24 <Piraty> and i have to rebuild everything, if ccache isn't in option. but i'm glad it is
Dec 11 14:38:41 <Piraty> thanks you rburton
Dec 11 14:39:10 <tgoodwin> rburton: is there a mechanism, from a conf file, that would dynamically enforce package versions?  For example, a layer has two versions of package A, which has a pile of dependencies with different version requirements for each version A.  Would the anonymous python function route "work" in that sense to inject PREFERRED_VERSIONs?  Seems like the evaluation of those new preferred version references would be "too late" to
Dec 11 14:39:10 <tgoodwin> get picked up.
Dec 11 14:39:41 <rburton> tgoodwin: i'd use anon py to abort the build early if the versions don't work
Dec 11 14:39:51 <tgoodwin> alright
Dec 11 14:50:46 <eduardas_m> rburton: how to fix update-alternatives conflict for SDK generation? https://pastebin.com/26tgB5Yb
Dec 11 14:57:58 <eduardas_m> rburton: I am using thud branch as it is, as far as I know this still does not contain this: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=f00b998ef2403cefb0515258a87f14ad687d2325
Dec 11 14:58:04 <eduardas_m> can this be related?
Dec 11 15:17:10 <didile> Hi there!
Dec 11 15:17:23 <didile> I've an issue at first boot with busybox
Dec 11 15:17:28 <didile> "update-alternatives: Error: not linking /sbin/klogd to /bin/busybox.nosuid since /sbin/klogd exists and is not a link"
Dec 11 15:18:08 <eduardas_m> didile: seems like some other package in the image ships a klogd binary
Dec 11 15:21:36 <didile_> eduardas_m: this issue happen in poky sumo
Dec 11 15:21:56 <didile_> http://lists.openembedded.org/pipermail/openembedded-core/2018-August/155009.html
Dec 11 15:23:02 <eduardas_m> didile_: so this fix is not yet in sumo?
Dec 11 15:24:03 <didile_> eduardas_m: nop
Dec 11 15:25:01 <didile_> I don't think you can make poky sumo fully work as it is
Dec 11 15:25:26 <didile_> I also have a warning at do_rootfs
Dec 11 15:25:43 <didile_> "do_rootfs: Intentionally failing postinstall scriptlets of ['busybox'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} (). If deferring to first boot wasn't the intent, then scriptlet failure may mean an issue in the recipe, or a regression elsewhere."
Dec 11 15:26:15 <didile_> the busybox recipe seems broken
Dec 11 15:28:18 <eduardas_m> didile_: seems there is some related busybox patch: http://lists.openembedded.org/pipermail/openembedded-core/2018-August/273469.html
Dec 11 15:28:56 <didile_> eduardas_m: this is the same patch
Dec 11 15:29:20 <didile_> from a different topic
Dec 11 15:30:29 <didile_> *a different page of the mailinglist
Dec 11 15:34:02 <didile_> I don't explicitly add klogd so to me this is a universal issue with poky sumo
Dec 11 15:35:23 <didile_> the patch works however
Dec 11 15:38:14 <didile_> I don't have the rights to do a pull request
Dec 11 15:39:45 <eduardas_m> didile_: if you read carefully, I think Chen Qi says he has sent out another patch
Dec 11 15:39:56 <eduardas_m> that is not directly linked in the post
Dec 11 15:40:19 <eduardas_m> didile_: he says "Khem, I've sent out a patch to fix busybox's alternatives logic"
Dec 11 15:40:31 <eduardas_m> so that might not have been the final fix
Dec 11 15:40:33 <didile_> eduardas_m: yes
Dec 11 15:40:48 <didile_> eduardas_m: but nobody responded since then...
Dec 11 15:41:57 <eduardas_m> didile_: I think the fix in master is this: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=705bb5e8479b814efc2970b79f8709b4364f189d
Dec 11 15:43:37 <didile_> eduardas_m: I see...
Dec 11 15:45:33 <eduardas_m> didile_: commit seems to be on thud branch, but not in sumo
Dec 11 15:46:17 <didile_> sumo needs it too
Dec 11 15:47:32 <didile_> definitely
Dec 11 15:49:09 <eduardas_m> rburton: I am not sure who is responsible for sumo branch maintenance, but could you look at https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=705bb5e8479b814efc2970b79f8709b4364f189d
Dec 11 15:49:20 <rburton> eduardas_m: not me, you want armpit
Dec 11 15:49:59 <eduardas_m> rburton: ok, thank you
Dec 11 15:50:33 <didile_> rburton: do_rootfs is doing its job
Dec 11 15:50:38 <eduardas_m> armpit: hello, could you look at backporting this to sumo: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=705bb5e8479b814efc2970b79f8709b4364f189d
Dec 11 15:50:39 <didile_> ...
Dec 11 15:51:17 <eduardas_m> armpit: I believe it would fix the problem that didile_ has encountered
Dec 11 15:52:39 <didile_> eduardas_m: it does
Dec 11 15:52:54 <armpit> got.. thanks..
Dec 11 15:56:49 <didile_> what's the diff between sumo and thud today?
Dec 11 15:57:03 <didile_> is thud a stable branch?
Dec 11 15:57:14 <didile_> or rocko?
Dec 11 15:57:18 <rburton> both are
Dec 11 15:57:19 <armpit> both are.. sumo is 2.5 release, thud is 2.6
Dec 11 15:57:37 <rburton> https://wiki.yoctoproject.org/wiki/Releases
Dec 11 15:57:38 <didile_> ok
Dec 11 15:57:45 <nacknick> is there any way to prevent yocto from stripping linux built-in binaries?
Dec 11 15:58:00 <didile_> thanks :)
Dec 11 15:58:17 <rburton> nacknick: what do you mean by linux built-in?
Dec 11 15:58:54 * armpit starts 2 full builds
Dec 11 15:59:06 <rburton> nacknick: also, whatever is stripped goes into the -dbg package, so you still have symbols available if you install that package
Dec 11 16:01:25 <nacknick> rburton: thanks
Dec 11 16:13:28 <nacknick> for my script, I need the full  path of the generated binary (under build/tmp/), what variable saves that path inside .bb file?
Dec 11 16:17:20 <fmns> nacknick, I think you want to add a deploy task to deploy a binary next to images or add a new task
Dec 11 16:21:24 <nacknick> fmns I want to add a 'curl' command inside 'do_install' function and I need to specify the binary's full path
Dec 11 16:21:57 <fmns> urgs. why not adding it to SRC_URI?
Dec 11 16:22:14 <nacknick> adding what?
Dec 11 16:22:26 <fmns> the file you want to download
Dec 11 16:22:44 <kergoth> nacknick: you sohuld not be doing anything with curl in do_install. the only network connections should be done in do_fetch
Dec 11 16:23:06 <fmns> ack
Dec 11 16:23:08 <pepijndevos> The gstreamer plugin problem is still unresolved... but I've given up for today. I updated all the other repos too, let it build for a few hours... still the same.
Dec 11 16:23:32 <nacknick> I don't want to download it. I want to modify an existing binary
Dec 11 16:23:55 <nacknick> kergoth, ok. when do_fetch runs? after do_install?
Dec 11 16:24:07 <kergoth> no
Dec 11 16:24:22 <nacknick> after make?
Dec 11 16:24:29 <nacknick> I need ready binary
Dec 11 16:24:29 <kergoth> i have no clue what you're trying to do
Dec 11 16:24:36 <kergoth> why would you run curl to modify a binary?
Dec 11 16:24:51 <kergoth> again, if you want to download something, add it to SRC_URI and let do_fetch download it for you
Dec 11 16:24:56 <kergoth> as fmns indicated
Dec 11 16:25:16 <kergoth> otherwise it breaks numerous expectations of the system, and will make it impossible to do builds without network connectivity
Dec 11 16:26:57 <rburton> nacknick: in do_install, binaries are expected to be installed under $D
Dec 11 16:30:15 <yates_home> is there a recipe/package that pulls in the normal development packages all at once, like gcc, g++, make, etc?
Dec 11 16:30:28 <yates_home> is packagegroup-core-buildessential?
Dec 11 16:30:31 <nacknick> kergoth, I have a server that get the binary and returns modified one which I want to replace with the original one
Dec 11 16:30:49 <rburton> yates_home: in an image?
Dec 11 16:30:49 <nacknick> I send the binary to the server with curl
Dec 11 16:30:57 <kergoth> again, add the url to SRC_URI, let do_fetch download it, and install it to the right place in do_install
Dec 11 16:31:17 <yates_home> rburton: no, a package i can "smart install"
Dec 11 16:31:26 <RP> sounds like some kind of signing server?
Dec 11 16:31:28 <rburton> yates_home: buildessential is probably i
Dec 11 16:31:42 <yates_home> right
Dec 11 16:31:59 <nacknick> kergoth, but SRC_URI is defined before running bitbake...
Dec 11 16:32:21 <kergoth> ahh, interesting. that's not ideal
Dec 11 16:32:30 <rburton> yates_home: the tools-sdk image feature uses packagegroup-core-sdk
Dec 11 16:32:45 <nacknick> kergoth, I'm glad you understand at least
Dec 11 16:32:58 <rburton> nacknick: $D is the path you're after
Dec 11 16:33:10 <yates_home> ok, thanks
Dec 11 16:33:10 <rburton> assuming you're running as part of do_install
Dec 11 16:33:23 <rburton> *if* this is a signing server then you'll want to generalise a lot more
Dec 11 16:33:50 <rburton> and we can help with that, which is why its best to explain what you're trying to d
Dec 11 16:41:08 <fmns> kergoth, do you think it would be costly to replace dict(), set() by ordered versions in lib/bb/data.py to get binary reproducable output from pickle?
Dec 11 16:48:08 <nacknick> rburton / kergoth: as I wrote, I have a server which modifies the binary (add a protection code to the original binary). you send a post request to the server with the binary in its content and you get in response a modified one. all I need to do is to send the binary to the server and replace the original with the one I get from the server
Dec 11 16:48:52 <kergoth> the files are in ${D}, modify it there
Dec 11 16:49:13 <kergoth> ideally you'd use a bbclass for this which is generic, metadata controlled, and could be disabled if necessary
Dec 11 16:50:24 <nacknick> kergoth, as you can guess, I'm pretty new in yocto, I'll appreciate references because I have no idea what's it 'bbclass'
Dec 11 16:51:53 <fmns> I think the binaries from PKGD should be used because it's after usual post processing
Dec 11 16:55:51 <nacknick> fmns what do you mean please?
Dec 11 16:56:13 <fmns> bbclass files are bitbake's way of extending functionality in multiple recipes
Dec 11 17:03:37 <fmns> nacknick, I think you need to create a class to add a function at the end of PACKAGEBUILDPKGD
Dec 11 17:09:11 <kergoth> to clarify, you certainly *can* do it directly in do_install, and that'd work for now, but it'd be ideal to use a bbclass for easier usage and maintenance in the long term, rather than copying and pasting fragments around
Dec 11 17:09:31 <kergoth> fmns is right though, packaging will modify the binaries, so you should sign after that
Dec 11 17:09:40 <kergoth> or disable stripping/splitting/etc
Dec 11 17:15:55 <fsdun> tada
Dec 11 17:17:36 <nacknick> kergoth / fsdun: if I use bbclass, can I choose which packages I want to apply my modification on, or it applies on all packages?
Dec 11 17:18:33 <fsdun> you can selectivliy inherit in a recipe or INHERIT in all recipes
Dec 11 17:19:34 <nacknick> fsdun. ok. sounds interesting
Dec 11 17:19:40 <fsdun> mostly likely you want to extend KERNEL_CLASSES
Dec 11 17:20:06 <fsdun> because you'd talk about kernel before IIRC
Dec 11 17:59:49 <tgoodwin> Has anyone run into this in rocko:  you rebuild your work environment from an sstate-cache only to find that some packages in your recipe "PACKAGES += ..." did not get populated
Dec 11 18:04:09 <Piraty> format c:
Dec 11 18:04:16 <Piraty> oops wrong window
Dec 11 18:16:24 <rburton> tgoodwin: never seen that
Dec 11 18:16:50 <tgoodwin> Weird.  Even after a rebuild, I get "nothing provides package-a-python" which is in my package-a recipe as PACKAGES += "package-a-devel"
Dec 11 18:17:11 <tgoodwin> sorry, package-a-python (in the packages list)
Dec 11 18:18:12 <tgoodwin> Ah... the package is empty
Dec 11 18:20:18 <Crofton> the awful hack is ALLOW_EMPTY sometimes
Dec 11 19:07:34 <yates_home> i'm trying to build and use the soci recipe for on-target development. in addition to the core soci package, there are a number of soci "backends" which can be used such as sqlite4, mysql, odbc, etc, but the recipe apparently only builds the pseud-backend "empty"
Dec 11 19:07:41 <yates_home> https://paste.fedoraproject.org/paste/DpK2643Uy2ZWuP~ObkK4ug
Dec 11 19:08:20 <yates_home> is there a way to bitbake that recipe but override the PACKAGECONFIG to use one of the other backends, such as "odbc"?
Dec 11 19:08:33 <yates_home> without changing the recipe?
Dec 11 19:08:46 <yates_home> which is in sources/meta-openembedded/meta-oe/recipes-support/soci/
Dec 11 19:10:23 <yates_home> i mean, what's the best way to do this/
Dec 11 19:10:25 <yates_home> ?
Dec 11 19:10:49 <yates_home> i can think of a couple of ways, but they seem like hacks..
Dec 11 19:12:48 <yates_home> on fedora/dnf/rpm, these backends come as separate packages.
Dec 11 19:13:45 <yates_home> am i missing something? like, are these already being built somehow somewhere?
Dec 11 19:20:30 <yates_home> via .bbappend?
Dec 11 19:42:06 <yates_home> yates_home: yes, via .bbappend
Dec 11 20:00:30 <yates_home> quiet around here...
Dec 11 20:02:42 <bluelightning> yates_home: sorry, I didn't see the earlier part of the discussion, otherwise I'd probably be responding
Dec 11 21:13:53 <rburton> yates_home: bbappend or from distro config eg PACKAGECONFIG_pn-soci = "sqlite"
Dec 11 21:14:46 <rburton> there's a big bit in the docs about this with plenty of worked examples
Dec 11 21:16:00 <kergoth> i like to use _append and _remove with an indirection rather than explicitly setting the value, that way changes to the default config won't be lost as  upstream layers are updated, myself
Dec 11 21:39:26 <derRichard> how does yocto learn dependencies for packages?
Dec 11 21:39:30 <derRichard> i'm facing this:
Dec 11 21:39:31 <derRichard> ERROR: regina-rexx-3.3-r0 do_package_qa: QA Issue: /usr/share/dateconv.rexx contained in package regina-rexx requires /scratch/rw/xxx/build/tmp/work/i586-poky-linux/regina-rexx/3.3-r0/image/usr/bin/rexx, but no providers found in RDEPENDS_regina-rexx? [file-rdeps]
Dec 11 21:40:04 <derRichard> the problem is that the requires path contains the sysroot prefix. it should be just /usr/bin/rexx
Dec 11 21:45:29 <peniwize> I’m using the meta-intel layer, which has a .conf file that contains:
Dec 11 21:45:29 <peniwize> SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1 115200;ttyS2"
Dec 11 21:45:29 <peniwize> I need to disable all boot loader serial consoles so I assume that I need to set SERIAL_CONSOLES to nothing and I’m not sure where to do it.  Can I simply set SERIAL_CONSOLES in one of my recipes or do I need to do it in my local.conf?  Is it possible to override the BSP’s conf file like you can override a recipe with an append file?  What is the correct way to do this?
Dec 11 21:46:38 <kergoth> derRichard: sounds like you need to fix dateconv to no longer hardcode the full absolute reference to rexx
Dec 11 21:48:39 <rburton> derRichard: what kergoth said, that's a bug in regina-rexx
Dec 11 21:48:53 <rburton> peniwize: your local.conf or distro conf
Dec 11 21:49:23 <peniwize> rburton: thanks
Dec 11 21:52:34 <derRichard> kergoth: i don't understand how yocto find out. does it read /usr/share/dateconv.rexx?
Dec 11 21:52:59 <rburton> no, it reads the file in the package staging directory that corresponds to /usr/share/dateconv.rexx
Dec 11 21:53:24 <rburton> so for you /scratch/rw/xxx/build/tmp/work/i586-poky-linux/regina-rexx/3.3-r0/packages-split/regina-rexx/usr/share/dateconv.rexx
Dec 11 21:53:51 <rburton> doesn't show you the full path as it's not useful, it's telling you what file in what package
Dec 11 21:55:30 <derRichard> hmmm
Dec 11 21:55:32 <derRichard> tricky
Dec 11 21:55:58 <rburton> its foolishly inserting a build path instead of a target path
Dec 11 21:56:14 <rburton> genuine upstream bug, you just need to figure out how to fix it
Dec 11 21:56:42 <derRichard> yeah, regina-rexx is "interesting"
Dec 11 21:56:44 <rburton> good news is that if other distros like debian have packaged this, they'll most likely have fixed it already
Dec 11 21:57:00 <derRichard> it used to be in openembedded: http://cgit.openembedded.org/openembedded/tree/recipes/regina-rexx/regina-rexx_3.3.bb
Dec 11 21:58:53 <yocti> New news from stackoverflow: Is it possible to use Embedded OS prepared for i.MX6solo over i.MX6UL...? [closed] <https://stackoverflow.com/questions/53638232/is-it-possible-to-use-embedded-os-prepared-for-i-mx6solo-over-i-mx6ul>
Dec 11 22:21:03 <derRichard> ./configure: line 4690: MH_CHECK__SIGHANDLER_T: command not found
Dec 11 22:21:15 * derRichard never saw such odd errors (autoconf)
Dec 11 22:23:46 <RP> derRichard: it can do much worse, trust me ;-)
Dec 11 22:24:08 <neverpanic> derRichard: Looks like an unexpanded macro after running autoreconf
Dec 11 22:24:10 <derRichard> RP: yes. for sure
Dec 11 22:24:20 <neverpanic> maybe a missing dependency?
Dec 11 22:24:50 <derRichard> well, i don't run autoreconf. just "./configure ...". on my host it works. in yocto it explodes with the said error
Dec 11 22:24:57 <neverpanic> yocto runs autoreconf
Dec 11 22:25:25 <derRichard> i'm in devshell
Dec 11 22:25:47 <derRichard> and disabled autoreconf with:
Dec 11 22:25:48 <derRichard> do_configure() {
Dec 11 22:25:49 <derRichard>         oe_runconf
Dec 11 22:25:49 <derRichard> }
Dec 11 22:26:02 <derRichard> the package sucks, and autoreconf does not work
Dec 11 22:26:15 <neverpanic> it seems to already have done it then, because your ./configure looks broken. Unless the configure script shipped in the tarball is already broken.
Dec 11 22:26:29 <RP> derRichard: usually, its easier to make it autoreconf
Dec 11 22:26:49 <derRichard> RP: i fear you are right
Dec 11 22:26:50 <RP> it does look rather like an unexpanded macro
Dec 11 22:30:46 <rburton> https://fossies.org/linux/Regina-REXX/aclocal.m4
Dec 11 22:30:52 <rburton> it doesn't use aclocal
Dec 11 22:30:56 <derRichard> RP: maybe you can point me in the right direction? http://paste.debian.net/plain/1055423
Dec 11 22:30:58 <rburton> RP: remember i was moaning about this ;)
Dec 11 22:31:10 <rburton> derRichard: EXTRA_AUTORECONF += "--exclude=aclocal"
Dec 11 22:31:33 <rburton> that might make it autoreconf
Dec 11 22:31:44 <rburton> if it doesn't then it does sound like you just need to clean and rebuild it
Dec 11 22:32:10 <rburton> (if you try the extra autoreconf thing remember to remove your do_configure)
Dec 11 22:32:55 <derRichard> sure
Dec 11 22:33:17 <derRichard> sadly --exclude=aclocal does not change things
Dec 11 22:33:39 <rburton> same error?
Dec 11 22:33:43 <derRichard> yes
Dec 11 22:33:47 <rburton> oh, clean it first
Dec 11 22:33:55 <rburton> you'd have messed up the tree already
Dec 11 22:33:56 <derRichard> so did i.
Dec 11 22:34:05 <derRichard> i did a bitbake -c cleanall ...
Dec 11 22:34:18 <rburton> well, bitbake [recipe] -C unpack is a easy way to force a build from scratch for a specific recipe
Dec 11 22:34:22 <derRichard> then -c devshell again and ran autoreconf --exclude=aclocal
Dec 11 22:34:28 <rburton> oh, don't do it in a devshell
Dec 11 22:34:41 <rburton> you'll forget the arguments you need to pass
Dec 11 22:34:56 <derRichard> ok, give me a second
Dec 11 22:35:23 <rburton> or, hope the configure works, leave your do_configure in and run from clean, that should work as that's definitely an undefined macro error which *is* defined in their tree
Dec 11 22:35:29 <derRichard> i set now EXTRA_AUTORECONF and removed the do_configure hook
Dec 11 22:36:28 <derRichard> hm, same error (now bitbake ran autoreconf with all the parameters needed)
Dec 11 22:37:11 <rburton> tbh if its a known crazy upstream, i'd start by making that old oe recipe work and then upgrade it
Dec 11 22:37:26 <rburton> i suspect you want to change autotools to autotools-brokensep
Dec 11 22:37:35 <derRichard> did that already :)
Dec 11 22:37:38 <rburton> oh the pastebin has different errors
Dec 11 22:37:46 <rburton> thats autoheader, add --exclude=autoheader too
Dec 11 22:38:59 <derRichard> wow, it configured. how did you know that --exclude=autoheader is needed?
Dec 11 22:39:15 <derRichard> i have to admit that my autotools fu is weak
Dec 11 22:39:18 <rburton> because the error log you pastebined was entirely autoheader going ARGH PANIC
Dec 11 22:39:25 <rburton> which suggests that they don't use autoheader
Dec 11 22:40:01 <rburton> sounds like a very old school configure script so you're lucky it configured at all
Dec 11 22:40:12 <derRichard> hehe, ok
Dec 11 22:40:19 <rburton> the old recipe says clearly  that they disable autoreconf because its so archaic
Dec 11 22:40:22 <derRichard> i wonder why configure works fine on my host system
Dec 11 22:40:31 <rburton> because then you're running the configure they generated
Dec 11 22:40:54 <rburton> would most likely work in oe too, the recipe in oe-classic did exactly that
Dec 11 22:40:55 <derRichard> true, but the same configure does not work in yocto
Dec 11 22:41:06 <derRichard> 23:21 < derRichard> ./configure: line 4690: MH_CHECK__SIGHANDLER_T: command not found
Dec 11 22:41:16 <rburton> yes
Dec 11 22:41:25 <rburton> [22:33:47]  <rburton>	oh, clean it first
Dec 11 22:41:26 <derRichard> i get this when i try to run the configure script as-is in yocto (with autoreconf disabled)
Dec 11 22:41:31 <derRichard> i did that :)
Dec 11 22:42:02 <rburton> are you positive? because autotools.bbclass has some code to delete aclocal.m4 which is most likely the cause
Dec 11 22:42:10 <rburton> anyway, configures now, and properly
Dec 11 22:42:10 <rburton> so thats good
Dec 11 22:42:23 <rburton> now back to watching my government explode
Dec 11 22:43:31 <kergoth> derRichard: either that was defined in aclocal as rburton indicates, or it's provided by a dependency that you don't have in DEPENDS
Dec 11 22:43:55 <kergoth> best to check into it outside of yocto in a freshly unpacked tarball, or clean and re-run unpack/patch and examine that
Dec 11 22:44:19 <kergoth> if you disabled autoreconf but didn't clean the recipe, it's possible it didn't re-unpack the sources to resotre the already-removed aclocal
Dec 11 22:44:25 <kergoth> so i'd clean and rebuild the recipe to start
Dec 11 22:44:54 <derRichard> kergoth: thanks a lot for the hint! makes sense
Dec 11 22:45:21 <kergoth> bitbake detects variable cahnges to re-run the changed tasks, but just re-executing the task doesn't always undo what previous runs did, if that makes sense
Dec 11 22:46:11 * ant_home sees Gentoo has a recipe for 3.9.1 and uses eautoconf... plain, no patches
Dec 11 22:48:24 <derRichard> ant_home: yeah, suse also uses the configure as-is
Dec 11 22:48:34 <ant_home> try to update
Dec 11 22:48:59 <derRichard> this is 3.9.1
Dec 11 22:49:24 <ant_home> ok, I've read a 3.3 before, my bad
Dec 11 22:51:35 <kergoth> most distros do, but most distros don't need to cross-compile either. we've had to change a number of macros, which means configure needs to be regenerated to include the changes
Dec 11 22:51:37 <derRichard> yeah 3.3 was the old version
Dec 11 22:52:09 <derRichard> kergoth: one thing i don't fully understand. why do you need to autoreconf?
Dec 11 22:52:25 <kergoth> i just told you
Dec 11 22:53:13 <derRichard> ahh, now it makes sense
Dec 11 22:53:20 <kergoth> we've changed macros, configure needs to be regenerated using them, which means autoconf needs to be re-run, and we need to re-run aclocal to ensure the updated macros from the other recipes make it into aclocal.m4 to be used by autoconf
Dec 11 22:53:37 <kergoth> automake, etc are done too as a matter of course, less critical though
Dec 11 22:53:44 <derRichard> i didn't realize that you changed autoconf that deeply
Dec 11 22:54:27 <kergoth> libtool sucks, every libtool-using project includes th elibtool macros and ltmain.sh, and we've had to change both to ensure the generated libtool script is functional in a cross-compilation environment
Dec 11 22:54:43 <kergoth> and most projects using autoconf+automake also use libtool, so that's a required autoreconf by most recipes there alone
Dec 11 22:54:50 <kergoth> and then we've had to change some other macros as well along the way
Dec 11 22:56:18 <derRichard> what a pain ;-\
Dec 11 23:02:03 <kergoth> that's cross-compilation for you
Dec 11 23:02:09 <kergoth> a pain all around, in every way
Dec 11 23:03:21 <derRichard> a few years ago i wrote a tool go generate a distro from scratch (cross arm and mips). it was a super pain. but i never had to mess with libtool and autoreconf
Dec 11 23:03:34 <derRichard> maybe because the set of packages i used as minimal :-)
Dec 11 23:08:25 <RP> derRichard: we really need to sort our libtool patches out with upstream. We just never get around to it and it will be painful
Dec 11 23:11:14 <derRichard> RP: these? https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-devtools/libtool/libtool/
Dec 11 23:13:30 <RP> derRichard: yes
Dec 11 23:26:48 <rburton> RP: qa series resent (and in ross/qa)
**** ENDING LOGGING AT Wed Dec 12 03:00:00 2018