**** BEGIN LOGGING AT Thu Jul 05 03:00:02 2018
Jul 05 03:17:53 <yocti> New news from stackoverflow: Building other image before core-image-minimal <https://stackoverflow.com/questions/51005969/building-other-image-before-core-image-minimal>
Jul 05 10:07:25 <t0mmy> Hello, following the activation of share sstate on our servers of CI we have problems of corrumption: "Removing corrupt package file ..." followed by "Collected errors:
Jul 05 10:07:28 <t0mmy>   * opkg_install_pkg: Failed to download bmon. Maybe you need to run 'opkg update'? "
Jul 05 10:07:31 <t0mmy> Is this a known bug?
Jul 05 10:07:33 <t0mmy> Can this be due to the fact that there are several parallel builds on our servers?
Jul 05 10:07:44 <t0mmy> Thank you in advance for your answers.
Jul 05 10:57:05 <jof> Is it possible to do a bitbake -c devshell after patching and configure but before compile?
Jul 05 11:31:04 <pouet_forever> You can try this : addtask devshell before do_compile after do_configure
Jul 05 11:31:08 <pouet_forever> jof:
Jul 05 11:33:36 <jof> pouet_forever: Thanks! But I actually just solved it by doing a -c configure first, and then doing a: make <myown>_defconfig  :)  Got to the the place where I wanted to be  :)
Jul 05 11:34:33 <pouet_forever> Ok :)
Jul 05 11:38:51 <reto> I just created a distro layer for a commercial project. Eventually, everything will be published to the public. I am thinking about GPL vs MIT for the license. MIT seems to be the default in Yocto. Howevery, personally, I like the copy-left aspect of GPL. Any other good reason to go for one or the other?
Jul 05 11:39:51 <jof> Some people argue that GPL does a better job of protecting the commons, but it does alienate those who can't comply with GPL.
Jul 05 11:41:32 <reto> If you cant comply with the GPL, ain't using Yocot impossible anyway?
Jul 05 11:49:20 <yocti> New news from stackoverflow: Yocto mounting initramfs / initrd image to Raspberry Pi <https://stackoverflow.com/questions/50466075/yocto-mounting-initramfs-initrd-image-to-raspberry-pi>
Jul 05 12:36:03 <mihai> is there a known issue with the mail lists?
Jul 05 12:37:04 <mihai> or is someone around that can help with more info on why are my emails getting deferred?
Jul 05 12:37:11 <mihai> halstead?
Jul 05 12:50:58 <rburton> reto: a fun game is reading the gpl in the context of a layer.  it doesn't get compiled...
Jul 05 12:52:23 <ryfa> Hello Yocto Community - Im having a wierd issue that maybe someone here can point me in the direction of the problem... I have a recipe in my project that fails to build when I am building the whole image, but completes without error if I use bitbake -b, or simply make it from the source code.
Jul 05 12:53:47 <rburton> the big problem with the GPL is that its very explicitly refering to source code that gets built
Jul 05 12:54:11 <rburton> doesn't really work for things which are not that, i.e. scripts, images, layers
Jul 05 12:59:13 <reto> rburton: thx!
Jul 05 14:09:31 <armpit> mihai, which mailing list
Jul 05 14:11:02 <armpit> rburton, do you have any builds that include the xf86-video-fbdev update.. I believe there was an issue, but i can not find the log
Jul 05 14:32:36 <rburton> armpit: yes, the x server wasn't starting
Jul 05 14:32:42 <armpit> k
Jul 05 14:32:43 <rburton> not sure i can find a log bug easy to replicate
Jul 05 14:33:37 <armpit> k. trying to reproduce
Jul 05 14:40:20 <mihai> armpit, meta-freescale list
Jul 05 14:42:52 <armpit> mihai, trying ping otavio , michael is on holiday
Jul 05 14:44:42 <mihai> armpit, ah ok, thanks
Jul 05 14:49:52 <yocti> New news from stackoverflow: Building a Yocto Layer with a Software written with IBM Rhapsody <https://stackoverflow.com/questions/51193765/building-a-yocto-layer-with-a-software-written-with-ibm-rhapsody>
Jul 05 15:17:36 * kergoth yawns
Jul 05 15:18:37 <armpit> +1
Jul 05 15:21:55 <armpit> RP, can we stop the weekly morty and pyro builds ?
Jul 05 15:22:23 * florian has coffee
Jul 05 15:23:10 <armpit> coffee no longer helps
Jul 05 15:33:03 <noway96> I want to assign a unique version to each yocto linux image. What's the appropriate way to do this? Someone mentioned including the version string such that uname -r will spit out MyVersion-x.x.x. That would require defining LINUX_VERSION and LINUX_VERSION_EXTENSION. eg. LINUX_VERSION=x.x.x and LINUX_VERSION_EXTENSION=-MyVersion. Can I do this inside my own recipe, i.e. not inside poky? Will I need to rebuild the entire
Jul 05 15:33:04 <noway96> kernel for this to take effect?
Jul 05 15:33:38 <noway96> btw. uname -r would spit out x.x.x-MyVersion in this case
Jul 05 16:04:26 <RP> armpit: I've tried,  I cna't find where they're triggered from
Jul 05 16:05:34 <RP> armpit: I suggest we wait for halstead to return
Jul 05 16:12:39 <armpit> k
Jul 05 16:46:45 <desert> if I have plenty of disk space, is it wise to not use "rm_work.bbclass" in order to get faster builds ?
Jul 05 16:47:00 <desert> or is it irrelevant?
Jul 05 16:49:04 <kergoth> depends on how much those rms will affect i/o performance for the other tasks. if you're concerned about performance, test it
Jul 05 16:59:11 <rburton> desert: there's surprisingly little impact from using rm_work in the scheme of things
Jul 05 16:59:31 <rburton> if you tune the commit time on the build disk to be minutes, the files can be deleted before they're even written to disk
Jul 05 16:59:49 <rburton> personally if you have enough ram i endorse putting the build dir in a tmpfs with rm_work
Jul 05 17:00:09 <desert> interesting
Jul 05 17:01:43 <desert> i get build times around 15min on a CI machine, but just 5 min on my desktop, we have lots of disk (8TB) to spare and even an SSD. I want to make this as fast as possible
Jul 05 17:01:49 <rburton> but basically, benchmark it
Jul 05 17:01:50 <desert> but i wasnt thinking about a ramfs
Jul 05 17:02:17 <desert> this thing runs triggered by a Gitlab-runner
Jul 05 17:16:53 <khem> rburton: you forgot to cherry-pick mesa wayland fix https://patchwork.openembedded.org/patch/152290/ this would bring build errors down by 1 in my autobuilder setup
Jul 05 17:18:50 <halstead> Those are triggered at /etc/cron.d/idlebuild on controller.yocto.io AFAIK. I just commented out morty and pyro. I'm back tomorrow.
Jul 05 17:28:27 <kergoth> hmm, why am i getting "Previous bitbake instance shutting down?, waiting to retry..." in this docker image for no reason
Jul 05 17:28:30 * kergoth scratches head
Jul 05 17:37:03 <khem> kergoth: some persistent state file may be
Jul 05 18:02:34 <otavio[m]> mihai: are you subscribed to it?
Jul 05 18:03:52 <kergoth> found the issue, i was mounting tmp to a volume, but obviously bitbake writes stuff directly to topdir, and that wasn't on a capable fs, just need to rework my volume mounts and what lives on the local fs vs in the volume
Jul 05 18:03:55 * kergoth yawns
Jul 05 18:27:16 <JPEW> Anyone know off the top of their head why 'python' has to be python 2. If it's python 3 you get: OpenEmbedded requires 'python' to be python v2 (>= 2.7.3), not python v3.
Jul 05 18:28:47 <kergoth> JPEW: it's not due to us, it's due to the projects we build
Jul 05 18:28:54 <kergoth> numerous upstream project buildsystems expect python to be python2
Jul 05 18:29:12 <kergoth> presumably we could create a symlink in our sysroot setup to hack around it
Jul 05 18:29:26 <JPEW> Interesting
Jul 05 18:29:52 <kergoth> also, pretty sure arch is still the only distro that sets python to python3..
Jul 05 18:30:04 <kergoth> i disable that on every system i set up
Jul 05 18:34:27 <JPEW> Fair enough. I ask because I was looking into setting up bitbake to run with pipenv.... but pipenv makes 'python' map to 'python3'
Jul 05 18:35:43 <JPEW> It looks like it's just a symlink, so you might be able to remove it with some post processing?
Jul 05 18:38:15 <kergoth> i imagine it wouldn't be hard to set up a python -> python2 sylink when we set up the HOSTTOOLS symlinks
Jul 05 18:38:28 <kergoth> i'd try doing that instead, and ensure bitbake's shebang is python2
Jul 05 18:38:30 * kergoth shrugs
Jul 05 18:40:04 <JPEW> I though bitbake was python3?
Jul 05 18:41:52 <timm1> i'm trying to get my Canon printer running on Yocto. As far as I understand I have to build CUPS and Gutenprint.
Jul 05 18:42:09 <timm1> I didn't find any recipes for Gutenprint
Jul 05 18:43:10 <timm1> there is a recipt in the deprecated repository: https://github.com/openembedded/openembedded/tree/master/recipes/gutenprint
Jul 05 18:44:10 <timm1> Gutenprint is essential for printing. is there a reason, why CUPS is still in the repository and gutenprint isn't?
Jul 05 18:46:58 <timm1> I have posted my question stackoverflow: https://stackoverflow.com/questions/51180262/using-printers-on-yocto
Jul 05 18:48:27 <kergoth> JPEW: yeah, that's what i went
Jul 05 18:49:29 <JPEW> kergoth: Ok, just checking
Jul 05 18:49:45 <kergoth> meant, even
Jul 05 18:50:05 <JPEW> It is time for more coffee.....
Jul 05 18:55:11 <kergoth> yes, yes it is
Jul 05 19:42:43 <rburton> timm1: gutenprint is in meta-oe iirc
Jul 05 19:44:09 <timm1> rburton: I can't find it in meta-oe: https://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/
Jul 05 19:44:28 <timm1> I'm using the rocko branch
Jul 05 19:45:25 <rburton> maybe you just need to write a recipe...
Jul 05 19:46:44 <rburton> iirc gutenprint isn't *required*
Jul 05 19:47:13 <timm1> rburton: so, my printer will work without gutenprint?
Jul 05 19:47:21 <rburton> i didn't say that
Jul 05 19:47:25 <rburton> for canon, you might need it
Jul 05 19:47:44 <rburton> it depends on the drivers
Jul 05 19:47:59 <rburton> if you need gutenprint then write a recipe. as you say, there's one in the old oe repo you can use for inspiration
Jul 05 19:49:02 <timm1> I'm currently writing a new recipe.
Jul 05 19:51:45 <timm1> The old scripts cannot be converted 1:1 to the newer version of gutenprint, so I have to figure out, what I have to do....
Jul 05 20:57:07 <desert> how to mark a conflicting package?
Jul 05 20:57:56 <desert> I have a recipe pulling from a stable git commit, say   myprog.bb, but I want also master builds, say myprog_master.bb
Jul 05 20:58:10 <desert> both generate the same binaries and same everything but from different commits
Jul 05 20:58:35 <desert> I want to avoid an image adding both recipes, should be either one or the other
Jul 05 20:59:14 <desert> also I want both *.ipk to be  myprog-...ipk and myprog_master-....ipk
Jul 05 20:59:24 <desert> but also want to avoid people from installing both
Jul 05 20:59:43 <desert> this would mean to mark one conflicting with the other
Jul 05 21:00:06 <desert> but googling  bitbake mark conflict recipe gives me results for resolving problems
Jul 05 21:00:14 <desert> is there a parameter
Jul 05 21:00:30 <desert> CONFLICTS_WITH, similar to DEPENDS
Jul 05 21:00:30 <desert> ??
Jul 05 21:01:34 <JPEW> RCONFLICTS?
Jul 05 21:02:02 <desert> oh, i see... "R" means Runtime?
Jul 05 21:13:13 <JPEW> Yes
Jul 05 21:13:38 <JPEW> DEPENDS = build time dependencies, RDEPENDS = runtime dependencies
Jul 05 22:54:32 <ak4721269> Actually I was facing the following issue while building my Yocto SDK on Docker container
Jul 05 22:55:03 <ak4721269> Removing intermediate container 4f3743321874  ---> 674e007553da Step 4/5 : RUN chmod +x /tmp/$META_TOOLCHAIN  ---> Running in ababb0649ea1 Removing intermediate container ababb0649ea1  ---> 5f558946851e Step 5/5 : RUN /tmp/$META_TOOLCHAIN  ---> Running in 929c7ea6af59 Poky (Yocto Project Reference Distro) SDK installer version 2.4.3 ================================================================= You are about to install the SDK to
Jul 05 22:55:34 <ak4721269>  Extracting SDK.............done Setting it up...ls: cannot access '/home/akash/rpil/rpi-build/tmp/environment-setup-cortexa7hf-neon-vfpv4-poky-linux-gnueabi': No such file or directory SDK relocate failed, could not get executalbe files The command '/bin/sh -c /tmp/$META_TOOLCHAIN' returned a non-zero code: 1
Jul 05 22:57:00 <ak4721269> I was facing this issue when environment-setup-cortexa7hf-neon-vfpv4-poky-linux-gnueabi
Jul 05 22:57:22 <ak4721269> is present in my tmp directory
**** ENDING LOGGING AT Fri Jul 06 03:00:01 2018