**** BEGIN LOGGING AT Thu Feb 21 02:59:57 2019 Feb 21 07:36:52 Hi Feb 21 07:37:30 not sure of the etiquette, first time here Feb 21 10:03:48 Hello, 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. Feb 21 10:04:46 I 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-qt Feb 21 10:06:21 I'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 qt Feb 21 10:11:45 willie: no, the lgpl applies to qt Feb 21 10:12:29 you can happily use it for whatever proprietary code you ship, as long as you only LINK against it in its unmodified official version Feb 21 10:12:39 thats the whole point of LGPL vs GPL Feb 21 10:14:00 willie: lgpl only starts to bite if you actually patch qt itself Feb 21 10:16:11 LetoThe2nd: 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? Feb 21 10:17:37 willie: add a COPYING.MIT file to your sources (you should do that anyways!) and take its checksum. Feb 21 10:30:39 LetoThe2nd: Do you mean the sources directory or in the directory with my sources files for that project? Feb 21 10:31:42 willie: is there a difference? Feb 21 10:33:57 LetoThe2nd: 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" Feb 21 10:35:31 willie: 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 hash Feb 21 10:36:25 willie: here is a perfect example: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/busybox/busybox.inc#n11 Feb 21 10:36:51 and it refers to this: https://git.busybox.net/busybox/tree/LICENSE Feb 21 10:48:23 LetoThe2nd: 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 :> Feb 21 12:41:27 LetoThe2nd: I think i found the problem, but not the why. the license with correct checksum should en up in a dir named "license-destdir" Feb 21 12:43:15 LetoThe2nd: 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? Feb 21 12:49:07 LetoThe2nd: If i manually copy, it will probably work, but surley that is not inteded Feb 21 13:05:13 kanavin: any idea why https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/313 would appear, then disappear in the next build? :/ Feb 21 13:05:30 kanavin: the successful patches tested ok so I've sent them out Feb 21 13:05:41 RP: /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/ Feb 21 13:05:41 1.0-r0/testsdkext/tmp/sysroots/x86_64/usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders: not found Feb 21 13:06:15 sadly, no :( the 'missing' binary is unconditionally installed in do_install of the gdk-pixbuf recipe Feb 21 13:06:44 kanavin: I'd thought I'd ask. Kind of like the permissions issue but different Feb 21 13:06:49 do_install_append() { Feb 21 13:06:49 # Move gdk-pixbuf-query-loaders into libdir so it is always available Feb 21 13:06:49 # in multilib builds. Feb 21 13:06:49 mv ${D}/${bindir}/gdk-pixbuf-query-loaders ${D}/${libdir}/gdk-pixbuf-2.0/ Feb 21 13:06:49 } Feb 21 13:07:10 so if that succeeded, I really don't know why it would go missing later Feb 21 13:08:54 RP: I can maybe try to reproduce it here Feb 21 13:09:24 kanavin: did you find a cause for the warnings in the oecore-qemuarm build? Feb 21 13:09:50 RP: yes, and fixed them. I fixed all three issues (race, warnings, no-x11 breakage). Feb 21 13:10:22 kanavin: great, thanks, I wasn't quite sure about whether you'd found them all! :) Feb 21 13:10:48 kanavin: build looks green but I'd like rburton to review those patches before they merge too Feb 21 13:10:53 RP: yeah, I did :) should've been more noisy about it Feb 21 13:11:36 RP: I see you are taking more AUH patches, how much is left (of the ones that are 'perfect', e.g. no do_compile issues)? Feb 21 13:13:26 kanavin: there are 3-4 general SRVREV bumps Feb 21 13:13:39 * RP didn't see the point in picking random srcrevs Feb 21 13:14:27 kanavin: there are a few upgrades blocked on "problems" which I think we may need to help out Feb 21 13:14:31 kanavin: ltp comes to mind Feb 21 13:14:39 * RP would also love to get the ptest'd Feb 21 13:15:21 kanavin: was thinking if we could get the noise of the point upgrades sorted out it would show more clearly which other pieces need help Feb 21 13:15:38 RP: yeah, AUH does upgrade to latest commit ids for recipes where upstream never issues releases (e.g. kmscube or gst-examples) Feb 21 13:16:15 we have a special variable, UPSTREAM_CHECK_COMMITS for that I thnk Feb 21 13:17:06 RP: yep, I hope the march AUH run will be centered mostly on things that cannot be auto-updated Feb 21 13:17:33 kanavin: right, it makes sense, I just wanted to be clear about the bits I didn't take Feb 21 13:17:55 kanavin: I did redo the gnuconfig one to move to a more recent point in git history Feb 21 14:53:12 adelcast: mind if i rewrite opkg-unbuild in shell (and contribute)? Feb 21 14:53:41 currently it's a python2 script, not very portable Feb 21 14:53:57 also overkill for the task of un ar/tar ing Feb 21 14:54:05 * armpit does his auh work on weekend Feb 21 15:22:59 rburton, gtk+ has been renamed to just gtk, so I guess we can name the gtk4 recipe simply gtk :) never liked hardcoding version numbers in PN Feb 21 15:23:50 kanavin: it was handy to allow 2 and 3 to coexist Feb 21 15:24:24 RP: 2, 3 and 4 will coexist, as gtk+, gtk+3 and gtk_4.x Feb 21 15:24:33 morning sgw_ Feb 21 15:24:41 kanavin: right, but 5 won't :) Feb 21 15:24:59 RP: morning back at you! Feb 21 15:25:34 armpit: I updated the curl commit message btw, thanks Feb 21 15:25:59 RP: no :( but then it would depend on how incompatible it is with 4.x Feb 21 15:26:10 RP, I saw.. thanks Feb 21 15:26:15 kanavin: right. I'm thinking too far ahead Feb 21 15:34:55 Hi, 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. Feb 21 15:35:35 I'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. Feb 21 15:35:48 Any opinions, advice, war stories? Feb 21 15:36:11 evadeflow, 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. Feb 21 15:36:19 (We're using NXP's publicly-available support layers, with very small mods to fsl-image-qt5.) Feb 21 15:37:08 @kanavin: Thanks for the response. Feb 21 15:37:12 you 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. Feb 21 15:37:33 3.5.2 means you do have a quite old release Feb 21 15:38:10 Yeah, it's a bit older than NXP's latest. Feb 21 15:39:32 So... you recommend updating the `poky` layer to the current master and start fixing all the things that break, one at a time? Feb 21 15:39:55 'poky' layer, and all other layers to their respective master branches Feb 21 15:40:04 and then start fixing Feb 21 15:40:20 at some point you have to do it anyway, so might as well make a habit of staying close to upstream Feb 21 15:40:29 Oh, update *all* the layers. Feb 21 15:40:36 * evadeflow Gulps. Feb 21 15:40:55 I see why you said it's "very difficult". Feb 21 15:41:05 well, they should be keeping up with yocto upstream, or then they're not maintaining properly Feb 21 15:41:17 That's just what I needed to know, thanks. Feb 21 15:41:58 This isn't likely something we'll be able to do in "a few days", we need to block off a whole sprint for it. Feb 21 15:42:51 I'd even claim you can't estimate this in advance Feb 21 15:43:00 if managements asks you to, say 'a few sprints' Feb 21 15:44:08 Good idea! Feb 21 15:45:54 also, explain to them the concept of 'technical debt' :) Feb 21 15:46:30 you've accumulated debt by sticking to an old yocto release, and it's time to re-pay it Feb 21 15:49:40 I'll definitely make that case. Feb 21 15:50:29 RP: fwiw, I couldn't reproduce the testsdk gdk-pixbuf issue. Clean build works fine, wipe-tmp-and-use-sstate also works fine. Feb 21 15:50:38 RP: might be again one of those distro specific issues :-/ Feb 21 15:51:43 RP: but then the distro here was ubuntu 18.04, precisely what I use Feb 21 16:27:32 In my current project, there's an append recipe in one of the upstream layers that contains `PACKAGECONFIG_remove_imx = "eigen python3"`. Feb 21 16:28:55 I'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. Feb 21 16:29:09 How do you undo that removal syntax in an append? Feb 21 16:29:55 (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.) Feb 21 16:33:13 Aigh. I suppose I'll try `PACKAGECONFIG_append_imx = "eigen python3"` in my append. Feb 21 16:35:00 kanavin: thanks for trying. I wonder if it depends which distro the sstate was built on? Feb 21 16:35:43 evadeflow: remove is a nightmare to undo, its near impossible. Only way is anonymous python which resets the variable Feb 21 16:35:51 RP: might be :-/ which makes it fiendishly difficult to reproduce Feb 21 16:39:57 RP: Wow. That's useful info, thanks. (Some dim memory in the back of my mind was nagging at me that this would be tricky.) Feb 21 16:41:22 my 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 variable Feb 21 16:41:31 course that doesn't help if you werent the one that added the _remvoe, but.. Feb 21 16:42:02 Clever! Feb 21 16:42:50 I also try not to use _remove anywhere in oe-core. It really is a tool of last resort Feb 21 16:42:55 evadeflow, 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. Feb 21 16:43:16 kergoth: that is a good tip Feb 21 16:44:10 _remove and bbappends are those things in Yocto I'm not a great fan of :( Feb 21 16:44:24 they're *so* easy to misuse, and and often are Feb 21 16:44:55 ugh, yes i hate it when a distro scatters their settings all over the distro layer when they dont have to Feb 21 16:45:20 I think people in general don't get the concept of a 'distro config' Feb 21 16:45:28 so they put stuff anywhere else, except that Feb 21 16:45:35 bbappends, local.conf, etc. Feb 21 16:45:55 also, there is some kind of mental barrier to writing own image recipes Feb 21 16:46:58 better examples out there could help with that Feb 21 16:47:29 kanavin: an "antipatterns" section in the manual might help too Feb 21 16:47:43 If you find yourself doing X, do Y instead Feb 21 16:47:48 RP: do we have one? Feb 21 16:48:04 kanavin: a section? probably not Feb 21 16:48:16 kanavin: could have though Feb 21 16:49:00 hmm, I can't fix this problem with a change to both the autobuilder and helper code. gah. Feb 21 16:49:09 I 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 template Feb 21 16:49:25 recipetool new-image? *shrug* Feb 21 16:49:32 kergoth: totally. I'd love to see that Feb 21 16:49:47 kergoth: if you don't write it, file a bug? Feb 21 17:01:17 adelcast: 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? Feb 21 17:01:49 sure, i'll create a bug for now. might implement it too, but fighting other fires just this second (as usual..) Feb 21 17:03:14 i 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? Feb 21 17:03:28 adelcast: ah it's broken for me because the shell commands in the python (... :-/) assume bourne shell via >& . the most classic bashism Feb 21 17:03:33 kergoth: thanks, I know the fires problem all too well Feb 21 17:03:58 kergoth: I suspect not, people take time to adapt to the new tools Feb 21 17:04:07 kergoth: not sure how you speed that up Feb 21 17:04:49 yeah, 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 :) Feb 21 17:11:02 Hi, how can I run bitbake with a single thread as in make -j1? Feb 21 17:11:55 gsalazar: 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, though Feb 21 17:18:56 I should adjust PARALLEL_MAKE with PARALLEL_MAKE = "1"? I was doing PARALLEL_MAKE=1 Feb 21 17:19:19 I should set it globally? with export? or is there a conf file? Feb 21 18:01:55 JPEW:is there is latest setup on icecc the OE wiki has one but its from 2013 Feb 21 18:18:55 So... 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: Feb 21 18:18:57 python () { d.setVar('PACKAGECONFIG', 'python3 eigen ' + d.getVar('PACKAGECONFIG', False)) } Feb 21 18:19:43 Alas, everything builds fine, but... I can tell from the debug prints I put in that `python3 eigen` is NOT being (re-)added, as desired. Feb 21 18:22:00 (Oh, slight mispaste. I tried both True/False for the 'expand' parameter. It didn't seem to make a difference.) Feb 21 18:22:20 I guess it could be an issue with layer priority(?) Checking... Feb 21 18:30:03 _remove is final operation Feb 21 18:30:10 it can not be undone Feb 21 18:41:59 khem: No, I should probably update it.... although I tried not to change the setup to much Feb 21 18:44:20 JPEW: so all I need is INHERIT += "icecc" and that it ? Feb 21 18:44:27 I have nodes working ok now Feb 21 18:44:47 Ya, and twiddiling the blacklist.... I need to do better about keeping it accurate :( Feb 21 18:44:48 icecream-sundae can list all the nodes Feb 21 18:44:55 Yep Feb 21 18:46:49 Hmm, the OE wiki wants my personal biography to get an account... I feel like this is some sort of test for a secret organization Feb 21 18:48:05 this was due to spam it was getting in past Feb 21 18:48:26 accounts were being created by bots Feb 21 18:48:48 Ah Feb 21 18:52:15 jpew, just convince me you are not a dirty spammer Feb 21 18:52:30 I only approve about 30% Feb 21 18:52:38 I really do not need more busines offers Feb 21 18:53:29 Crofton: I can convince you, but I'll need $9.99 from you first ;) Feb 21 18:53:57 Crofton: I already had an account, I apparently I just forgot the password Feb 21 18:54:26 JPEW: WARNING: icecc-create-env-native-0.1-r2 do_configure: Cannot use icecc: invalid ICECC_ENV_EXEC Feb 21 18:54:51 Yep, known issue. The warning is just saying "I can't use icecream to compile this!" Feb 21 18:55:36 YOCTO #9618 Feb 21 18:55:43 only one request tight now, here is what passes for a bio Feb 21 18:55:45 Hi, letting you know that http://GetaBusinessLoan365.com 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: http://GetaBusinessLoan365.com Minimum requirements include your company being established for at least a year and with current gross revenue of at least 120K. Eligibility and . . . Feb 21 18:55:51 OK so it means its only complaining for this one packahge ? Feb 21 18:56:35 khem: You'll see that warning for several recipe that can't use icecc Feb 21 18:56:49 Usually because CC isn't defined Feb 21 19:00:52 JPEW:thats no problems ok. Feb 21 19:01:02 JPEW: I Can see both nodes whirring now :) Feb 21 19:02:38 JPEW: so the toolchain gets built on one host ? Feb 21 19:02:46 or does it spread the native and cross jobs too Feb 21 19:03:26 khem: icecc creates a toolchain tarball and transfers it over Feb 21 19:03:51 so it will have to wait for toolchain pieces to finish then Feb 21 19:03:59 or does it do with every job Feb 21 19:04:52 The nodes have a cache of toolchains, it only sends it over if the node doesn't already have it Feb 21 19:05:38 JPEW:ok and where can I look at icecc workspaces on nodes Feb 21 19:05:56 Its configured on the node itself but usually...... Feb 21 19:06:35 just now I see cmake-native building on a differnet node so native is shipped Feb 21 19:06:47 so looks ok Feb 21 19:06:51 /var/cache/icecream Feb 21 19:07:35 Here is the script that OE passes to icecc to create the toolchains if you are curious: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/icecc-create-env/icecc-create-env/icecc-create-env Feb 21 19:08:08 And OE generates the toolchains into work-shared/ice/ Feb 21 19:10:40 how does it interact with sstate Feb 21 19:11:12 It works fine, but enabling changes all the hashes. Feb 21 19:11:51 So you can't share sstate between a build with INHERIT += icecc and one without Feb 21 19:13:09 JPEW:if I dont want to use /var/cache/icecc but something like /mnt/var/cache/icecc Feb 21 19:13:11 If 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 hashes Feb 21 19:14:00 You have to change the config for your local icecc daemon Feb 21 19:14:01 ICECC_DISABLED would disable the distributed compile isnt it ? Feb 21 19:14:17 Right yes. Feb 21 19:14:58 So if you want to share sstate, use INHERIT += "icecc" everywhere, then use ICECC_DISABLED to control if icecream is actually used or not Feb 21 19:15:03 (Thats what we do here) Feb 21 19:31:18 khem: Updated the wiki Feb 21 19:31:36 JPEW: awesome Feb 21 19:32:01 JPEW:so at this time either icecc or sstate Feb 21 19:32:07 both cant complement each other Feb 21 19:33:38 Well, 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 produce Feb 21 19:34:53 khem: But you couldn't share with some random published sstate cache (I think OE-core has one?) Feb 21 19:35:23 khem: Although, hash equivalence servers would help with that ;) Feb 21 19:42:35 users can use INHERIT += "icecc" thats a central policy we can easily push that to everyone Feb 21 19:43:14 we dont consume random sstate cache, we build every day and try to use that Feb 21 19:43:26 and its built by same builders that do CI works Feb 21 19:47:49 khem: Ya sounds exactly like what we do. I suspect it will work fine then. Feb 21 19:49:59 evadeflow: I'd try a delVar then setVar Feb 21 19:50:41 evadeflow: although that could have the unfortunate side effect of clearing the flags so you may need to preserve those too Feb 21 20:00:08 JPEW:once I change ICECC_BASEDIR to something other than /var/cache/icecc icecream-sundae is not listing the node Feb 21 20:00:13 JPEW:it that known ? Feb 21 20:00:31 Hmm, I'm not sure. I've never tried changing it. Feb 21 20:01:23 it will be common since / is small on nodes and there is another mount with large storeage Feb 21 20:02:51 Did you restart iceccd? Feb 21 20:11:26 RP: thanks for delVar() suggestion. Trying this now: https://gist.github.com/evadeflow/d4d81484d760a85b88cd215c83a2be0b Feb 21 20:12:12 khem: 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 ... Feb 21 20:12:20 khem: or I missed something? Feb 21 20:12:31 It resulted in a bunch of QA warnings, so... I'm skeptical. Feb 21 20:16:44 * armpit misses everything Feb 21 20:18:25 evadeflow_: you need to go a d.getVarFlags and then set them again too Feb 21 20:19:04 RP: Oh, okay. (That probably explains why it didn't work. :-) ) Feb 21 20:19:18 otavio: you did not miss Feb 21 20:19:52 JPEW:yes disappears after restart Feb 21 20:33:41 khem: I'm not sure, you might try starting the daemon manually in the foreground? Perhaps it can't contact the scheduler anymore Feb 21 20:33:52 Or maybe your PC is the scheduler.... Feb 21 20:39:22 kergoth: what are your thoughts on http://lists.openembedded.org/pipermail/bitbake-devel/2018-October/019449.html ? Feb 21 20:39:37 kergoth: I like the idea apart from the way its playing with __builtins__ Feb 21 20:39:52 kergoth: any suggestion on how we could do that better? Feb 21 20:55:29 JPEW: does scheduler has to know ICECC_BASEDIR Feb 21 20:55:37 I guess not Feb 21 20:56:02 khem: I don't think so, but usually when a node disappears it's because it can't talk to the scheduler anymore Feb 21 20:56:32 JPEW: yeah Feb 21 20:56:47 I guess there might be more involved Feb 21 20:56:56 Ya Feb 21 21:00:45 New news from stackoverflow: Yocto's ROOTFS_POSTPROCESS_COMMAND not working? Feb 21 21:24:05 RP: 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, they Feb 21 21:24:05 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__. Feb 21 21:25:20 or just rely on OE_IMPORTS for the import and just let it look it up as is, even easier Feb 21 21:25:51 kergoth: I was wondering if we could tie it to OE_IMPORTS somehow. How easy would that be from your own layer? Feb 21 21:26:16 kergoth: would you mind replying on the bitbake list please? (or I can copy this there) Feb 21 21:26:34 kergoth: I was pinged about that patch and I think the idea is good, we just need a better API Feb 21 21:26:42 yeah, i'll reply Feb 21 21:26:45 kergoth: might as well try and get it right for a change! Feb 21 21:27:18 kergoth: thanks! Feb 21 21:57:18 Is there a way to remove an inherited class through a bbappend? Feb 21 21:58:38 no Feb 21 21:58:48 Thanks rburton **** ENDING LOGGING AT Fri Feb 22 02:59:56 2019