**** BEGIN LOGGING AT Mon Jun 12 03:00:02 2017 Jun 12 03:30:56 the / file system i have created is read only Jun 12 06:04:09 morning all Jun 12 07:16:30 good morning Jun 12 09:57:55 pohly: Unfortunately the DISTRO_FEATURES change appears to trigger selftest sig change failures Jun 12 09:58:07 pohly: its not your patch as such but a bug in the code using those variables Jun 12 09:59:28 RP: can you fix that code? I wouldn't know where to start. Jun 12 10:02:31 pohly: I'm looking at it... Jun 12 10:03:16 Thanks. We have a working solution for refkit (albeit without the df- prefix), so it is not too urgent to get something merged. Jun 12 10:08:08 pohly: I think I know how to fix it.. Jun 12 11:34:17 hi Jun 12 11:54:30 Hi, i have a touchscreen device but if i build an ap in qt the touch input is not handled Jun 12 11:55:25 if i run tools like evtest and libinput-debug-events then i can see that the touchscrene input is working Jun 12 11:55:56 Btw i'm running wayland/weston Jun 12 12:05:26 MarcWe: this sounds like a qt issue, you should make sure qt is reading the correct input device file Jun 12 12:06:45 aratiu: oke can you give me a hint there ? Jun 12 12:56:03 which .bb file creates the initrd image Jun 12 12:56:12 or initial ram disk Jun 12 12:59:54 black_13: depends on what image you're building. the core-images use core-image-minimal-initramfs. Jun 12 13:01:12 that name "core-image" is the name of a .bbclass file correct? Jun 12 13:02:30 i have build an x86 iso image which does load the initial ram disk but root file file system on the in init ram fs is read only or is mounted read only Jun 12 13:03:08 is this by design or have incorrectly configured an option to the local.conf Jun 12 13:04:24 i'm not sure but i wouldn't be surprised if an ISO was read only by design, as its meant to be on a read only medium Jun 12 13:05:03 if you're not using the latest release then hddimg is read/write Jun 12 13:05:28 or if you are using a modern image then use wic images instead, the x86 wic image is a disc image which mounts readwrite Jun 12 13:18:24 i have noticed wic files have been but in the tmp/deploy area what are these? Jun 12 13:34:16 is there an intended way to have the currently built kernel be placed at e.g. /boot/zImage instead of a file + symlink? Jun 12 13:38:02 (50 Jun 12 13:40:45 when I run one of the basic yocto bitbake recipes it produces a wic file ... what are these Jun 12 13:42:28 black_13: https://git.yoctoproject.org/cgit.cgi/poky/plain/scripts/wic Jun 12 13:46:47 Ok could you give some context Jun 12 13:47:17 black_13: its a partition image Jun 12 13:47:32 black_13: run file on it and youll see it says its a partition table. just dd it to a usb stick or something. Jun 12 13:47:54 ah Jun 12 13:52:52 rburton: wic is a particular type of image you mean Jun 12 13:53:16 wic is the tool that makes them, the exact content depends on the BSP (and thus the instructions to wic) Jun 12 13:53:23 for x86 targets, its a partition image Jun 12 13:53:34 and then the when you run the wic program it takes this image and flashes the bits /dev/sda ... Jun 12 13:53:55 no, wic made the image Jun 12 13:54:00 to put it on a disk, just use dd Jun 12 13:54:54 i guess it would be useful if wic could write them (cc ed2) Jun 12 13:57:10 thank you for the context Jun 12 14:00:20 if I have two sstate caches from the same exact OE + layer versions, one built for machine A and the other for machine B, is it ok to merge them by copying one on top the other and reuse the resulting merged sstate? or do I invalidate it by the copy? Jun 12 14:01:06 what is sstate? Jun 12 14:04:33 aratiu: yes Jun 12 14:04:41 erm, yes to its ok Jun 12 14:04:56 thank you! Jun 12 14:04:59 the filenames contain the lookup key, so there can be no conflicts Jun 12 14:05:36 yocto's focus is not really to make live iso its to make an image that can dd ed into a flash Jun 12 14:05:51 would this be a correct statement Jun 12 14:06:32 black_13: no. the hddimg type is a "live iso" Jun 12 14:06:48 oh ... Jun 12 14:07:21 so if i see xxx.hdd that is something that can be dd into iso image Jun 12 14:07:36 black_13: there is a hybrid iso bbclass which is used specifically to build live iso images Jun 12 14:07:46 isoimage-isohybrid.bbclass IIRC Jun 12 14:07:54 oh Jun 12 14:08:19 ./scripts/lib/wic/plugins/source/isoimage-isohybrid.py in openembedded-core Jun 12 14:08:26 I use it all the time for live iso images Jun 12 14:08:45 oh Jun 12 14:09:01 do you have something on github i could look at Jun 12 14:10:24 here's a random public link with what we've been using in production a couple of years ago: https://github.com/ni/nilrt/blob/nilrt/comms-2.0/scripts/buildRecoveryISO.sh Jun 12 14:23:08 aratiu: national istruments Jun 12 14:33:12 aratiu: this was to build something that NI used boot linux and had some purpose Jun 12 14:45:50 yup Jun 12 15:17:56 hello, Jun 12 15:18:26 my deploy folder has a lot of images and takes up a lot of space; is it possible to tell yocto to keep only the last image ? Jun 12 15:18:49 top22: it already does Jun 12 15:25:01 kergoth: in my deploy/images/ I see a lot of .rootfs.* that are timestamped using YYYYMMDDHHIISS Jun 12 15:25:11 then you're using an old yocto release Jun 12 15:25:38 in which case there's a varaible to handle it, iirc it's RM_OLD_IMAGES or something, check the yocto project documentation for the version you're using Jun 12 15:27:25 kergoth: cool, thanks; just for information, i'm using the krogoth release Jun 12 15:28:30 np Jun 12 16:24:21 pohly: there is a bigger problem with your distro_features change Jun 12 16:24:34 Saur: thanks for the reminder about that patch, there is a bigger problem Jun 12 16:28:18 RP: I just got a déjà vu when I saw your commit so I had to look through the mail history. Jun 12 16:33:06 Saur: my point from back then does stand :/ Jun 12 16:34:37 RP: I guess theory and practice do not always match... Jun 12 16:36:17 RP: Btw, I see you have stacked my RPM changes in master-next. Assuming they make it into master, do you think it will be possible to get the corresponding changes into Pyro before the next release (I have a stack waiting for that)? Jun 12 16:40:47 Saur: maybe. I do have my concerns about instantly backporting patchsets like this. Its not in master yet... Jun 12 16:41:18 RP: No, I know, which is why I have waited with the corresponding stack for Pyro. Jun 12 16:46:28 * RP idly wondered who's idea whitelisting MACHINE as a vardep of MACHINEOVERRIDES was. Unsurprisingly it was mine 6 years ago :/ Jun 12 16:47:28 heh, always funny when you run "git blame" on some suspect line and find your own name. Jun 12 16:48:00 oops Jun 12 16:48:02 paulg: you can imagine how often that happens with OE for me :/ Jun 12 16:48:16 no doubt Jun 12 16:50:53 alias git blame "RP" Jun 12 16:51:30 Crofton|work: I'd probably make it rburton or Crofton ;-) Jun 12 16:51:41 RP: by the amount of code you have in repos, statistically you get more blames :p Jun 12 16:54:32 lol Jun 12 16:55:35 Hmm, I wonder if tinfoil's remote bitbake server handling would work from a regular non-memres bitbake task, to contact the current automatically running server. have a need to gather some info that can't be easily done from within a task, but don't think i'd be able to run a tinfil-based external script either due to the bitbake locking Jun 12 17:00:59 Saur: first casualty from your patches: https://autobuilder.yocto.io/builders/nightly-non-gpl3/builds/293/steps/BuildImages/logs/stdio :( Jun 12 17:01:40 kergoth: if its not memres it probably isn't listening :( Jun 12 17:01:55 kergoth: I guess if you use xmlrpc as the transport... Jun 12 17:02:13 * RP really wants to kill the osbolete server types and merge them Jun 12 17:02:55 have a need to organize my downloads by layer, but want to intelligently handle appends, so new sources added by an append are associated with that layer, which would be easiest with varhistory, but of course we don't generally enable varhistory for recipes without -e, .. Jun 12 17:03:30 and wanted to run that from inside a task, but might just shift it out and let our jenkins job do it Jun 12 17:07:37 RP: I guess it was inevitable. :( Jun 12 17:13:20 RP: I guess building only core-image-minimal plus our own (quite big) image successfully was expecting too much when it comes to other images. Jun 12 17:19:45 rburton: where do you queue up patches for master-next? Jun 12 17:30:53 Hello, I'm working on a somewhat simple problem. I've made a couple small edits to a git repository that I've cloned to my machine. And due to the nature of the repo I can't make a pull request with my changes (it's TI's repo), but I want to use bitbake to build the contents of the repo. Is there a way to configure bitbake to do this? I've tried modifying the existing recipe to look to the locally-cloned Jun 12 17:30:59 repo, and to the repo compressed as a tarball, but no dice. Jun 12 17:32:50 twall: Are you trying to build a recipe that uses the local git repo in the SRC_URI? Jun 12 17:35:27 yes Jun 12 17:37:18 twall: Did you try SRC_URI = "git:///path/to/repo..." (note the 3 slashes) Jun 12 17:37:40 twall: And make sure your changes are commited to the local repo Jun 12 17:38:19 Do I have to make a local commit or does a simple file change suffice? Jun 12 17:38:53 twall: No, you would need to actually commit it Jun 12 17:39:18 twall: And change the sha1 referenced in the recipe to the new SHA1 one of your commit Jun 12 17:39:46 twall: FWIW, I think there is probably an easier way to do what you want, but I don't remeber how off the top of my head Jun 12 17:41:03 ah, that would be it then. I just commented out the SHA line. And I'm certain that there is, but I'm fairly new to yocto/embedded linux dev in general, and I haven't found it yet after scanning through the manuals. I appreciate the help though! Jun 12 17:43:47 twall, also look at using a bbappend in a local layer so you do not need to modify meta-ti (?) Jun 12 17:44:05 Crofton|work: that's what I've been doing Jun 12 17:44:09 also, if you have issues with meta-ti, I'm sure denix would like to hear about them Jun 12 17:44:21 I'll keep that in mind, thanks Jun 12 17:49:47 twall: if you only have "couple small edits", it's easier to have them applied as patches in bbappend, than to carry an entire git clone... Jun 12 17:51:26 hmm...I should look into that. it's not much change to the code (changing a fourcc value in one of the ti gstreamer plugins) Jun 12 17:52:14 if I were to apply them as patches in a bbappend, where would I start on that? Jun 12 17:52:35 I've used bbappends only for modifying existing recipes in small ways, not actual code changes Jun 12 18:02:08 twall: "devtool modify -x " is probably a good start... Then modify the source in workspace/sources/ and when you are satisfied create the bbappend and patches with "devtool finish ". Jun 12 18:09:26 twall: I've never used devtool, but you could also use "git format-patch" to create .patch files in the original repository, then add them to SRC_URI_append in the bbappend file. Jun 12 18:10:21 +=, no need for _append there Jun 12 18:10:22 twall: e.g: SRC_URI_append = " file://my_changes.patch" Jun 12 18:10:26 unless you need to use overrides Jun 12 18:11:24 kergoth: I was always curious about that, is that the general rule for append vs +=? Jun 12 18:12:04 _append and _prepend are postponed operations, they happen at the end of parsing, rather than immediately. if there's no need for it, don't do it, it just adds confusion about what's done when Jun 12 18:12:15 well, technically they're applied at expansion time, now, but still Jun 12 18:14:14 kergoth: Ya, I knew they were postponed, I just wasn't sure which was preferred. For some reason I was thinking that _append was preferred and += was only if you needed it instead of the other way around Jun 12 18:14:55 it's less problematic than it used to be, now that it's applied at expansion/getvar time and we have _remove, but it can still add confusion Jun 12 18:16:19 kergoth: Makes sense. Thanks Jun 12 18:16:35 np Jun 12 18:27:20 RP: given 'd', do we have the original configuration metadata (cooker.data) available, from a recipe's task, short of walking the parents of the DataSmart objects? Jun 12 19:04:03 denix: Quick thing: I don't think bitbake is hitting my source directory. It reaches the point where it goes to configure the autotools configure script, then fails to find the script. Is there an environment variable that I should be setting earlier on that specifies the location of the source directory, or should i put my source directory somewhere else? Right now it's just in $HOME Jun 12 19:05:46 I have SRC_URI looking into the directory that the source code is currently in though Jun 12 19:10:06 twall: you are not using patches in bbappend, are you? Jun 12 19:10:49 twall: you might want to look into externalsrc.bbclass then Jun 12 19:13:29 Hi guys, I tried the mailing list, but I'm not getting help there, but I'm having issues trying to get a program cross-compiled with LLVM (https://gist.github.com/kratsg/10cf7835a83d4f17ad93173c8655c8e9) using this recipe: https://github.com/kratsg/meta-l1calo/blob/master/recipes-core/root/root_6.04.12.bb Jun 12 19:14:21 denix: I'm not using the patches in bbappend, no. what's different about the externalsrc.bbclass other than specifying a different SRC_URI and SHA1 hash in a bbappend Jun 12 19:18:01 twall: so, are you shortcutting fetch/unpack/patch then? Jun 12 19:19:06 twall: if you want to build from a local source tree directly then just use externalsrc Jun 12 19:19:13 twall: check the $TMP dir for your recipe - does it contain the original code or your modified one? also check the logs for what gets executed Jun 12 19:20:34 rburton: did you see my question above? do you have a separate repo with queued up patches for master? Jun 12 19:21:33 denix: I guess I'm shortcutting? Jun 12 19:22:10 All I did was attempt to redirect where bitbake is fetching the source from Jun 12 19:23:22 denix: here's the log paste. It's not super helpful. https://pastebin.com/t3mRjPs9 Jun 12 19:23:35 all I'm getting is that it can't find autogen.sh Jun 12 19:32:20 twall: what's your ${S} and why there's no autogen.sh? Jun 12 19:32:51 dumb question: how do i print ${S} Jun 12 19:33:03 (feel free to groan audibly) Jun 12 19:35:33 twall: look at your /media/tom/Backup/tisdk/build/arago-tmp-external-linaro-toolchain/work/am57xx_evm-linux-gnueabi/gstreamer1.0-plugins-vpe/git-r2.14/temp/run.do_configure.13961 Jun 12 19:35:49 I did, it's pasted above Jun 12 19:37:30 denix: oh i didn't see that. poky-contrib:ross/mut Jun 12 19:37:51 rburton: thanks Jun 12 19:39:02 rburton: is that everything you queued up for autobuilder? Jun 12 19:40:48 so far, i need to hit the list again. Jun 12 19:40:56 if theres anything in particular shout :) Jun 12 19:47:13 rburton: yep, did you miss my util-linux upgrade patch? Jun 12 20:08:48 Hi guys, I tried the mailing list, but I'm not getting help there, but I'm having issues trying to get a program cross-compiled with LLVM (https://gist.github.com/kratsg/10cf7835a83d4f17ad93173c8655c8e9) using this recipe: https://github.com/kratsg/meta-l1calo/blob/master/recipes-core/root/root_6.04.12.bb Jun 12 20:47:25 kergoth: no, not really Jun 12 20:47:58 figured, it'd risk a circular reference anyway Jun 12 20:51:08 Is there something preventing https://patchwork.openembedded.org/series/6626/ from being merged? Jun 12 20:52:39 well... other than that it probably no longer applies cleanly Jun 12 21:05:38 RP: FYI, I have fixed the problems now that caused the build of core-image-full-cmdline to fail with my patches. However, I guess I should probably build myself through some of the other core images, so I will do that before I send an updated set of patches... Jun 12 21:06:40 Saur: FWIW, https://autobuilder.yocto.io/tgrid is the set of errors it triggered on the autobuilder (the top line of red) Jun 12 21:08:49 RP: Well, at least not everything was red. :/ Jun 12 21:09:47 Saur: thanks for taking a look btw, we're going to have to figure this out on way or another Jun 12 21:10:06 Saur: those errors should be getting logged into the error reporting tool but aren't, I'll have to file a bug about that :/ Jun 12 21:35:54 RP: I deviced a solution for pie/nopie to utilize gcc driver itself which gets rid of pretty much all pinnings for using SECURITY_NO_PIE_CFLAGS Jun 12 21:36:02 in security_flags.inc Jun 12 21:36:16 RP: thats a step towards hardening the toolchain Jun 12 21:36:28 nice Jun 12 21:37:04 http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=cca00f7c8eb86d734969e76b15f2f79096c6d591 Jun 12 21:37:29 http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/master&id=e6a6882f19d8e7934235376ce446f012c009810d Jun 12 22:00:41 khem: I'll echo nerdboy and also say "nice" Jun 12 22:06:52 khem: I like those a lot! Jun 12 22:11:56 khem: awesome Jun 12 22:22:52 RP: I am of the opinion that we can make mainstream poky distribution hardened by default Jun 12 22:23:18 poky, or oe-core nodistro Jun 12 22:23:52 either is fine, if we did that for oe-core then poky would inherit it yeah Jun 12 22:24:07 I would also like to enable ssp support Jun 12 22:24:15 rburton: poky is usually more strict for things like dangling bbappends, etc - should probably stay that way even for hardening Jun 12 22:27:28 denix: I saw the overrides issue you ran into with base_conditional. Not sure how we'll fix that :( Jun 12 22:27:54 kergoth: there is a nice ordering issue about the base functions not being loaded early enough when overrides is getting expanded :( Jun 12 22:28:13 * RP -> sleep on it Jun 12 22:28:27 khem: please do send the above patches Jun 12 22:39:01 RP: I am doing world builds Jun 12 22:39:11 and waiting on gcc7 to merge before it Jun 12 22:39:18 since all my testing is using gcc7 Jun 12 22:41:05 Peter K has provided some useful feedback so I have included that and now running builds again Jun 12 23:20:44 RP: same issue with oe.utils.conditional() of course... **** ENDING LOGGING AT Tue Jun 13 03:00:00 2017