Thursday, 2019-02-21

*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC00:11
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC00:21
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC00:29
*** Zajc <Zajc!> has quit IRC00:31
*** Zajc <Zajc!> has joined #yocto00:39
*** nerdboy <nerdboy!> has joined #yocto00:45
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto00:45
*** zzeroo <zzeroo!> has quit IRC01:10
*** sjolley <sjolley!> has joined #yocto01:15
*** zzeroo <zzeroo!> has joined #yocto01:16
khemRP: I will once the OE servers are free01:52
*** stephano <stephano!~stephano@> has quit IRC02:07
*** khem <khem!~khem@unaffiliated/khem> has quit IRC02:14
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto02:14
*** sjolley <sjolley!> has quit IRC02:15
*** onlyesterday16 <onlyesterday16!~onlyester@> has joined #yocto02:19
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto02:23
*** ankit <ankit!~apnavik@> has joined #yocto02:39
*** lucaceresoli <lucaceresoli!> has quit IRC02:50
*** lucaceresoli <lucaceresoli!> has joined #yocto02:52
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC03:04
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto03:23
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC03:27
*** sjolley <sjolley!> has joined #yocto03:35
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:39
*** pbb <pbb!> has quit IRC03:43
*** BuddyButterfly1 <BuddyButterfly1!> has joined #yocto03:51
*** BuddyButterfly <BuddyButterfly!> has quit IRC03:53
*** ankit <ankit!~apnavik@> has quit IRC04:36
*** agust <agust!> has joined #yocto04:39
*** sjolley <sjolley!> has quit IRC05:10
*** sjolley <sjolley!> has joined #yocto05:11
*** camus <camus!~Instantbi@> has joined #yocto05:21
*** kaspter <kaspter!~Instantbi@> has quit IRC05:23
*** camus is now known as kaspter05:23
*** thaytan <thaytan!> has quit IRC05:49
*** thaytan <thaytan!> has joined #yocto05:51
*** AndersD <AndersD!~AndersD@> has joined #yocto06:25
*** lucaceresoli <lucaceresoli!> has quit IRC06:35
*** jobroe <jobroe!~manjaro-u@> has joined #yocto06:38
*** lucaceresoli <lucaceresoli!> has joined #yocto06:41
*** AndersD <AndersD!~AndersD@> has quit IRC06:52
*** AndersD <AndersD!> has joined #yocto06:53
*** JaMa <JaMa!~martin@> has joined #yocto06:54
*** sjolley <sjolley!> has quit IRC07:00
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto07:17
*** TobSnyder <TobSnyder!> has joined #yocto07:20
*** lucaceresoli <lucaceresoli!> has quit IRC07:28
*** frsc <frsc!> has joined #yocto07:29
*** marble_visions <marble_visions!~user@> has quit IRC07:30
*** marble_visions <marble_visions!~user@> has joined #yocto07:32
*** lucaceresoli <lucaceresoli!> has joined #yocto07:32
*** JulesVerne_ <JulesVerne_!56b8c8bd@gateway/web/freenode/ip.> has joined #yocto07:36
JulesVerne_not sure of the etiquette, first time here07:37
*** jmiehe <jmiehe!> has joined #yocto07:47
*** JulesVerne_ <JulesVerne_!56b8c8bd@gateway/web/freenode/ip.> has quit IRC07:50
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC07:50
*** nerdboy <nerdboy!~sarnold@> has joined #yocto07:53
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto07:53
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:55
*** fl0v0 <fl0v0!> has joined #yocto07:57
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC07:58
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:58
*** AndersD_ <AndersD_!> has joined #yocto07:59
*** hamis <hamis!~irfan@> has joined #yocto07:59
*** AndersD <AndersD!> has quit IRC08:01
*** sagner <sagner!~ags@> has joined #yocto08:09
*** pbb <pbb!> has joined #yocto08:12
*** willie <willie!d973313a@gateway/web/freenode/ip.> has quit IRC08:13
*** tgraydon <tgraydon!~textual@> has quit IRC08:28
*** gtristan <gtristan!~tristanva@> has joined #yocto08:31
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC08:41
*** varjag <varjag!> has joined #yocto08:44
*** dev1990 <dev1990!> has quit IRC08:51
*** Bunio_FH <Bunio_FH!> has joined #yocto08:56
*** lfa <lfa!~lfa@> has quit IRC08:58
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto08:59
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:00
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC09:02
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:04
*** sagner <sagner!~ags@> has quit IRC09:05
*** sagner <sagner!~ags@> has joined #yocto09:07
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto09:13
*** cquast <cquast!~cquast@> has joined #yocto09:14
*** wooosaiiii <wooosaiiii!> has joined #yocto09:22
*** willie <willie!d973313a@gateway/web/freenode/ip.> has joined #yocto09:31
*** pbb <pbb!> has quit IRC09:37
*** dv_ <dv_!~dv@> has quit IRC09:38
*** pbb <pbb!> has joined #yocto09:38
*** learningc <learningc!> has joined #yocto09:45
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:51
*** dv_ <dv_!~dv@> has joined #yocto09:51
*** BuddyButterfly1 <BuddyButterfly1!> has quit IRC10:01
*** BuddyButterfly <BuddyButterfly!> has joined #yocto10:02
willieHello, i started this yday but my browser crashed so i missed any responses. How does licenses work? I want to use qt which on their website says it can be used with LGPLv3 for open source.10:03
willieI assume that in the "LICENSE" i should set it to LGPLv3, but where do i get the checksum for the license? does it need to be specific from qt, i could not find checksum on their website or in the meta-qt10:04
*** yacar_ <yacar_!> has joined #yocto10:05
willieI'm obviously a newbie and in other stuff i have used it was always sufficient to use "MIT" and put a COPY.MIT in the project directory but that does not seem to be the case for qt10:06
*** yacar_ <yacar_!> has left #yocto10:07
*** yacar_ <yacar_!> has joined #yocto10:08
LetoThe2ndwillie: no, the lgpl applies to qt10:11
LetoThe2ndyou can happily use it for whatever proprietary code you ship, as long as you only LINK against it in its unmodified official version10:12
LetoThe2ndthats the whole point of LGPL vs GPL10:12
LetoThe2ndwillie: lgpl only starts to bite if you actually patch qt itself10:14
*** mckoan|away is now known as mckoan10:14
willieLetoThe2nd: Okay, i got a bit worried last night, and i sure wont touch qt itself.  regarding the checksum, should i use the last commit to the meta-qt?10:16
LetoThe2ndwillie: add a COPYING.MIT file to your sources (you should do that anyways!) and take its checksum.10:17
*** BuddyButterfly1 <BuddyButterfly1!> has joined #yocto10:18
*** BuddyButterfly <BuddyButterfly!> has quit IRC10:21
willieLetoThe2nd: Do you mean the sources directory or in the directory with my sources files for that project?10:30
LetoThe2ndwillie: is there a difference?10:31
*** melonipoika <melonipoika!~jose@> has joined #yocto10:32
willieLetoThe2nd: Well, i guess that depends on where the function looks for the file? I'm still getting "LIC_FILES_CHKSUM contains an invalid URL: bdf7935524383ae97b7d2f5f0565829d"10:33
LetoThe2ndwillie: why not just look at other recipes how they do it. the LIC_FILES_CHECKSUM should refer to a file that somes with the sources of your project. which makes perfect sense, as the file should state the license of the sources of the project. and of that file, it is a defined hash10:35
LetoThe2ndwillie: here is a perfect example:
LetoThe2ndand it refers to this:
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:36
*** learningc <learningc!> has quit IRC10:43
*** learningc <learningc!> has joined #yocto10:45
*** rburton <rburton!> has joined #yocto10:48
willieLetoThe2nd: I think my structure is the same, perhaps something else has broke due to many error runs, i'll have a look at it after lunch :>10:48
*** ak77_ <ak77_!c12e4b03@gateway/web/freenode/ip.> has joined #yocto10:56
*** ak77 <ak77!c12e4b03@gateway/web/freenode/ip.> has quit IRC10:57
*** sk_tandt <sk_tandt!> has joined #yocto10:57
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC10:59
*** onlyesterday16 <onlyesterday16!~onlyester@> has quit IRC11:09
*** cvasilak <cvasilak!> has joined #yocto11:12
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto11:19
*** gtristan <gtristan!~tristanva@> has quit IRC11:21
*** berton <berton!~berton@> has joined #yocto11:36
*** berton <berton!~berton@> has quit IRC11:40
*** berton <berton!~berton@> has joined #yocto11:42
*** learningc <learningc!> has quit IRC11:43
*** learningc <learningc!> has joined #yocto11:44
*** vicky_ <vicky_!uid270243@gateway/web/> has joined #yocto11:47
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:18
*** Bunio_FH <Bunio_FH!> has quit IRC12:33
*** Bunio_FH <Bunio_FH!> has joined #yocto12:34
willieLetoThe2nd: I think i found the problem, but not the why. the license with correct checksum should en up in a dir named "license-destdir"12:41
willieLetoThe2nd: But for some reson the COPYING.MIT does not end up in /work/cortex..../my-project/1.0.0-r0/my-project. Should it not be built from layer?12:43
*** learningc <learningc!> has quit IRC12:43
*** learningc <learningc!> has joined #yocto12:44
willieLetoThe2nd: If i manually copy, it will probably work, but surley that is not inteded12:49
*** JaMa <JaMa!~martin@> has quit IRC12:53
*** JaMa <JaMa!~martin@> has joined #yocto12:56
*** JaMa <JaMa!~martin@> has quit IRC12:57
RPkanavin: any idea why would appear, then disappear in the next build? :/13:05
RPkanavin: the successful patches tested ok so I've sent them out13:05
kanavinRP: /home/pokybuild/yocto-worker/qemux86-64/build/build/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/testsdkext/tmp/sysroots/qemux86-64/usr/bin/postinst-gdk-pixbuf-native: 2: /home/pokybuild/yocto-worker/qemux86-64/build/build/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/testsdkext/tmp/sysroots/qemux86-64/usr/bin/postinst-gdk-pixbuf-native: /home/pokybuild/yocto-worker/qemux86-64/build/build/tmp/work/qemux86_64-poky-linux/core-image-sato/13:05
kanavin1.0-r0/testsdkext/tmp/sysroots/x86_64/usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders: not found13:05
kanavinsadly, no :( the 'missing' binary is unconditionally installed in do_install of the gdk-pixbuf recipe13:06
RPkanavin: I'd thought I'd ask. Kind of like the permissions issue but different13:06
kanavindo_install_append() {13:06
kanavin        # Move gdk-pixbuf-query-loaders into libdir so it is always available13:06
kanavin        # in multilib builds.13:06
kanavin        mv ${D}/${bindir}/gdk-pixbuf-query-loaders ${D}/${libdir}/gdk-pixbuf-2.0/13:06
kanavinso if that succeeded, I really don't know why it would go missing later13:07
kanavinRP: I can maybe try to reproduce it here13:08
RPkanavin: did you find a cause for the warnings in the oecore-qemuarm build?13:09
kanavinRP: yes, and fixed them. I fixed all three issues (race, warnings, no-x11 breakage).13:09
RPkanavin: great, thanks, I wasn't quite sure about whether you'd found them all! :)13:10
RPkanavin: build looks green but I'd like rburton to review those patches before they merge too13:10
kanavinRP: yeah, I did :) should've been more noisy about it13:10
kanavinRP: I see you are taking more AUH patches, how much is left (of the ones that are 'perfect', e.g. no do_compile issues)?13:11
RPkanavin: there are 3-4 general SRVREV bumps13:13
* RP didn't see the point in picking random srcrevs13:13
RPkanavin: there are a few upgrades blocked on "problems" which I think we may need to help out13:14
RPkanavin: ltp comes to mind13:14
*** frsc is now known as frieder13:14
* RP would also love to get the ptest'd13:14
RPkanavin: was thinking if we could get the noise of the point upgrades sorted out it would show more clearly which other pieces need help13:15
kanavinRP: yeah, AUH does upgrade to latest commit ids for recipes where upstream never issues releases (e.g. kmscube or gst-examples)13:15
kanavinwe have a special variable, UPSTREAM_CHECK_COMMITS for that I thnk13:16
*** lfa <lfa!~lfa@> has joined #yocto13:16
*** frieder is now known as frsc13:16
kanavinRP: yep, I hope the march AUH run will be centered mostly on things that cannot be auto-updated13:17
RPkanavin: right, it makes sense, I just wanted to be clear about the bits I didn't take13:17
RPkanavin: I did redo the gnuconfig one to move to a more recent point in git history13:17
*** learningc <learningc!> has quit IRC13:36
*** learningc <learningc!> has joined #yocto13:37
*** hamis <hamis!~irfan@> has quit IRC13:39
*** JaMa <JaMa!~martin@> has joined #yocto13:41
*** melonipoika <melonipoika!~jose@> has left #yocto13:41
*** TobSnyder <TobSnyder!> has quit IRC13:47
*** vicky_ <vicky_!uid270243@gateway/web/> has quit IRC13:55
*** nighty- <nighty-!> has quit IRC14:03
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:21
*** sagner <sagner!~ags@> has quit IRC14:50
*** sagner <sagner!~ags@> has joined #yocto14:52
Piratyadelcast: mind if i rewrite opkg-unbuild in shell (and contribute)?14:53
Piratycurrently it's a python2 script, not very portable14:53
Piratyalso overkill for the task of un ar/tar ing14:53
* armpit does his auh work on weekend14:54
*** AndersD_ <AndersD_!> has quit IRC15:01
*** frsc <frsc!> has quit IRC15:07
*** cvasilak <cvasilak!> has quit IRC15:12
*** sgw1 <sgw1!~sgw@> has joined #yocto15:13
*** sgw_ <sgw_!sgw@nat/intel/x-cxuajrivqaqjmtpt> has quit IRC15:13
*** sjolley <sjolley!> has joined #yocto15:19
kanavinrburton, gtk+ has been renamed to just gtk, so I guess we can name the gtk4 recipe simply gtk :) never liked hardcoding version numbers in PN15:22
*** sgw1 is now known as sgw_15:23
*** frsc <frsc!> has joined #yocto15:23
RPkanavin: it was handy to allow 2 and 3 to coexist15:23
kanavinRP: 2, 3 and 4 will coexist, as gtk+, gtk+3 and gtk_4.x15:24
RPmorning sgw_15:24
RPkanavin: right, but 5 won't :)15:24
sgw_RP: morning back at you!15:24
RParmpit: I updated the curl commit message btw, thanks15:25
kanavinRP: no :( but then it would depend on how incompatible it is with 4.x15:25
armpitRP, I saw.. thanks15:26
RPkanavin: right. I'm thinking too far ahead15:26
*** jobroe <jobroe!~manjaro-u@> has quit IRC15:27
*** evadeflow <evadeflow!d1ddf0c1@gateway/web/freenode/ip.> has joined #yocto15:31
*** sno <sno!> has quit IRC15:33
evadeflowHi, all.  I'm supporting an i.MX8-based project that includes Python 3.5.2 by default. My team just asked if I could upgrade them to Python 3.6.15:34
evadeflowI've not managed to find any recipes for 3.6, so... I'm worried that this request---which seems like it should be easy on the surface---might turn out to be difficult.15:35
evadeflowAny opinions, advice, war stories?15:35
kanavinevadeflow, it is very difficult, but we managed it for the upcoming Yocto release. Your best bet is to take the current poky master, and work with that.15:36
evadeflow(We're using NXP's publicly-available support layers, with very small mods to fsl-image-qt5.)15:36
evadeflow@kanavin: Thanks for the response.15:37
kanavinyou can probably also attempt to backport the 3.7.2 recipe from master to whatever release you are using now, but you are on your own there.15:37
kanavin3.5.2 means you do have a quite old release15:37
evadeflowYeah, it's a bit older than NXP's latest.15:38
evadeflowSo... you recommend updating the `poky` layer to the current master and start fixing all the things that break, one at a time?15:39
kanavin'poky' layer, and all other layers to their respective master branches15:39
kanavinand then start fixing15:40
kanavinat some point you have to do it anyway, so might as well make a habit of staying close to upstream15:40
evadeflowOh, update *all* the layers.15:40
* evadeflow Gulps.15:40
evadeflowI see why you said it's "very difficult".15:40
kanavinwell, they should be keeping up with yocto upstream, or then they're not maintaining properly15:41
evadeflowThat's just what I needed to know, thanks.15:41
evadeflowThis isn't likely something we'll be able to do in "a few days", we need to block off a whole sprint for it.15:41
kanavinI'd even claim you can't estimate this in advance15:42
kanavinif managements asks you to, say 'a few sprints'15:43
evadeflowGood idea!15:44
kanavinalso, explain to them the concept of 'technical debt' :)15:45
kanavinyou've accumulated debt by sticking to an old yocto release, and it's time to re-pay it15:46
evadeflowI'll definitely make that case.15:49
kanavinRP: fwiw, I couldn't reproduce the testsdk gdk-pixbuf issue. Clean build works fine, wipe-tmp-and-use-sstate also works fine.15:50
kanavinRP: might be again one of those distro specific issues :-/15:50
kanavinRP: but then the distro here was ubuntu 18.04, precisely what I use15:51
*** varjag <varjag!> has quit IRC15:52
*** sagner <sagner!~ags@> has quit IRC15:56
*** sagner <sagner!~ags@> has joined #yocto15:58
*** paulg <paulg!~paulg@> has quit IRC16:01
*** paulg <paulg!> has joined #yocto16:03
*** malanecora <malanecora!b23cc82c@gateway/web/freenode/ip.> has quit IRC16:10
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC16:20
evadeflowIn my current project, there's an append recipe in one of the upstream layers that contains `PACKAGECONFIG_remove_imx   = "eigen python3"`.16:27
evadeflowI've found I can't build the opencv Python bindings with that line in place. Manually removing that line gives the result I want, but... I'm not sure how to write an append recipe of my own that simply acts to 'undo' this line from the other append recipe.16:28
evadeflowHow do you undo that removal syntax in an append?16:29
evadeflow(I've forked the other layer, so I could just modify the original, but I'm trying to avoid that because it always comes back to bite me.)16:29
*** sno <sno!~sno@2a01:598:9988:b2ef:c46f:96b9:5778:2530> has joined #yocto16:31
evadeflowAigh. I suppose I'll try `PACKAGECONFIG_append_imx   = "eigen python3"` in my append.16:33
RPkanavin: thanks for trying. I wonder if it depends which distro the sstate was built on?16:35
*** lusus <lusus!~lusus@> has quit IRC16:35
RPevadeflow: remove is a nightmare to undo, its near impossible. Only way is anonymous python which resets the variable16:35
kanavinRP: might be :-/ which makes it fiendishly difficult to reproduce16:35
*** nighty- <nighty-!> has joined #yocto16:36
*** sgw <sgw!~sgw@> has joined #yocto16:37
*** sgw_ <sgw_!~sgw@> has quit IRC16:38
*** yacar_ <yacar_!> has quit IRC16:39
evadeflowRP: Wow. That's useful info, thanks. (Some dim memory in the back of my mind was nagging at me that this would be tricky.)16:39
kergothmy rule of thumb is to avoid _remove unless absolutely necessary, but if it is necessary, then always, always use an intermediate variable. FOO_REMOVE = "something"; FOO_remove = "${FOO_REMOVE}" - then you can alway soverride the intermediate variable16:41
kergothcourse that doesn't help if you werent the one that added the _remvoe, but..16:41
RPI also try not to use _remove anywhere in oe-core. It really is a tool of last resort16:42
kanavinevadeflow, PACKAGECONFIGs should be set with = from a distro config anyway, never from bbappends. You should tell the upstream layer not to do what they do.16:42
RPkergoth: that is a good tip16:43
kanavin_remove and bbappends are those things in Yocto I'm not a great fan of :(16:44
kanavinthey're *so* easy to misuse, and and often are16:44
kergothugh, yes  i hate it when a distro scatters their settings all over the distro layer when they dont have to16:44
*** rcw <rcw!~rcw@> has joined #yocto16:45
kanavinI think people in general don't get the concept of a 'distro config'16:45
kanavinso they put stuff anywhere else, except that16:45
kanavinbbappends, local.conf, etc.16:45
kanavinalso, there is some kind of mental barrier to writing own image recipes16:45
RPbetter examples out there could help with that16:46
RPkanavin: an "antipatterns" section in the manual might help too16:47
RPIf you find yourself doing X, do Y instead16:47
kanavinRP: do we have one?16:47
RPkanavin: a section? probably not16:48
RPkanavin: could have though16:48
RPhmm, I can't fix this problem with a change to both the autobuilder and helper code. gah.16:49
kergothI wonder if it'd help to have more subcommands for things like recipe creation, so they dont have to think 'okay, what i do i call it, where do i put it, etc'. just make me an image and put it in this layer and open my editor with a template16:49
*** sgw1 <sgw1!~sgw@> has joined #yocto16:49
kergothrecipetool new-image? *shrug*16:49
RPkergoth: totally. I'd love to see that16:49
*** jmiehe <jmiehe!> has quit IRC16:49
RPkergoth: if you don't write it, file a bug?16:49
*** sgw <sgw!~sgw@> has quit IRC16:51
*** nerdboy <nerdboy!> has joined #yocto16:59
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:59
Piratyadelcast: for me the python thing opkg-unbuild is broken? is that correct? also, the way it is now is that targetdirs are set next to the package itself, not matter if cwd is somewhere else. wouldn't it make sense to extract to cwd?17:01
kergothsure, i'll create a bug for now. might implement it too, but fighting other fires just this second (as usual..)17:01
kergothi wonder if a lot of folks even know what all bitbake-layers, recipetool, and devtool provide in terms of functionaity. do folks know you can create a new layer, add it to the build, and add a bbappend of a recipe, and override files from the target fs all easily and trivially with a few short commands and no manual moving things around?17:03
Piratyadelcast: ah it's broken for me because the shell commands in the python (... :-/) assume bourne shell via >& . the most classic bashism17:03
RPkergoth: thanks, I know the fires problem all too well17:03
RPkergoth: I suspect not, people take time to adapt to the new tools17:03
RPkergoth: not sure how you speed that up17:04
kergothyeah, i have no idea either. maybe explicitly listing in the migration guides or changelogs, but most folks don't read those anyway, so that doesn't really help :)17:04
*** gsalazar <gsalazar!> has joined #yocto17:10
gsalazarHi, how can I run bitbake with a single thread as in make -j1?17:11
kergothgsalazar: BB_NUMBER_THREADS = "1" will make bitbake run one task at a time. it'll still pass -j down into the makes it spawns unless you also adjust PARALLEL_MAKE, though17:11
*** fl0v0 <fl0v0!> has quit IRC17:14
*** ferlzc <ferlzc!~ferlzc@> has joined #yocto17:15
gsalazarI should adjust PARALLEL_MAKE with PARALLEL_MAKE = "1"? I was doing PARALLEL_MAKE=117:18
gsalazarI should set it globally? with export? or is there a conf file?17:19
*** WillMiles <WillMiles!> has joined #yocto17:24
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC17:24
*** frsc <frsc!> has quit IRC17:30
*** gsalazar <gsalazar!> has quit IRC17:39
*** sk_tandt <sk_tandt!> has quit IRC17:40
*** nighty- <nighty-!> has quit IRC17:40
*** cquast <cquast!~cquast@> has quit IRC17:51
*** mckoan is now known as mckoan|away17:51
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC17:53
*** sno <sno!~sno@2a01:598:9988:b2ef:c46f:96b9:5778:2530> has quit IRC17:59
*** gsalazar <gsalazar!> has joined #yocto18:00
khemJPEW:is there is latest setup on icecc the OE wiki has one but its from 201318:01
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC18:02
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC18:02
*** nerdboy <nerdboy!> has joined #yocto18:02
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto18:02
evadeflowSo... my inglorious hack to undo a _remove assignment in another layer's append recipe isn't working. I tried @RP's suggestion of using an anonymous Python function, like so:18:18
*** kanavin <kanavin!~kanavin@> has quit IRC18:18
evadeflowpython () {      d.setVar('PACKAGECONFIG', 'python3 eigen ' + d.getVar('PACKAGECONFIG', False)) }18:18
*** kanavin <kanavin!~kanavin@> has joined #yocto18:19
evadeflowAlas, everything builds fine, but... I can tell from the debug prints I put in that `python3 eigen` is NOT being (re-)added, as desired.18:19
evadeflow(Oh, slight mispaste. I tried both True/False for the 'expand' parameter. It didn't seem to make a difference.)18:22
evadeflowI guess it could be an issue with layer priority(?) Checking...18:22
*** Bunio_FH <Bunio_FH!> has quit IRC18:24
*** dev1990 <dev1990!> has joined #yocto18:26
*** sgw1 <sgw1!~sgw@> has quit IRC18:28
khem_remove is final operation18:30
khemit can not be undone18:30
JPEWkhem: No, I should probably update it.... although I tried not to change the setup to much18:41
khemJPEW: so all I need is INHERIT += "icecc" and that it ?18:44
khemI have nodes working ok now18:44
JPEWYa, and twiddiling the blacklist.... I need to do better about keeping it accurate :(18:44
khemicecream-sundae can list all the nodes18:44
JPEWHmm, the OE wiki wants my personal biography to get an account... I feel like this is some sort of test for a secret organization18:46
khemthis was due to spam it was getting in past18:48
khemaccounts were being created by bots18:48
*** lfa <lfa!~lfa@> has quit IRC18:49
*** sgw <sgw!~sgw@> has joined #yocto18:51
Croftonjpew, just convince me you are not a dirty spammer18:52
CroftonI only approve about 30%18:52
CroftonI really do not need more busines offers18:52
JPEWCrofton: I can convince you, but I'll need $9.99 from you first ;)18:53
JPEWCrofton: I already had an account, I apparently I just forgot the password18:53
khemJPEW: WARNING: icecc-create-env-native-0.1-r2 do_configure: Cannot use icecc: invalid ICECC_ENV_EXEC18:54
JPEWYep, known issue. The warning is just saying "I can't use icecream to compile this!"18:54
JPEWYOCTO #961818:55
Croftononly one request tight now, here is what passes for a bio18:55
CroftonHi, letting you know that can find your business a SBA or private loan for $2,000 - $350K Without high credit or collateral. Find Out how much you qualify for by clicking here: Minimum requirements include your company being established for at least a year and with current gross revenue of at least 120K. Eligibility and . . .18:55
khemOK so it means its only complaining for this one packahge ?18:55
JPEWkhem: You'll see that warning for several recipe that can't use icecc18:56
JPEWUsually because CC isn't defined18:56
*** evadeflow <evadeflow!d1ddf0c1@gateway/web/freenode/ip.> has quit IRC18:58
khemJPEW:thats no problems ok.19:00
khemJPEW: I Can see both nodes whirring now :)19:01
*** sagner <sagner!~ags@> has quit IRC19:02
khemJPEW: so the toolchain gets built on one host ?19:02
khemor does it spread the native and cross jobs too19:02
JPEWkhem: icecc creates a toolchain tarball and transfers it over19:03
khemso it will have to wait for toolchain pieces to finish then19:03
khemor does it do with every job19:03
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:04
JPEWThe nodes have a cache of toolchains, it only sends it over if the node doesn't already have it19:04
khemJPEW:ok and where can I look at icecc workspaces on nodes19:05
JPEWIts configured on the node itself but usually......19:05
khemjust now I see cmake-native building on a differnet node so native is shipped19:06
khemso looks ok19:06
JPEW /var/cache/icecream19:06
JPEWHere is the script that OE passes to icecc to create the toolchains if you are curious:
JPEWAnd OE generates the toolchains into work-shared/ice/19:08
khemhow does it interact with sstate19:10
JPEWIt works fine, but enabling changes all the hashes.19:11
JPEWSo you can't share sstate between a build with INHERIT += icecc and one without19:11
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC19:11
khemJPEW:if I dont want to use /var/cache/icecc but something like /mnt/var/cache/icecc19:13
JPEWIf you want to do that, I usually suggest that you add INHERIT += "icecc" ICECC_DISABLED = "1" as the default.  That way you can share sstate (since ICECC_DISABLED *doesn't* affect the hashes19:13
JPEWYou have to change the config for your local icecc daemon19:13
khemICECC_DISABLED would disable the distributed compile isnt it ?19:14
JPEWRight yes.19:14
JPEWSo if you want to share sstate, use INHERIT += "icecc" everywhere, then use ICECC_DISABLED to control if icecream is actually used or not19:14
JPEW(Thats what we do here)19:15
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:19
JPEWkhem: Updated the wiki19:31
khemJPEW: awesome19:31
khemJPEW:so at this time either icecc or sstate19:32
khemboth cant complement each other19:32
JPEWWell, it depends. You *can* use both if you can make all your users build with INHERIT += "icecc". For example, our sstate caches are populated by our nightly autobuilders; they don't use icecc to actually compile but we can use the sstate they produce19:33
JPEWkhem: But you couldn't share with some random published sstate cache (I think OE-core has one?)19:34
JPEWkhem: Although, hash equivalence servers would help with that ;)19:35
*** evadeflow <evadeflow!d1ddf0c1@gateway/web/freenode/ip.> has joined #yocto19:41
khemusers can use INHERIT += "icecc" thats a central policy we can easily push that to everyone19:42
*** rewitt <rewitt!rewitt@nat/intel/x-dqcjslooastrlfes> has quit IRC19:42
khemwe dont consume random sstate cache, we build every day and try to use that19:43
khemand its built by same builders that do CI works19:43
JPEWkhem: Ya sounds exactly like what we do. I suspect it will work fine then.19:47
RPevadeflow: I'd try a delVar then setVar19:49
RPevadeflow: although that could have the unfortunate side effect of clearing the flags so you may need to preserve those too19:50
*** evadeflow_ <evadeflow_!d1ddf0c1@gateway/web/freenode/ip.> has joined #yocto19:52
*** evadeflow <evadeflow!d1ddf0c1@gateway/web/freenode/ip.> has quit IRC19:52
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto19:53
*** gtristan <gtristan!~tristanva@> has joined #yocto19:54
*** sjolley <sjolley!> has quit IRC19:59
khemJPEW:once I change ICECC_BASEDIR to something other than /var/cache/icecc icecream-sundae is not listing the node20:00
khemJPEW:it that known ?20:00
JPEWHmm, I'm not sure. I've never tried changing it.20:00
khemit will be common since / is small on nodes and there is another mount with large storeage20:01
JPEWDid you restart iceccd?20:02
evadeflow_RP: thanks for delVar() suggestion. Trying this now:
otaviokhem: berton and I are here discussing about the patch; do you wish the backport of the revert to be added to mesa? It seems to be on drm ...20:12
otaviokhem: or I missed something?20:12
evadeflow_It resulted in a bunch of QA warnings, so... I'm skeptical.20:12
*** rcw <rcw!~rcw@> has quit IRC20:13
* armpit misses everything20:16
RPevadeflow_: you need to go a d.getVarFlags and then set them again too20:18
evadeflow_RP: Oh, okay. (That probably explains why it didn't work. :-) )20:19
khemotavio: you did not miss20:19
khemJPEW:yes disappears after restart20:19
JPEWkhem: I'm not sure, you might try starting the daemon manually in the foreground? Perhaps it can't contact the scheduler anymore20:33
JPEWOr maybe your PC is the scheduler....20:33
RPkergoth: what are your thoughts on ?20:39
RPkergoth: I like the idea apart from the way its playing with __builtins__20:39
RPkergoth: any suggestion on how we could do that better?20:39
*** sagner <sagner!~ags@2a02:169:3465:0:6c69:2b1e:235b:318b> has joined #yocto20:41
*** sno <sno!> has joined #yocto20:44
*** sno <sno!> has quit IRC20:51
khemJPEW: does scheduler has to know ICECC_BASEDIR20:55
khemI guess not20:55
JPEWkhem: I don't think so, but usually when a node disappears it's because it can't talk to the scheduler anymore20:56
khemJPEW: yeah20:56
*** sno <sno!> has joined #yocto20:56
khemI guess there might be more involved20:56
*** ferlzc <ferlzc!~ferlzc@> has quit IRC20:59
yoctiNew news from stackoverflow: Yocto's ROOTFS_POSTPROCESS_COMMAND not working? <>21:00
*** berton <berton!~berton@> has quit IRC21:01
*** sagner <sagner!~ags@2a02:169:3465:0:6c69:2b1e:235b:318b> has quit IRC21:09
*** stephano <stephano!stephano@nat/intel/x-bvshisuwiueafpkp> has joined #yocto21:10
*** sno <sno!> has quit IRC21:16
kergothRP: I'd change it to accept a full path with import. i.e. custom:oe.myprogress.MyProgressHandler, and adjust the code to try to import oe.myprogress and look it up there. then we can use the existing ability to import packages from layers and just include a .py in your layer with the progress handler rather than fully defining it in the metadata. or if the person really wants to define it wholly in the metadata through injection rather than import, they21:24
kergoth could still do so, just make sure it only tries to import when the lookup fails, and set to custom:bb.context.MyProgressHandler and let install_my_progress_handler() inject it there rather than __builtins__.21:24
kergothor just rely on OE_IMPORTS for the import and just let it look it up as is, even easier21:25
RPkergoth: I was wondering if we could tie it to OE_IMPORTS somehow. How easy would that be from your own layer?21:25
RPkergoth: would you mind replying on the bitbake list please? (or I can copy this there)21:26
RPkergoth: I was pinged about that patch and I think the idea is good, we just need a better API21:26
kergothyeah, i'll reply21:26
RPkergoth: might as well try and get it right for a change!21:26
RPkergoth: thanks!21:27
*** lquirion <lquirion!> has joined #yocto21:29
*** gtristan <gtristan!~tristanva@> has quit IRC21:33
*** WillMiles <WillMiles!> has quit IRC21:37
*** sno <sno!> has joined #yocto21:54
*** rewitt <rewitt!~rewitt@> has joined #yocto21:54
*** moosnat <moosnat!~nmoos@unaffiliated/moosnat> has joined #yocto21:56
moosnatIs there a way to remove an inherited class through a bbappend?21:57
moosnatThanks rburton21:58
*** moosnat <moosnat!~nmoos@unaffiliated/moosnat> has quit IRC22:06
*** tgraydon <tgraydon!textual@nat/intel/x-lfiynlyqecmxaqrd> has joined #yocto22:15
*** rburton <rburton!> has quit IRC22:27
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto22:43
*** evadeflow_ <evadeflow_!d1ddf0c1@gateway/web/freenode/ip.> has quit IRC23:47
*** lquirion <lquirion!> has quit IRC23:59

Generated by 2.11.0 by Marius Gedminas - find it at!