| *** BobPungartnik <BobPungartnik!~BobPungar@177.41.206.9> has quit IRC | 00:00 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@177.41.206.9> has joined #yocto | 00:01 | |
| JPEW | ah, I see the minimum is listed as 3.4 | 00:12 |
|---|---|---|
| *** monkeyman79 <monkeyman79!~monkeyman@apn-5-60-198-197.dynamic.gprs.plus.pl> has joined #yocto | 00:41 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 00:56 | |
| *** PinkSnake <PinkSnake!51ff1123@81.255.17.35> has quit IRC | 01:05 | |
| *** camus <camus!~Instantbi@222.67.188.194> has joined #yocto | 01:34 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 01:38 | |
| *** camus is now known as kaspter | 01:38 | |
| *** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has quit IRC | 01:44 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.194> has quit IRC | 01:52 | |
| *** monkeyman79 <monkeyman79!~monkeyman@apn-5-60-198-197.dynamic.gprs.plus.pl> has quit IRC | 01:52 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.181> has joined #yocto | 02:02 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@177.41.206.9> has quit IRC | 02:09 | |
| *** wak-work <wak-work!wak-workma@gateway/shell/matrix.org/x-unzlbewtdtizbuqi> has quit IRC | 02:19 | |
| *** silviof <silviof!silv-iomat@gateway/shell/matrix.org/x-pqixlwlqvyoapnbz> has quit IRC | 02:19 | |
| *** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-cxlwoltkhsygzcrz> has quit IRC | 02:19 | |
| *** bachp <bachp!bachpmatri@gateway/shell/matrix.org/x-isiejdwqixlowryo> has quit IRC | 02:19 | |
| *** bachp <bachp!bachpmatri@gateway/shell/matrix.org/x-lbmyizapxypkkluc> has joined #yocto | 02:25 | |
| *** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-gnfejstjobvjcmum> has joined #yocto | 02:41 | |
| *** silviof <silviof!silv-iomat@gateway/shell/matrix.org/x-cohmpvvguynesgub> has joined #yocto | 02:41 | |
| *** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-gnfejstjobvjcmum> has quit IRC | 02:50 | |
| *** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has quit IRC | 02:50 | |
| *** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-euabtsighxzzilgj> has joined #yocto | 02:51 | |
| *** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has joined #yocto | 02:56 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 03:04 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.181> has quit IRC | 03:12 | |
| *** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has quit IRC | 03:18 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.177> has joined #yocto | 03:23 | |
| *** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has joined #yocto | 03:24 | |
| *** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC | 04:03 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:06 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:16 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:18 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:24 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:24 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:25 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:28 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:29 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:32 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:41 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:45 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:45 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 04:45 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:48 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:49 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:53 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 04:54 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC | 04:56 | |
| *** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has joined #yocto | 05:01 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 05:06 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 05:21 | |
| iceaway | I'm still struggling with my initramfs image. I (think) I have managed to load the kernel+initramfs+dtb from sdcard into RAM, but when I boot the kernel I eventually get the message: root '' doesn't exist or does not contain a /dev | 05:21 |
| iceaway | Looking at the generated cpio.gz of the root filesystem, there certainly is a /dev there with a console node. | 05:22 |
| kroon | iceaway, which yocto version are you on ? | 05:23 |
| iceaway | I'm using 2.5 | 05:23 |
| kroon | iceaway, maybe its not related, but i remember fixing a missing console device in an initramfs with https://github.com/openembedded/openembedded-core/commit/490d6fbd14805b6c72b525fbe8c9c6e08d796597 | 05:26 |
| kroon | but that doesn't like your error message | 05:27 |
| kroon | but "root ''" looks like the kernel is being passed an empty root string, no ? | 05:29 |
| iceaway | Yes, I thought that was the recommended approach when using a "bundled" initramfs, no? | 05:31 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:34 | |
| kroon | iceaway, not sure about that | 05:35 |
| kroon | iceaway, maybe try: root=/dev/ram0 | 05:36 |
| kroon | iceaway, from https://www.kernel.org/doc/html/latest/admin-guide/initrd.html | 05:36 |
| *** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has quit IRC | 05:36 | |
| kroon | or maybe im confusing initrd with initramfs here | 05:42 |
| iceaway | I think so, I think the kernel knows that it has the built-in initramfs and thus does not need the root= parameter | 05:47 |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto | 05:49 | |
| *** zkrx <zkrx!~quassel@adsl-89-217-88-77.adslplus.ch> has quit IRC | 05:57 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 06:03 | |
| *** zkrx <zkrx!~quassel@adsl-89-217-88-77.adslplus.ch> has joined #yocto | 06:05 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:30 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 06:40 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto | 06:40 | |
| qschulz | iceaway: AFAIR, yes. It's even "worse", if there is a bundled initramfs, the root= is ignored IIRC | 06:42 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 06:47 | |
| iceaway | qschulz: so for some reason it seems that the kernel does not recognize the bundled initramfs. From what I could figure out i should see a "uncompressing initramfs" message somethere during the boot. | 06:48 |
| qschulz | iceaway: is it possible for you to test it manually? take the .cpio of your initramfs and give it to the kernel at compilation time? (I mean, compiling the kernel outside of Yocto) that way you know if it's the initramfs (cpio) which is bad or the current implementation of initramfs bundliung in your Yocto | 06:51 |
| qschulz | iceaway: maybe you can give the bootlog? I think the kernel supports multiple types of compression but they might not be all enabled by default, so if you're trying a cpio.gz and it's not supported in the kernel you're building.. well it's not going to work | 06:53 |
| iceaway | qschulz: I suppose that would be possible, just need to look into how to do that. I have checked my kernel config, and all initramfs/initrd compression options are enabled. | 06:54 |
| iceaway | bootlog: https://pastebin.com/M3Jap8Dd | 06:56 |
| *** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC | 06:57 | |
| iceaway | (Maybe) strange that it says freeing unused kernel memory (20032K), that should be the initramfs | 06:58 |
| yocti | New news from stackoverflow: Yocto xfce image on jetson nano camera test: No element "nvarguscamerasrc" <https://stackoverflow.com/questions/57968736/yocto-xfce-image-on-jetson-nano-camera-test-no-element-nvarguscamerasrc> | 06:58 |
| *** PinkSnake <PinkSnake!51ff1123@81.255.17.35> has joined #yocto | 07:00 | |
| qschulz | iceaway: interesting! I don't want to mislead you but I think it's actually loading the initramfs? I don't think `udevd[223]: starting eudev-3.2.5` is part of the kernel | 07:01 |
| *** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto | 07:01 | |
| qschulz | iceaway: I would check what you're initramfs is supposed to do. A few systems actually boot an initramfs by default and from there loads a rootfs from another medium. So it might be trying to find where the rootfs to switch to is, but there is none. | 07:02 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 07:04 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 07:12 | |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto | 07:15 | |
| *** yann <yann!~yann@aputeaux-655-1-52-10.w86-195.abo.wanadoo.fr> has quit IRC | 07:17 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 07:22 | |
| iceaway | qschulz: definitely worth looking into, will do that in a bit. Still all new to working with initramfs stuff. | 07:22 |
| jmiehe | Hi, does bitbake automatically extract a .tar.gz file if that's my source? Can/should I stop that? | 07:24 |
| jmiehe | I want to include third-party software provided to us as an archive and not worry too much about its internal structure. Can I manually extract that tar.gz? | 07:27 |
| LetoThe2nd | jmiehe: have you looked up the corresponding fetcher documentation in the bitbake manual? should be mentioned there, me guesses. | 07:29 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 07:31 | |
| jmiehe | LetoThe2nd: in https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#local-file-fetcher, there's the sentence "If you specify a directory, the entire directory is unpacked." | 07:34 |
| LetoThe2nd | jmiehe: scroll up a litt,e find https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#bb-the-unpack | 07:34 |
| LetoThe2nd | jmiehe: i think it explains exactly what you want | 07:34 |
| jmiehe | I found that the second I posted the previous link^^ | 07:35 |
| LetoThe2nd | :-) | 07:35 |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 07:37 | |
| jmiehe | tl;dr specify as file://SOMETHING.tar.gz;unpack=0 | 07:38 |
| *** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has quit IRC | 07:45 | |
| *** yacar_ <yacar_!~yacar@87-231-0-253.rev.numericable.fr> has joined #yocto | 07:51 | |
| *** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has joined #yocto | 08:08 | |
| *** shan1 <shan1!86666183@dhcp-131.biba.uni-bremen.de> has joined #yocto | 08:09 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 08:09 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:10 | |
| *** goliath <goliath!~goliath@82.150.214.1> has joined #yocto | 08:11 | |
| *** kpo <kpo!~kpo@eet50.internetdsl.tpnet.pl> has quit IRC | 08:16 | |
| *** kpo <kpo!~kpo@eet50.internetdsl.tpnet.pl> has joined #yocto | 08:18 | |
| jmiehe | Is there a more bitbakey-way of changing an RPATH than just calling patchelf (or chrpath)? | 08:29 |
| *** yann|work <yann|work!~yann@85.118.38.73> has joined #yocto | 08:43 | |
| iceaway | I need to add a file (a startup script) to my image, so there is to real source code or remote repo involed. Would the recommnded approach be to create a recipe that simply copies the file from the recipe directory to the target? | 08:47 |
| LetoThe2nd | iceaway: startup scripts are often just added to the layers directly, unless they correlate with a bigger application which they actually start up | 08:48 |
| shan1 | LetoThe2nd saw the video from yesterday's live coding. Do you need help in a writeup of the all the episodes? The writeup could include all the steps you performed in the videos (minus the mistakes) for a future reference. | 08:53 |
| LetoThe2nd | shan1: if you want to do a write up / summary /whatever, it will certainly be appreciated, I'm sure we can forward it to the right people for it to reach a wider audience. yet, i do not intend to make such. | 08:55 |
| iceaway | LetoThe2nd: how do you mean added to the layer directly? How would I add it to the image ? | 08:56 |
| LetoThe2nd | iceaway: its three things. 1) a recipe, for example fantastic_start.bb | 08:56 |
| LetoThe2nd | 2) the actual script, located in fantastic_start/realscript right next to the recipe | 08:57 |
| shan1 | I can try squeezing some time for e.g. Video#1 and find out some nuggets and then write them up. Will let you in on a fdraft | 08:57 |
| LetoThe2nd | 3) the image has IMAGE_INSTALL += "fantastic_startup" | 08:57 |
| LetoThe2nd | erm, "fantastic_start", of course | 08:57 |
| LetoThe2nd | shan1: :-) | 08:57 |
| LetoThe2nd | shan1: as i said, i can maybe find some time for review and comments, but will not do actual writing. | 08:58 |
| yocti | New news from stackoverflow: Same build/source code for multiple machines in Yocto <https://stackoverflow.com/questions/57811452/same-build-source-code-for-multiple-machines-in-yocto> | 08:58 |
| shan1 | LetoThe2nd You don't have to. I can take that part. | 08:58 |
| iceaway | LetoThe2nd: ok sounds good, I will give that a go! Thanks! | 09:00 |
| *** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has joined #yocto | 09:01 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 09:08 | |
| yocti | New news from stackoverflow: No ethernet access on jetson nano with custom yocto image <https://stackoverflow.com/questions/57970792/no-ethernet-access-on-jetson-nano-with-custom-yocto-image> | 09:28 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:32 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 09:33 | |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto | 09:36 | |
| rburton | kergoth: the web site is failing to actually explain why git-revise is better than rebase | 09:37 |
| LetoThe2nd | rburton: NOTHING IS BETTER THAN GIt REBASE! | 09:38 |
| * LetoThe2nd puts hands on ears and starts singing LALALALALALA | 09:39 | |
| rburton | well revise is rebase but less poking at the disk, so its faster | 09:39 |
| LetoThe2nd | LALALALALALAAAAAA | 09:39 |
| diego_r | LetoThe2nd: "git rebase -i" is better than "git rebase" | 09:39 |
| LetoThe2nd | that counts as git rebase :) | 09:40 |
| rburton | though 'A successful git revise will add a single entry to the reflog, allowing it to be undone with git reset @{1}. Unsuccessful git revise commands will leave your repository largely unmodified.' is a killer feature on its own | 09:40 |
| qschulz | diego_r: git rebase -i --autosquash is the dream :) | 09:42 |
| LetoThe2nd | rburton: DONT CONFUSE ME WITH FACTS! | 09:43 |
| diego_r | qschulz: :) | 09:44 |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto | 10:13 | |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 10:17 | |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC | 10:18 | |
| *** shan1 <shan1!86666183@dhcp-131.biba.uni-bremen.de> has quit IRC | 10:20 | |
| *** fbre <fbre!91fdde45@145.253.222.69> has joined #yocto | 10:24 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 10:26 | |
| fbre | Hi! I'm still wondering why I can't manage to install my own systemd service via Yocto .bb file. That bitbake does install the files at the right directories but my new systemd service is not enabled on reboot of my yocto Linux. | 10:26 |
| fbre | I found out "systemctl enable start-firmware.service" actually just creates a symlink from /lib/systemd/system/start-firmware.service to a subdir called /lib/systemd/system/multi-user.targets.wants. | 10:28 |
| fbre | Now I wanted to do that by myself in the start-firmware.bb do_install() section by adding there the following line: | 10:28 |
| LetoThe2nd | fbre: stupid as it may sound, you do not tinker with SYSTEMD_AUTO_ENABLE? and set SYSTEMD_SERVICE as well as SYSTEMD_PACKAGES accordingly? | 10:29 |
| LetoThe2nd | fbre: see also https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/systemd.bbclass#n9 | 10:29 |
| fbre | ln -sfr ${D}${systemd_system_unitdir}/multi-user.targets.wants/start-firmware.service ${D}${systemd_system_unitdir}/start-firmware.service | 10:30 |
| LetoThe2nd | fbre: see http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-extended/cronie/cronie_1.5.4.bb for an example of a rather simple recipe that perfectly works with systemd auto-enabled | 10:31 |
| fbre | But adding this symlink creation to do_install() leads to an bitbake error "start-firmware-1.0-r0 do_package: SYSTEMD_SERVICE_start-firmware value start-firmware.service does not exist | 10:31 |
| fbre | LetoThe2nd: systemd.bbclass contains a line: SYSTEMD_AUTO_ENABLE ??= "enable". So it should be enabled by default. | 10:32 |
| LetoThe2nd | fbre: i don't know what you're doing, so its hard to tell. i can only say that the cronie recipe does exac6tly what you wnt, so try reproducing it step by step | 10:33 |
| fbre | LetoThe2nd: my start-firmware.bb file has also a line SYSTEMD_AUTO_ENABLE_${PN} = "enable" | 10:33 |
| fbre | I can upload my .bb file to pastebin if that helps | 10:34 |
| LetoThe2nd | fbre: oh, and please note the little magic snippet in cronie's do_install that seds the service files. its needed. | 10:34 |
| LetoThe2nd | so really, try and reproduce starting from that. | 10:34 |
| fbre | LetoThe2nd: OK, where is cronie located in the file tree? | 10:35 |
| fbre | LetoThe2nd: Should I just search for a file called "cronie"? | 10:35 |
| LetoThe2nd | fbre: *sigh* scroll up. read again | 10:38 |
| rburton | fbre: just checking: you know that file you're expecting to exist should be created at install time, not package build time. | 10:48 |
| rburton | the postinst should be creating it when installed, be it on target or at rootfs time. it won't be in the package. | 10:49 |
| *** feilz <feilz!~feil@212-50-143-116.co.dnainternet.fi> has quit IRC | 10:54 | |
| fbre | rburton: yes, I know. At install time. | 10:58 |
| fbre | LetoThe2nd: Ah OK, now I checked your links and see that cronie. Reading trough it now... | 10:59 |
| rburton | fbre: can you replicate the problem with a minimal recipe? | 11:01 |
| iceaway | This initramfs-thing is driving me nuts. What I am trying to do is to run a tiny image live from RAM, but everything seems to be centered around mounting the "real" rootfs as the initramfs is loaded. Am I missing something? I am basing my image on core-image-minimal-initramfs, and all the "startup scripts" try to mount another root filesystem. To get rid of those scripts I have to remove all the | 11:10 |
| iceaway | initramfs-* packages, so that ultimately I cannot even build the image. | 11:10 |
| LetoThe2nd | iceaway: what is the rationale/usecase behind it anyways? | 11:11 |
| LetoThe2nd | iceaway: it might very well be a "i want to do x, and think that initramfs is the way archieve it" case | 11:11 |
| fbre | rburton: yes, my start-firmware.bb is actually already a trivial one. So does the start-firmware.service file (IMHO) | 11:11 |
| iceaway | LetoThe2nd: I want to run the swupdate utility from RAM, so I can upgrade the firmware/software (even the swupdate part if required). | 11:12 |
| rburton | iceaway: the core-image-minimal-initramfs is designed to boot real file system, yes. what's the difference between an initramfs and a 'real' file system though, apart from the type of file system | 11:13 |
| LetoThe2nd | iceaway: but that can be done way simpler | 11:13 |
| rburton | the important bit is setting IMAGE_FSTYPES | 11:13 |
| LetoThe2nd | iceaway: just make an initrd and glue it up | 11:13 |
| iceaway | LetoThe2nd: you make it sound so simple :) | 11:14 |
| LetoThe2nd | iceaway: the complications of initramfs and all are not worth the headaches if the only thing you want to do is "run x from ram" | 11:14 |
| LetoThe2nd | if you're on arm, you can totally glue up kernel + dtb + initrd into a fit image, and tell u-boot to use that. done. | 11:15 |
| *** learningc <learningc!~learningc@121.122.76.45> has joined #yocto | 11:15 | |
| iceaway | LetoThe2nd: I'm definitely starting to see that now. I tried making an initrd, but failed when u-boot complained about the initrd format. Can I generate an initrd from within Yocto, in a similar way that it build my initramfs? | 11:15 |
| LetoThe2nd | iceaway: an initrd is just a standard filesystem, basically | 11:15 |
| LetoThe2nd | and see, here's even fit-image support ready to use: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel-fitimage.bbclass | 11:16 |
| LetoThe2nd | everybody seems to love initramfs there days, but in my opinion they only serve a very specific usecase. | 11:16 |
| iceaway | So I could in theory just use the filesystem that Yocto already generates? | 11:17 |
| rburton | precisely the point | 11:17 |
| LetoThe2nd | iceaway: bingo. thats what we do. | 11:17 |
| iceaway | Cool. Would I need to put it in some kind of initrd-container ? | 11:17 |
| LetoThe2nd | scroll up, read again. | 11:17 |
| LetoThe2nd | rburton: can you put a mark on the XY-question list? | 11:18 |
| iceaway | Will do. Thanks a lot. Now I will attack this from a different angle. | 11:18 |
| fbre | LetoThe2nd: Do I understand you right you mean with your note about cronie that I should use it as example of a service that works well? | 11:19 |
| LetoThe2nd | 10:33 < LetoThe2nd> fbre: i don't know what you're doing, so its hard to tell. i can only say that the cronie recipe does exac6tly what you wnt, so try reproducing it step by step | 11:19 |
| LetoThe2nd | fbre: i think that i said pretty much precisely that, yes. | 11:19 |
| fbre | Leto | 11:19 |
| fbre | LetoThe2nd: ah OK, thanks. I was reading it as if cronie is a sub-tool of bitbake doing that installing. Sorry, I was confused | 11:20 |
| LetoThe2nd | fbre: thats why i said "scroll up, read again". :) | 11:21 |
| fbre | LetThe2nd: yes, sorry. I was a bit distracted here by other things happening in parallel here at work. That's why my slow response also. Thanks for the cronie example. I can imagine it can help me! Now I've something to step further. Thanks a lot, guys! | 11:23 |
| *** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC | 11:25 | |
| yocti | New news from stackoverflow: "do_populate_sdk:Could not invoke dnf. Command" in yocto warrior branch <https://stackoverflow.com/questions/57973228/do-populate-sdkcould-not-invoke-dnf-command-in-yocto-warrior-branch> | 11:29 |
| *** tgoodwin <tgoodwin!~tgoodwin@static-108-40-78-74.bltmmd.fios.verizon.net> has joined #yocto | 11:36 | |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:41 | |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 11:46 | |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:48 | |
| kroon | Why am I seeing "DEBUG: Updating new environment variable LC_ALL to en_US.UTF-8", and all recipes are reparsed on each invocation of bitbake, although no recipes/conf files changed | 12:00 |
| kroon | nm, im confused | 12:06 |
| *** nabokov <nabokov!~armand@67.218.223.154> has quit IRC | 12:06 | |
| kroon | log says bitbake is gonna rebuild bb_cache.dat, but it never gets created, there is just a dangling symlink | 12:10 |
| fbre | YIPPPIE!!!!!!!!!!!!! I found the failure. | 12:15 |
| fbre | The file start-firmware.service had a bad newline character in the last line of the file. I replaced it with a Linux newline character \n and suddenly it works | 12:17 |
| fbre | This took me two and a half days *sigh* | 12:18 |
| fbre | It is exactly the same type of error as reported here: http://lists.openembedded.org/pipermail/openembedded-devel/2016-March/106656.html | 12:19 |
| fbre | The difference is just that I had a bad newline char while the guy from the mailing-list had a bad space char | 12:20 |
| fbre | I wonder why it has such impact of the fact whether the whole thing works or not | 12:21 |
| rburton | fbre: please create a bug :) | 12:22 |
| fbre | I had \r\n and it has to be \n | 12:22 |
| rburton | we have a custom systemctl for rootfs-time which presumably has bad line breaking logic in | 12:23 |
| fbre | That is why I asked where that custom systemctl is located 2 days ago. I really want to see that script and what it does. Maybe I can provide a patch. | 12:25 |
| rburton | please do | 12:25 |
| rburton | systemctl-native | 12:25 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 12:27 | |
| palate | I'm not completely clear with configuring the kernel. Does `bitbake -c menuconfig` open the kernel of the BSP referenced by `MACHINE` in my conf/local.conf? | 12:29 |
| palate | I'd like to take the defconfig of the BSP I'm using (meta-pocketbeagle in this case) and add an option to the kernel | 12:30 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 12:37 | |
| zeddii | palate. yes it would. | 12:38 |
| *** learningc <learningc!~learningc@121.122.76.45> has quit IRC | 12:41 | |
| fbre | I'm in Bugzilla now. I select "Build System, Metadata & Runtime". Is that systemctl-native thing now a problem of BitBake, BSPs, Meta-yocto, OE-Core, Other YP Layer, Runtime, Security - Recipe Ugrade or Toaster? | 12:46 |
| rburton | its in oe-core, so oe-core | 12:47 |
| rburton | then the core component, i guess | 12:47 |
| fbre | all right | 12:48 |
| fbre | thanks | 12:48 |
| *** learningc <learningc!~learningc@121.122.76.45> has joined #yocto | 12:50 | |
| yates | on an initramfs boot, where there is no x11 or other graphical interface, it appears the console is echoed on the display. how do i disable this? | 12:51 |
| yates | i want to take full control of the frame buffer with a startup application | 12:52 |
| yates | it appears the cursor from the console takes out a block of pixels from the frame buffer and hoses my screen. | 12:53 |
| yates | i.e., this is the image specified in my build's local.conf: INITRAMFS_IMAGE = "initramfs-image" | 12:55 |
| fbre | rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13535 | 12:55 |
| yocti | Bug 13535: normal, Undecided, ---, ross.burton, NEW , systemctl | 12:55 |
| yates | also, what is the process for submitting a new or updated recipe to oe? | 12:57 |
| yates | hello? | 13:00 |
| yates | is this thing on? | 13:00 |
| *** nabokov <nabokov!~armand@67.218.223.154> has joined #yocto | 13:01 | |
| * yates checks his internet connection.. | 13:01 | |
| rburton | yates: post a patch to the list | 13:03 |
| rburton | should be in the readme for whatever layer | 13:03 |
| yates | ok | 13:04 |
| yates | nobody knows how to disable console output on the display? | 13:05 |
| LetoThe2nd | yates: kernel option fb_console or something similar | 13:07 |
| LetoThe2nd | yates: look there, you'll find it | 13:08 |
| yates | LetoThe2nd: will do! thank you! | 13:08 |
| *** Kobboi <Kobboi!~Kobboi@14.125.146.82.ipv4.evonet.be> has joined #yocto | 13:10 | |
| yates | CONFIG_FRAMEBUFFER_CONSOLE=y ? | 13:10 |
| Kobboi | i've built a toolchain with bitbake meta-toolchain, how can I make it have a static libc (next to the existing dynamic one)? | 13:10 |
| LetoThe2nd | yates: sounds fitting, if that is y then it might be the cause. | 13:12 |
| fbre | see you guys. I'll give a party now since the failure is found :-D Thanks again and Bye | 13:13 |
| *** fbre <fbre!91fdde45@145.253.222.69> has quit IRC | 13:14 | |
| yates | rburton: ack. | 13:15 |
| *** kanavin_ <kanavin_!~kanavin@141.113.67.203> has quit IRC | 13:24 | |
| zeddii | RP: before I send the strace issue to lkml, I'm doing a clean build and run and will also do it with 5.3 .. just in case there's already a fix lurking. | 13:27 |
| *** gourve_l <gourve_l!~laurent@40.72.95.92.rev.sfr.net> has joined #yocto | 13:30 | |
| *** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto | 13:32 | |
| JPEW | RP: Sent V2 of the hashequiv with the requested changes... it should skip the tests (and at least parse) on Python 3.5, but I don't have a 3.5 image handy to test with | 13:38 |
| yates | rburton: i can't find a wx recipe in my layers but i'm pretty sure i based mine on this one: https://layers.openembedded.org/layerindex/recipe/20507/ | 13:38 |
| *** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 13:42 | |
| yates | https://layers.openembedded.org: Your account has been locked out. Please contact the admin. | 13:44 |
| fullstop | how do I add strace to an image? I've added it as a package in local.conf but it doesn't seem to be included.. ? | 13:44 |
| yates | fullstop: CORE_IMAGE_EXTRA_INSTALL += "strace" | 13:45 |
| yates | in your image.bb file | 13:45 |
| fullstop | OMG | 13:45 |
| fullstop | CORE_IMAGE_INSTALL_EXTRA | 13:45 |
| fullstop | I can't believe that I did that | 13:45 |
| yates | you mean you can't believe you're human? | 13:46 |
| fullstop | I can't believe that I didn't see it sitting right next to the others with the right word order. :-) | 13:46 |
| yates | lol | 13:47 |
| qschulz | fullstop: mmmmm, you know you should really avoid doing too much of that? Use an image recipe and IMAGE_INSTALL when you're ready, local.conf shouldn't really be shared | 13:47 |
| qschulz | and CORE_IMAGE_EXTRA_INSTALL should be used only in local.conf according to the ref-manual (I didn' | 13:47 |
| qschulz | t know that) | 13:47 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 13:48 | |
| fullstop | I'm only using CORE_IMAGE_EXTRA_INSTALL in local.conf and it will be moved into layers and cleaned up once I know what I want and what I'm doing. | 13:48 |
| *** nabokov <nabokov!~armand@67.218.223.154> has quit IRC | 13:48 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 13:49 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 13:51 | |
| RP | JPEW: thanks, I'll trigger a test run | 13:58 |
| *** nabokov <nabokov!~armand@208.86.205.5> has joined #yocto | 14:00 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 14:01 | |
| *** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 14:07 | |
| JPEW | RP: Oops, I send that patch to the wrong ML :/ | 14:07 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 14:14 | |
| *** armpit <armpit!~armpit@2601:202:4180:c33:bd66:ef14:2024:3051> has quit IRC | 14:24 | |
| *** nabokov <nabokov!~armand@208.86.205.5> has quit IRC | 14:32 | |
| *** armpit <armpit!~armpit@2601:202:4180:c33:45b7:cfa2:129c:2a54> has joined #yocto | 14:37 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 14:43 | |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC | 14:54 | |
| *** goliath <goliath!~goliath@82.150.214.1> has quit IRC | 14:54 | |
| armpit | YPTM - armin is on | 14:58 |
| dl9pf | YPTM - Jan-Simon is on | 14:59 |
| yocti | New news from stackoverflow: Yocto system lockup: rcu_preempt detected stalls on CPUs/tasks <https://stackoverflow.com/questions/57976701/yocto-system-lockup-rcu-preempt-detected-stalls-on-cpus-tasks> | 14:59 |
| rburton | JPTM ross in | 15:05 |
| armpit | Tim its a trap | 15:08 |
| rburton | run away from the docbook | 15:09 |
| zeddii | YPTM: on another meeting. but will lurk on IRC. | 15:09 |
| *** behanw <behanw!uid110099@gateway/web/irccloud.com/x-yiqloelgeevqanwv> has quit IRC | 15:10 | |
| *** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 15:11 | |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 15:14 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 15:14 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 15:15 | |
| RP | BB_SIGNATURE_HANDLER = "OEEquivHash" | 15:15 |
| RP | BB_HASHSERVE = "auto" | 15:15 |
| *** JPEW25 <JPEW25!cc4da373@204.77.163.115> has joined #yocto | 15:17 | |
| tlwoerner | YPTM: tlwoerner has been on since the start (but wasn't watching IRC) | 15:17 |
| RP | https://autobuilder.yocto.io/pub/non-release/20190916-9/testresults/testresult-report.txt | 15:18 |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC | 15:23 | |
| RP | smurray: I think that unit file perhaps should read ConditionPathExists=!/lib/udev/hwdb.bin | 15:32 |
| RP | ConditionPathExists=!/etc/udev/hwdb.bin | 15:32 |
| RP | ConditionPathExists=|!/lib/udev/hwdb.bin | 15:32 |
| RP | ConditionPathExists=|!/etc/udev/hwdb.bin | 15:32 |
| RP | since we want to trigger if either the etc or lib hwdb.bin isn't present but if one is we're ok | 15:33 |
| smurray | hrm, it's |/etc/udev/hwdb.bin even on Fedora, which you'd think would be a distro where people pay attention to that | 15:34 |
| RP | smurray: hence why I think I have to be missing something | 15:36 |
| RP | rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1054 (distcc breaks) | 15:37 |
| smurray | RP: the commit message that added that logic implies it's to prevent regenerating it | 15:37 |
| smurray | RP: so I agree, the condition seems wrong, and it is strange ;) | 15:38 |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 15:40 | |
| rburton | damnit | 15:40 |
| RP | smurray: I suspect upstream would tell us to generate the file into /lib | 15:41 |
| smurray | RP: it does look to have been regenerated on my F30 desktop even though Fedora ship it as a binary in /etc/udev, and have no extra files in /etc/udev/hwdb.d... | 15:41 |
| RP | Does anyone know any friendly systemd people we could ask? | 15:42 |
| smurray | RP: it seems likely the x86 folks probably never noticed it since it's fast | 15:42 |
| RP | smurray: right :/ | 15:42 |
| smurray | RP: heh, I'm going to be at the All Systems Go! conf this weekend, I could ask in person, perhaps | 15:42 |
| smurray | RP: might be easier to open an issue in their github | 15:43 |
| RP | smurray: right, an issue would be the next step I think | 15:43 |
| palate | I am using meta-pocketbeagle from here: https://github.com/e-ale/meta-pocketbeagle, and it works. I wanted to add support for g_ether in the kernel, and used `bitbake -c menuconfig virtual/kernel` to edit it, and then `bitbake -c savedefconfig virtual/kernel` to save it as defconfig. However, it looks very different from the original defconfig: | 15:44 |
| palate | https://github.com/e-ale/meta-pocketbeagle/blob/master/recipes-kernel/linux/files/defconfig | 15:44 |
| palate | For instance, my defconfig doesn't have any "is not set" line. | 15:44 |
| palate | When running `bitbake -c menuconfig virtual/kernel`, isn't it supposed to load the defconfig from meta-pocketbeagle, so that I can just edit it? | 15:45 |
| LetoThe2nd | palate: probably the layer maintainers use make savedefconfig before adding the result, which means all the non-set options are stripped out to remove unneded clutter. | 15:45 |
| palate | LetoThe2nd: well, my defconfig has those lines stripped out, but the layer doesn't. That's the opposite of what you suggest, right? | 15:46 |
| LetoThe2nd | palate: yeah then i got it backwards. but the meaning is clear, right? | 15:47 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 15:47 | |
| tlwoerner | LetoThe2nd: palate: actually the opposite. the layer defconfig is just the straight .config from the kernel build. | 15:47 |
| palate | oh, right. | 15:48 |
| tlwoerner | palate: are you using the master or OE/master branch? (or something else?) | 15:49 |
| palate | tlwoerner: of yocto? 2.7.1 | 15:50 |
| tlwoerner | palate: of meta-pocketbeagle | 15:50 |
| palate | tlwoerner: master | 15:51 |
| palate | You're right, it's apparently the .config directly. But then my .config is quite different than theirs. I just added "USB_ETH" as a module to get g_ether, and now my image doesn't build (it loops on "no usb device found"). Difficult to see if I messed something up in the kernel config | 15:53 |
| palate | (well I autoload g_ether, too, maybe that's not clever as a first try) | 15:54 |
| tlwoerner | palate: thanks. i was just curious. master is using the yocto-linux kernel (4.x) and OE/master is using 5.2.14 stable (upstream) | 15:54 |
| palate | tlwoerner: oh, you are actually the author :D | 15:55 |
| tlwoerner | helper | 15:55 |
| palate | tlwoerner: should I be using OE/master? | 15:55 |
| tlwoerner | depends on what you want | 15:55 |
| palate | tlwoerner: I want a pocketbeagle that can run g_ether :D | 15:55 |
| tlwoerner | so you're plugging in a usb-to-ether into the baconbits cape? | 15:56 |
| palate | tlwoerner: no, I just have a pocketbeagle (I don't know what the baconbits cape is). And yes, I try to connect to it from my computer over usb | 15:57 |
| tlwoerner | palate: https://images.app.goo.gl/BrUDPtr2qe2LfKfe6 | 15:58 |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 15:59 | |
| RP | smurray, rburton: https://github.com/systemd/systemd/issues/13581 | 15:59 |
| palate | tlwoerner: right. No I only have the pocketbeagle | 15:59 |
| palate | tlwoerner: but I guess the meta-pocketbeagle should still be fine | 16:00 |
| tlwoerner | palate: in any case, that's a common use-case. i'll take a look at enabling it "out of the box" | 16:00 |
| palate | tlwoerner: could it be that the pocketbeagle is "OTG" and therefore needs other modules than just g_ether? | 16:01 |
| tlwoerner | palate: yea, using the pocketbeagle by itself will be different than with the cape. i'm not sure how i'd connect an ethernet dongle to the pocketbeagle alone | 16:02 |
| LetoThe2nd | tlwoerner: guess i should get a pb plus cape some time soon too :P | 16:02 |
| palate | tlwoerner: I'm connecting a USB cable from my computer to the pocketbeagle, that's it | 16:03 |
| tlwoerner | i have one of these i can experiment with: https://images.app.goo.gl/9Z8xqWUq2arixK8y5 | 16:03 |
| palate | tlwoerner: why not just a USB cable between your computer and the beagle? | 16:03 |
| tlwoerner | palate: that's a serial console :-) | 16:04 |
| palate | My goal is to learn how to setup my yocto such that I can connect my computer to the pocketbeagle, have it recognized as an ethernet gadget, get an IP from a DHCP server running on the pocketbeagle, and then SSH into it | 16:04 |
| *** learningc <learningc!~learningc@121.122.76.45> has quit IRC | 16:04 | |
| palate | tlwoerner: so I really want ethernet going through a normal usb cable, hence g_ether | 16:05 |
| smurray | palate: you're going to have more luck asking on #beagle imo | 16:07 |
| palate | smurray: I just broke my image by updating the kernel, so I was wondering if I had done something wrong there. Maybe I did it right, but I just did not set the right options :D | 16:08 |
| smurray | palate: questions about kernel config are more on topic for #beagle | 16:09 |
| palate | got it, thanks :) | 16:10 |
| tlwoerner | someday the yocto project / oe will decide on one set of tools for kernel configs, then all BSP layers can have one mechanism ;-) | 16:10 |
| *** kanavin <kanavin!~kanavin@141.113.67.203> has joined #yocto | 16:10 | |
| palate | tlwoerner: what are the different mechanisms? I only know menuconfig | 16:11 |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 16:11 | |
| tlwoerner | behind the scenes there are differences. take a look at meta-raspberrypi | 16:12 |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 16:13 | |
| Crofton | tlwoerner, and then we solve world peace | 16:14 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 16:16 | |
| tlwoerner | Crofton: hahaha LOLzzzz | 16:17 |
| * zeddii has patches for that! well, not world peace | 16:18 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 16:22 | |
| tlwoerner | fwiw, baconbits is being deprecated for https://beagleboard.org/techlab | 16:25 |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 16:26 | |
| *** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has joined #yocto | 16:34 | |
| *** Kobboi <Kobboi!~Kobboi@14.125.146.82.ipv4.evonet.be> has quit IRC | 16:35 | |
| *** yacar_ <yacar_!~yacar@87-231-0-253.rev.numericable.fr> has quit IRC | 16:36 | |
| palate | tlwoerner: what's the relation between the company/people doing baconbits and pocketbeagle? Did pocketbeagle acquire baconbits, somehow? | 16:39 |
| palate | tlwoerner: or simpler: is it a good thing that baconbits is being deprecated for that? :D | 16:40 |
| *** behanw <behanw!uid110099@gateway/web/irccloud.com/x-jdaooecwdegnugya> has joined #yocto | 16:41 | |
| behanw | Baconbits is open hardware | 16:42 |
| tlwoerner | (i'll let behanw answer, he's more involved with the specifics) | 16:43 |
| behanw | Techlab is a mostly a superset design of baconbits. As a part of making it available as a part of the Beagle ecosystem it was redesigned and cost reduced to an extent | 16:44 |
| behanw | Baconbits isn’t deprecated. It’s still a great board. | 16:44 |
| tlwoerner | ah, my bad | 16:44 |
| behanw | Techlab was put together to be made widely available via the usual distribution channels | 16:45 |
| tlwoerner | i also hadn't noticed the techlab is now available for purchase, i thought it was still in testing :-) | 16:45 |
| behanw | You can buy techlab from digikey for instance | 16:45 |
| *** stephano <stephano!~stephano@134.134.139.77> has joined #yocto | 16:45 | |
| tlwoerner | behanw: don't you mean mouser... ;-) lol | 16:45 |
| behanw | A matter of time | 16:46 |
| behanw | The idea is to have them available from wherever | 16:46 |
| behanw | Our kits are special though because we need things pre-soldered. | 16:46 |
| tlwoerner | behanw: i'm just pulling your leg, i think it's totally awesome they're available from either, although i find mouser *tends* to be cheaper on average | 16:47 |
| behanw | So I have kits with techlab/pocketbeagle soldered together with cables, sd card and reader, etc | 16:47 |
| tlwoerner | it blows me away how i can order something from either mouser or digi-key at 7pm one day, and it's on my desk before lunch the next :-) | 16:47 |
| behanw | I buy direct from the mfg. I don’t actually know where they’re sold ;) | 16:48 |
| behanw | The difference is that my lead time is 8 weeks, not next day | 16:49 |
| tlwoerner | behanw: did mw design the techlab? the gamepup cape looks interesting too; where did that come from? | 16:54 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 16:59 | |
| behanw | Baconbits is from m_w | 16:59 |
| behanw | Techlab is designed by ghi | 17:00 |
| behanw | Based on the bb design | 17:00 |
| behanw | Both are open hardware | 17:00 |
| behanw | And the baconbits is based on the bacon cape designed by prpplague | 17:01 |
| behanw | Long lineage | 17:01 |
| Piraty | hey what's the preferred way to install a bunch of ipk to a folder and still be able to leverage the postinst hooks ? using opkg -o myNewRootfs install *.ipk requires --force-postinstall, but the scripts still operate on the real root instead of the one given after -o | 17:06 |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 17:08 | |
| *** yacar_ <yacar_!~yacar@87-231-0-253.rev.numericable.fr> has joined #yocto | 17:12 | |
| *** marler89976 <marler89976!0f41fc0d@ztxe01hpics303.austin.hp.com> has quit IRC | 17:19 | |
| *** yann|work <yann|work!~yann@85.118.38.73> has quit IRC | 17:19 | |
| *** vineela <vineela!vtummala@nat/intel/x-ekfugyuglzyhvojv> has joined #yocto | 17:24 | |
| *** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 17:25 | |
| *** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 17:25 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 17:28 | |
| *** armpit <armpit!~armpit@2601:202:4180:c33:45b7:cfa2:129c:2a54> has quit IRC | 17:29 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 17:31 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 17:31 | |
| yates | LetoThe2nd: to follow-up, i have confirmed changing CONFIG_FRAMEBUFFER_CONSOLE to no disables "echo console to framebuffer" behavior. thanks again! | 17:34 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 17:38 | |
| *** thannoy <thannoy!~anthony@134-48-190-109.dsl.ovh.fr> has joined #yocto | 17:48 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 18:04 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 18:06 | |
| *** yacar_ <yacar_!~yacar@87-231-0-253.rev.numericable.fr> has quit IRC | 18:15 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 18:17 | |
| *** jae1 <jae1!95c73e81@149.199.62.129> has joined #yocto | 18:25 | |
| LetoThe2nd | yates: :-) | 18:33 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 18:35 | |
| *** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 18:42 | |
| *** Crofton|mini <Crofton|mini!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 18:42 | |
| *** makudaku <makudaku!~apatel@static-108-40-78-74.bltmmd.fios.verizon.net> has left #yocto | 18:44 | |
| *** nabokov <nabokov!~armand@67.218.223.154> has joined #yocto | 18:48 | |
| *** monkeyman79 <monkeyman79!~monkeyman@apn-5-60-198-197.dynamic.gprs.plus.pl> has joined #yocto | 18:49 | |
| RP | JPEW: any idea on https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/717/steps/8/logs/step2d ? | 19:04 |
| RP | JPEW: that is with http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=c7d482523599e204f2580002485e4125a9cd45dc | 19:04 |
| JPEW | RP: I'll take a look | 19:05 |
| RP | JPEW: good news is that the new server stuff seemed to work ok this time! | 19:06 |
| JPEW | RP: Excellent. Is it fast enough? You can use the bitbake-hashclient command to get the server stats. | 19:06 |
| RP | JPEW: I've not enabled it yet. This just tested we don't regress | 19:07 |
| RP | JPEW: one step at a time | 19:07 |
| JPEW | RP: Ya, I realized that was probably the case as soon as I asked :) | 19:07 |
| JPEW | RP: Hmm, that one is interesting because it's actually failing in the do_deploy_source_date_epoch this time.... so that's obviously not the task causing the race | 19:08 |
| RP | JPEW: I didn't look in detail but gcc is shared workdir which may play a part | 19:09 |
| RP | (or may not( | 19:09 |
| *** rcw <rcw!~rcw@80.155.43.58> has joined #yocto | 19:10 | |
| JPEW | RP: Ah, `deltask do_unpack` for the shared gcc source will do that... the SDE is only created as a postfunc of do_unpack :( | 19:14 |
| JPEW | RP: We probably never noticed it was missing before.... | 19:15 |
| RP | JPEW: that would indeed explain it | 19:20 |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 19:21 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto | 19:21 | |
| JPEW | RP: Not sure the best solution... add it as a prefunc to do_patch and do_deploy_source_date_epoch? That feels messy, but would probably catch the current failure cases. It looks like do_patch is also commonly deleted in recipes that delete do_unpack. | 19:23 |
| RP | JPEW: could we copy the file in gcc shared-work if present? | 19:26 |
| RP | JPEW: or redefine SDE_FILE for gcc?> | 19:27 |
| JPEW | RP: The SDE file is one we create (a cache of sorts) in a postfunc of do_unpack, so there really isn't anywhere to copy it from | 19:29 |
| RP | JPEW: but one will have been created by the original shared gcc workdir? | 19:29 |
| RP | JPEW: there is a gcc-source do_unpack so I'm wondering if we can use that somehow | 19:29 |
| JPEW | Oh, ya, there should be one in it's ${WORKDIR}, we might be able share it somewhere | 19:30 |
| JPEW | Although, the more I look at this, the more I think rburton is right and we shouldn't even bother with the complex logic, just define the SOURCE_DATE_EPOCH variable to a constant and leave it at that. | 19:31 |
| JPEW | Problem is, no one can tell me if there is a really good reason why we do it this way | 19:31 |
| yocti | New news from stackoverflow: create symbolic link in bitbake recipe <https://stackoverflow.com/questions/48167601/create-symbolic-link-in-bitbake-recipe> | 19:32 |
| JPEW | Hmm.... That's interesting though... if the SDE file can't be found, it falls back to a constant, so one option is just to make the missing file non-fatal | 19:33 |
| JPEW | RP: Anyway, short answer is to drop the patch from master-next for now; it will cause more build failures than it attempts to fix :) | 19:34 |
| RP | JPEW: having the dates all set to one thing was rather ugly and looked poor. It came from a desire to simply do better from what I remember | 19:34 |
| *** wak-work <wak-work!wak-workma@gateway/shell/matrix.org/x-bbppztpiixhozaer> has joined #yocto | 19:34 | |
| JPEW | RP: Ya, I can see why that would be desirable | 19:35 |
| *** kaspter <kaspter!~Instantbi@222.67.188.177> has quit IRC | 19:35 | |
| RP | dreyna: pip._internal.exceptions.DistributionNotFound: No matching distribution found for Django<1.12,>1.8 (from -r /media/build1/poky/build/tmp/work/qemux86_64-poky-linux/build-appliance-image/15.0.0-r0/rootfs/home/builder/poky/bitbake/toaster-requirements.txt (line 1)) | 19:36 |
| RP | dreyna: I'm wondering what changed for us to start seeing this :( | 19:36 |
| RP | dreyna: (its from bitbake build-appliance-image, reproduces locally) | 19:36 |
| RP | Ah, Could not fetch URL https://pypi.org/simple/pip/: There was a problem confirming the ssl certificate: | 19:37 |
| dreyna | RP: I am preparing on a patch set to take Toaster to support Django 2.x (since the latest hosts use this). Hopefully the SSL issue will solve your immediate issue | 19:38 |
| * RP wonders if this is the openssl issue | 19:38 | |
| RP | dreyna: thanks. I'm just getting confused over which patches are causing which problems :( | 19:39 |
| RP | khem: 5 failures for meta-oe: https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/4 | 19:39 |
| RP | zeddii: https://autobuilder.yoctoproject.org/typhoon/#/builders/90/builds/3 meta-virt had 4 failures | 19:41 |
| palate | With the `core-image-minimal`, I don't get much output from the kernel at boot time. How can I get more? Is that the default loglevel? | 19:41 |
| RP | palate: its probably more about what is on your kernel commandline and where you sent the logging | 19:41 |
| palate | RP: hmm I'm new to yocto and linux kernels, I'm not sure that helps me. Here is the output I get when starting my pocketbeagle: https://pastebin.com/DbGiGH7Q. That's not a lot, is it? | 19:43 |
| *** PinkSnake <PinkSnake!51ff1123@81.255.17.35> has quit IRC | 19:44 | |
| Jusii | palate: cat /proc/cmdline | 19:45 |
| Jusii | will show your kernel commandline options which were used when booting | 19:45 |
| *** armpit <armpit!~armpit@45.19.219.178> has joined #yocto | 19:45 | |
| palate | Jusii: `root=PARTUUID=e8a517c2-02 rootwait console=ttyS0,115200` <- this? | 19:47 |
| Jusii | so is the above pastebin from serial output? | 19:48 |
| palate | Jusii: yes | 19:49 |
| palate | Jusii: oh, is it sending less output over serial? | 19:49 |
| Jusii | well, console=ttyS0,115200 should print all on serial | 19:52 |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC | 19:53 | |
| Jusii | but ofcourse there's many ways to disable kernel messages on boot, like in your case it is | 19:53 |
| RP | quite often you'd have console=tty in there too to have a console on the video output but as it stands it looks to be sending it to serial. Is ttyS0 correct for a pocketbeagle | 19:53 |
| RP | ? | 19:53 |
| palate | RP: I'm connecting with `screen /dev/ttyUSB0 115200` | 19:54 |
| Jusii | what's this? pocketbeagle /dev/ttyO0 | 19:54 |
| Jusii | that's your local serial, but what is the serial device on pocket beagle | 19:55 |
| *** rcw <rcw!~rcw@80.155.43.58> has quit IRC | 19:55 | |
| RP | palate: that is the device on your host system which would be different to the one on the target beagle | 19:55 |
| Jusii | http://beaglebone.cameon.net/home/serial-ports-uart | 19:55 |
| Jusii | so maybe console=ttyO0,115200 should fix that? | 19:56 |
| RP | I'd agree with that FWIW | 19:56 |
| palate | https://pastebin.com/pRVT33me | 19:56 |
| palate | that's what I get with `ls -l /dev/tty*` | 19:56 |
| palate | Jusii: can I just edit /proc/cmdline? | 19:57 |
| RP | right, you want O1 | 19:57 |
| Jusii | no | 19:57 |
| RP | palate: no | 19:57 |
| Jusii | you should be able to fix that in u-boot I'd guess | 19:57 |
| Jusii | which passes the cmdline to kernel | 19:57 |
| RP | or in the kernel if its compiled in there instead | 19:57 |
| Jusii | true | 19:58 |
| palate | that means on the yocto side before building the image, or directly from the pocketbeagle over serial? | 19:58 |
| Jusii | now you need to figure out how to modify kernel boot cmdline | 19:58 |
| palate | ok | 19:58 |
| palate | (sorry I'm very new to all that, but taking notes :-) ) | 19:58 |
| Jusii | you can do it yocto side before building for sure | 19:58 |
| Jusii | but you can try doing it in u-boot too | 19:59 |
| RP | palate: if I remember you were editing a defconfig earlier? | 19:59 |
| palate | RP: why do I want O1? Because O0 and O4 are used already? | 19:59 |
| RP | palate: sorry, I meant o) | 19:59 |
| RP | O0 | 19:59 |
| * RP should just stop trying to help :/ | 19:59 | |
| palate | RP: yes, I was. But the image would not boot anymore, so I tried to go back to the one that was booting (and that's the output I shared here) | 20:00 |
| palate | ok -> O0 it is :D | 20:00 |
| RP | palate: ok. I was wondering if this was something you'd set. In that case its probably coming from uboot | 20:00 |
| palate | RP: so now I need to get more output, so that when I start again and it fails, I can have an idea why | 20:00 |
| rburton | RP: you blamed distcc for https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1054 but isn't that the gles typo? | 20:00 |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 20:01 | |
| RP | rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/1058 | 20:02 |
| RP | rburton: that is the failure I was trying to link to, perhaps unsuccessfully | 20:02 |
| rburton | gotcha | 20:02 |
| RP | "Postinstall scriptlets of ['distcc'] have failed. If the intention is to defer them to first boot," | 20:02 |
| RP | sounds distcc like | 20:02 |
| rburton | yeah :) | 20:02 |
| RP | but nothing would surprise me today :( | 20:02 |
| rburton | ok fixed, forgot to update another PN -> PN-server | 20:04 |
| rburton | still need to write my pkgdata browser to inspect what goes into packages | 20:04 |
| RP | rburton: glad its something simple | 20:04 |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 20:04 | |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC | 20:06 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 20:08 | |
| RP | rburton: that openssl issue is what is breaking build-appliance too | 20:08 |
| RP | khem: your patch fixes it, thanks! | 20:09 |
| rburton | oh hooray khem | 20:11 |
| rburton | bit concerned that latest debian has 'older glibc' | 20:12 |
| *** yann|work <yann|work!~yann@aputeaux-655-1-52-10.w86-195.abo.wanadoo.fr> has joined #yocto | 20:15 | |
| *** Crofton|mini <Crofton|mini!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 20:16 | |
| RP | JPEW: full build fired with hashequiv enabled | 20:19 |
| palate | I think I mess up when I rebuild the kernel. So I have this BSP, meta-pocketbeagle, that works. From build/, I do `bitbake -c menuconfig virtual/kernel`, I "save" to ".config" without having changed any option, and then I do bitbake -c savedefconfig virtual/kernel. This outputs a `defconfig`. I replace the old defconfig of meta-pocketbeagle with that new one (which should be exactly the same, | 20:23 |
| palate | right?), and the image does not boot anymore -_- | 20:23 |
| palate | I was expecting that `bitbake -c menuconfig` would use the options defined by my defconfig in the first place... | 20:24 |
| palate | Is it wrong to generate the defconfig this way? | 20:25 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 20:27 | |
| palate | argh I think I'm doing something wrong. I edited the *working* defconfig (without calling menuconfig at all, because that fails), to comment out CONFIG_SERIAL_OMAP and replace it by another option. I get the following output: https://pastebin.com/1ydPiACN | 20:29 |
| palate | It seems to still take my commented out option -_- | 20:29 |
| *** rcw <rcw!~rcw@80.155.43.58> has joined #yocto | 20:29 | |
| khem | RP: is the weston-init patch ok now ? | 20:33 |
| khem | I am more and more impressed with AB testing | 20:34 |
| *** rcw <rcw!~rcw@80.155.43.58> has quit IRC | 20:35 | |
| RP | khem: I haven't requeued as I have a few too many other problems without that added risk (yet) | 20:36 |
| RP | khem: the test matrix is getting fairly comprehensive :) | 20:36 |
| khem | rburton: I thing the --with-rand-seed=devrandom is wrong but then I dont have those older glibc systems to test removing it, so I kept it there as fallback | 20:37 |
| khem | RP:this was a genuine problem introduced in my patch and it was nice a system called it out | 20:37 |
| RP | khem: we've had those tests for a while. They were written to detect that exact problem :) | 20:38 |
| khem | RP:no hurry it can go in next lot, I have few BSP layer patches waiting on it | 20:38 |
| *** rcw <rcw!~rcw@80.155.43.58> has joined #yocto | 20:39 | |
| khem | something has broken musl/risv64 dont know what | 20:39 |
| khem | maybe its musl or maybe something else in core metadata or packages | 20:40 |
| RP | need to get them as members and into the test matrix | 20:40 |
| khem | :) | 20:40 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 20:40 | |
| khem | all are startups | 20:40 |
| khem | maybe silver | 20:40 |
| *** Crofton|mini <Crofton|mini!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 20:42 | |
| khem | RP:re meta-oe AB runs 3 failures are openssl induced which should be fixed now, uim-native and dfu-util-native are new and seems specific to build host | 20:45 |
| RP | khem: ok, sounds promising that some should get fixed then | 20:46 |
| khem | this is tumbleweed is it ? | 20:47 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 20:52 | |
| khem | RP:in case of dfu-util-native it seems the build machine needs to have static glibc-devel installed and is missing so it fails to do static linkinh | 20:52 |
| khem | maybe if you have access to build node then try gcc -static hello.c -lpthread on it I think it will fail in same way | 20:53 |
| khem | /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: cannot find -lpthread | 20:53 |
| khem | /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: cannot find -lc | 20:53 |
| khem | uim-native is | 20:56 |
| khem | | collect2: error: ld returned 1 exit status | 20:56 |
| khem | | x86_64-linux-libtool: error: error: relink 'libuim-fileio.la' with the above command before installing it | 20:56 |
| khem | seems we can get past by deleting .la files | 20:56 |
| RP | khem: that sounds like we have an undocumented dependency then | 20:56 |
| RP | khem: we install exactly what is documented onto the workers | 20:57 |
| khem | right | 20:57 |
| khem | if you or someone can validate then we can change the docs | 20:57 |
| RP | khem: is there no way to avoid that dependency? | 20:58 |
| khem | some packages like luajit also needs 32bit gcc on build hosy | 20:58 |
| khem | maybe disable static linking | 20:58 |
| khem | I dont know why one would need a statically linked binary on the build host | 20:58 |
| tlwoerner | palate: RP: this (lack of kernel output on booting) is exactly what i was talking about in http://lists.openembedded.org/pipermail/openembedded-core/2019-September/286869.html | 20:59 |
| RP | khem: we may just have to have an exclusion file listing these things | 20:59 |
| RP | tlwoerner: I'm out of touch with wic I'm afraid so I'm not much help :( | 21:00 |
| jwessel | tlwoerner: The u-boot defaults are what set that string. | 21:00 |
| jwessel | Depending on the board. | 21:00 |
| tlwoerner | jwessel: in this case that string is being set by wic | 21:00 |
| jwessel | I suppose that is plausible, but doesn't it imply that it is reading it from a file which u-boot knows to look for? | 21:01 |
| tlwoerner | RP: i only pointed to you because you were trying to help :-) | 21:01 |
| *** armpit <armpit!~armpit@45.19.219.178> has quit IRC | 21:02 | |
| tlwoerner | might as well try to short-circuit everyone trying to help when i've already root-caused the issue ;-) | 21:02 |
| RP | tlwoerner: fair enough. I'm just sad I'm so out of touch with some of this stuff :( | 21:02 |
| tlwoerner | jwessel: yes, there are many ways to help U-Boot pass cmdline args to the linux kernel, extlinux is one of them | 21:02 |
| jwessel | I'd like to at least make it consistent with what ever it is you are doing. | 21:03 |
| tlwoerner | RP: you do what you do best, 'cause i don't know many who could take over from you! | 21:03 |
| jwessel | The ostree boot mechanics for example, make use of the boot.scr generated file from u-boot-env. | 21:03 |
| jwessel | But again, this is something that is highly board dependent. | 21:03 |
| tlwoerner | jwessel: as such, there is a whole class mechanism in place so a user can tweak the extlinux file (which is great, yea!!) | 21:03 |
| jwessel | Well I guess you could always encode it in the kernel that is getting loaded too. ;-) | 21:04 |
| tlwoerner | jwessel: but as soon as the user decides to use wic, and specifically uses the bootimg-partition option, wic comes along and clobbers whatever the user has requested and hard codes the extlinux file with no ability for the user to tweak :-( | 21:05 |
| tlwoerner | it's something i only stumbled upon very recently (as i was tweaking the meta-pocketbeagle BSP layer) and then, a couple days later, a user comes along and stumbles on the same thing :-) | 21:06 |
| jwessel | https://linux-sunxi.org/Mainline_U-Boot - How many of the u-boots are configured to use that feature? | 21:06 |
| * jwessel goes to look at a local board. | 21:06 | |
| tlwoerner | palate: this is "fixed" in the OE/master layer, it's fixed by hard-coding the kernel cmdline in the kernel config itself ;-) | 21:06 |
| jwessel | I was using bootmenu on this particular board previously. | 21:06 |
| tlwoerner | see: http://cgit.openembedded.org/openembedded-core/tree/scripts/lib/wic/plugins/source/bootimg-partition.py#n146 | 21:07 |
| tlwoerner | jwessel: palate: ^^ does that look familiar (i.e. the contents of the extlinux file)? | 21:08 |
| jwessel | I would agree you need the ability to customize it, I didn't even know it existed. | 21:08 |
| *** cconlon <cconlon!~cconlon@72.175.11.38> has joined #yocto | 21:08 | |
| palate | tlwoerner: oh... | 21:09 |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 21:09 | |
| tlwoerner | so either i could not use the bootimg-partition facility of wic (like Otavio does in his BSPs) | 21:09 |
| jwessel | It looks to me like you can put a custom file in there though. | 21:09 |
| *** cconlon <cconlon!~cconlon@72.175.11.38> has left #yocto | 21:09 | |
| tlwoerner | or not use wic (and let the extlinux class generate the file) | 21:09 |
| tlwoerner | or tweak the wic thing | 21:10 |
| palate | tlwoerner: so that's not related to the ttyO0 vs ttyS0 thing? | 21:10 |
| tlwoerner | jwessel: yes, it's looking "somewhere" but for the life of me i can't figure out where. if you use the extlinux class, it will generate a file and place it in U-Boot's ${B} directory, but this wic class is obviously not looking there | 21:11 |
| tlwoerner | palate: no, there's a kernel config option to get OMAP-type processors to use ttyS instead of ttyO | 21:11 |
| jwessel | configfile = cr.ks.bootloader.configfile | 21:12 |
| tlwoerner | jwessel: exactly. any idea where that is? | 21:12 |
| * tlwoerner 's python-foo only gets him so far... | 21:13 | |
| tlwoerner | in any case, it's not looking where the extlinux class is placing its results | 21:13 |
| tlwoerner | (presumably wic does its work very late in the process, so it can't be a timing issue) | 21:13 |
| jwessel | scripts/lib/wic/ksparser.py: bootloader.add_argument('--configfile') | 21:13 |
| jwessel | It is one of the options you can specify. | 21:14 |
| jwessel | wic help kickstart |less | 21:14 |
| jwessel | Run that and search for configfile | 21:14 |
| jwessel | You'll see it is actually documented. | 21:14 |
| jwessel | Where by you can pass in what ever you like. | 21:15 |
| palate | tlwoerner: actually, I think I may have another fix, thanks to zmatt on #beagle: set CONFIG_SERIAL_8250=y, CONFIG_SERIAL_8250_OMAP=y and CONFIG_SERIAL_8250_CONSOLE=y instead of CONFIG_SERIAL_OMAP and CONFIG_SERIAL_OMAP_CONSOLE | 21:15 |
| tlwoerner | pfft! who reads documentation? (lol, here i was trying to read the code!) | 21:15 |
| palate | tlwoerner: now I just get a lot of output when booting, without changing anything else (well, rebuilding the kernel). Does that make sense? | 21:15 |
| jwessel | I read the code to find the doc. | 21:15 |
| jwessel | See my reference to ksparser.py above. | 21:15 |
| jwessel | Then I realized it was documented. | 21:15 |
| khem | RP: dfu-utils problem might be gone if we remove this patch https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/dfu-util/dfu-util/0001-Revert-Makefile.am-Drop-static-dfu-util.patch which is a revert of an upstream commit | 21:18 |
| tlwoerner | palate: yes https://github.com/e-ale/meta-pocketbeagle/blob/OE/master/recipes-kernel/linux/linux-stable-5.2/defconfig (notice also the CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y as well) | 21:18 |
| tlwoerner | i'm not 100% sure what is the smallest config you need to get it working, but this one works | 21:18 |
| RP | khem: worth a try, its from 2011 so things have changed | 21:18 |
| palate | tlwoerner: should I actually just go on OE/master completely? | 21:21 |
| tlwoerner | well... i don't want to get into any fights... | 21:21 |
| palate | tlwoerner: I have no clue about the difference. OE/master is some kind of fork, but in a branch? | 21:22 |
| tlwoerner | master was intended for someone to use with yocto, OE/master was intended to be used was OE only | 21:22 |
| tlwoerner | palate: yes | 21:22 |
| palate | tlwoerner: but OE/master now works with yocto, right? | 21:22 |
| tlwoerner | OE/master only depends on openembedded-core | 21:22 |
| RP | khem: do you want to try that in a -next branch for meta-oe? | 21:23 |
| palate | tlwoerner: and you're here. So I'm moving to OE/master :D | 21:23 |
| RP | khem: we could try a build of -next of poky and meta-oe | 21:23 |
| tlwoerner | master depends on poky | 21:23 |
| tlwoerner | master uses yocto-linux, and OE/master uses upstream | 21:24 |
| palate | tlwoerner: but yocto is based on OE, right? | 21:24 |
| RP | tlwoerner: I'm now wondering what the difference is :/ | 21:24 |
| RP | tlwoerner: surely a given layer works with poky or oe-core+bitbake and doesn't need two branches? | 21:25 |
| *** marler899722 <marler899722!0f41fc0d@ztxe01hpics303.austin.hp.com> has joined #yocto | 21:25 | |
| tlwoerner | i had a conversation over the weekend with Robert about what i should use for the upstream defconfig, but it kinda petered out | 21:25 |
| RP | palate: yocto is very much oe based | 21:25 |
| palate | right | 21:28 |
| *** thannoy <thannoy!~anthony@134-48-190-109.dsl.ovh.fr> has quit IRC | 21:28 | |
| tlwoerner | well... i *could* dive into a whole diatribe... but nobody wants that, not even me! ;-) lol | 21:29 |
| tlwoerner | plus, i didn't create the meta-pocketbeagle layer and having the two branches is a way of preserving what was there, while also moving along with new things | 21:30 |
| RP | tlwoerner: I'm not asking for a diatribe, I would like to understand why one layer can't work with both. Is it a technical reason? | 21:30 |
| tlwoerner | the branch that works with poky uses an older kernel, that needs, for example, ttyO0. but using the latest stable upstream kernel switches to ttyS0 | 21:30 |
| tlwoerner | so instead of making the layer really messy with overrides, i just created two branches | 21:30 |
| tlwoerner | i'm not saying overrides wouldn't have worked or aren't elegant in their own way, i'm just saying this is my brutish way of doing overrides | 21:31 |
| RP | tlwoerner: ah, so the difference is trying to align with linux-yocto? | 21:31 |
| tlwoerner | yes, and not clobbering the valid work of other people | 21:32 |
| tlwoerner | if you want to generate a tar.bz2, jffs2, wic, and wic.bmap, be my guest (master). all i need is a wic (OE/master) ;-) | 21:32 |
| RP | tlwoerner: I worry this approach is going to really confuse users | 21:32 |
| tlwoerner | RP: welcome to BSP-land, where every BSP does every thing its own way | 21:33 |
| ecdhe | I'm having an issue with RDEPENDS: https://pastebin.com/pMqd2REe | 21:33 |
| tlwoerner | RP: i'm laughing as i say that, but it's not far from the truth ;-) | 21:33 |
| ecdhe | I'm clearly RDEPENDING on python3 in a recipe that's installing a python file that starts with the line "#!/usr/bin/python3" | 21:34 |
| tlwoerner | and it's not meant to insult the hard work people have put into their BSP layers, BSP layers have their own quirks | 21:34 |
| tlwoerner | e.g. tweaking a kernel configuration | 21:34 |
| *** Crofton|mini <Crofton|mini!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC | 21:34 | |
| tlwoerner | e.g. proving recipes for vendor-kernels/u-boot/windowing-systems vs upstream | 21:35 |
| RP | tlwoerner: my concern is simply that having one configuration marked as "yocto" and one as "OE" is pretending the difference is something which its really not :/ | 21:35 |
| tlwoerner | RP: okay, fair enough, i can switch that to "upstream" (?) | 21:36 |
| RP | tlwoerner: that means its hard for a user to understand what it is and fans "OE vs Yocto" flames when its not really that | 21:36 |
| tlwoerner | s/proving/providing | 21:36 |
| RP | tlwoerner: marking one as "linux-yocto "and one as "upstream kernel" would be clearer (I don't still fully understand the difference so it maybe the markup needs to be different) | 21:37 |
| RP | tlwoerner: FWIW I'm fine with BSPs using different kernels. They can use linux-yocto if it works for them or not. Having one recommended kernel for a given platform is probably wise, or let the user select with PREFERRED_PROVIDER and/or PREFERRED_VERSION | 21:38 |
| ecdhe | I am including the python3 package in my layer, and the booted image does indeed contain python3 located in /usr/bin/ | 21:39 |
| ecdhe | So the package called "python3" seems to be providing the file /usr/bin/python3. | 21:39 |
| ecdhe | But when I run bitbake, it complains: ERROR: QA Issue: /usr/local/bin/enum.py contained in package diagnostics requires /usr/bin/python3, but no providers found in RDEPENDS_diagnostics? [file-rdeps] | 21:40 |
| ecdhe | But this is despite my "diagnostics.bb" containing the line RDEPENDS_${PN} += "python3" | 21:40 |
| palate | tlwoerner: that's interesting | 21:41 |
| tlwoerner | RP: choosing a kernel has dramatic consequences for a build. for example with a vendor kernel you can then use, say, mali for your graphics, but most vendor kernels are *very* old, which means you can't use the latest this or that (e.g. perf). whereas if the user selects an upstream kernel they can now choose, say, panfrost or etnaviv | 21:41 |
| palate | tlwoerner: what would be the risk/downside of using `master` (seems like `OE/master` is just more modern) | 21:42 |
| tlwoerner | being forced to base a build on, say, a 3.x or 4.x vendor kernel (not uncommon) affects a lot of other configurations and choices | 21:43 |
| RP | tlwoerner: Yes, I can imagine that. I guess that is where the overrides come in :/ | 21:44 |
| RP | tlwoerner: I guess it comes down to better labelling of the branches then as "OE" really doesn't cover that | 21:44 |
| tlwoerner | Otavio tried to capture this in one layer/branch by using his machine-overrides-extender.bbclass, but efforts to get that into openembedded-core (so everyone could use it) weren't successful | 21:44 |
| tlwoerner | RP: yes, sorry. didn't mean to put things sideways :-( | 21:45 |
| tlwoerner | https://github.com/Freescale/meta-fsl-arm/blob/master/classes/machine-overrides-extender.bbclass | 21:45 |
| palate | tlwoerner: btw, I just built from OE/master, and I think it generated a .tar.gz... :D | 21:46 |
| tlwoerner | so i suggested a meta-bsp layer where some BSP authors could get together to define a set of common classes and recipes for upstream stuff, but that never took off either :-/ | 21:46 |
| tlwoerner | *shrug* | 21:47 |
| tlwoerner | palate: wic might need a tar.gz | 21:47 |
| RP | tlwoerner: there are other simpler ways you could probably do something like that albeit with slightly more duplication | 21:47 |
| tlwoerner | (but i don't explicitly need one) | 21:47 |
| RP | tlwoerner: I was never sold on adding that level of complexity into the core | 21:47 |
| RP | tlwoerner: if the feedback is many people need it we could look at it again | 21:47 |
| tlwoerner | RP: i'm sitting at a point here with meta-pocketbeagle (and some other BSP layers) where i'd be willing to give other things a try | 21:48 |
| tlwoerner | RP: i'm not the strongest bitbake/layer developer, so if you could point me at something that'd be awesome! :-D | 21:49 |
| palate | tlwoerner: OE/master seems to be working like a charm! | 21:49 |
| palate | tlwoerner: and apparently it has g_ether already \o/ | 21:49 |
| tlwoerner | palate: w00t! | 21:50 |
| ecdhe | any ideas on the RDEPENDS error? | 21:50 |
| * tlwoerner accidentally did something right ;-) | 21:50 | |
| palate | tlwoerner: xD | 21:50 |
| tlwoerner | lol, how most things get done | 21:50 |
| tlwoerner | palate: do you know it's CONFIG_ option? | 21:50 |
| tlwoerner | (s/it's/its) | 21:51 |
| palate | tlwoerner: I think it should be CONFIG_USB_ETHER | 21:51 |
| palate | tlwoerner: but I'm new to... kernels... so I may be wrong. Though I got help to find that out :) | 21:51 |
| RP | tlwoerner: I'm wondering why you can't set MACHINEOVERRIDES to what you need directly? | 21:51 |
| tlwoerner | palate: CONFIG_USB_ETH=m | 21:52 |
| RP | tlwoerner: Core supports MACHINEOVERRIDES, its just the magic groupings it doesn't | 21:52 |
| palate | tlwoerner: yep, that's consistent with what I see | 21:52 |
| tlwoerner | palate: Robert suggested i base my defconfig on omap2plus_defconfig, so it probably came in from there | 21:52 |
| palate | tlwoerner: right. That's awesome, `modprobe g_ether` just worked :) | 21:52 |
| tlwoerner | palate: and it only took 6 hours for us to figure out i had already inadvertently solved your issue | 21:53 |
| palate | I'll go to bed soon, but before, I really don't understand. From OE/master, if I now go in build and run `bitbake -c menuconfig virtual/kernel`, it should load the defconfig coming from meta-pocketbeagle, right? | 21:53 |
| palate | tlwoerner: haha yes, but I learned many things in the process! | 21:53 |
| tlwoerner | palate: yes, i would expect that | 21:54 |
| palate | tlwoerner: (more than 6 hours for me, though :D) | 21:54 |
| tlwoerner | RP: okay, i'll have to take a deeper look | 21:54 |
| palate | tlwoerner: ok, let me just do that, and export it without changing anything. Before that was breaking my image (it would not boot anymore) | 21:54 |
| palate | well, now it says "no change to .config"... before it would just save it | 21:57 |
| palate | Let's say I'm happy with OE/master, I'll work on networking through g_ether next time :-) | 21:57 |
| palate | Thank you so much with all the help! | 21:57 |
| tlwoerner | palate: you're welcome, and welcome to #yocto! | 21:58 |
| palate | thanks :-) | 21:58 |
| palate | Thanks RP, too (obviously)! | 21:59 |
| palate | good night guys! | 21:59 |
| *** stephano <stephano!~stephano@134.134.139.77> has quit IRC | 21:59 | |
| marler899722 | I'm using an EXTERNAL_TOOLCHAIN, but in the SDK, the executables from it are not using absolute paths and the EXTERNAL_TOOLCHAIN directory is not added to PATH | 22:00 |
| *** rcw <rcw!~rcw@80.155.43.58> has quit IRC | 22:00 | |
| marler899722 | Any ideas what's gone wrong here? | 22:00 |
| yocti | New news from stackoverflow: How does VARIABLE_*_something works? in Yocto <https://stackoverflow.com/questions/57982423/how-does-variable-something-works-in-yocto> | 22:03 |
| *** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has quit IRC | 22:03 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 22:04 | |
| tlwoerner | ecdhe: does it help if you just change it to a DEPENDS (drop the *R*DEPENDS)? | 22:05 |
| ecdhe | tlwoerner: will check | 22:05 |
| tlwoerner | RP: okay, reading about MACHINEOVERRIDES gives me something to try, i'll give it a whirl | 22:09 |
| ecdhe | tlwoerner: RDEPENDS->DEPENDS doesn't fix it. | 22:09 |
| tlwoerner | ecdhe: that is a good thing, it would have been messy if it did | 22:10 |
| ecdhe | Yeah, I didn't figure it was the problem. | 22:10 |
| ecdhe | I'm trying to confirm that the python3 recipe provides the /usr/bin/python3 file, but I can't find the .bb file that brings along the interpreter itself anywhere in meta-python. | 22:11 |
| RP | tlwoerner: if its not working talk to me about it | 22:17 |
| tlwoerner | RP: will do | 22:17 |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 22:18 | |
| *** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto | 22:28 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 22:43 | |
| *** nabokov <nabokov!~armand@67.218.223.154> has quit IRC | 22:51 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.137.100> has joined #yocto | 22:53 | |
| *** yacar_ <yacar_!~yacar@87-231-0-253.rev.numericable.fr> has joined #yocto | 22:55 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has quit IRC | 23:08 | |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC | 23:18 | |
| *** armpit <armpit!~armpit@2601:202:4180:c33:45b7:cfa2:129c:2a54> has joined #yocto | 23:23 | |
| *** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has quit IRC | 23:29 | |
| *** vmeson <vmeson!~rmacleod@192-0-133-18.cpe.teksavvy.com> has joined #yocto | 23:30 | |
| *** monkeyman79 <monkeyman79!~monkeyman@apn-5-60-198-197.dynamic.gprs.plus.pl> has quit IRC | 23:34 | |
| *** vmeson <vmeson!~rmacleod@192-0-133-18.cpe.teksavvy.com> has quit IRC | 23:48 | |
| *** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has joined #yocto | 23:49 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!