**** BEGIN LOGGING AT Mon Apr 09 03:00:03 2018
Apr 09 03:23:50 <AbleBacon> does yocto automatically make a ".config" file fo the linux kernel?
Apr 09 03:24:14 <AbleBacon> i want to make changes to my kernel config--should i make them in the .config file, or will they get overwritten?
Apr 09 07:02:02 <mckoan> good morning
Apr 09 07:48:46 <Renault> RP: do you need something else (test or development) around F28 issue?
Apr 09 08:13:49 <RP> Renault: I merged the patches with some fixes, thanks!
Apr 09 08:14:04 <Renault> yes I saw it, just to be sure that is OK :)
Apr 09 08:14:22 <RP> Renault: the one remaining issue I'm aware of is that libxcrypt doesn't build on old distros so we need to sort that
Apr 09 08:20:33 <RP> Renault: and I see JaMa sent a patch, thanks!
Apr 09 08:21:54 <Renault> ok, great
Apr 09 08:44:23 <T_UNIX> hi
Apr 09 10:44:51 <steeno> Hi guys, one simple stupid question. Is it possible to reset a package revision which gets automatically incremented by prserv? so f.e. reset custom-package 1.0-r0.1 to 1.0-r0.0? so that the package manager doesn't think he needs to upgrade the package on a system upgrade?
Apr 09 10:56:21 <mcfrisk> steeno: roll back the changes made to recipe. prserv will give the old version numbers again.
Apr 09 11:29:13 <steeno> mcfrisk, assumed the new revision is a result of a force compile with -f -ccompile f.e., i am not able to revert changes which does not exist. long story short: for some unknown reason each packet has a newer revision, so an opkg update tries to update the whole system with 1800+ packages which don't really need to be upgraded.
Apr 09 11:44:21 <mcfrisk> steeno: maybe you can fix the versions in prserv database
Apr 09 11:44:52 <steeno> ok, i will have a look, thank you so much sir
Apr 09 12:18:50 <eduardas_m> hello, I need to rotate the image on the parallel LCD by 180 degrees using i.MX6 Quad... strangely enough, commands like echo 3 > /sys/class/graphics/fb0/rotate have no effect on image rotation (using Linux 4.9 kernel shipped by NXP).. is anyone familiar with resolving similar issues?  also, I am aware that this is not specifically related to Yocto, but I have found this channel to be the best place to find embedded Linux people on freenode, so I hope
Apr 09 12:18:51 <eduardas_m> I can be forgiven for that
Apr 09 12:20:04 <eduardas_m> considering how popular i.MX6 is, I would expect other people to hit a similar problem
Apr 09 12:50:36 <Isaac_> There are two download options at https://www.yoctoproject.org/software-overview/downloads/
Apr 09 12:51:05 <Isaac_> Downloading via git clone and downloading the tarball. The source code of these two differs. Which one is official release?
Apr 09 12:51:57 <Isaac_> Shouldn't the git clone point to a specific tag (e.g. yocto-2.4.2 or rocko-18.0.2) instead of rocko branch?
Apr 09 13:00:59 <rburton> Isaac_: there are tags if you want to use them
Apr 09 13:01:12 <rburton> Isaac_: but if you track the branch then you'll get security updates as they land
Apr 09 13:07:02 <Isaac_> rburton: I see. Referencing tags makes the recipes and final generated binaries reproducable, but tracking branch can breaks it
Apr 09 13:07:25 <Isaac_> rburton: Which is really a bad thing for embedded systems
Apr 09 13:09:12 <Isaac_> rburton: For instance, after rocko-18.0.2 tags, there are commits related to glibc and gcc. That could cause incompatibility for binaries
Apr 09 13:10:46 <Isaac_> rburton: Why Yocto doesn't default to cloning a tag instead of branch, when the generated binaries can be incompatible depending on when you have cloned the repository
Apr 09 13:15:13 <rburton> Isaac_: the binaries won't be incompatible, there were gcc changes because of meltdown
Apr 09 13:15:25 <rburton> clone a tag if you want
Apr 09 13:15:41 <rburton> just remember to check for updates and new point releases
Apr 09 13:16:22 <RP> Isaac_: we have a specific policy for "stable" branch updates and we encourage users to take our stable series changes
Apr 09 13:18:15 <Isaac_> So the users must remember the latest commit on the branch they have cloned to have the reproducibility?
Apr 09 13:18:38 <Isaac_> Because the stable branch like rocko could have breaking changes?
Apr 09 13:19:09 <rburton> Isaac_: it won't have breaking changes, but if you're after reproducibility then yes, making note of the sha of every layer you use is a key part of the data required
Apr 09 13:19:14 <RP> Isaac_: We do a lot of testing to try and ensure we don't break them. git does also store logs of the changes made to the head revision
Apr 09 13:19:48 <Isaac_> They changes in the gcc aren't breaking (by breaking I mean they cause binary incompatibility)
Apr 09 13:19:50 <RP> as rburton says, if you want to reproduce something you'd have to note what you want to reproduce, the tag name or the sha hash
Apr 09 13:20:59 <Isaac_> Is there any reason the Yocto download page doesn't use a tag in the provided git clone?
Apr 09 13:22:25 <Isaac_> I know the users have the latest security fixes by pointing to a branch, but it is ambiguous and misleading since they are not actually cloning the mentioned version on the download page
Apr 09 13:23:22 <JPEW> RP: I found a few Icecream bugs, is to too late to get them into sumo?
Apr 09 13:25:54 <rburton> JPEW: no
Apr 09 13:30:46 * RP would love to get some bugs into sumo :)
Apr 09 13:31:27 <RP> Isaac_: yes, there is a reason, I'd much prefer people get the updates than get stuck on a tag
Apr 09 13:32:04 <RP> Isaac_: if you know what you're doing you are obviously free to do whichever
Apr 09 13:35:31 <Isaac_> RP: I see. I either wait for rocko-18.0.3 or use the hash commit to document the poky version
Apr 09 13:35:37 <Isaac_> Thanks guys
Apr 09 13:36:53 <sveinse> Anyone here with strange experience with pixz on an cortex-a9 target? For some reason pixz stops or crashes on a .tar.xz file compressed with -9. This leaves tar very confused
Apr 09 13:41:20 <yocti> New news from stackoverflow: How to install debug libraries (like lib*d) into packages in yocto <https://stackoverflow.com/questions/36651779/how-to-install-debug-libraries-like-libd-into-packages-in-yocto>
Apr 09 14:22:33 <sveinse> Am I correct that yocto is using xz not pixz? Any particular reason for that?
Apr 09 14:29:49 <RP> sveinse: ./meta/recipes-extended/pixz/pixz_1.0.6.bb ?
Apr 09 14:30:49 <sveinse> RP, no I meant when selecting IMAGE_FSTYPES="tar.xz". But perhaps this is just using tar and it in turn calls xz, right?
Apr 09 14:36:03 <rburton> sveinse: almost definitely
Apr 09 14:36:19 <rburton> i recently patched opkg-build to tell xz to use threads
Apr 09 14:36:55 <rburton> so
Apr 09 14:36:55 <rburton> CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_THREADS} --check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}${
Apr 09 14:36:58 <sveinse> rburton: do you know anything about xz vs pixz? I mean, since xz now has threads support
Apr 09 14:37:07 <rburton> XZ_THREADS ?= "-T 0"
Apr 09 14:37:27 <rburton> -T0 means "as many as cores"
Apr 09 14:37:32 <rburton> so its doing parallel compression
Apr 09 14:38:14 <rburton> pixz can do threaded decompression
Apr 09 14:39:02 <rburton> hm ok lets drop the use of pixz from sdk creation and use xz-T instead
Apr 09 14:39:11 <rburton> then we stop building both \o/
Apr 09 14:42:09 <sveinse> I've just made an investigation of the pixz performance for upgrade on target. Perhaps I should consider repeating it for xz to see if there are any real difference between the two (on target)
Apr 09 14:42:53 <rburton> please do ;)
Apr 09 15:16:42 <rburton> sveinse: xz -T0 is faster than pixz for sdk creation here
Apr 09 15:16:51 <rburton> and smaller output too
Apr 09 15:28:08 <Marex> khem: you didnt answer my question about your DTC version
Apr 09 15:28:31 <Marex> khem: that said, I suspect the problem you see happens both with u-boot 2018.01 and 2018.03, so no point in blocking that recipe ?
Apr 09 16:08:26 <armpit> should "dump data from host is in /tmp/oe-saved-tests/201804082318_qemu" change to ${TMP} or someother configurable local
Apr 09 16:08:49 <sveinse> rburton: https://bpaste.net/show/4945ca485ad4 <-- pixz vs xz compare on host and target real-life usage
Apr 09 16:26:13 <khem> Marex: 2018.01 builds ok here
Apr 09 16:27:13 <khem> and dtc is 1.4.6
Apr 09 16:27:34 <Marex> khem: so it's a 2018.03 problem ?
Apr 09 16:27:36 <Marex> hmmmmmmmmmmmm
Apr 09 16:27:38 <khem> it works fine if I remove dtc but I think thats just papering over the problem
Apr 09 16:27:42 <Marex> khem: which target ?
Apr 09 16:27:53 <Marex> khem: U-Boot should've never bundled DTC in the first place
Apr 09 16:28:07 <Marex> khem: I blame Tartarus for that and I was/am seriously opposed to that
Apr 09 16:28:24 <khem> all targets
Apr 09 16:28:35 <khem> since it happens with fw-utils recipe
Apr 09 16:28:58 <Marex> ah
Apr 09 16:29:06 <Marex> shyte
Apr 09 17:06:45 <rburton> sveinse: -T0 to xz I presume?
Apr 09 17:11:16 <fischerm> khem: does the freedom-u540 machine build for you with initramfs?
Apr 09 17:12:03 <yocti> New news from stackoverflow: Das U-boot, and core-image-minimal platform has no output from display <https://stackoverflow.com/questions/49738198/das-u-boot-and-core-image-minimal-platform-has-no-output-from-display> || Whenever running bitbake stops all application and locks the system <https://stackoverflow.com/questions/48148169/whenever-running-bitbake-stops-all-application-and-locks-the-system>
Apr 09 17:47:22 <khem> fischerm: I dont have the board
Apr 09 17:47:53 <khem> but the image builds ok
Apr 09 17:49:40 <fischerm> khem: for me it always fails to build, I'll give it another shot
Apr 09 17:56:45 <fischerm> anyone have an idea why the kernel-fitimage package wouldn't get installed? it gets build, but somehow doesn't make it to /boot on the image
Apr 09 17:58:32 <fischerm> ?
Apr 09 17:59:18 <abelloni_> fischerm: is it in your IMAGE_INSTALL?
Apr 09 18:01:20 <fischerm> do I manually have to add it?
Apr 09 18:01:32 <fischerm> I'm building core-image-minimal
Apr 09 18:01:49 <abelloni_> usually, yes, it kind of depends on your kernel recipe and image recipe
Apr 09 18:02:08 <fischerm> k, building off of linux-yocto
Apr 09 18:02:17 <abelloni_> but most image recipe are depending on the kernel bieng build but not installed
Apr 09 18:02:36 <abelloni_> that's what I have in my machine .conf:
Apr 09 18:02:37 <abelloni_> IMAGE_INSTALL_append = " kernel-image kernel-devicetree"
Apr 09 18:03:20 <fischerm> ok, cool. thanks. Will give that a shot
Apr 09 18:03:47 <abelloni> IIRC, the other way is to ensure you don't have RDEPENDS_kernel-base="" in your kernel recipe
Apr 09 18:05:47 <abelloni> # Allow machines to override this dependency if kernel image files are
Apr 09 18:05:47 <abelloni> # not wanted in images as standard
Apr 09 18:05:47 <abelloni> RDEPENDS_${KERNEL_PACKAGE_NAME}-base ?= "${KERNEL_PACKAGE_NAME}-image"
Apr 09 18:05:54 <abelloni> that's seems to be it
Apr 09 18:17:26 <khem> so if folks are using vscode there is bitbake plugin https://github.com/mholo65/vscode-bitbake
Apr 09 18:26:31 <khem> fischerm: whats the error ?
Apr 09 18:27:11 <fischerm> khem: I'll need to look at it tonight, it's an issue with riscv-pk and the initramfs
Apr 09 18:27:17 <khem> ok
Apr 09 19:01:06 <fischerm> abelloni: thanks, for your help, that resolved it. I still don't understand why I didn't run into it before, but for now seems safer to maek sure it gets installed by setting the IMAGE_INSTALL_append
Apr 09 22:43:02 <yocti> New news from stackoverflow: How do I boot a Yocto generated image on the MX6 SABRE devices <https://stackoverflow.com/questions/49738198/how-do-i-boot-a-yocto-generated-image-on-the-mx6-sabre-devices>
Apr 09 23:55:30 <fischerm> khem: any preference on the machine? Can make a freedom-u540-{sd,initrafms} and put a MACHINEOVERRIDE="freedom-u540:${MACHINE}" in the freedom-u540-common.inc ?
Apr 09 23:55:43 <fischerm> khem: or is that a bad idea
Apr 10 00:07:41 <brianm_> I'm trying to create a source download mirror by following this guide: https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F
Apr 10 00:07:45 <brianm_> It tells you to copy "build/downloads/" and use that as a mirror
Apr 10 00:07:50 <brianm_> But that directory has a bunch of build artifacts too (e.g. foo.tgz.done)
Apr 10 00:07:57 <brianm_> How can I get a directory of *only* the things I've downloaded?
Apr 10 01:46:13 <marex-cloud> brianm_: the metadata in the dl dir are fine
Apr 10 02:06:15 <brianm_> marex-cloud: I guess so, but I'd rather not dump my build artifacts on my company's public HTTP server
Apr 10 02:09:22 <marex-cloud> I thought you wanted a mirror for oe builds?
**** ENDING LOGGING AT Tue Apr 10 03:00:02 2018