**** BEGIN LOGGING AT Thu Sep 17 02:59:57 2020 **** BEGIN LOGGING AT Thu Sep 17 03:36:02 2020 **** BEGIN LOGGING AT Thu Sep 17 04:54:01 2020 **** BEGIN LOGGING AT Thu Sep 17 05:04:53 2020 **** BEGIN LOGGING AT Thu Sep 17 05:26:42 2020 **** BEGIN LOGGING AT Thu Sep 17 05:33:02 2020 **** BEGIN LOGGING AT Thu Sep 17 05:39:32 2020 Sep 17 06:04:52 How can I increase the memory size of an image? Sep 17 06:33:08 Hi. Can I ask a licence related question, or should this be done in a seperate channel ? Sep 17 06:48:51 cbs: please ask Sep 17 06:51:27 mckoan Thanks. It concerns third party licenses. Specifically in meta-qt5, but not limited to that meta-layer. Licenses for third party components are not shown, and licenses for third party, for third party is also not shown in Yocto. E.g. qtlocation uses 5 third party components, and one of them uses more than 10 another third party components. None of these licenses in reflected in the recipe. Is this by choice ?. See https://doc.qt.io/qt-5/licenses-used-in-qt Sep 17 06:51:27 .html Sep 17 06:53:31 mckoan : Or to be more precise; One of the third party components for qtlocation (mapbox-gl-native) is providing its License file, but the rest are not Sep 17 06:54:57 mckoan: Unsure if this is by choice, or not even needed. But if using QtLocation and looking into the generated rootfs license file, the fact that we are hit by the boost license (since that is used by Qtlocation as a third party component) is not shown Sep 17 06:55:29 mckoan: I'm not a lawyer, so unsure of how third party licenses are handled. Sep 17 06:55:41 cbs: Qt licenses in particular are a weird and puzzling matter. I suspect you won't get much help here though Sep 17 06:59:07 mckoan: Okay. But I geuss this problem is not limited to meta-qt5. That is simply just were I saw the problem. But in general, all third party components should have their license listed within the recipe ? Both with LICENSE and LIC_FILES_CHKSUM ? Sep 17 06:59:53 cbs: About Qt you can read some post from Burkhard here https://www.embeddeduse.com/2019/05/15/using-qt-under-lgplv3/ Sep 17 07:00:40 cbs: generally speking about recipes' licenses, every recupe have to declare its own LICENSE and LIC_FILES_CHKSUM Sep 17 07:01:02 mckoan: Include third party components ? Sep 17 07:01:26 mckoan: And thanks for the link! Sep 17 07:03:48 cbs: I don't understand what do you mean with 'third party'. If the component has a recipe must have a license too Sep 17 07:07:22 mckoan: E.g. qtlocation has software within it, i.e. not a dependency but included within the source code, clip2tri (MIT license), clipper (Boost 1.0 license), geosimplify.js ( geosimplify.js License), poly2tri (Boost license), mapbox-gl-native ( BSD-2 Claus). Then mapbox-gl-native (which is within the source code of qtlocation) then itself has third party components (i.e. again within the source code. Precisely qtlocation/src/3rdparty/mapbox-gl-native): more tha Sep 17 07:07:22 n 10 of these Sep 17 07:07:39 cbs: everything that is in the source tree of the recipe needs to be declared in LICENSE Sep 17 07:08:37 mcfrisk: Roger. Then someone, could be me, needs to add 150+ more licenses to LICENSE within meta-qt5. its all in https://doc.qt.io/qt-5/licenses-used-in-qt.html Sep 17 07:08:56 (or can be limited to what gets compiled but in that case I'd make sure problematic files are deleted in do_patch() or similar) Sep 17 07:09:27 mcfrisk: Yes. I suppose the safest method is to include all the licenses. But; There are quite a lot :) Sep 17 07:09:32 there may be gray areas if licenses are 'compatible' and relicensing is allowed Sep 17 07:09:36 yep, there is quite a lot Sep 17 07:11:05 and there are problems with licenses can be chose. Hence users may need to either rewrite the LICENSE field if they use that for collecting license texts and for compliance, or introduce a new variable (which is what we've done) Sep 17 07:15:48 mcfrisk Okay. I'll try to start a MR towards meta-qt5 and see what happens. Thanks for the responses mcfrisk mckoan! Sep 17 07:52:10 I often forget bitbake devshells open in one of my screen terminals and with dunfell they seem to hang like this for example if I wipe tmp in another terminal. Are there fixes in master already? https://pastebin.com/raw/34TM6fNh Sep 17 08:11:46 ndec: I sent a few docs patches in the middle of the night and I probably was in auto mode at that time, hopefully it's not completely garbage :) I don't care if you squash all of them together, it was more to explain a bit each of the changes and make them (hopefully) easier to review Sep 17 08:12:05 qschulz: i am reviewing them right now ;) Sep 17 08:12:31 i merge timo's patch first. i had a minor conflict with one of your patch, but i fixed it. Sep 17 08:12:55 ndec: also... I'm wondering if the boilerplate isn't missing in many places? Sep 17 08:13:19 e.g. https://docs.yoctoproject.org/ref-manual/ref-manual.html has it but https://docs.yoctoproject.org/ref-manual/ref-system-requirements.html does not Sep 17 08:13:48 usually the "Manual" pages have it but not sections Sep 17 08:13:53 we have it once for each 'manual', as opposed to on each page. Sep 17 08:14:17 ndec: ok, was wondering if it was on purpose or not :) Sep 17 08:15:08 i actually wondered about that.. on the original doc, we have 1 html page for each manual, and the 'boilerplate' once. Sep 17 08:15:19 but with sphinx we have split into many html 'pages'.. Sep 17 08:15:25 and last remark from last night wandering in the docs: am I the only one bothered by numbers for sections and subsections? (which gets used for the page title) Sep 17 08:16:38 what do you mean here? Sep 17 08:16:42 I would at least put a dot or parenthesis or something to clearly mark it's the number of the items and not part of the title? Sep 17 08:17:09 it is 'uncommon' i think to use numbered sections with sphinx. Sep 17 08:17:11 and since the sections and subsections are pretty well defined in the nav bar on the left, i'd say it's not really needed? Sep 17 08:17:26 s/defined/shown/ Sep 17 08:17:40 small night = broken english and brain farts so bare with me :D Sep 17 08:18:10 s/bare/bear/... /me facepalms Sep 17 08:18:52 have you tried removing :numbered: attribute to see how it looks like? Sep 17 08:20:03 ndec: haven't investigated yet but css would need some love on mobile. I can scroll horizontally but there is no text. Same for the navbar on mobile. Minor obviously :) Sep 17 08:20:14 ndec: I didn't, I will try some day :) thx for the tip **** BEGIN LOGGING AT Thu Sep 17 08:23:08 2020 Sep 17 08:25:20 ndec: lgtm and then we can reorganize later? or would this modify the organization in the navbar? Sep 17 08:26:22 i don't expect it will change the nav bar. the nav bar 'design' comes from index.rst, then we recursively include all the other files. Sep 17 08:26:45 so renaming/moving/merging files within each manual should have no impact on the output. Sep 17 08:27:08 then I think it's fine to do it later/mid-release? i'm no RP though :D Sep 17 08:27:10 renaming is probably important, since the filenames are often used in the :ref: Sep 17 08:27:23 it's definitly post 3.2! Sep 17 08:27:41 the ref aren't an issue, it's more the URL modification that isn't great Sep 17 08:27:56 because you break links then Sep 17 08:29:36 I mean... external links pointing to the docs, refs are just internal so /me shrugs Sep 17 08:32:32 right. i see. though when 3.2 is released, it will be in http://docs.yoctoproject.org/3.2, so if we change links for master/3.3 it will not impact what's published. Sep 17 08:35:51 ndec: having some kind of stable external links referencing is kind of desirable Sep 17 08:36:01 but for now I'll be happy to have the basics of the conversion done Sep 17 08:36:17 qschulz: thanks for the patches, I had a quick look this morning Sep 17 08:37:06 RP: you ok with "sphinx: replace special quotes with single and double quotes"? Sep 17 08:38:48 ndec: the metadata fixes there are clearly correct, not sure about the text ones, that is a style issue. Its probably more consistent though? Sep 17 08:40:30 RP: i think the rendered output by sphinx will use the right character, no? Sep 17 08:41:01 RP: it makes it much easier to grep through the docs in the git repo Sep 17 08:41:18 ndec: it seems ok for double quotes, I'll check for single Sep 17 08:41:35 ndec: http://docs.yoctoproject.org/adt-manual/adt-prepare.html => choose "I" is one I changed Sep 17 08:42:00 ndec: ah! a few lines lower, ` <&YOCTO_TOOLCHAIN_DL_URL;>`__ in the html :D Sep 17 08:42:22 adt is deprecated.. Sep 17 08:42:45 we will no longer publish it. i am not even sure why it's there. Sep 17 08:44:07 ndec: http://docs.yoctoproject.org/dev-manual/dev-manual-qemu.html => `You also need the target root filesystem for your target machine’s architecture:` was using the "weird' Sep 17 08:44:21 single quote and ctrl+f in FF is doing just fine Sep 17 08:44:31 so cosmetic change only for the git repo :) Sep 17 08:45:07 ndec: admittedly, was highlighted by vim spell plugin. Wouldn't be mad if it's not taken so no worries Sep 17 08:45:33 (it's a sed, a patch that took 3min :) ) Sep 17 08:45:53 i am ok with the patch, actually. i think it's better. and if the output is not impact we should be good. Sep 17 08:46:21 ndec: I hadn't checked the output but it seems reasonable to be consistent in the text Sep 17 08:48:12 ndec: to be clear, I checked docs.yoctoproject.org (so before the patch) not with mine (though I'm pretty sure I did yesterday/today but can't guarantee :) ) Sep 17 08:48:32 ndec: and indeed... linkcheck is REALLY slow. Like mindblowingly slow. Sep 17 08:48:40 i checked after your patch, and it looks ok. **** BEGIN LOGGING AT Thu Sep 17 08:51:24 2020 Sep 17 08:58:40 qschulz: i am going to squash this change in one of your patch, fyi.. Sep 17 08:58:45 https://www.irccloud.com/pastebin/8dc8asr9/ Sep 17 09:12:26 ndec: ahah! I was wondering how would one do it :) thx! Sep 17 09:21:51 does bitbake handle local paths with "@" character? Sep 17 09:29:36 lxc: can you present your problem or thought process please? the question isn't very clear to me Sep 17 09:32:23 lxc: I suspect the sed expressions we use in places may conflict Sep 17 09:33:17 RP okay, that may explain the errors. known issue, or plans to fix? Sep 17 09:33:45 lxc: we should probably just report it to the user as unsupported. We need to use some character so we'd just move the problem Sep 17 09:34:36 @rp I see, I believe Jenkins usually creates paths containing the @ character Sep 17 09:37:17 lxc: well, I'm only guessing, I don't know how widespread the problem is if I'm right. I do know people use jenkins for builds with YP just fine... Sep 17 09:49:40 RP error message seems in place: Error, you have an invalid character (@) in your COREBASE directory path. Please move the installation to a directory which doesn't include any @ characters. Sep 17 09:50:36 lxc: ah, cool. I did remember that correctly then :) Sep 17 09:51:06 @RP thanks, will solve by updating Jenkins path **** BEGIN LOGGING AT Thu Sep 17 10:14:30 2020 Sep 17 11:22:47 Hello is this the right place to ask questions on readonly-rootfs builds on yocto ? Sep 17 11:29:25 toast963,I think so what do you need to know? Sep 17 11:30:31 toast963: you can certainly ask! **** BEGIN LOGGING AT Thu Sep 17 11:52:03 2020 **** BEGIN LOGGING AT Thu Sep 17 12:13:31 2020