**** BEGIN LOGGING AT Tue Sep 06 02:59:58 2016 Sep 06 08:38:37 Anyone here with Qt5 app experience? I wonder how you deal with the fact that Qt rely (by default) on .so files, and they think/claim that this is how it should be done. I don't feel too comfortable to adding INSANE_SKIP_${PN} ?= "dev-so" all the time Sep 06 08:53:02 sveinse: I don't understand what do you expect instead Sep 06 08:55:29 mckoan: Point is, our Qt app has a lot of plugins, which is compiles to versioned .so files (as expected). But when I import the plugins from within the Qt app, it searches for the .so file without version number, which is in Yocto-world a -dev package. Sep 06 08:55:55 This is a controversy which I have given up making Qt-ppl understand is not common practice Sep 06 08:56:14 But it does not help to resolve it, so I'm looking for options Sep 06 08:56:38 this is normal. applications should not specify the exact .so version unless required. Sep 06 08:57:04 run ldconfig to create all required symlinks Sep 06 08:58:57 sveinse: libfoo.so is normally a symlink to the library and only required for development (so that the linker can find the library when you do -lfoo). that's why it's packaged into ${PN}-dev by default. Sep 06 08:59:16 fragfutter: Ok, but the Yocto fails loudly if any .so files are placed in the ${PN} packages, and there is apparently no postinst process for rebuilding them Sep 06 09:00:02 sveinse: i recommend reading the shared libraries chapter of the linux programming interface. it goes over all the concepts very clearly in great detail. :) Sep 06 09:00:10 Ulfalize: yes, but this is not the case for Qt apps. If you request to load a Qt plugin, it searches .so only Sep 06 09:00:15 not sure if that chapter is available for free online though Sep 06 09:00:38 sveinse: ah... w8. there are some other variables you could use in that case. Sep 06 09:00:50 Ulfalize: it's not my fault (not being defensive here), but this is how Qt expect things to work Sep 06 09:01:07 SOLIBSDEV iirc, but my browser keeps hanging up atm :P Sep 06 09:01:24 sveinse: yeah, no problem. it's pretty common for plugins to be unversioned i guess. Sep 06 09:02:01 Ulfalize: Yes, SOLIBDEV, that's right. I still need to bypass so-dev thou Sep 06 09:02:29 So my first question was how other Qt5 apps has handled this pickle Sep 06 09:04:01 And oh, how do I bypass is? I've added inherit insane and INSANE_SKIP-${PN} += "dev-so", but bitbake still fails on [dev-so] :o Sep 06 09:04:37 sveinse: it's _${PN} IIRC Sep 06 09:04:55 sveinse: where does your recipe install the .so files? Sep 06 09:05:07 erbo: Yes, typo from me INSANE_SKIP_${PN} += "dev-so" Sep 06 09:05:08 sveinse: have you tried SOLIBS = "${SOLIBSDEV}", meaning "shared libraries use the suffix as development links (.so)"? Sep 06 09:05:21 not sure if that's the recommended approach, but it might work Sep 06 09:05:22 erbo, ah yes, install location is custom (/opt), thanks. I' Sep 06 09:05:26 I'll check that Sep 06 09:06:14 might want to make it += if you still want to catch "normally" named libraries Sep 06 09:06:47 though if it's one recipe per plugin, it shouldn't usually matter Sep 06 09:07:48 sveinse: btw... INSANE_SKIP would need to be followed by '_' rather than '-' :) Sep 06 09:08:13 oh, nm, already corrected that Sep 06 09:11:10 I can't see where the meta-qt5 recipes work around the dev-so issue, and I can't recall that I've had problems building e.g. Qt plugins myself. Weird. Sep 06 09:13:12 erbo, Yeah, I'm no Qt dev, so I don't know if they use some special arrangement for loading the plugin. I was just told "this is how Qt5 does this", as either knowledge or arrogance, who knows. Sep 06 09:14:00 Not being the only one thou: http://stackoverflow.com/questions/34265476/bitbake-does-not-populate-so-symlinks-to-shared-libaries Sep 06 09:14:39 sveinse: Yeah the plugins are (and should be) unversioned, but I mean that I never had the dev-so check complain. I thought that was due to the check only caring about /usr/lib/ Sep 06 09:16:19 erbo, yes, and I think it is a side effect of us using /opt for the installation path. I've been seeing this elsewhere. Now with Yocto, we should probably migrate it to /usr/, but I need to take one issue at a time :D Sep 06 09:19:53 sveinse: the implementation of that check is in package_qa_check_dev() in meta/classes/insane.bbclass btw. it seems to hardcode ".so". maybe it ought to check for SOLIBSDEV instead. Sep 06 09:20:07 i'd send a message to the mailing list Sep 06 09:21:22 apparently your .so files are symlinks as well. is that intended? Sep 06 09:21:26 otherwise the QA check wouldn't fire Sep 06 09:24:37 sveinse, why do you install symlinks instead of the real the files without version infos? We compile / install our plugins without version and it works fine. Sep 06 09:26:26 Cubi1, so you configure qmake to build plugins without version? Sep 06 09:30:07 qmake installation per default, produces libmine.so.A.B.C as the file and sets up symlinks to libmine.so.A.B -> libmine.so.A.B.C, libmine.so.A -> libmine.so.A.B.C amd libmine.so -> libmine.so.A.B.C. Sep 06 09:30:25 And qt runtime seems to run dl_open() against libmine.so Sep 06 09:31:00 sveinse, we don't use qmake, so I don't know how to remove the version info there. If you don't find a way to fix it, you can rename the files in your recipe in do_install_append(). Sep 06 09:31:48 Cubi1: Yeah, I don't know if this behavior is specific to qmake and that cmake behaves differently Sep 06 09:32:40 I had hoped I could use Qt/qmake out-of-box without too much per recipe fiddling, but it seems this is unavoidable Sep 06 09:36:04 Heh, reading from Qt's QPluginLoader: "To be loadable, the file's suffix must be a valid suffix for a loadable library in accordance with the platform, e.g. .so on Unix," Sep 06 09:36:35 So Qt surely assume that the .so lib is installed by default and thus not being a -dev library :D Sep 06 09:44:23 sveinse, .so is ok for a plugin, it just must not be a symlink. We build our plugins using libtool with the ldflag "-avoid-version", maybe there is something similar for qt Sep 06 10:01:19 Cubi1: There are. CONFIG+=plugin in Qt libs stops using versioned libs and use .so for storage. And Yocto stops failing over it. Thanks! Sep 06 10:33:56 Hello. What is the recommended/preferred mechanism for secure over-the-air (OTA) updates in Yocto builds? Sep 06 10:35:21 I have just gone over the mender.io website, but I do not like the fact their solution is written in golang. Sep 06 10:36:17 Which is still kind of niche and developers are hard to find. Sep 06 10:44:39 hi Sep 06 10:45:13 is there any inherent issues with gobject-instrospection in oe? Sep 06 10:46:05 hey zeenix Sep 06 10:46:12 use a modern enough oe and no, it just works Sep 06 10:46:19 rburton, yo, there you are :) Sep 06 10:46:24 i was looking for a 'ross' nick :) Sep 06 10:46:35 some evil swine stole ross before i joined freenode Sep 06 10:47:42 https://paste.fedoraproject.org/422741/31588521 Sep 06 10:47:52 trying to update geoclue in oe Sep 06 10:53:25 zeenix: the recipe likely needs to export HOST_SYS or BUILD_SYS. what version of oe? Sep 06 10:54:10 this is krogoth branch from git Sep 06 10:58:32 * zeenix will try with master Sep 06 10:59:27 rburton: i've sent my patch to glibc upstream, but there is no answer... should I send a V2 of my patch with the glibc patch as "sent-upstream" ? Sep 06 10:59:48 boucman_work: yeah, Upstream-Status: Submitted [link to submission] Sep 06 11:00:23 ok, will do Sep 06 11:02:20 zeenix: maybe just add export HOST_SYS and export BUILD_SYS to the recipe? Sep 06 11:03:12 erbo, from geoclue recipe? I can try.. Sep 06 11:04:37 yup Sep 06 11:04:49 i *think* master fixed that generally at some point Sep 06 11:04:57 so you likely need to throw an export in Sep 06 11:05:20 i wonder if that was actually the GIR stuff throwing an error, or something else Sep 06 11:05:28 massively parallel builds are fun to hide errors Sep 06 11:06:08 i added those exports to geoclue recipe but still get the same error. I guess i gotta rebuilt gobject-introspection? Sep 06 11:06:13 no Sep 06 11:06:40 see http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/classes/gobject-introspection.bbclass?id=4977a0743ba439a46716c6ef10c5958d5a561115 Sep 06 11:06:49 that removed the export Sep 06 11:09:34 zeenix: i'd start by using the devshell to run make manually and identify what exactly is causing the error Sep 06 11:21:26 rburton, actually it was a different error Sep 06 11:22:05 rburton, erbo came down to my desk to try to help me out but i think the main issue might be our bistro distro being out of date with poky Sep 06 11:28:11 the latest error i get is python saying "no such file or directory" but no mention of which file Sep 06 11:28:13 Aha!! INSANE_SKIP_${PN} per package, not per recipe. E.g. INSANE_SKIP_${PN}-common. Sep 06 11:33:45 rburton, erbo: seems it tries to find libtool binary in geoclue top_builddir but it's not there Sep 06 11:34:10 Yocto is not built to build for multiple machines in one run, right? Sep 06 11:34:45 ah i think i need to add dep to libtool? Sep 06 11:35:44 zeenix: well good news is that is likely a bug in geoclue not oe Sep 06 11:35:51 sveinse: see oe-core master! Sep 06 11:35:52 Our use case is to make an OTA image that comprise of images for two machines. It would be convenient if I could write a yocto recipe for building that image, but if I need to rerun bitbake to change the MACHINE variable, this will not be immediately trivial Sep 06 11:36:50 rburton, but but make distcheck in geoclue runs fine :) Sep 06 11:40:26 rburton: sorry, can you be a bit more specific, please? I tried grepping for oe-core and master, and nothing useful Sep 06 11:40:28 --libtool=$(top_builddir)/libtool \ Sep 06 11:40:35 that might be it :) Sep 06 11:41:07 sveinse: bitbake: Initial multi-config support Sep 06 11:42:47 Hello Sep 06 11:43:19 rburton: thanks, I'll look into it Sep 06 11:49:28 zeenix: the dependency already comes from autotools class so shouldn't be needed. I've seen patches do --libtool="$(LIBTOOL)" to e.g. some gstreamer builds but don't know the background... Sep 06 11:50:06 oh all my old friends are here :) Sep 06 11:50:16 hi :) Sep 06 11:50:45 like meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0001-Makefile.am-don-t-hardcode-libtool-name-when-running.patch Sep 06 11:50:48 jku, rburton: btw i found the little ohand guy in my stuff when i was moving. He's doing alright :) Sep 06 11:51:06 ! Sep 06 11:51:10 they're rare as anything Sep 06 11:51:11 jku, ah ok, thanks Sep 06 11:51:12 well done Sep 06 11:51:38 for the libtool binary that gets written is prefixed with the host Sep 06 11:54:11 ah yes, that's true Sep 06 11:54:49 using $(LIBTOOL) should be upstreamable too Sep 06 11:55:42 yeah i just tried but seems that variable doesn't get expanded correctly Sep 06 12:01:51 zeenix: you might need to set LIBTOOL=@LIBTOOL@ in the makefile? Sep 06 12:06:59 rburton, nope, doesnt' help :( Sep 06 12:36:34 aha Sep 06 12:36:58 rburton, it's supposed to be -libtool="${LIBTOOL}" Sep 06 12:41:25 hmm.. now it can't find my library :( Sep 06 12:41:28 ERROR: can't resolve libraries to shared libraries: geoclue-2 Sep 06 13:20:58 Are there any examples of wic being used from recipes to generate images? Sep 06 13:31:52 Isn't it common to generate a dd-able image with wic from a recipe? I find little of it in the poky code base nor the documentation Sep 06 13:35:25 sveinse: there is a wic script in poky/scripts/ Sep 06 13:37:10 CTtpollard: yes, wic is a part of poky. But I'm curious how to plug that into a recipe in order for me to generate a dd image. The docs only talk about wic in respect of running it manually from the command line Sep 06 13:40:21 ..and it seems like meta-fsl-arm does not use wic at all for it's sdcard generation. So isn't wic intended for this purpose? Sep 06 13:41:20 wic is fairly new so you'll likely want to ask fsl if they plan to move to wic Sep 06 13:41:25 or if there's any problems with it Sep 06 13:42:53 rburton: ok, good. I frankly don't care what fsl has done. I'm searching for how to integrate wic into my image build workflow Sep 06 13:54:04 the only example I can find is meta-selftest/recipes-test/images/wic-image-minimal.bb. Let me see if I can use it Sep 06 14:01:42 is anyone aware of any .wks file available for the minnowboard max, meta-intel only seems to have one for galileo Sep 06 14:07:40 How new is wic? I don't get the impression this is very widely adopted yet Sep 06 14:14:46 i have a package A which creates a file in /opt/A, now i want to build package B which requires this file during building. i set DEPENDS="A", but which is the path to the file during build time? Sep 06 14:16:31 sveinse: here are some examples to use with fsl machines https://github.com/Freescale/meta-fsl-arm/tree/master/scripts/lib/image/canned-wks Sep 06 14:17:07 fragfutter: usually ${STAGING_DIR_HOST}/opt/A. btw, if you're not reading the latest (2.2) version of the manual, you might want to. Sep 06 14:17:31 see http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-DEPENDS and http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#ref-tasks-populate_sysroot (the second one is linked from the first one too) Sep 06 14:18:58 fragfutter: btw, please put spaces around '='. you don't need to to DEPENDS="foo" like in shell. :) Sep 06 14:19:06 and it looks a bit cramped Sep 06 14:20:37 sveinse: rename properly file ( with or without SPL ) to your image name. For example, for core-image-minimal.bb you need to rename wks file to core-image-minimal.wks and add IMAGE_FSTYPES_append = " wic" to local.conf Sep 06 14:21:43 sveinse: I use wic for customers for a while Sep 06 14:22:01 sveinse: as berton said, there is support for it on i.MX BSP Sep 06 14:22:02 Ulfalizer: i'm on 2.1, space are in my .bb, i did not read the documentation for do_populate_sysroot Sep 06 14:22:35 Ulfalizer: looks like i'm bitten by "Files that would typically not be needed by other recipes at build time are skipped" Sep 06 14:22:50 yeah i don't think stuff in /opt gets staged by default Sep 06 14:22:53 yeah, doesn't look like /opt is copied by default Sep 06 14:23:12 so you'll need to either a) stop using opt, read the FHS, and realise why you shouldn't use opt, or b) extend the staging function in your recipe Sep 06 14:23:14 looking in meta/classes/staging.bbclass Sep 06 14:24:08 fragfutter: extending the staging functions means doing sysroot_stage_dirs_append() { ... in your recipe btw Sep 06 14:24:42 see the .bbclass i just linked Sep 06 14:24:50 but yeah, it's a bit hackish Sep 06 14:25:53 berton: I have an image target (custom built) which is a derivative of core-image. It generates a rootfs/ including rootfs/boot/ which I want to copy to a image. Apparently --source bootimg-partition is not the thing here. IMAGE_BOOT_FILES unset Sep 06 14:27:01 This is not the var-som-dual btw Sep 06 14:29:24 hmm.. as soon as I include the library of geoclue into the build successfully, the generated package is named libgeoclue instead of geoclue :( Sep 06 14:29:44 is there a way to tell bitbake not to do that Sep 06 14:29:51 My objectives is to make an installable USB image. I have a .tar.bz2 rootfs which is complete. I then need to make a smaller second bootable core-image, install it to a USB device, which in turn erases the emmc and delivers the rootfs to it. Customer deployment of images. Sep 06 14:30:08 We have all this logic built today, but outside Yocto Sep 06 14:31:44 Ulfalizer: thanks. Is staging also applied to -dev packages? Sep 06 14:32:55 sveinse: you need to set IMAGE_BOOT_FILES something like MAGE_BOOT_FILES = "uImage u-boot.img imx6dl-var-som-solo-vsc.dtb" Sep 06 14:32:56 fragfutter: yup, as long as the files fulfill the "would typically be needed" criteria. the staging step doesn't really care about packages. Sep 06 14:33:37 berton: ok. Can't I just configure it do fetch everything from the rootfs/boot directory? Sep 06 14:33:42 fragfutter: see the first note for DEPENDS in the 2.2 reference manual btw. i added that to try to sort out some recipe vs. package confusion. :) Sep 06 14:34:24 "Putting a package name such as 'foo-dev' in DEPENDS does not make sense. Use 'foo' instead, as this will put files from all the packages that make up 'foo', which includes those from 'foo-dev', into the sysroot." Sep 06 14:37:20 sveinse: if you use core-image-minimal.wks it will create core-image-minimal image and will put IMAGE_BOOT_FILES to boot partition Sep 06 14:42:53 ah. notes are new in 2.2 documentation. Sep 06 14:43:58 quite a lot of new stuff Sep 06 14:44:19 berton: I don't have any core-image-minimal.wks in my sources. In all cases, this is beyond my point. When I build my image (based on core-image), it puts boot into rootfs/boot and the .tar.bz2. How can I put this into the /boot partition with wic? How come I need to use IMAGE_BOOT_FILES manually rather than using the rootfs/boot dir? Sep 06 14:45:10 this is just me trying to grasp the ideas behind wic Sep 06 14:50:27 So if I write in my wic recipe, a.bb, do_rootfs[depends] += "my-image:do_image", this will copy my-image's rootfs/ over to a's rootfs/, right? Sep 06 14:51:42 sveinse: i'm a wic noob, but that declaration by itself just adds a dependency between the tasks, so that my-image:do_image is guaranteed to run before a:do_rootfs Sep 06 14:53:36 Ulfalizer: yup, there are just some implicit actions here. as is: I find it easy to understand that my-image _depends_ on a:do_image. But that it also copies data is not intuitive Sep 06 14:54:51 sveinse: those implicit actions must be independent of that line though Sep 06 14:55:17 by itself it doesn't do anything but add a dependency between two tasks, so that they always run in a particular order relative to each other Sep 06 14:57:15 YPTM armin is on Sep 06 14:58:53 YPTM: Joshua is on Sep 06 14:59:06 YPTM: Ready-Access Number: 8007302996/9139049836 Access Code: 2705751 Sep 06 14:59:15 YPTM: Stephen joined Sep 06 15:02:14 yptm: ross on Sep 06 15:03:40 Sona is on Sep 06 15:06:05 * RP1 is dialing Sep 06 15:06:44 RP joined Sep 06 15:14:38 does any one know the status about https://bugzilla.yoctoproject.org/show_bug.cgi?id=7515? Sep 06 15:14:40 Bug 7515: enhancement, Medium+, 2.2 M3, mariano.lopez, IN PROGRESS REVIEW , Add CVE testing tool Sep 06 15:19:25 Sona: https://patchwork.openembedded.org/series/2005/ is the current series for 7515. your opinion on the cve-check class would be appreciated! Sep 06 15:19:51 thans Ross Sep 06 15:20:00 YPTM is over! Sep 06 15:29:08 berton: I looked at the fsl canned-wks URL you sent me. But I can't seem to find any recipes using these wks, am I right? Sep 06 15:30:04 generally the wks would be selected by the machine or user doing the build, not a recipe Sep 06 15:30:23 hardcoding machine specifics in the image recipe would break the orthogonality that is core to yocto/oe philosophy Sep 06 15:31:43 which implies that yocto needs a layer on top to make these semi-complete images into images that can be deployed to customers Sep 06 15:32:24 I had hoped I could write a set of recipes that could do that job, producing final shippable artefacts Sep 06 15:34:11 no, it doesn't imply that at all. Sep 06 15:35:41 Then there is probably something I'm completely missing in this picture Sep 06 15:39:03 Hmm, wic is unwilling to make a image without a bootloader: "Warning: bootloader config not specified, using defaults". Sep 06 15:39:32 Hi... what would the correct way to add some changes via my layer to a machine.conf file(existing in another layer)? The qemuarm.conf already exists in meta/conf/ .. I want to add some dependencies to machine type qemuarm in my layer.. Sep 06 15:51:29 halstead_: can you give me permission to edit patch status etc on the oe-core patchwork please Sep 06 15:52:10 Hello. Sep 06 16:02:15 kergoth: then I'm curious to your point. Why isn't wks "embeddable" into a recipe? Let's say you want to put an image into an image (e.g. for installation). Sep 06 16:03:00 the wks by definition is specific to the deployment method for your hardware, making it machine specific. our images are designed for use with any arbitrary distro or machine. hardcoding distro or machine specifics into an image violates that policy Sep 06 16:03:24 rburton, It says you already have it. Sep 06 16:04:24 halstead: huh Sep 06 16:04:26 kergoth: but how do you deploy images to customers? Or do you just leave it at "here is your .tar.bz2, do what you want with it"? Sep 06 16:04:50 I don't understand the question. let the machine .conf set the WKS_FILE and move on Sep 06 16:04:52 rburton, You are marked as a maintainer for Bitbake and OE-core in patchwork. Sep 06 16:05:31 rburton, Are you logged in as rossburton or a diffrent user? Sep 06 16:05:38 rossburton Sep 06 16:05:51 kergoth: point is, there is logic need to package, and with the layering scheme of yocto, it would seem like a good idea to make those overbuild as recipes, right. Otherwise you'd need another non-yocto system to handle artefacts on top of yocto Sep 06 16:06:04 halstead: oh and now it works :) Sep 06 16:06:16 rburton, Yay. Sep 06 16:06:36 sveinse: if you can do so without violating oe/yocto policy, sure Sep 06 16:06:50 just shift the logic out of the recipe itself Sep 06 16:10:41 kergoth: I have to admit I don't see why it is a problem. If you make a BSP for a particular machine, then that machine also has a scheme for booting, hence runnable images would be an expected part of building for that machine, wouldn't it? Sep 06 16:12:11 bsp layers should not be providing image recipes which only work for that bsp, no. Sep 06 16:12:43 any distro should work with any machine which should work with any image. this orthogonality of the system provides a great deal of flexibility, without which the project wouldn't have come as far as it has Sep 06 16:13:49 there are exceptions, valid ones, but they're few and far between Sep 06 16:14:41 I am lost then. Isn't then there missing something on top of this: The tool/method that can take whatever distro, whatever machine and whatever image and produce an artefact that is runnable on the selected machine? Sep 06 16:15:13 A tar.bz2 rootfs is not a complete artefact, it is a middle step Sep 06 16:15:22 the whole point of wic is to produce such an artifact. if it's insufficient, then the bsp generally provides a shell script to write things to the sd card or whatever other appropriate media Sep 06 16:15:46 i don't see why you're pushing the idea of a tarball, nobody actually uses a tar.bz2 for anything but debugging or nfsroot Sep 06 16:16:25 kergoth: because my entry to yocto is core-image-minimal, which by default produces a .tar.bz2. Sep 06 16:16:32 no, that's wrong Sep 06 16:16:38 the machine controls what image types are used, not the image Sep 06 16:16:48 so whatever machine you're using ddefaulted to that, that's all Sep 06 16:16:52 ok, right Sep 06 16:20:00 We have a end-user product (which is already on the marked), which is running Yocto. However, due to many reasons I won't list here, we get a core-image.tar.bz2 with the system and a SDK. We have then built a system using the SDK to make our application and manually inject this into the core-image, and then create the hdd image from the whole shebang. it works, but not very elegant. We now... Sep 06 16:20:02 ...want to move to a all-yocto solution and thus need all this image functionality into it. Sep 06 16:23:31 is it possible to encapsulate one image into another? Sep 06 16:24:21 sveinse: yes, live images have a initramfs inside them Sep 06 16:25:00 rburton: yes, ours do as well. It's three then Sep 06 16:25:50 The use case is making a bootable USB installer which installs the system onto the machine Sep 06 16:27:29 wic supports that use case already, though the installer might not be exactly what you need Sep 06 16:27:49 So what is being said here is that image creation is related to the machine, so this is where I need to start looking Sep 06 16:28:15 kergoth: I have my own installer (as a recipe -- a Qt5 GUI application) Sep 06 16:40:00 What does this cryptic error mean: Error: exec_cmd: 'sgdisk --partition-guid=1:0a58a7f0-be5b-49c7-a64e-03e672fe89a9 /home/me/yocto/build/tmp/deploy/images/lm-lb-gen2/usb-image-lm-lb-gen2-20160906163733/build/usb-image-201609061838-sda.direct' returned '3' instead of 0 Sep 06 16:41:46 sgdisk error Sep 06 16:41:58 Google sais error 3=non-gpt disk detected and no -g option. Which is right, because there is no GPT on this target Sep 06 16:42:20 Is this back to "Warning: bootloader config not specified, using defaults" I wonder Sep 06 16:43:11 its a non-GPT disk Sep 06 16:43:17 thats what tool is trying to day Sep 06 16:43:19 say Sep 06 16:43:51 khem: Yes, and I don't want GPT, so how do I disable it? Sep 06 16:44:55 because I have no "bootloader" statement in my wks. I don't need a bootloader Sep 06 16:45:30 Just one straight ext4 partition Sep 06 16:46:01 using msdos partitioning Sep 06 16:46:11 somewhere you are telling it to create GPT partition Sep 06 16:46:24 and then asking sgdisk to operate on it Sep 06 16:46:56 I see AB is also trying to help :) Sep 06 16:47:00 shhhh AB Sep 06 16:48:44 sveinse: how are partitions created ? may be there is a hint there Sep 06 16:49:34 khem, well I havent specified any. My wks only contains one line "part / --source rootfs --ondisk sda --label installer --align 4096 --use-uuid --fstype=ext4" Sep 06 17:01:57 khem: yes, you were right. The --use-uuid statement above triggers sgdisk and gpt. Thanks Sep 06 17:09:39 Can I delete a -native package which is deployed to the system? Sep 06 17:09:52 deployed? Sep 06 17:09:54 *system, I mean the buildtree Sep 06 17:10:02 native recipes don't generate packages nor are they deployed to the target Sep 06 17:10:16 if you just want to remove them from the sysroot for some reaosn, though i don't really see the point, use bitbake -c clean Sep 06 17:11:43 wic complained about missing sfdisk, so I had to depend on gptfdisk-native. Now that I've figured out how to not do gpt, I am wondering if I indeed still need the gptfdisk-native dep Sep 06 17:14:15 ASSUME_PROVIDED may be a way Sep 06 17:14:41 to let system assume that you are providing this package yourself and it need not build it Sep 06 17:15:21 khem: I want to build it. I just want to have the correct deps Sep 06 17:17:24 sveinse: you might have found a bug for missing dep Sep 06 17:17:39 so probbaly you fixed it rightly Sep 06 17:18:11 if bitbake -c clean gptfdisk-native works, then wic don't need it when no gpt is used, as my recipe succeeded. Sep 06 17:18:12 if its not needed to generate your final disk then its harmless Sep 06 17:18:37 sveinse: sure yes Sep 06 17:18:42 it being built doesn't harm anything Sep 06 17:19:15 khem: Well, I'm getting inspiration from poky/meta-selftest/recipes-test/images/wic-image-minimal.bb, where all these deps are listed Sep 06 17:19:47 sveinse: OK, they may be using GPT as base Sep 06 17:19:53 for partitioning scheme Sep 06 17:20:00 yes, they do Sep 06 17:20:18 so you may not be able to use it as it is Sep 06 17:20:42 I've got this figured for now Sep 06 17:22:39 khem: To confirm, if no gpt is used, then gptfdisk-native dep is not needed. Just tried reenabling gpt without adding this dep, and it failed. Sep 06 17:24:57 the deps vary depending on the wks, which bitbake doesn't know about, so it's not unusual to have to alter IMAGE_DEPENDS_wic Sep 06 17:25:10 i.e. we use wic for minnowmax, and set IMAGE_DEPENDS_wic_append = " dosfstools-native mtools-native parted-native" Sep 06 17:26:34 kergoth: yeah, precisely. ..and you need to update the deps if you take use of e.g. gpt Sep 06 17:26:41 * kergoth nods Sep 06 17:26:50 no, but this is good Sep 06 17:27:40 My image is booting on target HW. Goal accomplished. Sep 06 17:29:03 Would it be possible to manipulate the image via wic plugins? Sep 06 17:30:17 We have a compressed image file format that I want to add to wic. A type that does not write sectors unless they have actually been used, so it cuts image copying down by skipping unneccessary writes Sep 06 17:30:44 We have been talking about contributing this if there are any general interest for it Sep 06 17:30:56 we already have support for such a mechanism Sep 06 17:31:13 kergoth: oh, where? Sep 06 17:31:20 https://source.tizen.org/documentation/reference/bmaptool, https://source.tizen.org/documentation/reference/bmaptool/introduction Sep 06 17:32:00 at mentor we enable both wic.bz2 and wic.bmap image types, so the wic.bz2 can be written sparsely to the media with bmaptool, even though bzip doesn't retain actual sparseness Sep 06 17:33:05 kergoth: cool, sparseness is important on slow and large media with small fill. Sep 06 17:33:42 indeed. another option worth thinking about with removable media is to avoid using a fixed size image and let the rootfs be resized to the size of the media on first boot Sep 06 17:33:46 we switched to doing that recently Sep 06 17:33:56 previously we had multiple .wks files for each media size, which was a bit of a pain Sep 06 17:34:29 Heh, we have had both of these mechanisms in play in embedded product since 2012 actually. Not that that matters Sep 06 17:34:44 nice Sep 06 17:35:59 we're migrating to yocto now so that we can rid ourselves of our custom built build-system Sep 06 17:36:04 96boards-tools will do the auto rootfs resize if you install it (from the dragonboard folks), https://github.com/96boards/meta-96boards/tree/master/recipes-bsp/96boards-tools Sep 06 17:36:08 thus all my nagging questions :P Sep 06 17:36:26 ah, indeed Sep 06 17:38:40 kergoth: Yeah, we have a firstboot.service, which does a few additional task. But in essence not unlike the resize-helper.server Sep 06 17:39:26 But I have been thinking about removing this service. Isn't it superfluous with the postinstall mechanism in Yocto? Sep 06 17:39:39 Or is this deb-specific perhaps? Sep 06 17:40:16 any postinst that fails to run at rootfs construction time will automatically be run at first boot. really depends on what you're needing to do, whether its appropriate in a postinst or not Sep 06 17:41:42 kergoth: yes, and there are two levels of postinst, isn't there: One that is run by bitbake, and one that might run on target first boot, right? Sep 06 17:41:50 yes, right Sep 06 17:44:58 kergoth: the bmap tool is /very/ similar to our format. The approach is slightly different, but the end result would be the same. Very cool. Thanks Sep 06 17:45:04 np Sep 06 18:10:09 Wait, what: sudo dd if=usb-image-20160906175116.rootfs.wic of=/dev/sdd bs=1M. "136596480 bytes (137 MB, 130 MiB) copied, 0,0778612 s, 1,8 GB/s". Ke? Sep 06 18:10:29 And the image boots... I have serious problems trusting this right now Sep 06 18:16:57 sveinse: dont use bs= Sep 06 18:17:09 defaults are better Sep 06 18:18:25 khem: No, its my laptop which linux has apparently gone bonkers. I can write to /dev/sdanything with lightning speeds and nothing happens (or fills up). Nothing is written to disk Sep 06 18:19:04 i'd ls -l the device and make sure it's still correct, make sure nothing unlinked it and turned it into a regular file or something Sep 06 18:19:07 * kergoth shrugs Sep 06 18:19:59 yeah, weird, right? never seen this before :p But no worries Sep 06 18:20:25 scp it to another machine and write the usb drive there worked much better... Sep 06 18:22:16 I see that my image has 30M-ish available on target. What controls that "spare" size? Sep 06 18:24:16 sveinse: see IMAGE_ROOTFS_EXTRA_SPACE Sep 06 18:24:25 kergoth: thanks Sep 06 18:24:31 np Sep 06 18:36:51 When do you want to make a distro? Sep 06 18:39:00 a lot of people postpone creating a distro by doing everything in local.conf, but that's hard to maintain. i recommend folks make themselves a distro early, there's no real cost, and it gives you somewhere to put policy changes where they can be maintained Sep 06 18:41:12 kergoth: Does my questions regarding building multiple (encapsulated) images and wic images belong in a distro? Sep 06 22:53:44 Trying to make zmq.so the recipe does configure but doesn't build. I'm new not sure what is wrong. **** ENDING LOGGING AT Wed Sep 07 02:59:58 2016