**** BEGIN LOGGING AT Fri Sep 15 03:00:01 2017 Sep 15 06:44:08 j #raspberrypi Sep 15 08:04:30 sgw, about start_getty, I have possibly fixed the scipt Sep 15 08:23:04 hello Sep 15 08:23:57 is there a way to output the current built version of a package using bitbake ? like "bitbake -c getversion mypackagename" ? Sep 15 08:45:59 hello, can anyone tell me whether its possible to produce both sysvinit and systemd images from the same build directory? or must I have two separate build directories? Sep 15 08:46:54 if I can do this in a single build directory, could someone provide me with an example on how to write a proper local.conf for that? Sep 15 09:24:22 eduardas_m, you can do it at image level. See http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#selecting-an-initialization-manager Sep 15 09:33:35 Crofton: context please? Sep 15 09:44:32 ant_work: thank you Sep 15 11:04:18 We're attempting an upgrade to Pyro, and I'm noticing that meta-nodejs does not have a pyro branch (yet?). Anyone have any experience with nodejs on pyro? Sep 15 11:11:05 sveinse: I use pyro and the morty nodejs branch with no problems Sep 15 11:14:22 FabKna: Thanks Sep 15 11:34:01 This is a bitbake recipe of my image that I am trying to build: https://pastebin.com/zv1TRKMi Sep 15 11:35:02 Though I try to use systemd, I do not get the systemd package added in the final image Sep 15 11:36:05 ant_work: do you have any idea why adding systemd described in the way above does not work for me? Sep 15 11:36:56 the image builds, though the rootfs does not have the contents of the systemd package, like systemctl or journalctl, etc. Sep 15 11:38:08 eduardas_m: distro features should be set in distro definition, not in the image recipe Sep 15 11:38:16 eduardas_m: alternatively in your local.conf file Sep 15 11:39:50 eduardas_m, yep, move out lines with DISTRO_, these do not belong to images Sep 15 11:40:59 kanavin: thank you for the insight... it would be nice if bitbake somehow noticed that the place for DISTRO_ is not appropriate, though Sep 15 11:43:16 ant_work: do I move only DISTRO_FEATURES_append and DISTRO_FEATURES_BACKFILL_CONSIDERED? or all of the lines 56-60? Sep 15 11:43:58 eduardas_m: everything from 56 downwards. Sep 15 11:44:20 eduardas_m: also whats the point of inheriting another image, and then adding a load of stuff, and removing more stuff. just write your own image recipe... Sep 15 11:44:37 well, there is more, before, as well to put in machine.conf I'd say... Sep 15 11:44:49 also the IMAGE_FEATURES_append on line 48 won't work as you didn't add whitespace Sep 15 11:47:24 bbl Sep 15 11:51:11 rburton: thank you... but I am still unsure: how do I build both systemd and sysvinit images in same build directory using same local.conf? Sep 15 12:36:57 eduardas_m: you don't. they have to go to separate build directories. Sep 15 12:45:57 Compiling pyro for the first time. With per-task progress-bar. Nice! How is this implemented? I.e. how I can adopt my recipe to it? Sep 15 12:52:45 kanavin: I thought that was possible because of this description: http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#using-systemd-for-the-main-image-and-using-sysvinit-for-the-rescue-image Sep 15 12:53:52 sveinse: only possible if the underlying task output something that can be used for the progress estimate (e.g. cmake's percentages) Sep 15 12:54:48 kanavin: So if the recipe would output xx% to stdout, this would be interpreted and displayed, is that what you're saying? Sep 15 12:55:54 sveinse: yes, but I don't know the exact details Sep 15 12:56:09 kanavin: yes, thanks. I can grep for it. Sep 15 12:57:12 eduardas_m: you, right, seems that you can enable systemd and sysvinit distro features at the same time, and you can configure images to exclude the systemd bits Sep 15 12:57:35 eduardas_m: you need to see what core-image-minimal/rescue do to achieve this Sep 15 13:01:16 kanavin: core-image-minimal uses packagegroup-core-boot, so it won't be able to use sysvinit if main image uses systemd Sep 15 13:01:22 as far as I understand Sep 15 13:01:59 eduardas_m: if you want to build images with both then have both distro features but control what init manager is used per-image-recipe Sep 15 13:04:59 rburton: could you please elaborate? what parameter do I use in each image recipe to set the init system? Sep 15 13:05:30 VIRTUAL-RUNTIME_init_manager = "systemd" <-- the init manager is systemd Sep 15 13:06:37 rburton: and in local.conf I need to have DISTRO_FEATURES_append = " sysvinit systemd"? Sep 15 13:07:07 yes Sep 15 13:07:20 rburton: understood, thank you Sep 15 13:07:38 ah no the init manager can't be set per image like that as the packagegroup gets in the way Sep 15 13:07:53 so your sysv image would need to not use core-image-boot, but that's not a massive hardship Sep 15 13:08:13 assuming that your non-sysv image is a minimal one, you'll want to build the package list explicitly anyway Sep 15 13:12:55 rburton: did you mean non-systemd image actually? Sep 15 13:13:34 erm, yes Sep 15 13:13:35 sorry Sep 15 13:13:40 because my systemd image is the huge one for the user and the sysvinit image is for recovery Sep 15 13:13:56 ok, now it is clear Sep 15 13:29:38 Which -native recipe provides the sha1sum command? On Debian it comes from coreutils, but that would be overkill. Sep 15 13:30:02 If there is nothing, do I really need to emulate it in Python? Sep 15 13:30:15 can you not use the host command? Sep 15 13:30:28 rburton: it's not in the whitelisted tools list. Sep 15 13:30:34 ah Sep 15 13:30:38 easily extended Sep 15 13:31:35 I can also do do_compile in Python and use hashlib. Sep 15 13:44:10 hi Sep 15 13:44:57 I am not sure to be at the right place to ask the following question... Sep 15 13:45:50 How can I remove the following warning in Yocto after having disable syslogd from busybox configuration ? WARNING: busybox: NOT adding alternative provide /etc/init.d/syslog: /etc/init.d/syslog.busybox does not exist Sep 15 14:27:07 kanavin, meta-sdr has a recipe that needs python-mako not the three version Sep 15 14:28:32 Crofton: it could go to meta-python then, but really you should plan for python 3 transition Sep 15 14:32:34 Crofton: so the suggested fix is to investigate whether the recipe in meta-sdr can be moved to python 3 with minimal effort Sep 15 15:45:56 https://autobuilder.yoctoproject.org/main/ is ready for work again. Sep 15 15:47:13 rburton: the qemu-native isn't as ready as I thought tomorrow, to enable gl in spice, I had to upgrade spice a bit more (done, only nativesdk-spice fails for now), then to enable opengl in qemu itself (with glx PACKAGECONFIG) which results in http://errors.yoctoproject.org/Errors/Details/156041/ so I'll have to look a bit more later Sep 15 15:47:35 lol s/tomorrow/yesterday/g Sep 15 15:47:46 JaMa: still good progress, great stuff **** BEGIN LOGGING AT Fri Sep 15 16:05:51 2017 Sep 15 16:16:54 kanavin, I push on gnuradio to finish python3 transition also Sep 15 16:16:58 and Qt5 Sep 15 16:17:19 ant_home: you pinged me yesterday? Sep 15 16:18:23 halstead, thanks Sep 15 16:23:18 BTW I did get approval to go to Prague.. I'm all registered and will be there for both the OE and YP days.. Sep 15 16:26:18 is there a way to do an _append on all but one machine type? Sep 15 16:26:42 trying to mangle https://github.com/flatpak/freedesktop-sdk-base/blob/1.6/meta-freedesktop/recipes-devtools/gcc/gcc_6.2.bbappend together with https://pastebin.com/natpMbWh Sep 15 16:26:55 obviously need the gcov links to be TARGET_PREFIX unless TARGET_PREFIX was mangled Sep 15 16:27:19 fray, going to be a lot of people at OEDEM Sep 15 16:27:25 could just do REAL_PREFIX = ${TARGET_PREFIX} then REAL_PREFIX_qemuyada I guess? Sep 15 16:31:50 Hey, After my new build yesterday when I do a smart update it is trying to delete my -dev package Sep 15 16:31:57 is there any reason for this? Sep 15 16:32:29 instead of upgrading it it’s trying to remove it Sep 15 16:33:24 https://pastebin.com/PnMtpzvu Sep 15 16:33:49 I did change my recipie but I don’t think I did anything to affect the -dev of the package Sep 15 16:36:15 The image does install the dev package but instead of upgrading it SMART will try to remove it Sep 15 16:37:41 sgw, about the grep failing on tty names with spaces. I will send a fix later Sep 15 16:38:02 ant_home: Ok, thanks so much Sep 15 16:48:30 Should I expect hg as a fetcher working in pyro? Sep 15 16:49:42 I get an error ** Unknown exception encountered with possibly-broken third-party extension mercurial_keyring, which does work on the same setup in krogoth Sep 15 16:52:09 Crofton: I won't :-( Sep 15 16:56:53 otavio, we'll miss you Sep 15 17:02:48 armpit: RP: could we backport the interp/#! patches to pyro ? E.g. simila/related to https://bugzilla.yoctoproject.org/show_bug.cgi?id=11965 Sep 15 17:02:49 Bug 11965: major, Medium+, 2.5, dengke.du, NEW , autogen-native: /bin/sh: bad interpreter: Permission denied Sep 15 17:05:20 Hmm. YPD-EU2017 looks very interesting. Sep 15 17:11:38 sveinse, what is the url? Sep 15 17:12:07 Crofton: to what, the YPD? Sep 15 17:12:26 https://www.yoctoproject.org/yocto-project-developer-day-europe-2017 Sep 15 17:12:56 thanks Sep 15 17:13:01 mostly for other to to see Sep 15 17:13:23 sure Sep 15 17:14:18 I'm thinking about participating. Given that we have been using yocto for 3 years or so Sep 15 17:15:36 curious about the advanced track yet to be announced Sep 15 17:21:35 How can mercurial_keyring be built for hg native? Sep 15 17:22:55 From what I can see, the problem is that hg is built and run in the sysroot, but it inherits the user's .hgrc, which contains an extension mercurial_keyring (which is needed for the auth for the URL), but the sysrooted hg does not support that and it stops Sep 15 17:24:22 sveinse: i can see two solutions: 1) write a recipe for mercuial-keyring-native, 2) add hg to hosttools and hg-native to assume-provided Sep 15 17:25:36 rburton: How specifically do I do the 2nd item? hosttools += 'hg' and assume-providede += "hg-native" ? Sep 15 17:26:01 yes Sep 15 17:26:05 thanks Sep 15 17:26:19 former to allow it to be symlinked into hosttools, latter to stop it being built Sep 15 17:26:30 i'm assuming the recipe is hg-native and not mercurial-native, correct if wrong Sep 15 17:26:44 * rburton has no intention of ever using it Sep 15 17:27:33 * sveinse 's employer only use hg for repos. /me trying to change that.... Sep 15 17:29:05 import hg to git? export git to hg for pushing.. ;) Sep 15 17:29:19 (Had a friend at a compnay that would only use SVN that did that) Sep 15 17:30:44 fray: On our shedule to migrate to git. We're blocked by a upstream bug in hg which blocks our migration, and the attention for the bug has been tremendously silent Sep 15 17:31:14 i've bamboozled myself Sep 15 17:32:22 somehow, i got an existing kernel recipe in another meta-layer to generate patches under our layer, meta-abc, and i don't see how that happens Sep 15 17:32:27 the package is 'mercurial-native', but the cmd is hg, so I suppose its assume-provided += 'mercurial-native', while hosttools should be 'hg', right? Sep 15 17:33:35 lol, I can't imagine why they would ignore a bug that makes it easy for someone to not use their code.. ;) Sep 15 17:34:01 i want to do the same for u-boot and i can't get it to work. Sep 15 17:34:07 the original recipe is meta-variscite-fslc/recipes-bsp/u-boot/u-boot-variscite Sep 15 17:34:26 fray: yes, strange, right Sep 15 17:35:05 i've created a meta-abc/recipes-bsp/u-boot/u-boot-variscite_%.append, but devtool won't generate the patch there Sep 15 17:35:12 over the past 12 years.. we migrated CVS -> SVN (went back to CVS) and then to git.. and have been on git ever since Sep 15 17:36:42 fray, we did cvs|sourcesafe (shrug) -> svn -> hg. The latter decision was 3 years ago, back when hg and git were on almost equal footings, so we made the wrong bet, and now we are migrating to git Sep 15 17:48:08 nm it's working... Sep 15 17:58:19 Hi guys, where can I find some best practices regarding the 'clean' target in bitbake recipes? (I'm working from scratch, not using yocto/oe). Sep 15 18:37:50 spooky_d: what do you mean 'best practises' if you're defining the behaviour then its sort of up to you.. Sep 15 18:39:44 For example I'm trying to write a chain of rules in such a way that when a build fails, retrying will remove existing data and rebuild everything in that recipe. Sep 15 18:39:49 I'm not sure how to do this. Sep 15 18:43:39 we do that by having build artifacts go into a separate directory, and putting that in [cleandirs] so bitbake empties it Sep 15 18:43:58 (well thats not actually what happens a lot of the time, but is effectively what would happen) Sep 15 18:44:46 eg task[cleandirs] = "foo" means that before task runs, foo is an empty directory Sep 15 19:07:12 RP, rburton, armpit, Do you have anything to queue on yocto.io? I'll need something to build in an hour or two. CentOS7.4 update today so I'll need to pay extra attention. Sep 15 19:47:02 heyho Sep 15 19:47:38 any hints on how figure out where one last (wrong) -mfpu setting comes from? Sep 15 19:48:04 already changed the DEFAULTTUNE variable Sep 15 19:48:19 crazy_imp: bitbake -e Sep 15 19:48:30 and check the preprocessed output Sep 15 19:53:59 khem: ok, thanks. so far there's no -mfpu=neon in there, can it hide in some expression? Sep 15 19:54:20 or might it be caused by using cmake in the recipe? Sep 15 19:54:21 no, Sep 15 19:54:58 if it is still showing up in your final cmdline, then you have the component's own build system doing it Sep 15 19:55:18 so you have to fix the Makefiles or whatever it uses Sep 15 19:58:55 my CMakeLists.txt doesn't set it, my recipe sets FULL_OPTIMIZATION and BUILD_OPTIMIZATION, but not with -mfpu=neon. Sep 15 19:58:55 Oh, it makes sense, I didn't know about the cleandirs thing :) Sep 15 19:58:57 Thank you! Sep 15 19:59:06 (and sorry for the late acknowledgement) Sep 15 19:59:36 already ran bitbake -c cleanall $recipe and rebuild. it's still ending up in the files generated by cmake Sep 15 20:00:05 halstead: poky-contrib:ross/mut please Sep 15 20:00:22 rburton, Sweet. I'm moments away from being back online. Sep 15 20:01:21 rburton, Would you like to queue it? Sep 15 20:05:24 khem: hrm, looks like it's gone now. but it's still listed with with -frecord-gcc-switches in the binaries. so that's likely another problem now Sep 15 20:05:41 rburton, Started https://autobuilder.yocto.io/builders/nightly/builds/545 Sep 15 20:06:43 crazy_imp: you might want to do a complete clean build for this component Sep 15 20:06:58 does it use some other prebuilt library or something? Sep 15 20:07:11 it might be merging the note sections Sep 15 20:09:20 complete clean => -c cleanall ? Sep 15 20:09:20 do you have a requirement to record compiler cmdline ? Sep 15 20:09:59 you could also dump it into debug info with -grecord-gcc-switch option Sep 15 20:10:13 no hard requirement, but since i'm benchmarking and changing flags, it's nice to get the information out of the binary itself Sep 15 20:10:19 yeah cleanall but be aware it will delete the srcs too Sep 15 20:10:29 ok. Sep 15 20:10:50 these are not the options you use. but these are expanded options that cc1 sees Sep 15 20:11:16 i'm fine with deleted sources, it can fetch them from my git Sep 15 20:12:24 see http://sprunge.us/LCVV Sep 15 20:12:38 this is what gcc -O2 hello.c will pass to compiler Sep 15 20:12:57 ah, -fverbose-asm :) Sep 15 20:15:43 so its between gcc and cc1 that gets recorded Sep 15 20:16:02 so its not exactly all options that you see there but some of them Sep 15 20:16:40 if you pass -v option to cmdline then you can see the options that are passed to cc1 by gcc driver Sep 15 20:16:42 halstead: thanks Sep 15 20:16:49 rburton, Thank you. Sep 15 20:16:59 rburton, Do you expect this one to be green? Sep 15 20:17:05 erm greenish Sep 15 20:17:13 blue may be :) Sep 15 20:17:19 Good to know. :) Sep 15 20:17:58 for partial color blinds it will look same rburton Sep 15 20:24:35 khem: you were right, another needed lib still had -mfpu=neon in the options, now it's gone completly :) Sep 15 20:24:41 khem: thanks Sep 15 20:24:54 * khem wipes the crystal ball Sep 15 20:26:55 :D Sep 15 20:43:00 how I install my kernel modules onto the rootfs? I end up with the .ko files in /build/tmp/work/test-linux/kernel-module-test/1.0-r0/module.ko Sep 15 20:43:48 I want that module.ko to be inside my rootfs at /lib/modules/4.9.30-intel/ Sep 15 20:44:13 how can I* Sep 15 20:47:59 modules_install: $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install Sep 15 20:48:15 that's how I'm trying to install the modules in case someone was curious **** ENDING LOGGING AT Sat Sep 16 03:00:01 2017