**** BEGIN LOGGING AT Mon Jul 17 03:00:04 2017 Jul 17 07:37:11 pohly: WRT the glib/shared-mime-info issue: is the primary issue that the mime detection is wrong (claims text/plain when it's not) or that it needs to figure out what .gz means? Jul 17 07:38:16 jku: the result is text/plain when it should be gzip. Jul 17 07:38:34 And then code which relies on the type detection to do on-the-fly decompression fails. Jul 17 07:38:41 I ran into that with appstream-glib. Jul 17 07:40:27 One could of course argue that the type detection is on a best-effort basis and thus cannot be relied upon for anything besides perhaps informing the user. Jul 17 07:42:30 right. I think depending on shared-mime-info is the correct call in the end but that's what I was weighing... we could just try to fix the bug where it claims "text/plain" when it's not -- but that wouldn't really help you Jul 17 07:45:18 jku: for appstream-glib to work, both gzip and XML must be detected. So you are right, just distinguishing between text/plain and binary would not be enough. Jul 17 07:45:42 jku: see https://github.com/hughsie/appstream-glib/blob/master/libappstream-glib/as-node.c#L936 Jul 17 08:31:38 pohly: RP: #11767 looks similar to what's discussed here: http://lists.openembedded.org/pipermail/openembedded-core/2017-July/139000.html Jul 17 08:32:31 pohly: RP: Just wondering how that is supposed to work. It used to work somehow, right? Jul 17 08:34:53 ed2: I suspect that it worked before tmp/deploy/images was put under sstate control: all output for the current recipe went directly to it, and due to race conditions (or perhaps even explicit task ordering), functions like this do_image_elf found the expected files. Jul 17 08:34:59 ed2: Ah, so the issue is that its referencing the image in the final deploy directory Jul 17 08:35:11 pohly: I agree :) Jul 17 08:35:59 ed2: the images only have one deploy point. If they reference something which the images themselves are deploying, they need to reference it in the "pre-sstate" directory, not the post sstate one :/ Jul 17 08:36:41 ed2: the fix for do_image_elf should be to make it depend on do_image_cpio and let it look for the output in IMGDEPLOYDIR Jul 17 08:37:31 pohly: isn't it the same as Alejandro was trying to do and you're against it? Jul 17 08:38:33 ed2: depends on which recipe provides the .cpio. Jul 17 08:38:54 If it is always the same as the one where do_image_elf, then such a task dependency is okay, Jul 17 08:39:35 Haven't checked the bug in detail. But you might be right, if the cpio can also come from some other recipe, then we have the same problem. Jul 17 08:40:37 pohly: I think it's the same recipe. will try to add dependency as you've suggested and see if it works. Jul 17 08:46:17 RP: pohly: looks like dependency is already set: $ grep do_image_elf task-depends.dot |grep do_image_cpio Jul 17 08:46:18 "core-image-minimal.do_image_elf" -> "core-image-minimal.do_image_cpio" Jul 17 08:47:25 ed2: in which case its just looking in the wrong place since the deploy dir under sstate changes Jul 17 08:47:29 RP: pohly: changing --initrd=${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.cpio.gz -> --initrd=${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.cpio.gz seems to fix the build. Jul 17 08:47:40 RP: pohly: thank you! Jul 17 08:50:33 Has anybody had any experience with running winehq @ OE? Jul 17 09:14:49 ah, what is that now, db fails to build because libtool does not pass tag? This building qemuarm after armv5te Jul 17 09:22:48 RP: armv5 / armv5e are deprecated by gcc7. Building core-image-base I see that three packages (icu, gmp, glib) end up under /armv5e-oe-linux-xxx even if I set ARM_INSTRUCTION_SET = "thumb" in machine.conf. In fact these recipes set it to 'arm'. Are the feeds okay like that? Jul 17 09:24:35 I suspect there are issues with thumb code because the successive build for qemuarm failed: db fails for that strange libtool error. I see the db recipe is also patched for armv5.... Jul 17 09:27:37 fwiw JaMa forces 'thumb' for armv5 doing world builds Jul 17 09:27:58 nodistro does not Jul 17 09:53:02 ant_work: armv5 is totally deprecated or only non-thumb mode? Jul 17 10:02:00 nrossi: there? Jul 17 10:04:32 rburton: I am, just sat down Jul 17 10:08:26 nrossi: looking at the libgcrypt patch to sent to meta-mingw last year. it has a submitted tag, was that a patch on the list or a bug entry? Jul 17 10:08:46 basically wondering if we can drop it, or push it into oe-core to avoid pain on every upgrade Jul 17 10:09:04 *looks* like its still broken but i haven't tried using meta-mingw Jul 17 10:09:43 rburton: it was a patch on list, https://lists.gnupg.org/pipermail/gcrypt-devel/2017-January/004087.html. The maintainer was going to solve it differently (which was done for libgpg-error). I guess a nudge is needed to get it resolved :) Jul 17 10:09:51 RP: not yet totally afais Jul 17 10:09:53 https://gcc.gnu.org/gcc-7/changes.html Jul 17 10:10:09 will be removed in a future GCC release. Jul 17 10:10:50 abelloni, yes, qemuarm builds fine Jul 17 10:11:08 at least it runs in qemu, built with gcc7 Jul 17 10:11:43 (lot of sprintf() warnings around, though) Jul 17 10:13:29 good to know Jul 17 10:18:10 nrossi: thanks Jul 17 10:21:13 nrossi: would you be able to prod again? i can see the changes he meant in gpg-error Jul 17 10:21:39 rburton: yep, just searching for the email chain to reply to Jul 17 10:21:47 cheers Jul 17 10:51:13 rburton: any idea if you can split intltool-translated xml files into locale specific files somehow? e.g. shared-mime-info would become 200K instead of 2.2 MB... Jul 17 10:55:52 hello, is there a way how to build multiple kernels within one yocto build for one board ? Jul 17 11:32:47 eww, shared-mime-info is even worse in practice: It gets split into 800 tiny xml files. Everyone of them takes a block of course Jul 17 11:33:07 blocksplat! Jul 17 11:35:55 rburton: this is RE https://bugzilla.yoctoproject.org/show_bug.cgi?id=11792 -- is there an issue with adding 3.6MB of RRECOMMENDS to glib? Jul 17 11:35:56 Bug 11792: normal, Undecided, ---, jussi.kukkonen, NEW , glib: RRECOMMENDS shared-mime-info Jul 17 11:36:30 its a bit of a pain that its 3.6mb Jul 17 11:36:42 why isn't there a cached form Jul 17 12:42:20 abelloni, even known-good 4.4.8 does not boot if compiled by gcc7 Jul 17 12:42:43 now adding PREFERRED_VERSION_gcc-cross-${TARGET_ARCH} ?= "6.3%" Jul 17 12:43:26 just that, no other toolchain changes Jul 17 13:20:50 then it boots Jul 17 13:21:08 I do not suppose anyone here has got a Yocto build with the work area generated by (Gerrit) repo running under a Jenkins pipeline job have they? Not sure if I have hit some issue in that side of things or the creartive way that Phabricator (or rather Diffusion) handles git repos. Jul 17 13:24:10 lots of people use gerrit to schedule yocto builds Jul 17 13:24:49 say what the problem is and people might be able to help. its probably unrelated to gerrit or git :) Jul 17 13:35:22 The setup above results in repo init -u ssh://git@/diffusion/g/GitRepo.git -m repo/my_manifest.xml Jul 17 13:36:13 Then I see a failing job with `get ssh://git@url of internal server>/diffusion/g/GitRepo.git Permission denied (publickey,keyboard-interactive). Jul 17 13:36:13 Permission denied (publickey,keyboard-interactive). Jul 17 13:36:13 fatal: Could not read from remote repository. Jul 17 13:37:28 Now when I use a Git repo as the SCM type I can choose credentials from the drop down menu that allow access to the files. I cannot find that setting for the repo SCM manifest fetching bit. I am guessing that not having the credentials setup is blocking access to the manifest file. Jul 17 14:14:04 khem: SECURITY_NOPIE_CFLAGS vs SECURITY_NO_PIE_CFLAGS gives me a headache Jul 17 14:14:13 khem: can you remove one of them please? :) Jul 17 14:32:16 rburton: bitbake-selftest failed on ross/mut in bb.tests.fetch.GitShallowTest — any ideas? do you think that's the git upgrade? Jul 17 14:32:31 no thats kergoth's broken shallow fetcher Jul 17 14:32:40 there's a bug somewhere Jul 17 14:32:50 'broken', it fails on the AB "sometimes" Jul 17 14:33:47 oh, hooray! Jul 17 14:34:01 transient failures are my least favourite Jul 17 14:34:05 * joshuagl goes to find the bug Jul 17 14:38:24 hmm, lots of checkuri failures on morty. Do we want bugs for those? Jul 17 14:38:28 no armpit in here :-/ Jul 17 14:40:04 joshuagl: replicate on your own box, and if they still happen file a bug for them all? Jul 17 14:42:22 rburton: sure, seems sane Jul 17 14:42:32 although my box has caching proxy :-/ Jul 17 14:42:46 I shall try and setup something without right now Jul 17 14:50:10 rburton: think I'll try looking in some Jenkins/Pipeline areas for help. Jul 17 14:58:46 anyone else having problems with poky master and harfbuzz? https://pastebin.com/raw/6EnK12tM Jul 17 15:11:15 something in Ubuntu 14.04 isn't compatible with harfbuzz in master, installing things from http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#packages doesn't help. Jul 17 15:41:20 joshuagl: ugh, sorry about that, I'll see if I can find the time to dig into that today Jul 17 15:42:19 kergoth: thanks! Now I know it's a known issue I can ignore/update the correct bug as appropriate Jul 17 15:42:26 * kergoth nods Jul 17 16:13:09 sgw_: why does your pkgconfig patch need to use the pkgconfig binary with the arch in the name? Jul 17 16:13:40 rburton: take a look at sgw/pkg_wip, I have a new version yet again Jul 17 16:13:47 :) Jul 17 16:13:48 I was about to send v4! Jul 17 16:13:48 ok Jul 17 16:13:56 i'll stop testing then ;) Jul 17 16:15:27 rburton: yeah, I wonder how switching to pkgconf will work with pkg-config Jul 17 16:15:40 in theory just port whatever hackery you do Jul 17 16:20:27 rburton: v4 sent! Jul 17 16:20:44 sgw_: does it match was is in the branch i just pulled? Jul 17 16:20:47 rburton: this one has really had it's challenges! Jul 17 16:21:07 tweaking the behaviour in one very specific place withuot breaking anything else is fun isn't it Jul 17 16:21:11 minor tweek to commit message Jul 17 16:22:17 rburton: I think this version address rp's concerns. Jul 17 16:25:17 rburton: you looking at Haris's multi kernel patch? Jul 17 16:26:32 sgw_: i haven't yet but also note that zedd hasn't commented on it Jul 17 16:26:57 rburton: that a good or bad sign? Jul 17 16:27:24 lol not sure Jul 17 16:28:26 rburton: I was testing with an older version, I will check v4 now, it seems to be a reasonable solution Jul 17 16:28:33 cool Jul 17 16:28:42 zeddii: prod about haris's multi kernel patch on the list Jul 17 17:37:43 rburton, RP: can you expedite the merging of "[PATCH 01/30] oeqa/core/loader: Switch method definition for _make_failed_test"? It fixes a regression that prevents updating refkit to current OE-core master. Jul 17 17:38:11 I've not seen it in master-next, nor ross/mutt. Jul 17 17:41:13 pohly: just 1/30? Jul 17 17:41:50 rburton: yes. It's independent of the patch series. Jul 17 17:43:44 Hmm, looking further I'm not actually sure whether it's enough. alimon said that it would fix the issue that we were seeing in refkit, but we had the commit that is getting fixed by that patch already in refkit before, without it causing problems. Jul 17 17:44:01 Probably the code was never called, and it gets called. That's something that I'll also have to look into. Jul 17 17:44:34 Either way, merging the fix should be fine - it just doesn't help as much as I had hoped. Jul 17 18:22:46 Hello, Jul 17 18:23:16 I'm trying to compile automake-native 1.15.1 but it keeps failing because help2man cannot find --help for automake-1.15 Jul 17 18:23:21 I'm using krogoth revision Jul 17 18:23:29 And I have no idea how to fix this issue Jul 17 18:23:34 Also I'm using arch linux Jul 17 18:33:17 any ideas ? Jul 17 18:42:06 rburton: mesa 17.1.5 stable release is out; it fixes some known issues and merges one of patches. Bump is sent Jul 17 19:05:07 rburton: please don't take alimon's patch, it still isn't correct. Jul 17 19:05:47 pohly: ' Switch method definition for _make_failed_test'? Jul 17 19:05:53 rburton: yes Jul 17 19:06:01 ok Jul 17 19:19:27 pohly: my patch only makes visible the real exception into the test case Jul 17 19:19:48 pohly: can you show me the error log? Jul 17 19:41:51 I have some philosophical questions about storing the config/bblayers in SCM for reproducible builds. Is it bad to store the build/conf folder directly in git (and link it via submodules/repo tool/ or similar to the exact version of the layers) ? I know about the template directory method, but I don't like it because it requires testing via "local.conf" then updating the template, committing it, wiping the build/conf dir (such that the Jul 17 19:49:26 alimon: I sent an email. You need to handle yet another variation in Python 3.5. Jul 17 19:50:05 I also looked at how autobuilder manages this: it's basically printing the auto.conf based on yet another format of config file that's stored in git. Wondering if that's really necessary... Jul 17 19:50:10 pohly: :S, i see Jul 17 19:50:31 vbanea: your line got truncated, but yes its best not to put layers/config in scm. template files are the solution, yocto-autobuilder generates large chunks of config for us based on a few variables. Jul 17 19:50:48 pohly: i have been found this kind of non-compatibility in python sys libraries Jul 17 19:50:51 :/ Jul 17 19:51:13 alimon: you are overriding an internal Python method. It's not surprising that this breaks from time to time. Jul 17 19:52:05 yes Jul 17 19:52:09 You probably should add a unit test for this particular aspect, otherwise it'll cause problems again for the next developer who accidentally triggers the loader exception with a future, modified Python version. Jul 17 19:53:15 rburton: I'm not convinced about the template approach, because modifying templates and committing them would not update already existing configuration in build directories. Jul 17 19:53:16 pohly: other thing is why the default behavior in python unittest is to report this errors in runtime, Jul 17 19:53:36 vbanea: how do you propose to handle the requirement for absolute paths in bblayers.conf if you commit it to git? Jul 17 19:53:51 the ideal for local.conf is that the only content in it is DISTRO=mydistroname Jul 17 19:54:14 *maybe* machine if you support many machines and you can't just set that in the distro too Jul 17 19:57:07 It's useful to me to know the absolute paths issue.. is this the only reason that you know about? Jul 17 19:57:38 well what's wrong with a template bblayers, and then move all your configuration to where it should be: your distro conf Jul 17 19:57:40 rburton: absolute paths is pretty easy to address if the path is relative to where bblayers lives Jul 17 19:58:00 i've done it before, just use TOPDIR, and set TOPDIR relative to bblayers.conf, if needed Jul 17 19:58:06 but template is still better Jul 17 19:58:14 We added layers to bblayers.conf and our build machine does incremental builds Jul 17 19:58:24 alimon: probably because then errors in the tests or test classes end up in the usual test result reporting. Jul 17 19:58:29 so the build broke and people went nuts and want a solution Jul 17 19:58:36 Both approaches have their merits. Jul 17 19:59:27 IMO keeping the same build dir across multiple automated builds is a recipe for pain, too easy for some change to leak in if you aren't starting with a clean slate. if you want incremental builds, just use sstate Jul 17 19:59:50 that's what most do, afaik. it's certainly what we do, daily builds from sstate and weekly/release from scratch Jul 17 20:00:18 Hi Jul 17 20:00:55 So the recommended approach would be for the build machine to recreate its build dir for every build, while pointing to a peristent downloads path and sstate-cache path. Do I understand correctly? Jul 17 20:01:02 yes Jul 17 20:01:18 thank you very much, that's very valuable information Jul 17 20:01:55 building from sstate is a valuable code path to exercise, if the AB always does incremental builds then it won't exercise that path at all Jul 17 20:02:13 pohly: yes may be but that kind of errors are development related because isn't execute the real test, and for us is better to know when something is very wrong like a typo when importing certain module or something Jul 17 20:02:39 but yes i will add the other case and a unittest inside oeqa/core/tests Jul 17 20:04:17 hi, so I added udev-extraconf to my image so that the usb can auto mount. plugged in the USB and i can see it making /run/media/sda1 and there is nothing insides the folder. I run the mount command and the device isn’t mounted. But the script /etc/udev/scripts/mount.sh keeps saying successfuly mounted everytime and remove and plug the usb back in. Jul 17 20:04:35 It will mount successfully though when I run the mount command manually for the same directory Jul 17 20:08:23 We're a very small team maintaining our yocto recipes, and we've had the build work with "rm_work" active and fail with "rm_work" not active. While I realise that the root cause might be a badly written recipe, I need to track changes such as that in the build configuration. Jul 17 20:08:52 Would I put that in the distro conf? Jul 17 20:11:45 vbanea: failing with rm_work disabled but working enabled is the strangest error. but yes, that could be distro conf. Jul 17 20:12:07 (usually its the other way around, rm_work deletes stuff that other recipes were reading from the work directories) Jul 17 20:13:32 I know! Didn't investigate that yet, but I was just as surprised. Jul 17 20:22:12 If you had customers with different software needs from multiple upstream layers, would you just pile the layers for everyone or have different template dirs per customer? Adding layers would basically risk changing the output for an old machine/image i was thinking.. Jul 17 21:49:11 Hi Jul 17 21:50:42 how can i change systemd-udevd.service. I want to change a value in there. Should I do it as a pkg_postinst or is there a better way? Jul 17 22:04:39 HavoK__: patch it Jul 17 22:04:51 in a postinst is a horrible way :) Jul 17 22:31:32 hey, so, poky can be used both to build your own distributions, but is also a reference distribution unto itself? Jul 17 22:32:42 i have been told this and i'm not sure i understand. i figured a distro is something you could dd into an image and flash onto hardware. i'm not sure that i could dd poky and get anything useful Jul 17 22:42:06 no, that's not what a distro is for linux in general, and it's really not in oe context Jul 17 22:53:14 hmmm Jul 17 22:53:33 yocto docs call poky a "reference distribution" and i'm not sure what that means https://www.yoctoproject.org/tools-resources/projects/poky Jul 17 23:04:28 garbados: it serves as an example; you can use it as is (potentially with some tweaks), or just as a reference for creating your own custom distribution Jul 17 23:07:14 smurray, ah, ok. so it's a reference distro in the sense that to make my own distro, i might fork poky and build onto it? Jul 17 23:08:15 garbados: yes Jul 17 23:09:08 smurray, that makes sense, thank you :) Jul 17 23:09:18 garbados: np **** BEGIN LOGGING AT Tue Jul 18 02:14:51 2017 **** ENDING LOGGING AT Tue Jul 18 03:00:03 2017