**** BEGIN LOGGING AT Wed Jan 11 03:00:02 2017 Jan 11 04:21:06 khem: That's for the response, in the case I'm thinking of there would typically be *one* app in the image Jan 11 04:21:20 s/That's/thanks Jan 11 05:05:41 catch22: I think you should be able to do it like so, SOMEVAR_pn-somerecipe Jan 11 08:44:54 good morning Jan 11 09:40:30 mckoan: good morning Jan 11 10:16:52 on the machine layer there is this: do_rootfs[depends] += "u-boot-script-compulab:do_deploy" Jan 11 10:17:19 how do I remove that? I don't want to install a u-boot script Jan 11 10:18:23 I tried do_rootfs_remove but it fails Jan 11 10:22:12 aV_V: I don't think there is a clean way to remove that flag set without using python. Just modify the layer, it probably shouldn't be adding the depends like that anyways. Jan 11 10:22:44 aV_V: the clean way is to stop using crappy vendor layers :) Jan 11 10:22:55 that works too :) Jan 11 10:23:34 the layer is experimental, thats why is like that Jan 11 10:23:45 using a new vendor layer is like opening a box of candy Jan 11 10:23:51 xD Jan 11 10:24:19 jku, maxin: can one of you please look at the connman/musl problem in ross/mut? musl + kernel 4.9 headers = connman breaks Jan 11 10:24:20 all the candy is gone, and only the liquorish is left? Jan 11 10:29:24 how do I "ban" that recipe? u-boot-script-compulab Jan 11 10:30:11 or still if I ban it then will fail because of do_rootfs statement? Jan 11 10:31:41 aV_V: that wont help because your image do_rootfs task depends on it. You just need to modify the layer that adds the dependency. Jan 11 10:59:58 rburton: I *think* we might be ready to try recipe specific sysroots on the autobuilder Jan 11 11:02:01 !!!! Jan 11 11:02:23 RP: a bit surprised you didn't sneak a build on the cluster in secret Jan 11 11:02:33 * rburton -> dog walk, back shortly Jan 11 11:03:06 got the new libc building here now Jan 11 11:07:22 RP: wow, sounds like great progress Jan 11 11:09:51 joshuagl: I'll run an oe-selftest here and see how bad the breakage is there but I'm pleasantly surprised at how its working all of a sudden Jan 11 11:10:21 RP: "all of a sudden" :-D Jan 11 11:11:16 joshuagl: I fixed a bug at around 2am this morning which I'd kind of solved whilst trying to sleep but being unable to as it was bothering me Jan 11 11:12:11 RP: hopefully you slept better once that was fixed? Jan 11 11:14:11 joshuagl: yes although the wind kept me awake Jan 11 11:14:42 rburton: will do Jan 11 11:15:23 * RP wonders why oe-selftest takes 10mins just to load the tests Jan 11 11:15:49 oe-selftest seems like a good area to point some of our perf minded folk? Jan 11 11:16:04 joshuagl: it needs help for sure Jan 11 11:16:37 RP: worth filing a bug? Jan 11 11:17:16 joshuagl: for this specific thing, probably Jan 11 11:17:25 10mins to load tests is clearly nuts Jan 11 11:28:04 indeed :-/ Jan 11 12:02:26 doesn't take 10 minutes to load here Jan 11 12:02:53 also, there's a bug i now own filed yesterday that just 5 tests are responsible for 50% runtime, or something Jan 11 12:03:13 i suspect one is that the archiver causes a full rebuild so maybe it shouldn't be building an image Jan 11 12:03:44 khem: around? Jan 11 12:08:17 Hi, does anybody think it wouldn't be a good idea to make a patch adding (in insane.bbclass) the following QA test : Check if all files in ${sysconfdir} are listed in CONFFILES ? Jan 11 12:12:58 geoffrey_l: or you could just set CONFFILES=${sysconfdir} in bitbake.conf. pretty sure there was a discussion about this on the list. Jan 11 12:14:29 There is a driver on the kernel mainline that I use. The problem is that the driver version on the kernel that I'm using doesn't work. It does the driver version that is on the master branch. I don't want to change the branch, but just the master version of the driver. How I do that? Jan 11 12:15:33 rburton: So there is a recursive effect with CONFFILES on directory ? Jan 11 12:15:33 I mean, to add the newer driver to my yocto build Jan 11 12:17:05 geoffrey_l: oe-core 0d446ef0e5bbca7058eec7259e34f2a1637dfab1 is interestingly, as is #5200 Jan 11 12:20:49 rburton: Oh, thanks :) Jan 11 12:23:41 RP: build applicance failed on the AB as pip3 wasn't present :) Jan 11 12:27:06 rburton: can you give me an explanation of how rpm post-install scripts work in oe-core? I could figure out it from code, but maybe you talking is faster :) Jan 11 12:27:23 all that run-postinsts stuff Jan 11 12:27:36 hm now i need to remember ;) Jan 11 12:27:46 rburton: you can redirect me to someone else Jan 11 12:27:47 the magic happens in the package_rpm class Jan 11 12:27:59 give me a second, i can remember Jan 11 12:29:03 no, package_manager.py Jan 11 12:29:19 grep for SCRIPTLET_FORMAT and you'll be close Jan 11 12:30:15 iirc, basically the postinsts are dumped by rpm instead of being executed, and then we execute them manually Jan 11 12:30:35 yes this is the sort of thing that needs to be written down in english as its non-obvious Jan 11 12:33:06 kanavin: scripts/postinst-intercepts/ is worth knowing as well but I assume you do from all the g-i work Jan 11 12:33:24 joshuagl: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10874 fwiw Jan 11 12:33:26 Bug 10874: enhancement, Medium+, 2.3 M3, leonardo.sandoval.gonzalez, ACCEPTED , oe-selftest: 35% of the testing time is concentrated in 5 tests (out of ~200) Jan 11 12:33:56 jku: actually I don't, it was not necessary for g-i Jan 11 12:34:15 rburton: when does the manual execution happen, on first boot? Jan 11 12:34:23 at rootfs time first Jan 11 12:34:27 then anything remaining on first boot Jan 11 12:35:00 rburton: ah, so rpm does attempt to run then? Jan 11 12:36:01 rburton: I'm at that point where dnf/rpm4 run them during bitbake core-image-minimal, and obviously there's an explosion of failures Jan 11 12:36:09 i *think* that we tell rpm not to, and we do explicitly at rootfs time instead Jan 11 12:36:25 rburton: but how is that different from just letting rpm run them? Jan 11 12:36:38 i'm guessing that rpm won't pass $D for target rootfs Jan 11 12:37:25 rburton: yeah, this is the kind of thing that ought to be documented in plain english Jan 11 12:37:30 totally Jan 11 12:37:48 rburton: in fact, we should insist on well-commented code, or lines in recipes that do unusual thing Jan 11 12:38:02 kanavin see rootfs.py: _run_intercepts() Jan 11 12:39:35 hmm, does it actually run all postinsts there or just the intercepts? Jan 11 12:42:33 see, this is the reason I threw away existing code :) Jan 11 12:45:48 ah here it is I think meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts Jan 11 12:47:21 I guess that's just on first boot though Jan 11 13:10:38 RP: rburton: what's correct way to define a task only if some variable is set and does it make sense to do it at all? Jan 11 13:12:42 for example: defining do_efi_populate and add it before do_image_wic makes sense only if EFI and USING_WIC variables are set Jan 11 13:15:05 I don't see a lot of examples of this in meta/classes/, so I guess the overhead of defining tasks unconditionally is not that big Jan 11 13:17:25 one option would be to bail out o the task early if the variables are not let Jan 11 13:17:28 not set, even Jan 11 13:17:45 or write anonymous python to define the tasks Jan 11 13:18:13 probably neater to always have the task but let it do nothing if the variable isn't set Jan 11 13:25:36 you know i wish rm_work wouldn't cause the world to rebuild if toggled Jan 11 13:30:09 rburton: thank you. that's what I did. Just wondering if it's correct way. Jan 11 13:45:33 Has a qemu update to 2.8 been considered? Jan 11 14:08:31 pohly: afaik it hasn't been rejected. anything in 2.8 to push for the upgrade? Jan 11 14:09:35 rburton: the qemu-tpm patches are based on it. But after looking at this more closely, I find that they also apply cleanly to 2.7, so that alone isn't a reason for updating. Jan 11 14:12:30 pohly: alimon should be in charge of updating qemu Jan 11 14:13:13 pohly: also, there's always a default reason to update to new versions; we avoid updating if there's a specific reason not to :) Jan 11 14:14:23 quick question: I do chown 0:network ${D}${base_sbindir}/ip.iproute2 but the symlink /sbin/ip created by ALTERNATIVE_TARGET[ip] = "${base_sbindir}/ip.${BPN}" is still root:root Jan 11 14:14:55 how do I change the owner of the symlink? is there a standard way or do I also have to chown it (googling revealed nothing) Jan 11 14:15:46 (i'm grepping the sources now for some hints) Jan 11 14:17:32 aratiu: chown -h Jan 11 14:17:44 man chown ;) Jan 11 14:18:18 but the symlink is only created when update-alternatives run, so no Jan 11 14:18:36 i do wonder why the perms of the symlink matter? Jan 11 14:19:10 rburton: good question, checking now Jan 11 14:19:46 apparently there are systems where symlink ownership can't even be changed at all, so I'd say it does not matter Jan 11 14:20:16 you can think of the symlink as a tiny file with the contents pointing to the actual file Jan 11 14:20:40 as long as you can read the pointer, nothing else should matter Jan 11 14:21:43 it doesn't matter! yupi Jan 11 14:21:51 thank you both Jan 11 14:25:05 a symlink just tells the system to look somewhere else, so the perms on the target are what matter Jan 11 14:26:35 * kanavin has convinced rpm4 to install packages for yocto's weird architectures \0/ Jan 11 14:27:31 i do wonder what's the purpouse of having permissions on symlinks, they must be used for something... Jan 11 14:28:35 I think Linux doesn't have permissions on Symlinks Jan 11 14:28:38 Other systems do Jan 11 14:29:16 I guess to complicate unix file access logic even further Jan 11 14:29:24 by adding another layer Jan 11 14:30:25 chgrp -h can change the ownership on a symlink, which is what aratiu was after Jan 11 14:30:37 When do I add BBCLASSEXTEND = "native" and when "BBCLASSEXTEND = "native nativesdk"? Jan 11 14:31:10 pohly: do you mean whats the difference between native and nativesdk? Jan 11 14:31:13 I only need -native, but I think we had cases in Ostro where BBCLASSEXTEND = "native" then led to issues with producing an SDK. Jan 11 14:31:29 hm shouldn't have Jan 11 14:31:39 if you only need a native recipe then you might as well just inherit native Jan 11 14:32:20 but if you want the tool in a sdk as something you can run then you'll need to inherit nativesdk and put nativesdk-foo in the SDK Jan 11 14:32:22 rburton: so what's the rationale? Jan 11 14:32:36 still not sure what you're actually asking to be honest :) Jan 11 14:33:19 i think the only purpouse of permissions on symlinks is to provent other from unlinking them Jan 11 14:33:28 *prevent Jan 11 14:33:32 Basically I am enabling the native version of a recipe by adding BBCLASSEXTEND = "native", and I am wondering whether I should go for "native nativesdk" instead, because someone might also want it in an SDK. Jan 11 14:34:14 yeah probably safest Jan 11 14:34:29 armpit: ping? Jan 11 14:34:43 aratiu: unlinking only depends on write permissions of the containing directory (unless that directory has a sticky bit), so no, that's not it either. Jan 11 14:34:58 That's probably the only case where the owner of a symlink is relevant, though. Jan 11 14:38:26 pohly: do you are planning upgrade qemu? Jan 11 14:38:42 alimon: no, I was just wondering. Jan 11 14:39:35 I might want to get some of Stefan's qemu-tpm patches included (currently experimenting with that), but that should work with both 2.7 and 2.8. Jan 11 14:40:34 pohly: ok, i plan to upgrade qemu before m2 closes Jan 11 14:43:40 i wonder if we actually need grub_git.bb Jan 11 14:44:20 why is the recipe totally different to grub_2.00 Jan 11 14:44:34 ah, its an arm thing, okay Jan 11 14:45:26 grub is one of those projects stuck in perpetual beta Jan 11 14:45:40 they had another beta recently after years of commits Jan 11 14:46:44 not sure i want to know why grub depends on diffutils Jan 11 15:02:12 rburton: please don't delete grub_git I need it :) Jan 11 15:02:30 also grub-efi_git.bb which I get from meta-measured Jan 11 15:03:28 I was thinking maybe to move grub-efi_git.bb from meta-measured to OE-core, there's logic duplication between these recipes Jan 11 15:03:44 we generally need to clean up all the grub stuff Jan 11 15:03:57 (as in, tidy up the recipes, not remove them :) Jan 11 15:05:07 kanavin: yes, agreed Jan 11 15:06:09 why do we need grub-2 and grub-git Jan 11 15:06:20 if 2.00 is ancient then lets just move to a git snapshot Jan 11 15:06:37 rburton: that's exactly what I did with my repos Jan 11 15:06:44 I'm only using the git versions Jan 11 15:06:59 aratiu, sgw, armpit: there's quite some overlap between meta-security and meta-measured (trousers, tpm-tools, ...). Perhaps it would make sense to consolidate recipes in one place? Jan 11 15:07:28 rburton: or that recent beta Jan 11 15:11:44 rburton: i did the memory test overnight as you suggested. It ran two passes and did not detect an error. Jan 11 15:17:33 any /bin/sh experts_? Why would it refuse to run a command even though the path to it is in PATH? Jan 11 15:17:51 /var/tmp/rpm-tmp.tc1PPh: 4: /var/tmp/rpm-tmp.tc1PPh: mkdir: not found Jan 11 15:17:51 /var/tmp/rpm-tmp.tc1PPh: 6: /var/tmp/rpm-tmp.tc1PPh: cat: not found Jan 11 15:17:51 /var/tmp/rpm-tmp.tc1PPh: 28: /var/tmp/rpm-tmp.tc1PPh: cat: not found Jan 11 15:18:18 both are in /bin and /bin is in PATH Jan 11 15:21:14 i'd triple check that $PATH isn't mangled inside the script Jan 11 15:21:30 kanavin: i dont know, but if you have an exe in path, but it depends upon dynamic libs, then maybe the libs are not availabe Jan 11 15:21:51 davis: it works if I specify the command with full path Jan 11 15:22:20 you can test that with tthe ldd command. if you run ldd /bin/mkdir and it shows missing entries thatg woluld be the prob Jan 11 15:22:34 rburton: base-passwd_3.5.29.bb, line 81 Jan 11 15:22:57 put echo $PATH in that :) Jan 11 15:23:14 rburton: Jan 11 15:23:14 /sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin Jan 11 15:23:14 /var/tmp/rpm-tmp.8J8V4R: 4: /var/tmp/rpm-tmp.8J8V4R: mkdir: not found Jan 11 15:23:14 /var/tmp/rpm-tmp.8J8V4R: 6: /var/tmp/rpm-tmp.8J8V4R: cat: not found Jan 11 15:23:14 /var/tmp/rpm-tmp.8J8V4R: 28: /var/tmp/rpm-tmp.8J8V4R: cat: not found Jan 11 15:23:54 brute force by wrap it in strace? Jan 11 15:25:19 rburton: works like a charm if I prepend /bin/ to cat and mkdir Jan 11 15:25:44 I guess I have to try strace, yeah Jan 11 15:27:27 but now ---> sushi Jan 11 15:27:51 thanks for ideas! Jan 11 15:28:36 hey, guys Jan 11 15:28:51 how can I install my shared library without pkgconfig? Jan 11 15:29:46 pkgconfig has nothing to do with installing. it's used to get cflags/libs/ldflags for your dependencies, or check whether your deps are installed Jan 11 15:29:50 so the question really doesn't make sense Jan 11 15:30:59 so I have to use do_install function? Jan 11 15:31:16 Ox4: what build system are you using? Jan 11 15:31:53 qmake Jan 11 15:33:11 again, don't understand theq uestion. whether you need to define do_install depends on your buildsystem and whether you inherit a class that does it for you, pkgconfig is irrelevent Jan 11 15:33:26 perhaps you meant autoconf/automake? autotools.bbclass does define a do_install, but plenty of other classes do as well Jan 11 15:33:28 Ox4: I'm not an expert in that, but try 'inherit qmake5' - I would expect that to work Jan 11 15:33:30 including ones for qmake Jan 11 15:33:43 yeah, qmake5 is a good suggestion, assuming it's qt5 Jan 11 15:34:02 then you don't need to define do_* steps at all, unless your code does weird things Jan 11 15:34:34 ok, but I need my.so library be installed to /usr/lib/ Jan 11 15:34:39 with symlinks Jan 11 15:34:59 again, either you define do_install to do so, or a bbclass does so Jan 11 15:35:08 the qmake class will do it Jan 11 15:36:56 ah, understood. Thank you Jan 11 15:37:47 generally manually copying or linking files in do_install is discouraged where possible in favor of having the underlying buildsystem do it, hence the bbclass for that buildsystem usually handles it Jan 11 15:38:09 generally writing your own do_thing() is discouraged :) Jan 11 15:38:10 so if the underlying buildsystem doesn't do so properly, for example, we're better off patching it to do so than manually hacking up do_install Jan 11 15:38:13 indeed Jan 11 15:38:45 it's very likely there's a class that does all the necessary steps Jan 11 15:39:25 the only real exception is hand-crafted buildsystems, custom makefile-based setups, etc Jan 11 15:45:16 anyone ever have seen an error like this: Jan 11 15:45:30 File: '~/poky/meta/classes/patch.bbclass', lineno: 118, function: patch_do_patch Jan 11 15:45:43 *** 0118: import oe.patch Jan 11 15:45:51 Exception: ImportError: No module named patch Jan 11 15:46:02 meta/lib/oe/patch.py exists, yes? Jan 11 15:47:39 yes it does Jan 11 15:48:29 ... maybe to give a first hint why I maybe run in this ... I try to have a structure where I have some meta layers next to the poky folder not inside Jan 11 15:49:57 and also having the build folder then next to them ... so like Jan 11 15:50:03 doesn't matter where your layers are Jan 11 15:50:18 bitbake doesn't care, nor does oe-core Jan 11 15:51:10 ok ... also its not a problem if i source via ... . poky/oe-init-build-en Jan 11 15:52:01 RP: is there a way to control the way that bbappends are applied from different layers? Jan 11 15:52:28 i *thought* layer priority would make a difference, but it doesn't *seem* to ,AFAICT. Jan 11 15:54:26 darknighte: You'd have to look at the code, I don't remember offhand Jan 11 15:54:47 * kergoth had thought appends were applied in priority order, but hasn't looked at the code in a while Jan 11 15:55:26 kergoth: I know I put a sort() in there a while back to make it deterministic Jan 11 15:55:46 order from the disc wasn't good Jan 11 15:56:06 ah. maybe the order of operations is incorrect. we probably wnat to obey layer priorities, but where the priority is the same, use the sorted value by path, or so Jan 11 15:56:19 hmmm, i have avoided looking at bitbake code much until now. Jan 11 15:56:40 RP: kergoth: would one of you point me at the code? Jan 11 15:56:52 FWIW, I would agree with kergoth on that last bit. Jan 11 15:58:38 any way to check which python path bitbake uses? Jan 11 16:01:48 darknighte: collect_bbfiles() and get_file_appends() in cooker.py Jan 11 16:02:27 darknighte: looks like it respects BBFILES, appends found in BBFILES first get applied first Jan 11 16:03:14 darknighte: so depends how the layers build BBFILES Jan 11 16:03:39 ah, so it's based on BBLAYERS order, not layer priority. that's potentially confusing, since layer priority usually affects recipes, and bbpath/bbfiles is more about classes and config files and whatnot Jan 11 16:03:40 hmm Jan 11 16:05:05 * darknighte checks on layer ordering Jan 11 16:07:14 darknighte: note that if you used the mel setup script and added all layers with -l, not manually, the bblayers order should reflect the bbfile priority, but you'd have to re-source after changing the priority to re-sort Jan 11 16:08:22 kergoth: thanks for the tip. in this case, I did that with all but my two manual layers, which I added to the bottom of bblayers.conf. Jan 11 16:08:49 ah, that would put them last in bblayers, so last in bbfiles (since your layers probably += to BBFILES, anyway) Jan 11 16:09:29 that sounds right Jan 11 16:10:42 more accurately, that jives with what I'm seeing. Jan 11 16:11:31 not sure if it makes a difference, but I'm using bitbake v.1.28.0 Jan 11 16:13:58 hmmm, so, the order of the config fragment does not appear to follow the BBFILES or layer ordering Jan 11 16:21:17 bblayers has layer-a, then layer-b, with prios of 5 and 6 respectively, both with appends to a kernel recipe Jan 11 16:22:04 however, the frag in layer-b shows up before the frag in layer-a. Jan 11 16:22:25 making the prio of layer-b a 4 has no apparent effect Jan 11 16:23:11 as i said yesterday, use bitbake -e yourrecipe to examine how SRC_URI was constructed. you'll see what was applied to it in what order Jan 11 16:24:09 either source the setup scripts after changing priorities, or just manually move your layers to the top/beginning of BBLAYERS manually Jan 11 16:24:13 right, I have. it shows the order in BBFILES of layer-a then layer-b, but SRC_URI shows config frag in the other order Jan 11 16:24:36 hmmm ... ok ... seems like it's a bad idea to change the default BBLAYERS variable from /the/absolute/path/prj/poky/meta \ to ../poky/meta in the bblayers.conf file Jan 11 16:25:13 that's correct, yes, as the current directory changes during the bitbake build Jan 11 16:25:40 so it's also not smart to do it for "my" custom layers? Jan 11 16:26:24 kergoth: k, I'll try manually re-ordering the bblayers and see if that has the desired result Jan 11 16:26:56 mdnneo: you shouldn't be using relative paths in BBLAYERS at all. what layers you happen to include isn't relevant Jan 11 16:27:35 mdnneo: you could, however, use paths relative to ${TOPDIR} if you know ahead of time where the build directory is relative to the layer paths Jan 11 16:32:18 one more question: I have hpp file installed to image/usr/include and in the another package I have #define "this_file.hpp" in the source code. But I have a compilation error that there is no this_file.hpp Jan 11 16:32:26 sorry for my english :-( Jan 11 16:37:38 You used "" rather than <> Jan 11 16:37:43 Ox4: just some wild guess but first it is #include "this_file.hpp", or and if can you try to change to #inlcude_ Jan 11 16:38:09 which, incidentally, would have failed even outside of oe/yocto :) Jan 11 16:38:14 Ox4: if it is realy define shouldn't it look like #define MY_HEADER "foo.h" Jan 11 16:38:38 indeed, i figured he was trying to include the thing Jan 11 16:38:41 weird Jan 11 16:39:35 actually AFAIK "" should look in the inc path as well ... but u never know Jan 11 16:43:30 yes, as I know "" looks in the local directory and then in the inc path Jan 11 16:46:00 Ox4: still would give it a try ... and maybe also just like kergoth mentioned the error should be independent of yocto ... try to build via the SDK for example maybe gives some clue on what went wrong Jan 11 16:52:19 kergoth: RP: I just found out that one of the layers I've 'inherited' has two 'collections' defined. what problems might this create? Jan 11 16:52:51 shouldn't be a problem, afaik Jan 11 16:53:04 darknighte: right, shouldn't be an issue Jan 11 16:53:32 kergoth: wouldn't it me nice to go and simplify all this stuff... Jan 11 16:53:42 thx Jan 11 16:55:57 kergoth: I've been idly thinking of merging process and xmlrpc server backends and removing the server abstraction Jan 11 16:56:57 could make sense. could always add an *option* to also listen on another port for xml/rpc control if someone really needs to control bitbake from a different language, rather than having it as a separate server type Jan 11 16:57:06 anything we can do to simplify the codebase would be good Jan 11 16:57:48 kergoth: right, the idea would just be to optionally listen for xmlrpc on a port Jan 11 17:02:44 * kergoth nods, would be on board with that idea Jan 11 17:09:24 kergoth: thank you, it works now Jan 11 17:28:41 * RP triggers a morty 2.2.1 build Jan 11 17:32:53 RP: huh i see what you mean about selftest taking ages to load tests Jan 11 17:33:12 it didn't do it earlier when i was running archiver tests, but just started the devtool tests and its hanging at loading tests Jan 11 17:33:23 bitbake cooker/processqueue/knotty are pinning the CPU Jan 11 17:43:29 I am seeing Can NOT get PRAUTO, exception timed out Jan 11 17:43:34 on archlinux Jan 11 17:43:40 uses python 3.6 Jan 11 17:44:11 latest master, I saw someone else reporting it as well Jan 11 17:45:11 yay arch ;) Jan 11 17:45:42 yes, someone else reported that 3.6 was broken and they moved back to 3.something else and it worked Jan 11 17:52:38 khem: yeah. me too. had to downgrade to 3.5.2 Jan 11 17:54:04 khem: sudo pacman -U cd /var/cache/pacman/pkg/python-3.5.2-3-x86_64.pkg.tar.xz cd /var/cache/pacman/pkg/pyalpm-0.8-1-x86_64.pkg.tar.xz got it working again for me for now Jan 11 17:54:32 err... sudo pacman -U /var/cache/pacman/pkg/python-3.5.2-3-x86_64.pkg.tar.xz /var/cache/pacman/pkg/pyalpm-0.8-1-x86_64.pkg.tar.xz Jan 11 18:03:55 RP: image*.class code looks quite messy. Would it make sense to split it to several files - one file per image type? Jan 11 18:04:16 ed2: definitely not, that would result in a lot of files Jan 11 18:05:01 ed2: I'm open to better partitioning of the existing files though or splitting out where it makes sense and isn't too granular Jan 11 18:05:17 rburton: I have wondered why my build machine sounds like its chewing cpu Jan 11 18:05:51 * RP runs top, sees guile and decides to head afk Jan 11 18:05:54 RP: I'm going to move wic-related code to wic.class. It's quite a bit of code, I'd say. Jan 11 18:06:20 ed2: wic could make sense but maybe as image_wic.bbclass ? Jan 11 18:08:29 RP: image-wic.bbclass would be more consistent with existing image-vm.bbclass image-prelink.bbclass etc Jan 11 18:14:02 I've built the same image on qemux86 and "intel-core2-32" machine, on the "intel-core2-32" /var/log is linked to /var/volatile/log as one would expect but the folder /var/volatile/log is missing. As well as other things I may not be aware of. Does this ring a bell with anyone? Jan 11 18:14:07 I'm building on Ubuntu 16.04 Krogoth modified core-minimal Jan 11 18:23:00 Strike5150: It's missing on the device or in the build rootfs? Jan 11 18:23:25 Strike5150: Because the directory is created by initscripts from what I can tell Jan 11 18:25:00 pohly: i upgraded qemu to 2.8.0, i'm doing some testing in arm, ppc, mips, x86 before send the patch to the ML Jan 11 18:25:35 rewitt: Its missing from the rootfs Jan 11 18:26:00 Strike5150: Ok that makes sense because it gets created on boot Jan 11 18:26:08 rewitt: I'll have a look at initscripts see whats going on there Jan 11 18:26:13 Strike5150: Hence the "volatile" part Jan 11 18:27:36 downgrading python is a workaround, however sooner or later this will hit bitbake Jan 11 18:27:38 rewitt: does volatile in this context mean wiped each power cycle? Jan 11 18:36:27 Strike5150: It shouldn't I don't believe, that is to say once the directory is created it shouldn't need to created it next boot Jan 11 18:37:07 rewitt: Ok so volatile means might move around based on machine type or something along those lines, not volatile during runtime Jan 11 18:42:44 I can see that initscripts package installs ./populate-volatile.sh, and it is supposed to look at /etc/default/volatiles and add everything in those files. Of which "l root root 0755 /var/log /var/volatile/log" is there. But running it does nothing ... Jan 11 18:43:03 not even an error Jan 11 18:44:35 Strike5150: It really is volatile between boot, and I'm not sure why it is that way by default. There is even a person asking about it in a bug. https://bugzilla.yoctoproject.org/show_bug.cgi?id=3397#c7 Jan 11 18:44:36 Bug 3397: normal, Medium, 1.4 M4, Qi.Chen, RESOLVED NOTABUG, /var/log and /var/cache should not be on volatile storage (tmpfs) Jan 11 18:45:45 Strike5150: Now why it isn't in the rootfs at build time I don't know, but it shouldn't be a problem because that script also gets ran on boot, everytime. Jan 11 18:46:56 So I can verify the script does run, but it doesn't add /var/volatiles/log Jan 11 18:47:12 I know this will work properly if I change machine type to qemux86 Jan 11 18:47:29 That is the only change I made between these two versions Jan 11 18:47:49 Strike5150: Ah so meta-intel changes it's behavior, I see Jan 11 18:47:59 It seems to yea Jan 11 18:48:22 clsulliv: You around to help out Strike5150? Jan 11 18:49:10 Strike5150: I was missing the behavior being *different*, sorry Jan 11 18:49:39 heh np, thanks for helping me understand it Jan 11 18:50:10 This might be a stupid question, but is there any kind of version manager for the ADT, similar to the android sdkmanager tool? Jan 11 18:50:16 I can't find any reference to ./populate-volatile.sh or to initscripts in meta-intel Jan 11 18:52:50 themikenicholson: As far as I know there isn't. But if you build an extensible sdk, one of it's features is to be updatable. Jan 11 18:54:25 Strike5150: Could you maybe in one sentence describe the issue again? That way I can easily chuck it to one of the meta-intel people Jan 11 18:55:12 Strike5150: s/one sentence/concisely :) Jan 11 18:56:20 rewitt: Ok I'll do that Jan 11 18:59:22 rewitt: I hope I just messaged you, or that you at least received the sentance in some form :D Jan 11 18:59:39 Strike5150: Yep got it Jan 11 19:00:04 rewitt: Ok great thanks for the support Jan 11 19:00:29 rewitt: Looking at the user guide now, specifically I'm looking for a way to rev the ADT and even let users install multiple ADT versions simultaneously. Ideally we'd have a file in our application repo calling out what ADT version a specific branch of the application should build against. Jan 11 19:01:13 Strike5150: If you can I'd honestly suggest sending that to the meta-intel mailing list, easier for them to get back to you that way. https://lists.yoctoproject.org/listinfo/meta-intel Jan 11 19:01:26 Strike5150: I should have said that originally, my bad Jan 11 19:02:01 rewitt: no problem, knowing where to send it is half the battle. Jan 11 19:03:04 themikenicholson: You couldn't have multiple extensible sdk's at the same time, outside of having multiple directories Jan 11 19:03:40 themikenicholson: But theoretically you could change between revisions, i.e. update actually means "switch rev" Jan 11 19:05:49 rewitt: switching rev might be a possibility, although our build machines would have to maintain a per-branch ADT somehow.. We need to do things like build hot-fix releases on an older version of an ADT while building an in-development version with a newer ADT Jan 11 19:06:37 We're coming from ltib where we had the entire ltib tree and packages checked into the applications repo so managing version of the rootfs happened naturally Jan 11 19:07:48 themikenicholson: Well the way it works is that it's all based on the metadata/recipes, it leverages sstate. So just like we can backport things to yocto 2.1, you should be able to do a similar thing Jan 11 19:08:20 rewitt: Just starting to look into this. I'll spend more time with the user guide and mess around some more. Thanks for sending me on the right path. Jan 11 19:09:19 themikenicholson: Don't thank me yet :), you may realize it doesn't meet your needs. But if it doesn't we'd really be interested in hearing where it could be improved. Jan 11 19:11:08 rewitt: We're just starting to switch from LTIB and an internal build tool that did some of the same things as the extensible ADT, etc. Should be interesting, hopefully we can give something back. Jan 11 19:59:41 I have run into an issue where sort.coreutils when being run produces Illegal instruction. This is why populate-volatile.sh is failing, its using a sort to sort the /etc/default/voltailes files and execute them in order Jan 11 20:01:04 So unrelated to meta-intel or anything intel Yay :D Jan 11 20:22:03 Strike5150: So the compiler is generating bad code? Jan 11 20:26:44 Strike5150: illegal instruction sounds exactly like something related to meta-intel. what hardware are you running on? Jan 11 20:27:47 * rburton reads backtrace a bit Jan 11 20:28:59 note that if you're running a meta-intel intel-core2-32 image in qemu then you;ll need to pass options to qemu to tell it to emulate a core2 Jan 11 20:29:12 we should make the bsp do that automatically now that runqemu is more flexible Jan 11 20:29:35 but basically if you're running stuff in a qemu session then use a qemu machine, they're faster Jan 11 20:29:43 (and better adapted for the virtual hardware) Jan 11 20:46:29 aehs29: hi, I'm looking at your change gummiboot->systemd-boot. are we getting rid of gummiboot? we still have mkgummidisk.wks and gummiboot.bbclass though. Jan 11 20:47:23 aehs29: wic fails to build mkgummiboot image: Error: unrecognized bootimg-efi loader: gummiboot Jan 11 20:48:35 did gummiboot get anywhere after it was taken in by the systemd project? Jan 11 20:48:45 I just remember the changes stopping on the gummiboot side Jan 11 20:49:37 JEEB: even if it didn't it's quite strange to be able to set EFI_PROVIDER = 'gummiboot' and not being able to build an image. Jan 11 20:49:46 true Jan 11 20:50:05 could be an overlook in the testing department Jan 11 20:50:18 it should be either completely removed or made backwards compatible Jan 11 21:00:22 ed2: there's a pending patch series to remove gummiboot entirely Jan 11 21:00:31 hasn't been merged yet Jan 11 21:01:24 kergoth: ah, now i understand. thank you Jan 11 21:14:21 ed2: theres a patch already to remove those as well Jan 11 21:14:43 ed2: systemd-boot already replaces gummiboot completely Jan 11 21:15:23 aehs29: thanks. I'll not touch it then. Jan 11 21:16:05 ed2: so theres 4 patches regarding the gummiboot change I think, I dont know why only 2 are merged, the others are on ross/mut Jan 11 21:16:39 aehs29: ok, let's wait then. Jan 11 22:32:55 armpit: based on your build results and branch contents I merged morty-next, added the fixes for multiconfig and then have triggered a 2.2.1 build Jan 11 23:13:25 hi, it's been a long time since I've used OE/yocto - how do I get around the fact that http://www.zlib.net/zlib-1.2.8.tar.xz is 404 ? I have the file, but just putting it in downloads does not work - I don't understand the format of the .done files Jan 11 23:22:10 linuxjacques, you need the .md5 file I think Jan 11 23:22:22 what version are you using? Jan 11 23:22:40 Crofton|work, morty Jan 11 23:22:48 hmm Jan 11 23:22:54 that should be fixed ASAP Jan 11 23:23:06 is it really 404, or just temporary fetch issue? Jan 11 23:23:07 I see even master branch still uses 1.2.8 Jan 11 23:23:45 Crofton|work, not sure - I can get to the site - it's possible it was removed because of a security issue (?) Jan 11 23:24:03 I get 404 also Jan 11 23:24:58 I can download 1.2.10, but not 1.2.8 nor 1.2.9 Jan 11 23:26:20 linuxjacques: that upstream just has a policy of sharing latest version only. If you configure other source mirrors it should work Jan 11 23:26:36 linuxjacques: see poky.conf for an example mirror that no doubt has it Jan 11 23:28:03 linuxjacques: we did change the url in master to one that works btw Jan 11 23:28:11 linuxjacques: so you could use that too Jan 11 23:29:21 RP, thanks Jan 11 23:31:42 yeah, it seems a lot happier now **** ENDING LOGGING AT Thu Jan 12 03:00:01 2017