| *** eltricos <eltricos!~eltricos@ip68-8-181-201.sd.sd.cox.net> has quit IRC (Quit: Leaving.) | 00:18 | |
| *** sgw <sgw!~swold@user/sgw> has quit IRC (Quit: Leaving.) | 02:23 | |
| *** hrw <hrw!~hrw@redhat/hrw> has joined #oe | 07:08 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #oe | 07:11 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 07:41 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 07:41 | |
| *** Guest13 <Guest13!~Guest13@132.198.137.78.rev.vodafone.pt> has joined #oe | 08:36 | |
| *** mvlad <mvlad!~mvlad@2a02:2f05:821a:fb00:e88e:21ff:fe65:be18> has joined #oe | 09:04 | |
| *** mckoan|away is now known as mckoan | 09:27 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 09:43 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 09:44 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #oe | 10:18 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 11:00 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 11:00 | |
| *** Guest13 <Guest13!~Guest13@132.198.137.78.rev.vodafone.pt> has quit IRC (Quit: Client closed) | 11:02 | |
| *** Kubu_work <Kubu_work!~kubu@lfbn-nan-1-335-137.w82-120.abo.wanadoo.fr> has joined #oe | 11:22 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 272 seconds) | 11:45 | |
| mort | One thing I don't quite get is: why does yocto call its files .wic? It seems like a completely normal "image" file: copy it byte for byte to a block device and the block device will have a GPT partition table and a bunch of partitions; doesn't everyone else call that .img? | 12:21 |
|---|---|---|
| rburton | because it was generated by wic | 12:25 |
| rburton | nothing special about the extension | 12:26 |
| mort | I see, interesting | 12:27 |
| rburton | 'normal' images are pretty simple: take a rootfs directory and transform it using IMAGE_TYPES. so if that is set to ext4.gz you get a rootfs in a gzip'd ext4 | 12:27 |
| rburton | wic builds disk images with multiple partitions and so so, and to work with IMAGE_TYPES needed an extension | 12:28 |
| mort | that part makes sense, I just would've expected the extension to be .img | 12:28 |
| rburton | does it matter? :) | 12:29 |
| mort | not at all | 12:29 |
| mort | well | 12:29 |
| mort | it causes people like me to see a wic file and wonder what that is and try to figure out what a wic file is, without much luck until I waste your time by asking in an irc channel :p | 12:29 |
| rburton | well top hit for 'what is a wic image' on google is the wic documentation that says its a disk image | 12:30 |
| rburton | also explains why its called wic which is always funny | 12:30 |
| mort | the featured snippet for me is that it's a Windows Imaging Component <_< then the first actual result is an SO page which doesn't explain what a wic file actually *is*, just that "a .wic image is intended to be installed directly to its final destination" | 12:32 |
| mort | tho the documentation is up there | 12:32 |
| hrw | mort: 'file rootfs.wic' would tell that it is disk image? | 12:33 |
| mort | I did encounter https://docs.yoctoproject.org/dev/dev-manual/wic.html earlier, and the oeic -> wic thing is kinda funny; but it just talks about the tool, not the "wic" file format | 12:33 |
| rburton | "The wic command generates partitioned images" | 12:34 |
| rburton | feel free to contribute a patch to the docs, its hard to write documentation when you know the full context | 12:35 |
| mort | might be more helpful to write an answer to the StackOverflow result that ends up at the top of the search result page | 12:39 |
| mort | there's nothing lacking per se in the OE docs | 12:39 |
| mort | Is there any difference between the wic file and a hddimg file, or is it just about the tools which created them? | 12:41 |
| hrw | mort: oeic -> wic was probably done to show that it is possible to use this tool outside of OE. Just like we did oemake2 -> bitbake in paste. | 12:41 |
| hrw | s/paste/past | 12:41 |
| rburton | it was more the pronouciation problem | 12:45 |
| hrw | "OE I see" -> wic? | 12:46 |
| rburton | OE Image Creator, as it was based on Meego Image Creator | 12:53 |
| hrw | Meego... | 12:53 |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 13:02 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 13:02 | |
| *** sgw <sgw!~swold@user/sgw> has joined #oe | 13:22 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #oe | 13:24 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Remote host closed the connection) | 13:51 | |
| *** michael_e <michael_e!~michael_e@user/michael-e:30278> has joined #oe | 15:02 | |
| *** michael_e <michael_e!~michael_e@user/michael-e:30278> has quit IRC (Quit: Client closed) | 15:14 | |
| *** sgw <sgw!~swold@user/sgw> has quit IRC (Quit: Leaving.) | 15:24 | |
| *** mckoan is now known as mckoan|away | 15:47 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 15:47 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:03 | |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has quit IRC (Ping timeout: 246 seconds) | 16:15 | |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has joined #oe | 16:16 | |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has quit IRC (Read error: Connection reset by peer) | 16:19 | |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has joined #oe | 16:20 | |
| *** tgamblin_ <tgamblin_!~tgamblin@d24-150-219-207.home.cgocable.net> has joined #oe | 16:32 | |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has quit IRC (Ping timeout: 268 seconds) | 16:33 | |
| *** tgamblin_ is now known as tgamblin | 16:36 | |
| *** dankm <dankm!~dan@user/dankm> has quit IRC (Remote host closed the connection) | 17:38 | |
| *** dankm <dankm!~dan@user/dankm> has joined #oe | 17:40 | |
| mort | hm why is bitbake-server running under qemu-aarch64-static | 18:19 |
| mort | WHY IS MY /USR/BIN/PYTHON3 AN AARCH64 EXECUTABLE WAT | 18:20 |
| mort | ah. | 18:20 |
| mort | I accidentally created this docker container with --platform linux/arm64. That explains why everything seemed much slower than it should | 18:20 |
| *** skokkonda <skokkonda!~skokkonda@49.205.249.255> has quit IRC (Ping timeout: 252 seconds) | 18:22 | |
| rburton | lol | 18:45 |
| rburton | a fun fact I had to debunk once was that cross compilers are slower than native compilers | 18:46 |
| mort | cross compilers are much slower than native compilers if your cross compiler is an emulated native compiler | 18:46 |
| mort | turns out | 18:46 |
| *** florian <florian!~florian@dynamic-078-048-062-212.78.48.pool.telefonica.de> has joined #oe | 18:53 | |
| mort | what would be the logic behind cross compilers being slower than native compilers, it's not like CPUs have special instructions to optimize emitting bytes representing instructions for themselves | 18:53 |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 19:20 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 19:20 | |
| *** mvlad <mvlad!~mvlad@2a02:2f05:821a:fb00:e88e:21ff:fe65:be18> has quit IRC (Remote host closed the connection) | 20:25 | |
| rburton | mort: yeah no idea | 20:56 |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 20:57 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 20:57 | |
| hrw | cross or canadian-cross? | 21:20 |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 21:32 | |
| mort | cross presumably, canadian is very "compiling a cross compiler" specific right | 21:32 |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 21:32 | |
| mort | neat I found https://libera.irclog.whitequark.org/yocto/2021-11-30, someone else with a "libgomp: Thread creation failed: Resource temporarily unavailable" error during packaging while using rpm packages and building in a podman container | 21:35 |
| mort | I don't get why linux has so many arbitrary and surprisingly low limits, hundreds of cores aren't abnormal anymore | 21:39 |
| *** florian <florian!~florian@dynamic-078-048-062-212.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 21:52 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 22:18 | |
| *** Saur_Home5 <Saur_Home5!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #oe | 22:19 | |
| *** Kubu_work <Kubu_work!~kubu@lfbn-nan-1-335-137.w82-120.abo.wanadoo.fr> has quit IRC (Quit: Leaving.) | 22:28 | |
| mort | I had forgotten how annoying it is to have a yocto system with chromium T_T this thing has been abusing all my 32 hardware threads for hours now | 22:41 |
| khem | mort: if you built a container with --platform linux/arm64 and your target is arm64 then you do not need OE or any other cross-compiling infra :) | 23:46 |
| khem | and yes it will be slower if your host system is say x86_64 | 23:46 |
| khem | cross compilers are not slower than native compilers if you are using compiler terminology, a cross compiler itself will run like a native binary on the build host like the native compiler would, only difference is that the output it will generate will be for the target host and build != targer host where as for native compiler build == host target | 23:50 |
| khem | canadian cross compiler is a special case of cross compiler, where step 1 is to build a cross compiler which will be built on one system 'build host' runs on another system 'host' and generate code for yet another different system 'target host' | 23:54 |
| khem | yocto's SDKs use this method quite a bit | 23:55 |
| khem | mort: I could never get podman to behave well, docker works well surprisingly, see https://github.com/YoeDistro/yoe-distro/issues/789 | 23:56 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!