Tuesday, 2019-09-17

*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC00:00
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto00:01
JPEWah, I see the minimum is listed as 3.400:12
*** monkeyman79 <monkeyman79!~monkeyman@apn-5-60-198-197.dynamic.gprs.plus.pl> has joined #yocto00:41
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto00:56
*** PinkSnake <PinkSnake!51ff1123@> has quit IRC01:05
*** camus <camus!~Instantbi@> has joined #yocto01:34
*** kaspter <kaspter!~Instantbi@> has quit IRC01:38
*** camus is now known as kaspter01:38
*** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has quit IRC01:44
*** kaspter <kaspter!~Instantbi@> has quit IRC01:52
*** monkeyman79 <monkeyman79!~monkeyman@apn-5-60-198-197.dynamic.gprs.plus.pl> has quit IRC01:52
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:02
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC02:09
*** wak-work <wak-work!wak-workma@gateway/shell/matrix.org/x-unzlbewtdtizbuqi> has quit IRC02:19
*** silviof <silviof!silv-iomat@gateway/shell/matrix.org/x-pqixlwlqvyoapnbz> has quit IRC02:19
*** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-cxlwoltkhsygzcrz> has quit IRC02:19
*** bachp <bachp!bachpmatri@gateway/shell/matrix.org/x-isiejdwqixlowryo> has quit IRC02:19
*** bachp <bachp!bachpmatri@gateway/shell/matrix.org/x-lbmyizapxypkkluc> has joined #yocto02:25
*** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-gnfejstjobvjcmum> has joined #yocto02:41
*** silviof <silviof!silv-iomat@gateway/shell/matrix.org/x-cohmpvvguynesgub> has joined #yocto02:41
*** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-gnfejstjobvjcmum> has quit IRC02:50
*** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has quit IRC02:50
*** nrossi <nrossi!nrossimatr@gateway/shell/matrix.org/x-euabtsighxzzilgj> has joined #yocto02:51
*** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has joined #yocto02:56
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC03:04
*** kaspter <kaspter!~Instantbi@> has quit IRC03:12
*** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has quit IRC03:18
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:23
*** Crofton|work <Crofton|work!~balister@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has joined #yocto03:24
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC04:03
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto04:06
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC04:16
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto04:18
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC04:24
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto04:24
*** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto04:25
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC04:28
*** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC04:29
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto04:32
*** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto04:41
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC04:45
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto04:45
*** kroon <kroon!~kroon@> has joined #yocto04:45
*** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC04:48
*** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto04:49
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC04:53
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto04:54
*** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC04:56
*** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has joined #yocto05:01
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC05:06
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto05:21
iceawayI'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 /dev05:21
iceawayLooking at the generated cpio.gz of the root filesystem, there certainly is a /dev there with a console node.05:22
krooniceaway, which yocto version are you on ?05:23
iceawayI'm using 2.505:23
krooniceaway, maybe its not related, but i remember fixing a missing console device in an initramfs with https://github.com/openembedded/openembedded-core/commit/490d6fbd14805b6c72b525fbe8c9c6e08d79659705:26
kroonbut that doesn't like your error message05:27
kroonbut "root ''" looks like the kernel is being passed an empty root string, no ?05:29
iceawayYes, 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 #yocto05:34
krooniceaway, not sure about that05:35
krooniceaway, maybe try: root=/dev/ram005:36
krooniceaway, from https://www.kernel.org/doc/html/latest/admin-guide/initrd.html05:36
*** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has quit IRC05:36
kroonor maybe im confusing initrd with initramfs here05:42
iceawayI think so, I think the kernel knows that it has the built-in initramfs and thus does not need the root= parameter05:47
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto05:49
*** zkrx <zkrx!~quassel@adsl-89-217-88-77.adslplus.ch> has quit IRC05:57
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto06:03
*** zkrx <zkrx!~quassel@adsl-89-217-88-77.adslplus.ch> has joined #yocto06:05
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:30
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC06:40
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto06:40
qschulziceaway: AFAIR, yes. It's even "worse", if there is a bundled initramfs, the root= is ignored IIRC06:42
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto06:47
iceawayqschulz: 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
qschulziceaway: 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 Yocto06:51
qschulziceaway: 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 work06:53
iceawayqschulz: 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
iceawaybootlog: https://pastebin.com/M3Jap8Dd06:56
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC06:57
iceaway(Maybe) strange that it says freeing unused kernel memory (20032K), that should be the initramfs06:58
yoctiNew 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@> has joined #yocto07:00
qschulziceaway: 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 kernel07:01
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto07:01
qschulziceaway: 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 IRC07:04
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto07:12
*** tprrt <tprrt!~tprrt@> has joined #yocto07:15
*** yann <yann!~yann@aputeaux-655-1-52-10.w86-195.abo.wanadoo.fr> has quit IRC07:17
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto07:22
iceawayqschulz: definitely worth looking into, will do that in a bit. Still all new to working with initramfs stuff.07:22
jmieheHi, does bitbake automatically extract a .tar.gz file if that's my source? Can/should I stop that?07:24
jmieheI 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
LetoThe2ndjmiehe: 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 IRC07:31
jmieheLetoThe2nd: 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
LetoThe2ndjmiehe: scroll up a litt,e find https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#bb-the-unpack07:34
LetoThe2ndjmiehe: i think it explains exactly what you want07:34
jmieheI found that the second I posted the previous link^^07:35
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC07:37
jmiehetl;dr specify as file://SOMETHING.tar.gz;unpack=007:38
*** nslu2-log <nslu2-log!~nslu2-log@> has quit IRC07:45
*** yacar_ <yacar_!~yacar@87-231-0-253.rev.numericable.fr> has joined #yocto07:51
*** nslu2-log <nslu2-log!~nslu2-log@> has joined #yocto08:08
*** shan1 <shan1!86666183@dhcp-131.biba.uni-bremen.de> has joined #yocto08:09
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto08:09
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:10
*** goliath <goliath!~goliath@> has joined #yocto08:11
*** kpo <kpo!~kpo@eet50.internetdsl.tpnet.pl> has quit IRC08:16
*** kpo <kpo!~kpo@eet50.internetdsl.tpnet.pl> has joined #yocto08:18
jmieheIs there a more bitbakey-way of changing an RPATH than just calling patchelf (or chrpath)?08:29
*** yann|work <yann|work!~yann@> has joined #yocto08:43
iceawayI 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
LetoThe2ndiceaway: startup scripts are often just added to the layers directly, unless they correlate with a bigger application which they actually start up08:48
shan1LetoThe2nd 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
LetoThe2ndshan1: 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
iceawayLetoThe2nd: how do you mean added to the layer directly? How would I add it to the image ?08:56
LetoThe2ndiceaway: its three things. 1) a recipe, for example fantastic_start.bb08:56
LetoThe2nd2) the actual script, located in fantastic_start/realscript right next to the recipe08:57
shan1I 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 fdraft08:57
LetoThe2nd3) the image has IMAGE_INSTALL += "fantastic_startup"08:57
LetoThe2nderm, "fantastic_start", of course08:57
LetoThe2ndshan1: :-)08:57
LetoThe2ndshan1: as i said, i can maybe find some time for review and comments, but will not do actual writing.08:58
yoctiNew 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
shan1LetoThe2nd You don't have to. I can take that part.08:58
iceawayLetoThe2nd: ok sounds good, I will give that a go! Thanks!09:00
*** iokill <iokill!~dave@static.> has joined #yocto09:01
*** rburton <rburton!~rburton@> has joined #yocto09:08
yoctiNew 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 #yocto09:32
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:33
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto09:36
rburtonkergoth: the web site is failing to actually explain why git-revise is better than rebase09:37
LetoThe2ndrburton: NOTHING IS BETTER THAN GIt REBASE!09:38
* LetoThe2nd puts hands on ears and starts singing LALALALALALA09:39
rburtonwell revise is rebase but less poking at the disk, so its faster09:39
diego_rLetoThe2nd: "git rebase -i" is better than "git rebase"09:39
LetoThe2ndthat counts as git rebase :)09:40
rburtonthough '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 own09:40
qschulzdiego_r: git rebase -i --autosquash is the dream :)09:42
LetoThe2ndrburton: DONT CONFUSE ME WITH FACTS!09:43
diego_rqschulz: :)09:44
*** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto10:13
*** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC10:17
*** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC10:18
*** shan1 <shan1!86666183@dhcp-131.biba.uni-bremen.de> has quit IRC10:20
*** fbre <fbre!91fdde45@> has joined #yocto10:24
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto10:26
fbreHi! 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
fbreI 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
fbreNow I wanted to do that by myself in the start-firmware.bb do_install() section by adding there the following line:10:28
LetoThe2ndfbre: 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
LetoThe2ndfbre: see also https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/systemd.bbclass#n910:29
fbreln -sfr ${D}${systemd_system_unitdir}/multi-user.targets.wants/start-firmware.service ${D}${systemd_system_unitdir}/start-firmware.service10:30
LetoThe2ndfbre: 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-enabled10:31
fbreBut 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 exist10:31
fbreLetoThe2nd: systemd.bbclass contains a line: SYSTEMD_AUTO_ENABLE ??= "enable". So it should be enabled by default.10:32
LetoThe2ndfbre: 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 step10:33
fbreLetoThe2nd: my start-firmware.bb file has also a line SYSTEMD_AUTO_ENABLE_${PN} = "enable"10:33
fbreI can upload my .bb file to pastebin if that helps10:34
LetoThe2ndfbre: oh, and please note the little magic snippet in cronie's do_install that seds the service files. its needed.10:34
LetoThe2ndso really, try and reproduce starting from that.10:34
fbreLetoThe2nd: OK, where is cronie located in the file tree?10:35
fbreLetoThe2nd: Should I just search for a file called "cronie"?10:35
LetoThe2ndfbre: *sigh* scroll up. read again10:38
rburtonfbre: just checking: you know that file you're expecting to exist should be created at install time, not package build time.10:48
rburtonthe 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 IRC10:54
fbrerburton: yes, I know. At install time.10:58
fbreLetoThe2nd: Ah OK, now I checked your links and see that cronie. Reading trough it now...10:59
rburtonfbre: can you replicate the problem with a minimal recipe?11:01
iceawayThis 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 the11:10
iceawayinitramfs-* packages, so that ultimately I cannot even build the image.11:10
LetoThe2ndiceaway: what is the rationale/usecase behind it anyways?11:11
LetoThe2ndiceaway: it might very well be a "i want to do x, and think that initramfs is the way archieve it" case11:11
fbrerburton: yes, my start-firmware.bb is actually already a trivial one. So does the start-firmware.service file (IMHO)11:11
iceawayLetoThe2nd: I want to run the swupdate utility from RAM, so I can upgrade the firmware/software (even the swupdate part if required).11:12
rburtoniceaway: 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 system11:13
LetoThe2ndiceaway: but that can be done way simpler11:13
rburtonthe important bit is setting IMAGE_FSTYPES11:13
LetoThe2ndiceaway: just make an initrd and glue it up11:13
iceawayLetoThe2nd: you make it sound so simple :)11:14
LetoThe2ndiceaway: 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
LetoThe2ndif 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@> has joined #yocto11:15
iceawayLetoThe2nd: 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
LetoThe2ndiceaway: an initrd is just a standard filesystem, basically11:15
LetoThe2ndand see, here's even fit-image support ready to use: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel-fitimage.bbclass11:16
LetoThe2ndeverybody seems to love initramfs there days, but in my opinion they only serve a very specific usecase.11:16
iceawaySo I could in theory just use the filesystem that Yocto already generates?11:17
rburtonprecisely the point11:17
LetoThe2ndiceaway: bingo. thats what we do.11:17
iceawayCool. Would I need to put it in some kind of initrd-container ?11:17
LetoThe2ndscroll up, read again.11:17
LetoThe2ndrburton: can you put a mark on the XY-question list?11:18
iceawayWill do. Thanks a lot. Now I will attack this from a different angle.11:18
fbreLetoThe2nd: 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
LetoThe2nd10: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 step11:19
LetoThe2ndfbre: i think that i said pretty much precisely that, yes.11:19
fbreLetoThe2nd: ah OK, thanks. I was reading it as if cronie is a sub-tool of bitbake doing that installing. Sorry, I was confused11:20
LetoThe2ndfbre: thats why i said "scroll up, read again". :)11:21
fbreLetThe2nd: 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 IRC11:25
yoctiNew 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 #yocto11:36
*** berton <berton!~berton@> has joined #yocto11:41
*** berton <berton!~berton@> has quit IRC11:46
*** berton <berton!~berton@> has joined #yocto11:48
kroonWhy 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 changed12:00
kroonnm, im confused12:06
*** nabokov <nabokov!~armand@> has quit IRC12:06
kroonlog says bitbake is gonna rebuild bb_cache.dat, but it never gets created, there is just a dangling symlink12:10
fbreYIPPPIE!!!!!!!!!!!!! I found the failure.12:15
fbreThe 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 works12:17
fbreThis took me two and a half days *sigh*12:18
fbreIt is exactly the same type of error as reported here: http://lists.openembedded.org/pipermail/openembedded-devel/2016-March/106656.html12:19
fbreThe difference is just that I had a bad newline char while the guy from the mailing-list had a bad space char12:20
fbreI wonder why it has such impact of the fact whether the whole thing works or not12:21
rburtonfbre: please create a bug :)12:22
fbreI had \r\n and it has to be \n12:22
rburtonwe have a custom systemctl for rootfs-time which presumably has bad line breaking logic in12:23
fbreThat 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
rburtonplease do12:25
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC12:27
palateI'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
palateI'd like to take the defconfig of the BSP I'm using (meta-pocketbeagle in this case) and add an option to the kernel12:30
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:37
zeddiipalate. yes it would.12:38
*** learningc <learningc!~learningc@> has quit IRC12:41
fbreI'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
rburtonits in oe-core, so oe-core12:47
rburtonthen the core component, i guess12:47
fbreall right12:48
*** learningc <learningc!~learningc@> has joined #yocto12:50
yateson 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
yatesi want to take full control of the frame buffer with a startup application12:52
yatesit appears the cursor from the console takes out a block of pixels from the frame buffer and hoses my screen.12:53
yatesi.e., this is the image specified in my build's local.conf: INITRAMFS_IMAGE = "initramfs-image"12:55
fbrerburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=1353512:55
yoctiBug 13535: normal, Undecided, ---, ross.burton, NEW , systemctl12:55
yatesalso, what is the process for submitting a new or updated recipe to oe?12:57
yatesis this thing on?13:00
*** nabokov <nabokov!~armand@> has joined #yocto13:01
* yates checks his internet connection..13:01
rburtonyates: post a patch to the list13:03
rburtonshould be in the readme for whatever layer13:03
yatesnobody knows how to disable console output on the display?13:05
LetoThe2ndyates: kernel option fb_console or something similar13:07
LetoThe2ndyates: look there, you'll find it13:08
yatesLetoThe2nd: will do! thank you!13:08
*** Kobboi <Kobboi!~Kobboi@> has joined #yocto13:10
Kobboii'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
LetoThe2ndyates: sounds fitting, if that is y then it might be the cause.13:12
fbresee you guys. I'll give a party now since the failure is found :-D  Thanks again and Bye13:13
*** fbre <fbre!91fdde45@> has quit IRC13:14
yatesrburton: ack.13:15
*** kanavin_ <kanavin_!~kanavin@> has quit IRC13:24
zeddiiRP: 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@> has joined #yocto13:30
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto13:32
JPEWRP: 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 with13:38
yatesrburton: 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 IRC13:42
yateshttps://layers.openembedded.org: Your account has been locked out. Please contact the admin.13:44
fullstophow 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
yatesfullstop: CORE_IMAGE_EXTRA_INSTALL += "strace"13:45
yatesin your image.bb file13:45
fullstopI can't believe that I did that13:45
yatesyou mean you can't believe you're human?13:46
fullstopI can't believe that I didn't see it sitting right next to the others with the right word order.  :-)13:46
qschulzfullstop: 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 shared13:47
qschulzand CORE_IMAGE_EXTRA_INSTALL should be used only in local.conf according to the ref-manual (I didn'13:47
qschulzt know that)13:47
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC13:48
fullstopI'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@> has quit IRC13:48
*** kroon <kroon!~kroon@> has quit IRC13:49
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has quit IRC13:51
RPJPEW: thanks, I'll trigger a test run13:58
*** nabokov <nabokov!~armand@> has joined #yocto14:00
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto14:01
*** comptroller <comptroller!~comptroll@47-213-222-253.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto14:07
JPEWRP: 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 IRC14:14
*** armpit <armpit!~armpit@2601:202:4180:c33:bd66:ef14:2024:3051> has quit IRC14:24
*** nabokov <nabokov!~armand@> has quit IRC14:32
*** armpit <armpit!~armpit@2601:202:4180:c33:45b7:cfa2:129c:2a54> has joined #yocto14:37
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto14:43
*** tprrt <tprrt!~tprrt@> has quit IRC14:54
*** goliath <goliath!~goliath@> has quit IRC14:54
armpitYPTM - armin is on14:58
dl9pfYPTM - Jan-Simon is on14:59
yoctiNew 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
rburtonJPTM ross in15:05
armpitTim its a trap15:08
rburtonrun away from the docbook15:09
zeddiiYPTM: on another meeting. but will lurk on IRC.15:09
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-yiqloelgeevqanwv> has quit IRC15:10
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto15:11
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto15:14
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC15:14
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:15
RPBB_HASHSERVE = "auto"15:15
*** JPEW25 <JPEW25!cc4da373@> has joined #yocto15:17
tlwoernerYPTM: tlwoerner has been on since the start (but wasn't watching IRC)15:17
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC15:23
RPsmurray: I think that unit file perhaps should read ConditionPathExists=!/lib/udev/hwdb.bin15:32
RPsince we want to trigger if either the etc or lib hwdb.bin isn't present but if one is we're ok15:33
smurrayhrm, it's |/etc/udev/hwdb.bin even on Fedora, which you'd think would be a distro where people pay attention to that15:34
RPsmurray: hence why I think I have to be missing something15:36
RPrburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1054 (distcc breaks)15:37
smurrayRP: the commit message that added that logic implies it's to prevent regenerating it15:37
smurrayRP: 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 #yocto15:40
RPsmurray: I suspect upstream would tell us to generate the file into /lib15:41
smurrayRP: 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
RPDoes anyone know any friendly systemd people we could ask?15:42
smurrayRP: it seems likely the x86 folks probably never noticed it since it's fast15:42
RPsmurray: right :/15:42
smurrayRP: heh, I'm going to be at the All Systems Go! conf this weekend, I could ask in person, perhaps15:42
smurrayRP: might be easier to open an issue in their github15:43
RPsmurray: right, an issue would be the next step I think15:43
palateI 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
palateFor instance, my defconfig doesn't have any "is not set" line.15:44
palateWhen 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
LetoThe2ndpalate: 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
palateLetoThe2nd: well, my defconfig has those lines stripped out, but the layer doesn't. That's the opposite of what you suggest, right?15:46
LetoThe2ndpalate: yeah then i got it backwards. but the meaning is clear, right?15:47
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto15:47
tlwoernerLetoThe2nd: palate: actually the opposite. the layer defconfig is just the straight .config from the kernel build.15:47
palateoh, right.15:48
tlwoernerpalate: are you using the master or OE/master branch? (or something else?)15:49
palatetlwoerner: of yocto? 2.7.115:50
tlwoernerpalate: of meta-pocketbeagle15:50
palatetlwoerner: master15:51
palateYou'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 config15:53
palate(well I autoload g_ether, too, maybe that's not clever as a first try)15:54
tlwoernerpalate: 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
palatetlwoerner: oh, you are actually the author :D15:55
palatetlwoerner: should I be using OE/master?15:55
tlwoernerdepends on what you want15:55
palatetlwoerner: I want a pocketbeagle that can run g_ether :D15:55
tlwoernerso you're plugging in a usb-to-ether into the baconbits cape?15:56
palatetlwoerner: 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 usb15:57
tlwoernerpalate: https://images.app.goo.gl/BrUDPtr2qe2LfKfe615:58
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC15:59
RPsmurray, rburton: https://github.com/systemd/systemd/issues/1358115:59
palatetlwoerner: right. No I only have the pocketbeagle15:59
palatetlwoerner: but I guess the meta-pocketbeagle should still be fine16:00
tlwoernerpalate: in any case, that's a common use-case. i'll take a look at enabling it "out of the box"16:00
palatetlwoerner: could it be that the pocketbeagle is "OTG" and therefore needs other modules than just g_ether?16:01
tlwoernerpalate: 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 alone16:02
LetoThe2ndtlwoerner: guess i should get a pb plus cape some time soon too :P16:02
palatetlwoerner: I'm connecting a USB cable from my computer to the pocketbeagle, that's it16:03
tlwoerneri have one of these i can experiment with: https://images.app.goo.gl/9Z8xqWUq2arixK8y516:03
palatetlwoerner: why not just a USB cable between your computer and the beagle?16:03
tlwoernerpalate: that's a serial console :-)16:04
palateMy 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 it16:04
*** learningc <learningc!~learningc@> has quit IRC16:04
palatetlwoerner: so I really want ethernet going through a normal usb cable, hence g_ether16:05
smurraypalate: you're going to have more luck asking on #beagle imo16:07
palatesmurray: 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 :D16:08
smurraypalate: questions about kernel config are more on topic for #beagle16:09
palategot it, thanks :)16:10
tlwoernersomeday 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@> has joined #yocto16:10
palatetlwoerner: what are the different mechanisms? I only know menuconfig16:11
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC16:11
tlwoernerbehind the scenes there are differences. take a look at meta-raspberrypi16:12
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto16:13
Croftontlwoerner, and then we solve world peace16:14
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC16:16
tlwoernerCrofton: hahaha LOLzzzz16:17
* zeddii has patches for that! well, not world peace16:18
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto16:22
tlwoernerfwiw, baconbits is being deprecated for https://beagleboard.org/techlab16:25
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC16:26
*** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has joined #yocto16:34
*** Kobboi <Kobboi!~Kobboi@> has quit IRC16:35
*** yacar_ <yacar_!~yacar@87-231-0-253.rev.numericable.fr> has quit IRC16:36
palatetlwoerner: what's the relation between the company/people doing baconbits and pocketbeagle? Did pocketbeagle acquire baconbits, somehow?16:39
palatetlwoerner: or simpler: is it a good thing that baconbits is being deprecated for that? :D16:40
*** behanw <behanw!uid110099@gateway/web/irccloud.com/x-jdaooecwdegnugya> has joined #yocto16:41
behanwBaconbits is open hardware16:42
tlwoerner(i'll let behanw answer, he's more involved with the specifics)16:43
behanwTechlab 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 extent16:44
behanwBaconbits isn’t deprecated. It’s still a great board.16:44
tlwoernerah, my bad16:44
behanwTechlab was put together to be made widely available via the usual distribution channels16:45
tlwoerneri also hadn't noticed the techlab is now available for purchase, i thought it was still in testing :-)16:45
behanwYou can buy techlab from digikey for instance16:45
*** stephano <stephano!~stephano@> has joined #yocto16:45
tlwoernerbehanw: don't you mean mouser... ;-) lol16:45
behanwA matter of time16:46
behanwThe idea is to have them available from wherever16:46
behanwOur kits are special though because we need things pre-soldered.16:46
tlwoernerbehanw: 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 average16:47
behanwSo I have kits with techlab/pocketbeagle soldered together with cables, sd card and reader, etc16:47
tlwoernerit 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
behanwI buy direct from the mfg. I don’t actually know where they’re sold ;)16:48
behanwThe difference is that my lead time is 8 weeks, not next day16:49
tlwoernerbehanw: 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 #yocto16:59
behanwBaconbits is from m_w16:59
behanwTechlab is designed by ghi17:00
behanwBased on the bb design17:00
behanwBoth are open hardware17:00
behanwAnd the baconbits is based on the bacon cape designed by prpplague17:01
behanwLong lineage17:01
Piratyhey 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 -o17:06
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:08
*** yacar_ <yacar_!~yacar@87-231-0-253.rev.numericable.fr> has joined #yocto17:12
*** marler89976 <marler89976!0f41fc0d@ztxe01hpics303.austin.hp.com> has quit IRC17:19
*** yann|work <yann|work!~yann@> has quit IRC17:19
*** vineela <vineela!vtummala@nat/intel/x-ekfugyuglzyhvojv> has joined #yocto17:24
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC17:25
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto17:25
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:28
*** armpit <armpit!~armpit@2601:202:4180:c33:45b7:cfa2:129c:2a54> has quit IRC17:29
*** rburton <rburton!~rburton@> has quit IRC17:31
*** rburton <rburton!~rburton@> has joined #yocto17:31
yatesLetoThe2nd: 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 #yocto17:38
*** thannoy <thannoy!~anthony@134-48-190-109.dsl.ovh.fr> has joined #yocto17:48
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto18:04
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto18:06
*** yacar_ <yacar_!~yacar@87-231-0-253.rev.numericable.fr> has quit IRC18:15
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC18:17
*** jae1 <jae1!95c73e81@> has joined #yocto18:25
LetoThe2ndyates: :-)18:33
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto18:35
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC18:42
*** Crofton|mini <Crofton|mini!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto18:42
*** makudaku <makudaku!~apatel@static-108-40-78-74.bltmmd.fios.verizon.net> has left #yocto18:44
*** nabokov <nabokov!~armand@> has joined #yocto18:48
*** monkeyman79 <monkeyman79!~monkeyman@apn-5-60-198-197.dynamic.gprs.plus.pl> has joined #yocto18:49
RPJPEW: any idea on https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/717/steps/8/logs/step2d ?19:04
RPJPEW: that is with http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=c7d482523599e204f2580002485e4125a9cd45dc19:04
JPEWRP: I'll take a look19:05
RPJPEW: good news is that the new server stuff seemed to work ok this time!19:06
JPEWRP: Excellent. Is it fast enough? You can use the bitbake-hashclient command to get the server stats.19:06
RPJPEW: I've not enabled it yet. This just tested we don't regress19:07
RPJPEW: one step at a time19:07
JPEWRP: Ya, I realized that was probably the case as soon as I asked :)19:07
JPEWRP: 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 race19:08
RPJPEW: I didn't look in detail but gcc is shared workdir which may play a part19:09
RP(or may not(19:09
*** rcw <rcw!~rcw@> has joined #yocto19:10
JPEWRP: 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
JPEWRP: We probably never noticed it was missing before....19:15
RPJPEW: that would indeed explain it19:20
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC19:21
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto19:21
JPEWRP: 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
RPJPEW: could we copy the file in gcc shared-work if present?19:26
RPJPEW: or redefine SDE_FILE for gcc?>19:27
JPEWRP: 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 from19:29
RPJPEW: but one will have been created by the original shared gcc workdir?19:29
RPJPEW: there is a gcc-source do_unpack so I'm wondering if we can use that somehow19:29
JPEWOh, ya, there should be one in it's ${WORKDIR}, we might be able share it somewhere19:30
JPEWAlthough, 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
JPEWProblem is, no one can tell me if there is a really good reason why we do it this way19:31
yoctiNew news from stackoverflow: create symbolic link in bitbake recipe <https://stackoverflow.com/questions/48167601/create-symbolic-link-in-bitbake-recipe>19:32
JPEWHmm.... 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-fatal19:33
JPEWRP: 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
RPJPEW: 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 remember19:34
*** wak-work <wak-work!wak-workma@gateway/shell/matrix.org/x-bbppztpiixhozaer> has joined #yocto19:34
JPEWRP: Ya, I can see why that would be desirable19:35
*** kaspter <kaspter!~Instantbi@> has quit IRC19:35
RPdreyna: 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
RPdreyna: I'm wondering what changed for us to start seeing this :(19:36
RPdreyna: (its from bitbake build-appliance-image, reproduces locally)19:36
RPAh, Could not fetch URL https://pypi.org/simple/pip/: There was a problem confirming the ssl certificate:19:37
dreynaRP: 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 issue19:38
* RP wonders if this is the openssl issue19:38
RPdreyna: thanks. I'm just getting confused over which patches are causing which problems :(19:39
RPkhem: 5 failures for meta-oe: https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/419:39
RPzeddii: https://autobuilder.yoctoproject.org/typhoon/#/builders/90/builds/3 meta-virt had  4 failures19:41
palateWith 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
RPpalate: its probably more about what is on your kernel commandline and where you sent the logging19:41
palateRP: 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@> has quit IRC19:44
Jusiipalate: cat /proc/cmdline19:45
Jusiiwill show your kernel commandline options which were used when booting19:45
*** armpit <armpit!~armpit@> has joined #yocto19:45
palateJusii: `root=PARTUUID=e8a517c2-02 rootwait console=ttyS0,115200` <- this?19:47
Jusiiso is the above pastebin from serial output?19:48
palateJusii: yes19:49
palateJusii: oh, is it sending less output over serial?19:49
Jusiiwell, console=ttyS0,115200 should print all on serial19:52
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC19:53
Jusiibut ofcourse there's many ways to disable kernel messages on boot, like in your case it is19:53
RPquite 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 pocketbeagle19:53
palateRP: I'm connecting with `screen /dev/ttyUSB0 115200`19:54
Jusiiwhat's this? pocketbeagle /dev/ttyO019:54
Jusiithat's your local serial, but what is the serial device on pocket beagle19:55
*** rcw <rcw!~rcw@> has quit IRC19:55
RPpalate: that is the device on your host system which would be different to the one on the target beagle19:55
Jusiiso maybe console=ttyO0,115200 should fix that?19:56
RPI'd agree with that FWIW19:56
palatethat's what I get with `ls -l /dev/tty*`19:56
palateJusii: can I just edit /proc/cmdline?19:57
RPright, you want O119:57
RPpalate: no19:57
Jusiiyou should be able to fix that in u-boot I'd guess19:57
Jusiiwhich passes the cmdline to kernel19:57
RPor in the kernel if its compiled in there instead19:57
palatethat means on the yocto side before building the image, or directly from the pocketbeagle over serial?19:58
Jusiinow you need to figure out how to modify kernel boot cmdline19:58
palate(sorry I'm very new to all that, but taking notes :-) )19:58
Jusiiyou can do it yocto side before building for sure19:58
Jusiibut you can try doing it in u-boot too19:59
RPpalate: if I remember you were editing a defconfig earlier?19:59
palateRP: why do I want O1? Because O0 and O4 are used already?19:59
RPpalate: sorry, I meant o)19:59
* RP should just stop trying to help :/19:59
palateRP: 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
palateok -> O0 it is :D20:00
RPpalate: ok. I was wondering if this was something you'd set. In that case its probably coming from uboot20:00
palateRP: so now I need to get more output, so that when I start again and it fails, I can have an idea why20:00
rburtonRP: 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 IRC20:01
RPrburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/105820:02
RPrburton: that is the failure I was trying to link to, perhaps unsuccessfully20:02
RP"Postinstall scriptlets of ['distcc'] have failed. If the intention is to defer them to first boot,"20:02
RPsounds distcc like20:02
rburtonyeah :)20:02
RPbut nothing would surprise me today :(20:02
rburtonok fixed, forgot to update another PN -> PN-server20:04
rburtonstill need to write my pkgdata browser to inspect what goes into packages20:04
RPrburton: glad its something simple20:04
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC20:04
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC20:06
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:08
RPrburton: that openssl issue is what is breaking build-appliance too20:08
RPkhem: your patch fixes it, thanks!20:09
rburtonoh hooray khem20:11
rburtonbit 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 #yocto20:15
*** Crofton|mini <Crofton|mini!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC20:16
RPJPEW: full build fired with hashequiv enabled20:19
palateI 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
palateright?), and the image does not boot anymore -_-20:23
palateI was expecting that `bitbake -c menuconfig` would use the options defined by my defconfig in the first place...20:24
palateIs it wrong to generate the defconfig this way?20:25
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC20:27
palateargh 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/1ydPiACN20:29
palateIt seems to still take my commented out option -_-20:29
*** rcw <rcw!~rcw@> has joined #yocto20:29
khemRP: is the weston-init patch ok now ?20:33
khemI am more and more impressed with AB testing20:34
*** rcw <rcw!~rcw@> has quit IRC20:35
RPkhem: I haven't requeued as I have a few too many other problems without that added risk (yet)20:36
RPkhem: the test matrix is getting fairly comprehensive :)20:36
khemrburton: 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 fallback20:37
khemRP:this was a genuine problem introduced in my patch and it was nice a system called it out20:37
RPkhem: we've had those tests for a while. They were written to detect that exact problem :)20:38
khemRP:no hurry it can go in next lot, I have few BSP layer patches waiting on it20:38
*** rcw <rcw!~rcw@> has joined #yocto20:39
khemsomething has broken musl/risv64 dont know what20:39
khemmaybe its musl or maybe something else in core metadata or packages20:40
RPneed to get them as members and into the test matrix20:40
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto20:40
khemall are startups20:40
khemmaybe silver20:40
*** Crofton|mini <Crofton|mini!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto20:42
khemRP: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 host20:45
RPkhem: ok, sounds promising that some should get fixed then20:46
khemthis is tumbleweed is it ?20:47
*** rburton <rburton!~rburton@> has quit IRC20:52
khemRP: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 linkinh20:52
khemmaybe if you have access to build node then try gcc -static hello.c -lpthread on it I think it will fail in same way20:53
khem/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: cannot find -lpthread20:53
khem/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: cannot find -lc20:53
khemuim-native is20:56
khem| collect2: error: ld returned 1 exit status20:56
khem| x86_64-linux-libtool:   error: error: relink 'libuim-fileio.la' with the above command before installing it20:56
khemseems we can get past by deleting .la files20:56
RPkhem: that sounds like we have an undocumented dependency then20:56
RPkhem: we install exactly what is documented onto the workers20:57
khemif you or someone can validate then we can change the docs20:57
RPkhem: is there no way to avoid that dependency?20:58
khemsome packages like luajit also needs 32bit gcc on build hosy20:58
khemmaybe disable static linking20:58
khemI dont know why one would need a statically linked binary on the build host20:58
tlwoernerpalate: 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.html20:59
RPkhem: we may just have to have an exclusion file listing these things20:59
RPtlwoerner: I'm out of touch with wic I'm afraid so I'm not much help :(21:00
jwesseltlwoerner: The u-boot defaults are what set that string.21:00
jwesselDepending on the board.21:00
tlwoernerjwessel: in this case that string is being set by wic21:00
jwesselI 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
tlwoernerRP: i only pointed to you because you were trying to help :-)21:01
*** armpit <armpit!~armpit@> has quit IRC21:02
tlwoernermight as well try to short-circuit everyone trying to help when i've already root-caused the issue ;-)21:02
RPtlwoerner: fair enough. I'm just sad I'm so out of touch with some of this stuff :(21:02
tlwoernerjwessel: yes, there are many ways to help U-Boot pass cmdline args to the linux kernel, extlinux is one of them21:02
jwesselI'd like to at least make it consistent with what ever it is you are doing.21:03
tlwoernerRP: you do what you do best, 'cause i don't know many who could take over from you!21:03
jwesselThe ostree boot mechanics for example, make use of the boot.scr generated file from u-boot-env.21:03
jwesselBut again, this is something that is highly board dependent.21:03
tlwoernerjwessel: as such, there is a whole class mechanism in place so a user can tweak the extlinux file (which is great, yea!!)21:03
jwesselWell I guess you could always encode it in the kernel that is getting loaded too. ;-)21:04
tlwoernerjwessel: 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
tlwoernerit'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
jwesselhttps://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
tlwoernerpalate: this is "fixed" in the OE/master layer, it's fixed by hard-coding the kernel cmdline in the kernel config itself ;-)21:06
jwesselI was using bootmenu on this particular board previously.21:06
tlwoernersee: http://cgit.openembedded.org/openembedded-core/tree/scripts/lib/wic/plugins/source/bootimg-partition.py#n14621:07
tlwoernerjwessel: palate: ^^ does that look familiar (i.e. the contents of the extlinux file)?21:08
jwesselI would agree you need the ability to customize it, I didn't even know it existed.21:08
*** cconlon <cconlon!~cconlon@> has joined #yocto21:08
palatetlwoerner: oh...21:09
*** berton <berton!~berton@> has quit IRC21:09
tlwoernerso either i could not use the bootimg-partition facility of wic (like Otavio does in his BSPs)21:09
jwesselIt looks to me like you can put a custom file in there though.21:09
*** cconlon <cconlon!~cconlon@> has left #yocto21:09
tlwoerneror not use wic (and let the extlinux class generate the file)21:09
tlwoerneror tweak the wic thing21:10
palatetlwoerner: so that's not related to the ttyO0 vs ttyS0 thing?21:10
tlwoernerjwessel: 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 there21:11
tlwoernerpalate: no, there's a kernel config option to get OMAP-type processors to use ttyS instead of ttyO21:11
jwessel        configfile = cr.ks.bootloader.configfile21:12
tlwoernerjwessel: exactly. any idea where that is?21:12
* tlwoerner 's python-foo only gets him so far...21:13
tlwoernerin any case, it's not looking where the extlinux class is placing its results21:13
tlwoerner(presumably wic does its work very late in the process, so it can't be a timing issue)21:13
jwesselscripts/lib/wic/ksparser.py:        bootloader.add_argument('--configfile')21:13
jwesselIt is one of the options you can specify.21:14
jwesselwic help kickstart |less21:14
jwesselRun that and search for configfile21:14
jwesselYou'll see it is actually documented.21:14
jwesselWhere by you can pass in what ever you like.21:15
palatetlwoerner: 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_CONSOLE21:15
tlwoernerpfft! who reads documentation? (lol, here i was trying to read the code!)21:15
palatetlwoerner: now I just get a lot of output when booting, without changing anything else (well, rebuilding the kernel). Does that make sense?21:15
jwesselI read the code to find the doc.21:15
jwesselSee my reference to ksparser.py above.21:15
jwesselThen I realized it was documented.21:15
khemRP: 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 commit21:18
tlwoernerpalate: 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
tlwoerneri'm not 100% sure what is the smallest config you need to get it working, but this one works21:18
RPkhem: worth a try, its from 2011 so things have changed21:18
palatetlwoerner: should I actually just go on OE/master completely?21:21
tlwoernerwell... i don't want to get into any fights...21:21
palatetlwoerner: I have no clue about the difference. OE/master is some kind of fork, but in a branch?21:22
tlwoernermaster was intended for someone to use with yocto, OE/master was intended to be used was OE only21:22
tlwoernerpalate: yes21:22
palatetlwoerner: but OE/master now works with yocto, right?21:22
tlwoernerOE/master only depends on openembedded-core21:22
RPkhem: do you want to try that in a -next branch for meta-oe?21:23
palatetlwoerner: and you're here. So I'm moving to OE/master :D21:23
RPkhem: we could try a build of -next of poky and meta-oe21:23
tlwoernermaster depends on poky21:23
tlwoernermaster uses yocto-linux, and OE/master uses upstream21:24
palatetlwoerner: but yocto is based on OE, right?21:24
RPtlwoerner: I'm now wondering what the difference is :/21:24
RPtlwoerner: 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 #yocto21:25
tlwoerneri had a conversation over the weekend with Robert about what i should use for the upstream defconfig, but it kinda petered out21:25
RPpalate: yocto is very much oe based21:25
*** thannoy <thannoy!~anthony@134-48-190-109.dsl.ovh.fr> has quit IRC21:28
tlwoernerwell... i *could* dive into a whole diatribe... but nobody wants that, not even me! ;-) lol21:29
tlwoernerplus, 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 things21:30
RPtlwoerner: 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
tlwoernerthe branch that works with poky uses an older kernel, that needs, for example, ttyO0. but using the latest stable upstream kernel switches to ttyS021:30
tlwoernerso instead of making the layer really messy with overrides, i just created two branches21:30
tlwoerneri'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 overrides21:31
RPtlwoerner: ah, so the difference is trying to align with linux-yocto?21:31
tlwoerneryes, and not clobbering the valid work of other people21:32
tlwoernerif 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
RPtlwoerner: I worry this approach is going to really confuse users21:32
tlwoernerRP: welcome to BSP-land, where every BSP does every thing its own way21:33
ecdheI'm having an issue with RDEPENDS: https://pastebin.com/pMqd2REe21:33
tlwoernerRP: i'm laughing as i say that, but it's not far from the truth ;-)21:33
ecdheI'm clearly RDEPENDING on python3 in a recipe that's installing a python file that starts with the line "#!/usr/bin/python3"21:34
tlwoernerand it's not meant to insult the hard work people have put into their BSP layers, BSP layers have their own quirks21:34
tlwoernere.g. tweaking a kernel configuration21:34
*** Crofton|mini <Crofton|mini!~Crofton@d47-69-20-194.try.wideopenwest.com> has quit IRC21:34
tlwoernere.g. proving recipes for vendor-kernels/u-boot/windowing-systems vs upstream21:35
RPtlwoerner: 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
tlwoernerRP: okay, fair enough, i can switch that to "upstream" (?)21:36
RPtlwoerner: that means its hard for a user to understand what it is and fans "OE vs Yocto" flames when its not really that21:36
RPtlwoerner: 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
RPtlwoerner: 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_VERSION21:38
ecdheI am including the python3 package in my layer, and the booted image does indeed contain python3 located in /usr/bin/21:39
ecdheSo the package called "python3" seems to be providing the file /usr/bin/python3.21:39
ecdheBut 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
ecdheBut this is despite my "diagnostics.bb" containing the line RDEPENDS_${PN} += "python3"21:40
palatetlwoerner: that's interesting21:41
tlwoernerRP: 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 etnaviv21:41
palatetlwoerner: what would be the risk/downside of using `master` (seems like `OE/master` is just more modern)21:42
tlwoernerbeing forced to base a build on, say, a 3.x or 4.x vendor kernel (not uncommon) affects a lot of other configurations and choices21:43
RPtlwoerner: Yes, I can imagine that. I guess that is where the overrides come in :/21:44
RPtlwoerner: I guess it comes down to better labelling of the branches then as "OE" really doesn't cover that21:44
tlwoernerOtavio 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 successful21:44
tlwoernerRP: yes, sorry. didn't mean to put things sideways :-(21:45
palatetlwoerner: btw, I just built from OE/master, and I think it generated a .tar.gz... :D21:46
tlwoernerso 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
tlwoernerpalate: wic might need a tar.gz21:47
RPtlwoerner: there are other simpler ways you could probably do something like that albeit with slightly more duplication21:47
tlwoerner(but i don't explicitly need one)21:47
RPtlwoerner: I was never sold on adding that level of complexity into the core21:47
RPtlwoerner: if the feedback is many people need it we could look at it again21:47
tlwoernerRP: 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 try21:48
tlwoernerRP: i'm not the strongest bitbake/layer developer, so if you could point me at something that'd be awesome! :-D21:49
palatetlwoerner: OE/master seems to be working like a charm!21:49
palatetlwoerner: and apparently it has g_ether already \o/21:49
tlwoernerpalate: w00t!21:50
ecdheany ideas on the RDEPENDS error?21:50
* tlwoerner accidentally did something right ;-)21:50
palatetlwoerner: xD21:50
tlwoernerlol, how most things get done21:50
tlwoernerpalate: do you know it's CONFIG_ option?21:50
palatetlwoerner: I think it should be CONFIG_USB_ETHER21:51
palatetlwoerner: but I'm new to... kernels... so I may be wrong. Though I got help to find that out :)21:51
RPtlwoerner: I'm wondering why you can't set MACHINEOVERRIDES to what you need directly?21:51
tlwoernerpalate: CONFIG_USB_ETH=m21:52
RPtlwoerner: Core supports MACHINEOVERRIDES, its just the  magic groupings it doesn't21:52
palatetlwoerner: yep, that's consistent with what I see21:52
tlwoernerpalate: Robert suggested i base my defconfig on omap2plus_defconfig, so it probably came in from there21:52
palatetlwoerner: right. That's awesome, `modprobe g_ether` just worked :)21:52
tlwoernerpalate: and it only took 6 hours for us to figure out i had already inadvertently solved your issue21:53
palateI'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
palatetlwoerner: haha yes, but I learned many things in the process!21:53
tlwoernerpalate: yes, i would expect that21:54
palatetlwoerner: (more than 6 hours for me, though :D)21:54
tlwoernerRP: okay, i'll have to take a deeper look21:54
palatetlwoerner: 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
palatewell, now it says "no change to .config"... before it would just save it21:57
palateLet's say I'm happy with OE/master, I'll work on networking through g_ether next time :-)21:57
palateThank you so much with all the help!21:57
tlwoernerpalate: you're welcome, and welcome to #yocto!21:58
palatethanks :-)21:58
palateThanks RP, too (obviously)!21:59
palategood night guys!21:59
*** stephano <stephano!~stephano@> has quit IRC21:59
marler899722I'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 PATH22:00
*** rcw <rcw!~rcw@> has quit IRC22:00
marler899722Any ideas what's gone wrong here?22:00
yoctiNew 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 IRC22:03
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC22:04
tlwoernerecdhe: does it help if you just change it to a DEPENDS (drop the *R*DEPENDS)?22:05
ecdhetlwoerner: will check22:05
tlwoernerRP: okay, reading about MACHINEOVERRIDES gives me something to try, i'll give it a whirl22:09
ecdhetlwoerner: RDEPENDS->DEPENDS doesn't fix it.22:09
tlwoernerecdhe: that is a good thing, it would have been messy if it did22:10
ecdheYeah, I didn't figure it was the problem.22:10
ecdheI'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
RPtlwoerner: if its not working talk to me about it22:17
tlwoernerRP: will do22:17
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC22:18
*** Crofton <Crofton!~Crofton@d47-69-20-194.try.wideopenwest.com> has joined #yocto22:28
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC22:43
*** nabokov <nabokov!~armand@> has quit IRC22:51
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto22:53
*** yacar_ <yacar_!~yacar@87-231-0-253.rev.numericable.fr> has joined #yocto22:55
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has quit IRC23:08
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC23:18
*** armpit <armpit!~armpit@2601:202:4180:c33:45b7:cfa2:129c:2a54> has joined #yocto23:23
*** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has quit IRC23:29
*** vmeson <vmeson!~rmacleod@192-0-133-18.cpe.teksavvy.com> has joined #yocto23:30
*** monkeyman79 <monkeyman79!~monkeyman@apn-5-60-198-197.dynamic.gprs.plus.pl> has quit IRC23:34
*** vmeson <vmeson!~rmacleod@192-0-133-18.cpe.teksavvy.com> has quit IRC23:48
*** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has joined #yocto23:49

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!