**** BEGIN LOGGING AT Thu Jul 25 02:59:57 2019
Jul 25 08:41:03 <yocti> New news from stackoverflow: yocto: rebuild part of project <https://stackoverflow.com/questions/36452798/yocto-rebuild-part-of-project>
Jul 25 09:57:02 <kayterina> I sent emails from an rpi using ssmtp. To sent attachments,which package are you using?
Jul 25 09:57:11 <kayterina> *recipe
Jul 25 10:09:15 <leitao> Is it possible to define a set of files in the header of a .bb file that I could reuse to include them in the SRC_URI and to compile do_compile()? Something as:
Jul 25 10:10:03 <leitao> files = "a.c b.c", then I can use $files to include in SRC_URI and as a parameter to the compiler?
Jul 25 10:18:53 <rburton> yes
Jul 25 10:19:03 <rburton> but files in SRC_URI are URIs
Jul 25 10:19:22 <rburton> put the sources in a standalone git repo, with a proper makefile
Jul 25 10:19:49 <rburton> then SRC_URI is just a git url, do_compile is just make, and you can build the sources outside of yocto
Jul 25 10:25:50 <leitao> right
Jul 25 11:25:26 <tgoodwin> RP: Thanks.  Do you know if anyone has written tooling to help tie the editing of the helper json files to the builds described in the autobuilder config?
Jul 25 11:35:33 <RP> tgoodwin: I don't know of any
Jul 25 11:37:38 <tgoodwin> Best I can gather, the helper JSON file(s) map to the builds defined in the controller's config.  So to actually add a build, it goes beyond what that provided .patch file shows since one would also have to describe the steps of the build over in the JSON, is that right?
Jul 25 11:40:23 <RP> tgoodwin: the controller specifies the names of potential build targets. The details of the configurations in those builds is all contained in the helper
Jul 25 11:40:55 <RP> tgoodwin: I wish it were possible to totally abstract the two but that isn't possible :(
Jul 25 11:42:14 <tgoodwin> RP: no worries; I'm looking to stand it up inside an organization for a more limited set of builds and workers.
Jul 25 11:42:41 <tgoodwin> I'm considering putting my workers in docker containers since it's all running on one large server.
Jul 25 11:49:13 <RP> tgoodwin: there is no issue running workers and controller on the same machine natively fwiw, I do that for testing
Jul 25 11:53:18 <tgoodwin> I was thinking more to represent the types of developer machines we have in the office (Ubuntu 16, 18 and CentOS 7) since we have on rare occasions had builds work on Ubuntu but not CentOS and vice versa (usually a permitted host tool version issue)
Jul 25 11:57:44 <tgoodwin> If I were to run the worker natively, would the shared state still be usable by developers on different OSs?
Jul 25 12:11:38 <yocti> New news from stackoverflow: Run apt inside a bitbake recipe <https://stackoverflow.com/questions/57201571/run-apt-inside-a-bitbake-recipe>
Jul 25 12:13:41 <tgoodwin> RP: Do you happen to know how much space a world build would consume?
Jul 25 12:13:58 <tgoodwin> roughly
Jul 25 12:35:36 <rburton> tgoodwin: use rm_work and its a *lot* less
Jul 25 12:36:09 <rburton> note that its entirely worth blacklisting webkit if you won't be using it, as it's *huge*
Jul 25 12:45:29 <RP> tgoodwin: I have no idea offhand
Jul 25 12:52:31 <tgoodwin> rburton: thanks very good to know about webkit.  I was just attempting a build in RAM with 50G and ran out of space.
Jul 25 12:56:06 <kayterina> how to install conf files in yocto? which recipe to bbappend for  /etc/ssmtp/ssmtp.conf?
Jul 25 13:41:50 <yocti> New news from stackoverflow: Emulate/virtualize embedded i586 Linux gateway <https://stackoverflow.com/questions/57203371/emulate-virtualize-embedded-i586-linux-gateway>
Jul 25 14:12:34 <kergoth> kayterina: recipetool makes that much easier. see recipetool appendfile.
Jul 25 14:13:33 <kayterina> kergoth: a,ok,i'll check it out.thank you.
Jul 25 14:20:08 <rburton> tgoodwin: rm_work is essential for ram builds
Jul 25 14:20:32 <rburton> tgoodwin: (i do tmpfs+rm_work builds, no webkit, in a 32gb tmpfs)
Jul 25 14:22:24 <tgoodwin> rburton: good to know -- thanks! That's a much lower bar than I expected.
Jul 25 14:26:04 <rburton> tgoodwin: its only webkit or llvm that causes problems for me
Jul 25 14:45:15 <Dvorkin> Can't find -latomic while building nodejs with origin/warrior https://pastebin.com/Vj832sGd
Jul 25 14:52:19 <tgoodwin> The one i'm having trouble with is bpftool (thud, 2.6.2) because bpf doesn't exist in the kernel-source/tools path.
Jul 25 15:54:36 <rburton> adelcast: around?
Jul 25 15:55:14 <adelcast> yep, I am here, morning
Jul 25 15:55:19 <rburton> morning
Jul 25 15:55:29 <rburton> was just looking at reproducible builds
Jul 25 15:55:43 <rburton> and how you reverted the change to mtime the data in the ipk
Jul 25 15:55:54 <rburton> wouldn't tar --clamp-time solve that problem?
Jul 25 15:56:11 <adelcast> lemme get some context...
Jul 25 15:56:36 <rburton> 86b2dc4c9cc0b40e79d0bb049b98532285942b25 opkg-utils
Jul 25 15:56:47 <rburton> and https://reproducible-builds.org/docs/archives/
Jul 25 16:00:42 <adelcast> from my reading of what -clamp-mtime does, seems like it might
Jul 25 16:00:55 <rburton> only in newer tars though, of course
Jul 25 16:01:32 <rburton> you could set those options only if repo builds are requested via SOURCE_DATE_EPOCH and just make it a requirement
Jul 25 16:03:08 <adelcast> that would work, need to try it out but sounds like it should work
Jul 25 16:03:49 <adelcast> could you open a bugzilla ticket for opkg? I can fix it on this release, likely next week, just want to make sure I don't lose the details between now and then
Jul 25 16:04:00 <rburton> sure
Jul 25 16:04:44 <adelcast> thanks!, btw, I got budget to go to the Open Source Summit in San Diego this year, so I'll probably catch up with you'all there
Jul 25 16:04:55 * rburton grumbles about no travel budget
Jul 25 16:05:20 <adelcast> hehe, my trick is to over-budget, so when the cuts come, I still have a bit
Jul 25 16:10:51 <tgoodwin> rburton: is there a way to blacklist something that's in a package group?  I'm doing a 'world' build with meta-oe and meta-xilinx which is dying since the linux-xlnx doesn't have the bpftool source.
Jul 25 16:11:07 <tgoodwin> The only thing I could think of doing was an RDEPENDS override for the package group.
Jul 25 16:12:19 <rburton> yeah, that.  theres plenty of prior art in oe-core of machine-specific depends being overridden in or out of excitance
Jul 25 16:12:35 <rburton> a bbappend can knock it out for example
Jul 25 16:13:14 <tgoodwin> cool, thanks
Jul 25 16:16:52 <Dvorkin> Can't find -latomic while building nodejs with origin/warrior https://pastebin.com/Vj832sGd
Jul 25 16:20:59 <Dvorkin> as far as I can see, libatomic is in the gcc-runtime package. how to add dependency for nodejs-native with .bbappend correctly?
Jul 25 16:24:14 <rburton> Dvorkin: thats native, so it can't find libatomic on your build host
Jul 25 16:25:07 <Dvorkin> rburton, yes, I have no. is it possible to build it for enviroment by dependency?
Jul 25 16:25:43 <rburton> Dvorkin: we assume you've a working compiler
Jul 25 16:25:57 <rburton> its part of gcc, as you say
Jul 25 16:26:30 <Dvorkin> so I just need to install it?
Jul 25 16:28:30 <rburton> yes
Jul 25 16:29:47 <Dvorkin> I see. But what about including it into sdk and moving to another PC? do that PC need to have libatomic too ?
Jul 25 16:30:22 <rburton> well either the node build is quite broken, or you've somehow installed half of gcc
Jul 25 16:32:00 <rburton> in debian for example, its impossible to install gcc without libatomic
Jul 25 16:33:44 <Dvorkin> I have gcc 5.5 at my pc and libatomic is not included into gcc package
Jul 25 16:33:54 <Dvorkin> it is Mageia distribution
Jul 25 16:34:14 <Dvorkin> maybe it have to be documented somewhere in "requirements"
Jul 25 16:37:58 <rburton> gcc 5? ouch
Jul 25 16:39:31 <rburton> mageia 6 i presume
Jul 25 16:39:54 <Dvorkin> rburton, correct :)
Jul 25 16:40:36 <rburton> part of libatomic-devel, one of the packages built by gcc
Jul 25 16:41:00 <Dvorkin> already installed and continue to build.
Jul 25 16:42:20 <Dvorkin> I have another question. Why I may have /usr/lib/node -> /usr/lib/node_modules/ in my yocto build? when building several node modules yocto says, dir node/ is already exist in other package...
Jul 25 17:42:32 <yocti> New news from stackoverflow: do_compile: oe_runmake failed and do_compile: Function failed: do_compile error while building yocto project <https://stackoverflow.com/questions/52983127/do-compile-oe-runmake-failed-and-do-compile-function-failed-do-compile-error>
Jul 25 17:54:35 <rburton_> JPEW: is there a reason the reproducible selftest uses reproducible_build and not _simple?
Jul 25 17:55:02 <rburton_> JPEW: (subtext: _simple works more as its less clever, specifically ca-certificates isn't reproducible without _simple)
Jul 25 17:59:07 <JPEW> rburton_: My understanding is that you shouldn't ever use reproducible_build_simple directly.... reproducible_build inherits if if BUILD_REPRODUCIBLE_BINARIES is set
Jul 25 18:01:00 <JPEW> I'm not sure why exactly it's split up like that.... perhaps so setting BUILD_REPRODUCILE_BINARIES to "0" won't change taskhashes even if reproducible_build is inherited?
Jul 25 18:15:29 <rburton_> i thought reproducible_build was all logic to pick a epoch magically, whereas simple is just 'give me a date'
Jul 25 18:17:49 <rburton_> (logic which fails with ca-certs)
Jul 25 18:24:12 <JPEW> rburton_: J/s, I'm trying to find my notes
Jul 25 18:35:58 <JPEW> rburton_: I do not remember. Perhaps Juro or Douglas knows? If we aren't going to test reproducible_build.bbclass, we should proabably just delete it
Jul 25 19:34:14 <rburton_> JPEW: its probably a 'better' solution but i do like the elegant simplicity of _simple
Jul 25 20:14:14 <JPEW> rburton_: Ya. It would be nice to know what make ca-certs die.
Jul 25 20:14:21 <JPEW> I didn't see it when I was testing
Jul 25 20:14:26 <rburton> timestamps
Jul 25 20:17:04 <JPEW> Odd
Jul 25 20:20:42 <rburton> hm the test says libical differs but if i build it twice locally the files match
Jul 25 20:20:56 <rburton> and its not a buildpath issue
Jul 25 20:22:06 <rburton> i found the one thing that makes ipkg not reproducible fwiw, filed a bug for adelcast and have a hacky fix here that seems to work
Jul 25 20:24:19 <rburton> did a bit of poking today because i'm super-excited about RPs work and if we can ensure that core is reproducible then that's maximum reuse
Jul 25 20:28:26 <rburton> huh
Jul 25 20:28:36 <rburton> JPEW: did a rebuild of systemd and its pretty much the buildid changing
Jul 25 20:28:37 <rburton>  │ │ │ -  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)	    Build ID: c16e51facf5aea011bdb85b2f54462cd03a7c8f3
Jul 25 20:28:37 <rburton> │ │ │ │ +  GNU                  0x00000014	NT_GNU_BUILD_ID (unique build ID bitstring)	    Build ID: 93f23ab958484272b6d01ed7d6a516aba32411e9
Jul 25 20:28:59 <rburton> i get the feeling we're doing something wrong, or systemd is breaking something?
Jul 25 20:29:57 <rburton> ah huh no
Jul 25 20:29:59 <rburton> │ │ │ │ -   65ddb:	48 ba 3f 86 3f 02 87 	movabs $0x58e87023f863f,%rdx
Jul 25 20:29:59 <rburton> │ │ │ │ +   65ddb:	48 ba bf 2c 2d 25 87 	movabs $0x58e87252d2cbf,%rdx
Jul 25 20:30:12 <rburton> for some reason tiny pieces of the code are subtly different in rebuilds
Jul 25 20:34:27 <rburton> oh thats the timestamp
Jul 25 20:35:05 <rburton> 0x58e87252d2cbf is 1564085979000000, divide by a million and its Thu 25 Jul 21:19:39 BST 2019
Jul 25 20:39:49 <JPEW> Perhaps systemd needs to respect SOURCE_DATE_EPOCH?
Jul 25 20:40:17 <rburton> not sure where that is even coming from
Jul 25 20:45:05 <JPEW> rburton: Thats good on the IPK bug
Jul 25 20:52:28 <JPEW> I have an improved reproducible test on poky-contrib/jpew/reproducible
Jul 25 20:52:57 <rburton> oh yay
Jul 25 20:53:12 <JPEW> There is also diffoscope integration
Jul 25 20:53:24 <rburton> nice
Jul 25 20:54:31 <rburton> i'm enjoying the trydiffoscope tool as it means i don't have to install the world onto my build machine to use it :)
Jul 25 20:55:11 <JPEW> Ya, that's nice.
Jul 25 20:55:38 <JPEW> Word of warning: my new test does 2 clean builds from scratch instead of a clean one and an sstate one
Jul 25 20:55:43 <JPEW> so it takes a while
Jul 25 20:56:06 <rburton> yeah i noticed that
Jul 25 21:07:30 <rburton> RP: the git fetcher doesn't do anything clever/stupid with file timestamps does it?
Jul 25 21:13:46 <rburton> ok fun tmpfs quirk i think
Jul 25 21:14:09 <rburton> can someone do a git clone inside a tmpfs and verify that the mtimes don't get fixed to the time of the last change?
Jul 25 21:14:55 <rburton> ie systemd NEWS is Modify: 2019-04-25 16:12:55.096342845 +0100 on ext4 but Modify: 2019-07-25 22:10:56.014995103 +0100 on tmpfs for me
Jul 25 21:18:33 <RP> rburton: not aware of anything
Jul 25 21:18:39 <RP> rburton: let me try
Jul 25 21:19:03 <rburton> updating my laptop, tell me tomorrow :)
Jul 25 21:41:05 <JPEW> rburton: last modified time is the same as the clone time for me on both tmpfs and ext4
Jul 25 21:41:23 <rburton> whaaaaa
Jul 25 21:41:31 <rburton> i wonder if thats relatime messing around?
Jul 25 21:41:50 <rburton> anyway i'm only here to turn my laptop off :)
Jul 25 21:42:41 <RP> JPEW: was also about to report that :)
Jul 25 21:44:05 <JPEW> Maybe he has a commit hook with this: https://manpages.debian.org/stretch/git-restore-mtime/git-restore-mtime.1.en.html ?
Jul 25 21:44:36 <JPEW> err, not a commit hook, but a hook
Jul 25 21:46:09 <RP> JPEW: seems unlikely
Jul 25 21:46:44 <RP> equally I think runqueue is breaking my thought processes now
Jul 25 22:18:30 <RP> JPEW: this hash equivalence stuff is interesting. I just tried it with the package.bbclass change on list. It reran all the do_package tasks but not the package_write_* :)
Jul 25 22:36:49 <kergoth> ooh
Jul 26 00:43:34 <yocti> New news from stackoverflow: Enable root password verification while login with serial console in Yocto <https://stackoverflow.com/questions/57211741/enable-root-password-verification-while-login-with-serial-console-in-yocto>
**** ENDING LOGGING AT Fri Jul 26 02:59:59 2019