| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 00:10 | |
| *** whuang <whuang!~whuang@2607:9880:2d78:22:833:be63:2dc5:76ca> has joined #yocto | 00:11 | |
| whuang | is there a variable I can use to refer to python version? for example python3.8, python3.9 | 00:12 |
|---|---|---|
| whuang | there's a recipe that hard codes the python version (export NUMPY_INCLUDE_PATH = "${STAGING_DIR_TARGET}/usr/lib/python3.9/site-packages/numpy/core/include") | 00:12 |
| *** whuang <whuang!~whuang@2607:9880:2d78:22:833:be63:2dc5:76ca> has quit IRC (Quit: Client closed) | 00:32 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.) | 00:57 | |
| *** steve__ <steve__!~steve@24.16.44.202> has quit IRC (Ping timeout: 265 seconds) | 01:04 | |
| *** Guest5 <Guest5!~Guest5@2607:9880:2d78:22:8ffc:34ce:190f:f6b2> has joined #yocto | 01:28 | |
| *** Guest5 <Guest5!~Guest5@2607:9880:2d78:22:8ffc:34ce:190f:f6b2> has quit IRC (Client Quit) | 01:28 | |
| *** rber|res <rber|res!~rber|res@athedsl-4432950.home.otenet.gr> has joined #yocto | 01:32 | |
| *** RobertBerger <RobertBerger!~rber|res@128.90.148.25> has quit IRC (Ping timeout: 256 seconds) | 01:34 | |
| OutBackDingo | @zeddii ping | 01:44 |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 02:54 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 02:55 | |
| *** camus1 is now known as camus | 02:55 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.18> has quit IRC (Ping timeout: 255 seconds) | 04:06 | |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 04:38 | |
| *** amitk <amitk!~amit@103.208.71.49> has joined #yocto | 04:45 | |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-21-184-145-222-193.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.3-dev) | 05:32 | |
| *** YoctoStarter <YoctoStarter!~YoctoStar@cpe90-146-128-173.liwest.at> has joined #yocto | 05:43 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC (Ping timeout: 255 seconds) | 05:50 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 06:01 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 06:04 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 06:18 | |
| *** hmw__ <hmw__!~hmw@zimbra.welvaarts.com> has joined #yocto | 06:21 | |
| *** frieder <frieder!~frieder@i59F724D0.versanet.de> has joined #yocto | 06:21 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 06:23 | |
| *** YoctoStarter <YoctoStarter!~YoctoStar@cpe90-146-128-173.liwest.at> has quit IRC (Quit: Client closed) | 06:32 | |
| LetoThe2nd | yo dudX | 06:42 |
| *** mckoan|away is now known as mckoan | 06:42 | |
| mckoan | good morning | 06:42 |
| LetoThe2nd | mostly indeed. | 06:42 |
| mckoan | LetoThe2nd: :-D | 06:43 |
| mckoan | LetoThe2nd: summer holidays are approaching \o/ | 06:44 |
| LetoThe2nd | mckoan: somewhat, yes. | 06:45 |
| *** Schlumpf <Schlumpf!~schlumpf@p200300ca4f363000b46e22faf89acc52.dip0.t-ipconnect.de> has joined #yocto | 06:46 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Remote host closed the connection) | 06:56 | |
| *** zpfvo <zpfvo!~fvo@88.130.217.97> has joined #yocto | 06:58 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 07:06 | |
| *** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has joined #yocto | 07:16 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 07:21 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto | 07:27 | |
| *** zyga <zyga!~zyga@31.0.173.147> has joined #yocto | 07:31 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 07:36 | |
| *** gioyik <gioyik!~gioyik@gateway/tor-sasl/gioyik> has quit IRC (Quit: WeeChat 3.1) | 07:42 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 07:42 | |
| qschulz | morning | 08:01 |
| qschulz | JPEW: I'm not sure your PR works for local builds? | 08:04 |
| qschulz | I think at best your local build will be prefixed with the registry name (which, if it works, is confusing) | 08:07 |
| qschulz | On podman, I think local images are available with the localhost "registry", so if the same can be said for docker, we can just set registry to localhost when doing a local build? | 08:08 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 08:19 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 08:21 | |
| *** Schlumpf <Schlumpf!~schlumpf@p200300ca4f363000b46e22faf89acc52.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection) | 08:35 | |
| *** Schlumpf <Schlumpf!~schlumpf@p200300ca4f36300023fa559516bbe25e.dip0.t-ipconnect.de> has joined #yocto | 08:36 | |
| *** tnovotny_ <tnovotny_!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 08:42 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Read error: Connection reset by peer) | 08:42 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 08:48 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 09:18 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 252 seconds) | 09:21 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Ping timeout (120 seconds)) | 09:23 | |
| *** fleg <fleg!64bf4386e9@user/fleg> has joined #yocto | 10:07 | |
| fleg | hi, I am making a recipe for a CMake-based project, and for some reason while /usr/lib/libmylibrary.so.1.2.3 is packaged correctly, symlink to that file in /usr/lib/libmylibrary.so is split into the -dev package. Is it supposed to work this way, or am I doing something wrong? Thanks in advance for help! | 10:11 |
| qschulz | fleg: that | 10:12 |
| qschulz | 's expected | 10:12 |
| fleg | oh, thanks. Is there anything I can do to put those symlinks into the main package, or should I just install the -dev as well on the resulting image? | 10:12 |
| qschulz | fleg: why do you want the .so in your rootfs? | 10:13 |
| *** eFfeM <eFfeM!~eFfeM@185.184.109.34> has joined #yocto | 10:13 | |
| fleg | the application that I'm packaging depends on the .so | 10:13 |
| qschulz | make it depend on the versioned lib if possible (only exception would be if you receive precompiled binaries/libraries) | 10:14 |
| fleg | I will try to do that then, thanks! | 10:15 |
| qschulz | that's the cleanest way to do it | 10:15 |
| qschulz | otherwise, you need to remove the *.so from FILES_${PN}-dev and add it to FILES_${PN} (or another package) IIRC, setting FILES_SOLIBSDEV to "" and adding the two default paths to FILES_${PN} should be enough? | 10:17 |
| eFfeM | Hi, can I enforce that in a specific conf users cannot build a specific image recipe? | 10:17 |
| qschulz | or add the -dev but I don't know what exactly the consequences are | 10:17 |
| qschulz | eFfeM: you could always have a python anonymous function in the image recipe that looks for the current user and fail the parsing | 10:19 |
| qschulz | though, if your user have write access to said image recipe, they can remove it | 10:19 |
| eFfeM | What I want to achieve is that in a conf that allows GPLv3 code it is not possible to accidently buiild a release image (I have a different conf for release images) | 10:19 |
| eFfeM | qschulz: we have a different conf to build release images, but I want to make very sure that things do not get wrong. GPLv3 is to some extend a p.i.t.a. | 10:21 |
| eFfeM | I would love to go without it, but for dev purposes we need gdb | 10:21 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 10:21 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 10:22 | |
| *** camus1 is now known as camus | 10:24 | |
| qschulz | eFfeM: check the content of INCOMPATIBLE_LICENSE from the image recipe? | 10:24 |
| fleg | qschulz, I'll try to go the "depend on the versioned .so instead" route first, if I get stuck there then I'll try the other suggestions. Fortunately I build both the libraries and the application, so it should not be an issue | 10:24 |
| qschulz | fleg: :+1: | 10:26 |
| eFfeM | qschulz: hmm yes that is an idea | 10:27 |
| eFfeM | I'll explore after lunch | 10:28 |
| qschulz | eFfeM: but it's not bulletproof, because you can unset the INCOMPATIBLE_LICENSE per recipe in your conf file or have a package in the whitelist | 10:29 |
| qschulz | best option would be to check into the final manifest with the license of all software included in your image and check if there is a GPLv3 in there | 10:30 |
| qschulz | you might need to enable buildhistory for that, I don't remember | 10:30 |
| qschulz | maybe there's even something built in Yocto/bitbake but I'm not aware of it | 10:31 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:41 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has quit IRC (Ping timeout: 268 seconds) | 11:00 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 11:04 | |
| *** vmeson <vmeson!~rmacleod@198-48-226-187.cpe.pppoe.ca> has joined #yocto | 11:04 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 11:05 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 11:07 | |
| linums | hi | 11:07 |
| linums | I see that every branch brings it's own kernel version + the lts, like hardknott comes with 5.10 and 5.4 | 11:08 |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 11:08 | |
| *** camus1 is now known as camus | 11:08 | |
| linums | but the libc headers are only present with the version 5.10 on hardknott | 11:09 |
| linums | is it right, or should I not use hardknott for 5.4 kernel? | 11:10 |
| qschulz | linums: in most cases, you can use newer kernel release headers with an older kernel release | 11:12 |
| LetoThe2nd | linums: bruce might probably shed more light on this, but once there is no version selection available you will get the latest of a package, hence run 5.4 kernel and use the 5.10 libc headers. | 11:12 |
| linums | thanks, so it is intentional, so I'll select the kernel version, and nothing more | 11:31 |
| LetoThe2nd | linums: thats what i woould guess. | 11:32 |
| *** BCMM <BCMM!~BCMM@user/bcmm> has joined #yocto | 11:38 | |
| eFfeM | qschulz: yeah I know one can override INCOMPATIBLE_LICENSE, I also considered whitelisting gdb and then exclude it from the release image, but the pain is that gdb requires a newer readine than the one in meta-gplv2 and I cannot select a different version of readline in an image | 11:41 |
| LetoThe2nd | eFfeM: i personally would probably try BBMASK in the distro combined with an automated test on the resulting artifacts. | 11:50 |
| LetoThe2nd | https://docs.yoctoproject.org/ref-manual/variables.html?highlight=bbmask#term-BBMASK | 11:50 |
| eFfeM | LetoThe2nd: I'm not sure if that would help, I think INCOMPATIBLE_LICENSE is a better mechanism | 11:57 |
| LetoThe2nd | eFfeM: sure, it always depends. | 11:59 |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::e05> has joined #yocto | 12:19 | |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::e05> has quit IRC (Client Quit) | 12:19 | |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::f245> has joined #yocto | 12:20 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 12:54 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 12:55 | |
| *** camus1 is now known as camus | 12:55 | |
| *** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:a043:ef83:5025:ad7c> has joined #yocto | 13:27 | |
| *** override <override!~override@ec2-3-138-201-125.us-east-2.compute.amazonaws.com> has joined #yocto | 13:34 | |
| override | t | 13:36 |
| override | exit | 13:36 |
| override | so the byte for byte image type would be ext3? | 13:40 |
| whuang0389 | Hi I'm trying to create a recipe that depends on llvm | 13:41 |
| whuang0389 | Im guessing it needs to be llvm-lite but it's looking for a llvm-config file | 13:41 |
| JPEW | override: Ya, any of those file systemd formats (ext3, ext4, etc.) will produce an image you could directly dd into a partition | 13:41 |
| whuang0389 | so I have a DEPENDS += "llvm-native", but the llvm-native doesn't get compiled... am I missing something? | 13:42 |
| whuang0389 | or should DEPENDS be enough? | 13:42 |
| JPEW | override: If you need a whole disk images (i.e. all the partitions w/ partition table, you need to use wic) | 13:42 |
| override | whuang0389: you could check if its a run time or a build time dependency (RDEPENDS vs DEPENDS). and use oe-pkgdata-util to check youve got the right packages in your build.. | 13:44 |
| whuang0389 | maybe my understanding of run tim dependency is wrong.. but I believe that it means they are packages that are required to be pulled in when the source is runned on target? | 13:46 |
| whuang0389 | if that's the case, I think it'sa build time dependency | 13:47 |
| override | whuang0389: yeah then just make sure the recipe the package added as a depends and just maybe add the llvm-config depency to your recipe too. use the oe-pkagdata-util to find the name for whatever dependency you recipe needs... | 13:49 |
| override | thats just how I was told to do things.. not a yocto know it all by any standard | 13:50 |
| whuang0389 | no worries! thanks for some tips! | 13:50 |
| override | prolly a dumb question do distro/machine conf includes from different layers require absolute paths, or is YOCTO smart about them? | 13:55 |
| qschulz | override: relative to (any) layer root dir | 13:55 |
| qschulz | well, relative to the root dir of the layer with the distro/machine conf file | 13:56 |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:57 | |
| override | ok, think thats what I got | 13:58 |
| override | the manual reads The IMAGE_FSTYPES variable's default value now specifies ext4 instead of ext3. I dont see any of these being made for my builds | 14:08 |
| override | are they not made when I have something like IMAGE_FSTYPES += "teziimg" in my machine config? | 14:08 |
| override | im just appending to the IMAGE_FSTYPES varaible, I was expecting this would add fstypes on top of the defaults.. ? | 14:09 |
| JPEW | override: The defaults are probably "weak" so the += might be overriding them | 14:09 |
| override | and since ext4 is supposedly the default would it require something IMAGE_CLASSES_append " image_type_tezi ext5" in my case? | 14:10 |
| override | JPEW: when a varaible is "weak" does _append also overrides it, or just += | 14:11 |
| JPEW | override: I'm not sure if ext4 is the default | 14:11 |
| override | ive always been curious why we have _append and += | 14:11 |
| JPEW | override: _append is deferred until the end of parsing, += is immediate | 14:11 |
| qschulz | override: https://pretalx.com/media/yocto-project-summit-2021/submissions/WTT3UV/resources/Demystifying_the_OVERRIDES_mechan_no6J6fb.pdf | 14:12 |
| JPEW | override: You should explictly set the IMAGE_FSTYPES you want instead of relying on the defaults | 14:13 |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.97> has joined #yocto | 14:13 | |
| JPEW | override: If you are curious about how a variable gets it's value `bitbake -e <image>` will tell you | 14:14 |
| override | JPEW: would I need to do an IMAGE_CLASSES_append =" ext5" ? I have that in, but Im still just seeing the texiimg.. | 14:15 |
| Xagen | does anyone know why you would be able to build an image recipe, but `bitbake <recipe> -c populate_sdk` errors out? | 14:15 |
| rburton | Xagen: can you pastebin the error? | 14:15 |
| Xagen | sure, one moment | 14:15 |
| JPEW | override: I don't think you need that for any of the normal image types. If you are doing other things you might need something | 14:16 |
| Xagen | rburton: i'm going to have to rerun the command, so it will be a couple minutes | 14:17 |
| *** frieder <frieder!~frieder@i59F724D0.versanet.de> has quit IRC (Remote host closed the connection) | 14:29 | |
| Xagen | rburton: https://pastebin.com/KHutJ9yc | 14:30 |
| Xagen | i can see in toaster that json-c, libevent, libsodium, python, and python3 all built | 14:31 |
| Xagen | the only thing i could think of is that i need to have toaster run the populate_sdk itself, and that it wouldn't work from the cli, but i couldn't find any place to explicitly run populate_sdk | 14:33 |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 14:33 | |
| vd | hi all -- after systemd switches root from the initrd, I get a bench of FAILED service, for hardware RNG, network manager, user login management, etc. My guess is an issue with /var. Anyone with a clue? | 14:35 |
| whuang0389 | ok so, it turns out I do have llvm-config executable pulled in | 14:50 |
| whuang0389 | I think the setup.py file executes llvm-config to determine the llvm version | 14:50 |
| whuang0389 | but the setup fails with permission denied... | 14:51 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 14:51 | |
| whuang0389 | is there something I need to do allow the setup file to execute the llvm-config? I can execute it manually myself | 14:51 |
| *** eFfeM <eFfeM!~eFfeM@185.184.109.34> has quit IRC (Remote host closed the connection) | 14:55 | |
| *** roussinm <roussinm!~mroussin@184.145.222.193> has joined #yocto | 14:57 | |
| * RP is pondering an addlayer directive: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=9aa43a88d9ad9178f8ec4e5cec56662352a72c37 http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=0216deadff94f565fb880c17d0654606fe82ea65 | 15:02 | |
| *** steve__ <steve__!~steve@24.16.44.202> has joined #yocto | 15:03 | |
| Xagen | so i found a post saying that i could do the populate_sdk from toaster, but that it doesn't prepend the do_ | 15:04 |
| Xagen | so i ran it from inside toaster, and it had the same error as what i posted in the paste | 15:04 |
| override | whuang0389: try S = "${WORKDIR}/git" | 15:11 |
| override | where are you pulling the source from? | 15:11 |
| whuang0389 | git | 15:11 |
| whuang0389 | yea I do have that line | 15:12 |
| whuang0389 | btw I've used devtool. should i be doing devtool build recipe or bitbake recipe? | 15:12 |
| override | to test it out? bitbake recipe | 15:12 |
| override | devtool gives you a template for the recipe youre trying to put together | 15:13 |
| qschulz | whuang0389: both work just fine | 15:13 |
| override | oh, lol I didnt know that.. | 15:13 |
| whuang0389 | ive been using bitbake, wondering if devtool build would fix that permission denied | 15:13 |
| whuang0389 | lol | 15:13 |
| *** tnovotny_ <tnovotny_!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 15:14 | |
| whuang0389 | so generally, if a recipe depends on an executable to get information, yocto should be able to run that executable correct? | 15:14 |
| override | pastebin your recipe or just share a repo or something. sure someone would help you out | 15:14 |
| whuang0389 | thats awfully nice :) haha | 15:15 |
| whuang0389 | will do | 15:15 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 15:19 | |
| qschulz | whuang0389: yes, otherwise we wouldn't be able to use cmake/autotools/meson and all | 15:20 |
| rburton | whuang0389: depends *on the native recipe* that provides that binary | 15:21 |
| rburton | you can't run target binaries | 15:21 |
| *** saurabh <saurabh!~saurabh@61.1.159.150> has joined #yocto | 15:27 | |
| *** saurabh <saurabh!~saurabh@61.1.159.150> has quit IRC (Client Quit) | 15:28 | |
| *** Guest16 <Guest16!~Guest16@61.1.159.150> has joined #yocto | 15:29 | |
| *** Guest16 <Guest16!~Guest16@61.1.159.150> has quit IRC (Client Quit) | 15:30 | |
| *** Guest1739 <Guest1739!~Guest17@61.1.159.150> has joined #yocto | 15:30 | |
| *** Guest1739 <Guest1739!~Guest17@61.1.159.150> has quit IRC (Ping timeout: 246 seconds) | 15:41 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 265 seconds) | 15:42 | |
| yates | is there a variable which defines the cross-toolchain sysroot when cross-building the kernel? | 15:45 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 15:47 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 15:50 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 255 seconds) | 15:50 | |
| *** camus1 is now known as camus | 15:50 | |
| yates | i need to specify the --sysroot path to gcc when the kernel Makefile for my architecture runs in order to setup the libgcc library | 15:51 |
| *** Guest1766 <Guest1766!~Guest17@61.1.159.150> has joined #yocto | 15:51 | |
| *** Guest1766 <Guest1766!~Guest17@61.1.159.150> has quit IRC (Client Quit) | 15:53 | |
| yates | but wait - i just realized somewhere, between yocto and the kernel build system, that sysroot is already defined. | 15:54 |
| rburton | well, yes | 15:54 |
| rburton | did you try grepping oe-core for --sysroot? | 15:54 |
| yates | i will | 15:54 |
| rburton | conf/bitbake.conf:TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}" | 15:54 |
| rburton | if you use ${CC} you get that included | 15:55 |
| rburton | so, tell your kernel to use ${CC} not gcc | 15:55 |
| rburton | obviously, the standard kernel recipe/classes do this already | 15:55 |
| yates | rburton: in my arch's kernel Makefile, there is this line: libs-y += arch/csky/lib/ $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name) | 15:57 |
| rburton | right, so ensure CC is passed | 15:57 |
| rburton | or use the standard kernel classes that do this for you | 15:57 |
| rburton | using kernel.bbclass doesn't mean using linux-yocto | 15:58 |
| *** zpfvo <zpfvo!~fvo@88.130.217.97> has quit IRC (Quit: Leaving.) | 15:59 | |
| *** Guest44 <Guest44!~Guest44@61.1.159.150> has joined #yocto | 16:00 | |
| yates | i'm confused, but let me dig some more before I ask more stupid questions. | 16:00 |
| yates | thank you, rburton | 16:00 |
| yates | i guess basically i am wondering why yocto isn't already defining CC with the sysroot when this top-level Makefile is run | 16:01 |
| rburton | it is | 16:01 |
| rburton | export CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}" | 16:02 |
| * rburton goes to collapse somewhere | 16:02 | |
| yates | then why is "$(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name)" returning just "libgcc.a" and not "<some-path-in-sysroot>/libgcc.a"? | 16:02 |
| rburton | because gcc doesn't always give you an absolute path if the result is in the search path | 16:03 |
| Guest44 | I have problem generating eSDK for my image.my image usages meta-qt layer which has dependency on python3 where as my application are dependent on python2.i am using python2-mako in my applications and same mako is used by meta-qt as well but they use python3.-mako. | 16:03 |
| rburton | yates: this works for the standard kernels, therefore you're doing something odd or wrong. i suggest you don't write your own kernel recipe but use linux-yocto with a custom config if needed. if you *really* need to write your own recipe then at least inherit kernel.bbclass | 16:04 |
| Guest44 | so while generation it tries to install mako-render which is provided by both python packages.My problem is hot disable python3-mako while generation eSDK. | 16:05 |
| yates | rburton: i switched to using my own instead of linux-yocto because there were several complications due to this being for a new architecture which is not fully supported in yocto (yet). | 16:06 |
| rburton | but are you using mainline kernel? | 16:06 |
| yates | yes | 16:06 |
| rburton | so use linux-yocto as that is mainline | 16:06 |
| yates | 5.12 | 16:06 |
| yates | using linux-yocto pulls in other machinations unique to linux-yocto which do not work with the architecture i am using. i've already spent weeks tracking down those and decided it was better to based our system on mainline non-linux-yocto to remove dependencies on those machinations | 16:09 |
| yates | i resolved a couple, but it was very tedious. | 16:10 |
| yates | rburton: CC is not constructed with a --sysroot option when the top-level arch/<arch>/Makefile runs. i just instrumented it: CC = csky-poky-linux-gcc | 16:20 |
| yates | neither is there a sysroot in KBUILD_CFLAGS | 16:20 |
| yates | not at that time | 16:21 |
| yates | i believe the only time gcc emits just the "libgcc.a" filename is when it can't really find it. | 16:21 |
| yates | i know that a lower level submake has it defined, but that is after the libs-y has been improperly defined | 16:23 |
| yates | so i guess i have to dig and find out what happens between this top-level Makefile and the myriad levels the kernel build system evokes.. | 16:23 |
| yates | fun! | 16:23 |
| * yates takes a dirt nap... | 16:24 | |
| *** mckoan is now known as mckoan|away | 16:26 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 16:26 | |
| Xagen | rburton: did you get a chance to look at my pastebin? | 16:36 |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 16:40 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 240 seconds) | 16:41 | |
| *** camus1 is now known as camus | 16:41 | |
| *** Guest63 <Guest63!~textual@2600:1700:211:7e60:a0de:d28f:eac4:36af> has joined #yocto | 16:46 | |
| *** Xagen <Xagen!~Xagen@2600:1700:211:7e60:3d0a:f9eb:6f5f:7d30> has quit IRC (Quit: Xagen) | 16:47 | |
| *** Guest63 is now known as Xagen | 16:47 | |
| *** Guest44 <Guest44!~Guest44@61.1.159.150> has quit IRC (Quit: Client closed) | 16:51 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 17:04 | |
| *** fleg <fleg!64bf4386e9@user/fleg> has quit IRC (Remote host closed the connection) | 17:18 | |
| *** fleg <fleg!64bf4386e9@user/fleg> has joined #yocto | 17:20 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.97> has quit IRC (Ping timeout: 255 seconds) | 17:25 | |
| override | does anyone know what recipe is responsible for making the .json file we see under the deploy folder. its got the blockdevs (partitions and some other stuff defined in it. Not sure if this is some yocto standard way of doing things, or something the vendor pulled off. the .json files looks like this - https://pastebin.ubuntu.com/p/gtYBRqCkf7/ | 17:26 |
| *** florian_kc <florian_kc!~florian@dynamic-093-131-050-131.93.131.pool.telefonica.de> has joined #yocto | 17:34 | |
| yates | override: perhaps it is an output from "wic"? | 17:39 |
| override | oh, was really hoping I could just add a fs partition to that json file or something | 17:39 |
| override | guess I gotta look up wic | 17:39 |
| override | yates: could you link me to some wic doc or something? Ill try to figure if this is wic generated | 17:41 |
| override | does wic generate any json? | 17:41 |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 17:43 | |
| *** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:a043:ef83:5025:ad7c> has quit IRC (Quit: Client closed) | 17:43 | |
| *** BCMM <BCMM!~BCMM@user/bcmm> has quit IRC (Ping timeout: 256 seconds) | 17:44 | |
| *** amitk_ <amitk_!~amit@103.208.71.49> has joined #yocto | 17:44 | |
| override | yates: so I see a image_type.bbclass in a layer, does wic require something along those lines? | 17:45 |
| override | Im just having a hard time finding something to read for wic | 17:45 |
| override | the manual starts talking about partion commands wic supports.. I want an overview of what the heck is it all about even | 17:46 |
| *** amitk <amitk!~amit@103.208.71.49> has quit IRC (Ping timeout: 255 seconds) | 17:46 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 17:53 | |
| *** Guest8 <Guest8!~Guest8@50.237.172.122> has quit IRC (Quit: Client closed) | 18:05 | |
| JPEW | override: Ya, the "Getting started" documentation for wic needs some help | 18:08 |
| JPEW | override: You need to add a ".wic" file system to IMAGE_TYPES as a suffix of the rootfs type you want to embed, e.g. `IMAGE_TYPES += "ext4.wic"` | 18:09 |
| JPEW | override: Ugh, sorry, that's wrong. Just add `wic` to `IMAGE_FSTYPES` | 18:10 |
| override | JPEW: cool ok think my vendor is using something else, but while we are talking wics | 18:11 |
| override | I get the wic to my IMAGE_FSTYPES | 18:11 |
| override | im guessing that is in my maching.conf? | 18:11 |
| JPEW | override: Usually | 18:11 |
| override | then what happens? how do the partions get defined? | 18:12 |
| JPEW | override: The code will search for a .wks file; default file to look for is `"${IMAGE_BASENAME}.${MACHINE}.wks"` | 18:13 |
| JPEW | You can change it by setting the `WKS_FILE` variable | 18:13 |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has quit IRC (Ping timeout: 255 seconds) | 18:13 | |
| JPEW | override: It will search in the `wic` directory of every layer | 18:13 |
| override | ok nice, those were the extension names I was looking for | 18:14 |
| override | Im trying to make sure if my vendor is using wic or something not so standarized.. | 18:14 |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.210> has joined #yocto | 18:15 | |
| JPEW | wic is pretty flexible; if they boot from eMMC you can write a wic file to make the image | 18:15 |
| override | eMMC is sd cards and all, right | 18:16 |
| override | Im the worst with these terms | 18:16 |
| JPEW | Can you share the SoC? A lot already have examples you can start with | 18:16 |
| override | im using some som from toradex, let me get u the exact name and all one sec | 18:17 |
| *** Guest8 <Guest8!~Guest8@50.237.172.122> has joined #yocto | 18:17 | |
| override | toradex verdin imx8m mini | 18:17 |
| override | they have some easy installer stuff that is throwing me off / has zero docs when it comes to setting up partitions | 18:18 |
| JPEW | Oh, ya. That one should have pretty good support | 18:18 |
| Guest8 | Anyone have experience using dmalloc with c++ apps on yocto targets? | 18:18 |
| JPEW | override: Start here probably: https://github.com/Freescale/meta-freescale/tree/master/wic | 18:18 |
| override | sounds good | 18:19 |
| override | JPEW thats repo you just wanted me to look at some sample .wks files? | 18:23 |
| JPEW | override: Ya, that repo supports the IMX8M so one of those wks files is probably correct? | 18:24 |
| JPEW | override: At least as a starting point | 18:24 |
| override | yeah, Its beginning to sink in a little | 18:24 |
| override | like you add wic to the wic to the IMAGE_FSTYPES then you have a .wks file with the actual partion defintion youre going for.. | 18:25 |
| JPEW | override: Correct | 18:27 |
| override | i get what uboot is, whats uboot spl now? | 18:27 |
| JPEW | override: It's highly technical and related to the way that many SoC's boot: https://stackoverflow.com/questions/31244862/what-is-the-use-of-spl-secondary-program-loader | 18:29 |
| override | yeah, not sure if I should be too concerned about it right now.. | 18:30 |
| JPEW | override: Basically, u-boot is too big and SoC's can't access RAM immediately, so you need a small SPL to initialize RAM, copy u-boot into it and jump to it | 18:30 |
| override | oh, ok. thanks JPEW: | 18:31 |
| Tartarus | Dumb question, but wasn't there some way to make local source archives that included the githash in them? | 18:31 |
| JPEW | Tartarus: BB_GENERATE_MIRROR_TARBALL | 18:31 |
| Tartarus | ie for use cases like where you have a single local source mirror that you use when you start building $whatever and $whichever source branch that might be, get the right glibc git hash archive | 18:31 |
| Tartarus | JPEW: that only gives me git2_sourceware.org.git.glibc.git.tar.gz for example | 18:32 |
| JPEW | Ah, for a specific hash and/or branch? | 18:32 |
| Tartarus | Yeah | 18:32 |
| Tartarus | I have a site.conf I start with for everything and it has a own-mirror / SOURCE_MIRROR_URL in it | 18:33 |
| Tartarus | It's great for everything that's not git, but since I might be on thud or zeus or dunfell or something modern, all of the git stuff isn't a cache hit | 18:33 |
| JPEW | Ya, that's not supported.... we run into the same thing all the time :/ | 18:33 |
| Tartarus | Ugh, I thought it used to be | 18:34 |
| Tartarus | Guess it's time for plan B and directories for just the git ones | 18:34 |
| Tartarus | I should probably double check the logic for getting uninative stuff too while I'm at it | 18:35 |
| Tartarus | I think that's caught normally with own-mirrors | 18:35 |
| override | JPEW: you know what WKS_FILE_DEPENDS_append is all about? I think toradex is using the wic image type but its not very out very obvious becuase they define their own image type, which extends wic | 18:36 |
| JPEW | override: If you need to include other items in the disk image (e.g. u-boot or other bootloader), you need to tell bitbake to build them before attempting to run wic | 18:37 |
| JPEW | `WKS_FILE_DEPENDS` does that.... basically "Wic creation depends on these things" | 18:37 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 18:39 | |
| *** davidinux <davidinux!~davidinux@217.138.197.52> has quit IRC (Ping timeout: 268 seconds) | 18:39 | |
| JPEW | override: Sounds like they are producing a wic file then wrapping an installer around it? | 18:41 |
| *** davidinux <davidinux!~davidinux@217.138.197.52> has joined #yocto | 18:41 | |
| override | so this toradex som im working with has a image_type_tezi.bbclass with WKS_FILE_DEPENDS in it. which makes me think toradex is trying to extend the wic image type ... but I cant find a .wks file .. like I see some random ones | 18:41 |
| override | JPEW: im just trying to add another partition to the emmc or what ever the nand memory on the board is called, so I can just dd ext4 images to it, tell uboot to boot from that partion, and call this entire thing a system update | 18:42 |
| JPEW | override: Ya, pretty standard A/B partition stuff :) | 18:44 |
| override | JPEW: yeah it wouldbe been simpler if I didnt have toradex in my way right now | 18:44 |
| JPEW | Sounds like they did their own thing instead.... to bad. But the IMX8M has pretty good support, I'm fairly certain you can get it working | 18:45 |
| override | yeah think theyre extending the basic wic stuff tho | 18:45 |
| override | so if I can file the correct wks file i can just add the swap partion to it | 18:46 |
| override | right now I think it just has the one uboot and one kernel partition | 18:46 |
| Tartarus | JPEW: OK, so locally I'm fixing this by dropping own-mirrors, and having PREMIRRORS_prepend itself in site.conf with stuff like: git://.*/.* ${SOURCE_MIRROR_URL}/${LAYERSERIES_COMPAT_core} \n which evaluates correctly at least. But please tell me if that's still a horrid idea or something :) | 18:46 |
| JPEW | In fact, I'm positive you can get it to work, I've got an IMX8M on my desk that I had booting with wic a few months ago :) | 18:46 |
| *** marka <marka!~marka@198-84-181-245.cpe.teksavvy.com> has joined #yocto | 18:46 | |
| override | nice think I'll ditch whatever image class toradex has setup and just add simple wic to my distro | 18:47 |
| Tartarus | override: Modifying the tezi images is not easy, sadly. | 18:47 |
| override | Tartarus: you know about tezi? | 18:48 |
| Tartarus | Which is a problem if you want to use tezi to in turn flash a production run of toradex stuff | 18:48 |
| Tartarus | I have (ab)used it before, yes. | 18:48 |
| JPEW | override: Here is the specific wks file we use for the IMX8MM: https://github.com/Freescale/meta-freescale/blob/master/wic/imx-imx-boot-bootpart.wks.in | 18:49 |
| override | Im just trying to see if I just went all wic right now. I do a clean wipe of my emmc, then just write a fresh uboot, and kernel partition and swap partition just sits empty for now | 18:49 |
| override | I dont need no tezi then do i? | 18:49 |
| JPEW | override: Hard to say... it really depends on what else they have done | 18:50 |
| Tartarus | It also depends on what you're trying to do, in the end | 18:50 |
| override | if i went wic I'll still be doing everything toradex has done, just not making a tezi image? wic image instead | 18:51 |
| override | where would i run into issues that way? | 18:51 |
| Tartarus | Well, if you're on a toradex SOM, there's important questions | 18:51 |
| override | what might those be | 18:52 |
| Tartarus | Like, are you doing a one-off personal project? Or is this a company thing that'll have 1k units? | 18:52 |
| override | there can be all the units we want for it | 18:52 |
| Tartarus | Are you going to flash them, or is toradex? | 18:53 |
| override | no we are | 18:53 |
| override | like our cm people would | 18:53 |
| Tartarus | OK | 18:53 |
| override | they can just well I can get to that later | 18:53 |
| Tartarus | And you're just now figuring out how they'll do the flashing? | 18:53 |
| override | like ive use these dd scripts in the past .. | 18:53 |
| Tartarus | There's many ways to install, yes, which is why toradex created yet another one, their 'easy installer'. | 18:54 |
| override | yeah im trying to ditch that toradex easy installer stuff myself | 18:54 |
| Tartarus | OK, then yeah, look at the wks that JPEW mentioned | 18:54 |
| override | they use some library that doesnt work on osx for one thing | 18:54 |
| override | easy installer has some universal update utility dependency which doesnt work on osx | 18:55 |
| Tartarus | Then you can shove your product-image.wic.xz inside of installer-image.wic, and write installer-image.wic to SD card and have that boot and uncompress/dd product-image.wic.xz | 18:55 |
| override | so I gotta freakin sit at home with where my ubuntu machines at to be able to flash boards | 18:55 |
| override | Tartarus: yeah thats more or less what im trying to get it. still sounds quite a mouth full - given how I just figured out how wic is a file system type and wks file has the definition for wic | 18:56 |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 18:57 | |
| Tartarus | Ah, ok. Yeah, it's all a bit tricky but there's many examples. | 18:57 |
| Tartarus | The hard/ugly part comes when you copy image A in to image B | 18:57 |
| Tartarus | And that's more ugly than hard. | 18:58 |
| override | I dont think I have to take it that far tho | 18:58 |
| Tartarus | You do, it'll suck more than not to read the product-image.wks.xz in to U-Boot and write it out | 18:58 |
| Tartarus | It's doable, yes, but you're better off not I bet. | 18:58 |
| Tartarus | With my U-Boot custodian hat on. | 18:59 |
| override | I just copy to what ever partion Im not booting the kernel from and then just tell uboot to boot from this partion the kernel got copied to | 18:59 |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 255 seconds) | 18:59 | |
| Tartarus | You may want to explore using fastboot or similar, for flashing, too. | 18:59 |
| Tartarus | Fire up U-Boot, then write the disk image that way. | 18:59 |
| override | oh so like dd wont cut it? | 19:00 |
| Tartarus | Well, dd in Linux? sure | 19:00 |
| Tartarus | That's what you can easily automate, with an installer image | 19:01 |
| Tartarus | There's in-tree examples for that today | 19:01 |
| override | oh crap theres no uboot dd? | 19:01 |
| override | for now I was even then when I get that uboot interupt on boot up | 19:01 |
| *** florian_kc <florian_kc!~florian@dynamic-093-131-050-131.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 19:01 | |
| Tartarus | There's not "dd" but there is writing, yes | 19:01 |
| Tartarus | but you're limited by your amount of DDR | 19:01 |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has joined #yocto | 19:01 | |
| Tartarus | using fastboot or ums to expose the disk / device to the Linux host is probably easier | 19:01 |
| override | fastboot is a uboot utility? | 19:02 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 19:02 | |
| Tartarus | fastboot is a protocol supported in a lot of ways/places. | 19:02 |
| override | how would that do things faster with the same amount of ddR? | 19:02 |
| LetoThe2nd | Tartarus: side note: in german "fast" means "almost", which makes this thing named "almost-boot", essentially ;) | 19:03 |
| Tartarus | LetoThe2nd: and in turn, very accurate description of this ;) | 19:03 |
| LetoThe2nd | Tartarus: hi5 | 19:04 |
| override | Tartarus: you got a repo or something that I can start looking into. I start trying out JPEW's wic/wks | 19:04 |
| override | LetoThe2nd: thanks for linking me to that distro, machines, images youtube the other day. I still dont know the best way to like include stuff on top of vendors machine/distro, but I got a lot of stuff out of my local.conf | 19:06 |
| Tartarus | override: No, most of the time what I need is in meta-freeescale or meta-freescale-3rdparty | 19:07 |
| LetoThe2nd | override: have fun then. | 19:07 |
| Tartarus | Have you checked meta-freescale-3rdparty for the boad you're using? | 19:07 |
| override | no, ill make sure to look there | 19:08 |
| override | they got some interesting wks files there? | 19:08 |
| override | LetoThe@nd: what am I having fun with again? | 19:09 |
| LetoThe2nd | override: life, the universe and everything, hopefully. | 19:09 |
| override | LetoThe2nd: got it. enjoying all that is the least of my worries. Just his wic stuff and all that keeps me worried. | 19:10 |
| *** florian_kc <florian_kc!~florian@dynamic-093-131-050-131.93.131.pool.telefonica.de> has joined #yocto | 19:17 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has quit IRC (Ping timeout: 268 seconds) | 19:20 | |
| override | why am i seeing .wks files in my build directory? | 19:33 |
| *** florian_kc is now known as florian | 19:34 | |
| JPEW | override: is your input file a .wks.in file? | 19:35 |
| *** linums <linums!~linums@84.198.214.27> has quit IRC (Quit: Client closed) | 19:35 | |
| override | i have a feeling ... Im still not a hundred percent | 19:36 |
| JPEW | The code will do variable expansion on .wks.in files, so I *think* it writes out the final .wks (with the variables expanded) for reference | 19:36 |
| override | im trying to see what .wks would come out of this recipe.. https://pastebin.ubuntu.com/p/6f8wgTwxTy/ | 19:37 |
| override | well, its a bbclass to be precise | 19:37 |
| override | or more like what /wks file will this class be referring to | 19:38 |
| *** zyga <zyga!~zyga@31.0.173.147> has quit IRC (Ping timeout: 240 seconds) | 19:40 | |
| *** zyga <zyga!~zyga@31.0.173.147> has joined #yocto | 19:41 | |
| JPEW | override: easiest way to tell is to do `bitbake -e <image> | grep ^WKS_FILE` | 19:42 |
| override | nice, forgot about that | 19:44 |
| *** Schlumpf <Schlumpf!~schlumpf@p200300ca4f36300023fa559516bbe25e.dip0.t-ipconnect.de> has quit IRC (Quit: Konversation terminated!) | 19:51 | |
| override | JPEW: so I can find the first wks.in but the second one doesnt seem to exist. is that just some vraible expansion or something going on? | 19:53 |
| override | WKS_FILES="imx-imx-boot-bootpart.wks.in Reference-Minimal-Image.wks" | 19:53 |
| Xagen | is there a way, through bitbake, to show what a `do_populate_sdk` for a given image would think is available to be added to it? | 19:53 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 19:53 | |
| JPEW | override: WKS_FILES is a *little* annoying because it stops as soon as it finds one | 19:54 |
| JPEW | It doesn't generate one of each as you might expect :) | 19:54 |
| override | but why is it listing Reference-Minimal-Image.wks | 19:54 |
| override | that file doesnt seem to exist anywhere | 19:55 |
| JPEW | override: Someone added it.... `bitbake -e` can tell you who added it | 19:55 |
| JPEW | override: Ya, I'm not sure? | 19:55 |
| override | JPEW: so like bitbake -e | grep Reference-Minimal-Image should work? | 19:57 |
| JPEW | override: `bitbake -e <image> > env.txt` then look through the file | 19:57 |
| JPEW | It will give the "history" of the variables in a comment above each one so you can see how each was modified | 19:58 |
| override | JPEW: Im getting ERROR: Only one target can be used with the --environment option. | 19:59 |
| override | when I try something like bitbake -e tdx-reference-minimal-image env.txt | 19:59 |
| JPEW | Right, I usually redirect to a file (`> env.txt`) because it is a lot of outputy | 20:00 |
| override | ahh ok.. thanks | 20:00 |
| JPEW | I can see why that might be confusing with the `<>` I put around `image` | 20:00 |
| override | so wis is an image type or a file system type? | 20:13 |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has joined #yocto | 20:18 | |
| override | window 20 | 20:20 |
| *** Nullcast <Nullcast!~Nullcast@63.149.192.194> has joined #yocto | 20:22 | |
| Nullcast | Hi all, This may be more of an opkg question but that's a Yocto repo so... What's the minimum set of options for installing packages into an offline root tree that's opkg-based? Because --offline-root and --conf still gives me a setup that doesn't see existing packages. | 20:33 |
| Nullcast | Opkg version is 0.4.1 for ref | 20:36 |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 20:45 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 20:46 | |
| *** camus1 is now known as camus | 20:46 | |
| *** robbawebba <robbawebba!~rob@12.206.203.186> has joined #yocto | 20:48 | |
| override | is there an image only equivalent for IMAGE_FSTYPES, or am I just terribly confused? | 20:54 |
| override | something with just the kernel and not a complete file system image for istance | 20:55 |
| override | instance* | 20:55 |
| *** amitk <amitk!~amit@103.208.69.73> has joined #yocto | 20:55 | |
| *** amitk_ <amitk_!~amit@103.208.71.49> has quit IRC (Ping timeout: 255 seconds) | 20:57 | |
| kergoth | override: "image only"? i don't know what you mean. an image fs type can be a rootfs type, i.e. ext4, or a disk image, i.e. wic. if all you want is a kernel, don't build an image recipe at all, just bitbake virtual/kernel and use the kernel image in tmp*/deploy/images/ | 20:59 |
| override | kergoth: whats the difference between a rootfs and a disk image? | 21:03 |
| *** Guest8 <Guest8!~Guest8@50.237.172.122> has quit IRC (Quit: Client closed) | 21:05 | |
| Nullcast | A rootfs is an image(or tree) of / with your standard packages installed on it? It should be a (mostly) complete system. | 21:10 |
| *** Nullcast <Nullcast!~Nullcast@63.149.192.194> has quit IRC (Quit: Client closed) | 21:13 | |
| kergoth | a rootfs is just the root filesystem only, no partition table, etc. | 21:14 |
| *** Nullcast <Nullcast!~Nullcast@63.149.192.194> has joined #yocto | 21:18 | |
| override | kergoth, a disk image can have multiple partitions? | 21:28 |
| *** ant__ <ant__!~ant@host-87-8-132-196.retail.telecomitalia.it> has joined #yocto | 21:31 | |
| RP | kergoth: any thoughts on http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=9aa43a88d9ad9178f8ec4e5cec56662352a72c37 ? | 21:33 |
| *** zyga <zyga!~zyga@31.0.173.147> has quit IRC (Ping timeout: 255 seconds) | 21:35 | |
| Nullcast | I think I found my problem: The copy of opkg on my build server is one I added to my SDK. Apparently it's writing status in a local copy of the SDK sysroot path for /var/lib/opkg and I'm not sure which path option overrides that.g/ | 21:35 |
| Tartarus | So, uh, has anyone discussed rpm+zstd in general recently? I ask since I just needed to whack in a closed source rpm that was also using zstd on the inside, and rpm2cpio.sh blew up badly, and then I think since our rpm-native doesn't know zstd I had to drop in zstd -d in the pipe for do_install. | 21:43 |
| Tartarus | Wondering what direction I should take to deal with this if at all, upstream :) | 21:43 |
| Tartarus | (PACKAGECONFIG zstd to rpm?) | 21:43 |
| JPEW | Tartarus: Someone was looking into it, I do not recall who unfortunatley | 21:44 |
| Tartarus | I'll keep an eye on the ML then. Or if they don't show up in a while, feel free to poke me then | 21:44 |
| RP | JPEW, Tartarus: was kanavin | 21:44 |
| Tartarus | Ah, ok, so not a drive-by | 21:45 |
| RP | he is on holiday for a bit | 21:45 |
| RP | Tartarus: basically I think it is due in the next release at which point we might try it again. It was unstable until now | 21:45 |
| RP | our plan is to switch | 21:45 |
| Tartarus | Customer project is dunfell for now, might move up to next LTS | 21:45 |
| Tartarus | Ah, OK. So this particular bit of closed source stuff is ahead of the RPM recommended features anyhow? | 21:46 |
| RP | Tartarus: I think so | 21:46 |
| *** BobPungartnik <BobPungartnik!~Pung@187.113.141.142> has joined #yocto | 21:46 | |
| Tartarus | Makes a bit more sense then, ok | 21:46 |
| RP | Tartarus: I know kanavin did try it and it was all a bit too much of an experiment last time we looked so we were waiting | 21:46 |
| *** BobPungartnik <BobPungartnik!~Pung@187.113.141.142> has quit IRC (Client Quit) | 21:48 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 21:57 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection) | 21:59 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 21:59 | |
| *** camus1 is now known as camus | 21:59 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 22:06 | |
| *** zyga <zyga!~zyga@31.0.173.147> has joined #yocto | 22:20 | |
| *** florian <florian!~florian@dynamic-093-131-050-131.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 22:20 | |
| *** zyga_ <zyga_!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 22:22 | |
| *** zyga__ <zyga__!~zyga@31.0.173.147> has joined #yocto | 22:25 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Ping timeout: 255 seconds) | 22:25 | |
| *** zyga <zyga!~zyga@31.0.173.147> has quit IRC (Ping timeout: 258 seconds) | 22:26 | |
| *** zyga_ <zyga_!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has quit IRC (Ping timeout: 268 seconds) | 22:28 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 22:28 | |
| *** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto | 22:31 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 22:40 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.210> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 22:43 | |
| *** florian <florian!~florian@dynamic-093-131-050-131.93.131.pool.telefonica.de> has joined #yocto | 23:01 | |
| *** Nullcast <Nullcast!~Nullcast@63.149.192.194> has quit IRC (Quit: Client closed) | 23:03 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 252 seconds) | 23:05 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 23:05 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 23:05 | |
| *** zyga__ <zyga__!~zyga@31.0.173.147> has quit IRC (Quit: Leaving) | 23:09 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.210> has joined #yocto | 23:15 | |
| *** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:a043:ef83:5025:ad7c> has joined #yocto | 23:22 | |
| *** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:a043:ef83:5025:ad7c> has quit IRC (Client Quit) | 23:23 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.210> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 23:24 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.210> has joined #yocto | 23:26 | |
| *** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Remote host closed the connection) | 23:36 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.210> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 23:38 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.210> has joined #yocto | 23:40 | |
| *** florian <florian!~florian@dynamic-093-131-050-131.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 268 seconds) | 23:50 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!