*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC | 00:25 | |
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 00:59 | |
khem | rsalveti:my bad | 01:02 |
---|---|---|
khem | I guess I have to update my patchset | 01:02 |
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has quit IRC | 01:06 | |
*** mckoan|away <mckoan|away!~marco@unaffiliated/mckoan> has quit IRC | 01:14 | |
*** anujm <anujm!~anujm@134.134.139.77> has quit IRC | 01:40 | |
*** chinhuat647997 <chinhuat647997!~chinhuat@192.198.146.171> has joined #yocto | 01:47 | |
*** chinhuat64799 <chinhuat64799!~chinhuat@192.198.146.173> has quit IRC | 01:49 | |
*** JPEW <JPEW!~JPEW@ec2-18-219-251-161.us-east-2.compute.amazonaws.com> has quit IRC | 01:55 | |
*** kaspter <kaspter!~Instantbi@183.128.237.44> has joined #yocto | 01:59 | |
*** camus <camus!~Instantbi@183.128.237.44> has joined #yocto | 02:06 | |
*** armpit <armpit!~armpit@c-71-204-143-8.hsd1.ca.comcast.net> has quit IRC | 02:07 | |
*** kaspter <kaspter!~Instantbi@183.128.237.44> has quit IRC | 02:08 | |
*** camus is now known as kaspter | 02:08 | |
*** kaspter <kaspter!~Instantbi@183.128.237.44> has quit IRC | 02:12 | |
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 02:12 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 02:18 | |
*** kaspter <kaspter!~Instantbi@183.128.237.44> has joined #yocto | 02:19 | |
*** JPEW <JPEW!~JPEW@2600:1f16:181:f300:d350:982:b6f5:216c> has joined #yocto | 02:20 | |
*** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 02:20 | |
zeddii | RP: I didn't see a systemtap patch on master-next or master-next2, I wanted to grab it, since when I tested 32bit arm, I ran into the flags issue from earlier. | 03:10 |
*** JPEW <JPEW!~JPEW@2600:1f16:181:f300:d350:982:b6f5:216c> has quit IRC | 03:17 | |
*** JPEW <JPEW!~JPEW@2600:1f16:181:f300:d350:982:b6f5:216c> has joined #yocto | 03:23 | |
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 03:35 | |
*** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 03:35 | |
*** mtahmed <mtahmed!ad24d476@173.36.212.118> has joined #yocto | 03:53 | |
mtahmed | Hi all! I have been trying to figure out why building a simple recipe that has no dependencies ends up building "everything". Anything that ends up in the final image for that machine ends up as a dependency of the target_recipe.do_build in task-depends.dot | 03:54 |
mtahmed | I saw that there is a `do_build[recrdeptask] = "do_package_write_ipk` but this tiny recipe I am building has no declared dependencies yet ends up depending on a bunch of unrelated stuff in task-depends.dot | 03:55 |
*** mtahmed <mtahmed!ad24d476@173.36.212.118> has quit IRC | 03:58 | |
*** mtahmed <mtahmed!ad24d476@173.36.212.118> has joined #yocto | 03:59 | |
yocti | New news from stackoverflow: do_rootfs function failed in yocto project <https://stackoverflow.com/questions/50015694/do-rootfs-function-failed-in-yocto-project> | 04:14 |
*** mtahmed <mtahmed!ad24d476@173.36.212.118> has quit IRC | 04:23 | |
*** mtahmed <mtahmed!c9aa197a@201.170.25.122.dsl.dyn.telnor.net> has joined #yocto | 04:27 | |
*** mtahmed <mtahmed!c9aa197a@201.170.25.122.dsl.dyn.telnor.net> has quit IRC | 04:32 | |
*** iceaway <iceaway!~pelle@37.233.78.69> has joined #yocto | 05:13 | |
*** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has quit IRC | 05:25 | |
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:26 | |
*** armpit <armpit!~armpit@2601:202:4180:c33:811a:fbd5:24bc:2160> has joined #yocto | 05:31 | |
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto | 05:35 | |
*** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 06:07 | |
*** iceaway <iceaway!~pelle@37.233.78.69> has quit IRC | 06:13 | |
*** iceaway <iceaway!~pelle@37.233.78.69> has joined #yocto | 06:14 | |
yocti | New news from stackoverflow: Unable to start bitbake server <https://stackoverflow.com/questions/48132054/unable-to-start-bitbake-server> | 06:14 |
*** saraf <saraf!~a_saraf@123.252.238.18> has joined #yocto | 06:15 | |
*** feilz <feilz!~feil@212-50-143-116.co.dnainternet.fi> has joined #yocto | 06:16 | |
*** frsc <frsc!~frsc@200116b824d1b50049623ff52895edd0.dip.versatel-1u1.de> has joined #yocto | 06:32 | |
*** micka <micka!~micka@reverse-75.fdn.fr> has quit IRC | 06:33 | |
*** micka <micka!~micka@reverse-75.fdn.fr> has joined #yocto | 06:35 | |
*** lpoulain <lpoulain!lpoulain@gateway/shell/linaro/x-dzqnckydpijeibqp> has quit IRC | 06:45 | |
*** griffinp <griffinp!griffinp@gateway/shell/linaro/x-otxlgrsgngkzwvxg> has quit IRC | 06:45 | |
*** alimon <alimon!alimon@gateway/shell/linaro/x-jgbtkxiflkqtvjob> has quit IRC | 06:45 | |
*** chinhuat6479978 <chinhuat6479978!~chinhuat@192.198.146.173> has joined #yocto | 06:49 | |
*** lpoulain <lpoulain!lpoulain@gateway/shell/linaro/x-qrhypfouzsfpgvfe> has joined #yocto | 06:50 | |
*** chinhuat647997 <chinhuat647997!~chinhuat@192.198.146.171> has quit IRC | 06:50 | |
qschulz | fullstop: glad it's fixed :) Thanks for letting us know! | 06:52 |
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto | 06:54 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 07:07 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:09 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 07:17 | |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 07:23 | |
RP | zeddii: I just updated to a new git version so the patch was ammended | 07:24 |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 07:25 | |
*** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto | 07:26 | |
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto | 07:29 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 07:30 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 07:32 | |
*** yacar_ <yacar_!~yacar@80.215.195.222> has joined #yocto | 07:34 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 07:36 | |
*** bisbarn <bisbarn!~bisbarn@edge1.crosscan.com> has joined #yocto | 07:43 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 07:56 | |
*** Bunio_FH <Bunio_FH!~bunio@84.red-213-0-2.staticip.rima-tde.net> has joined #yocto | 08:04 | |
*** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC | 08:07 | |
*** Bunio_FH <Bunio_FH!~bunio@84.red-213-0-2.staticip.rima-tde.net> has quit IRC | 08:08 | |
*** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto | 08:08 | |
yocti | New news from stackoverflow: YOCTO : No '/lib/modules' directory in image, modprobe fails <https://stackoverflow.com/questions/57656086/yocto-no-lib-modules-directory-in-image-modprobe-fails> | 08:15 |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 08:19 | |
cengiz_io | hello there! I have a very silly question regarding `menuconfig` ncurses view. I'm indirectly running `make menuconfig` thru yocto/bitbake and whenever the ncurses UI pops up, line characters are messed up (particularly replaced with ^@ symbol). Any ideas? | 08:39 |
cengiz_io | running in a docker container based on ubuntu:18.10, I've tried changing $TERM variable, installing libncurses(w)5-dev instead of libncurses-dev, tried exporting some environment variable that supposedly forces ncurses to NOT to use unicode while drawing lines, I've messed with locale settings, LC_ALL=en.US-UTF8 oh and, `bitbake -c menuconfig virtu | 08:40 |
cengiz_io | al/kernel` runs menuconfig (devshell) via `screen` command. I can't modify those arguments because they all come from OpenEmbedded distro. | 08:40 |
cengiz_io | my yocto branch is `thud` | 08:40 |
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 08:45 | |
*** yacar_ <yacar_!~yacar@80.215.195.222> has quit IRC | 09:04 | |
*** likewise <likewise!~leon@213.34.54.210> has joined #yocto | 09:24 | |
feilz | cengiz_io: this isn't directly the answer, but for me at least I never successfully managed to use the 'menuconfig' to modify my kernel values, and were forced to still manually implement the changes I attempted that way (might also be cause I don't know how to get it to work). | 09:27 |
feilz | i introduced the changes using patch files to my kernel | 09:27 |
qschulz | feilz: you need menuconfig, then savedefconfig and then use a patch to replace the defconfig in question IIRC | 09:31 |
*** yacar_ <yacar_!~yacar@80.215.195.222> has joined #yocto | 09:33 | |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 09:46 | |
likewise | I have gdb-cross built. How can I easily call it directly without first going through the BSP flow? | 09:46 |
likewise | I recon I would need to create the combined sysroot for gdb-cross-<target-arch>, but I do not know how to do this. | 09:47 |
likewise | (Calling gdb-cross directly worked in older releases, but broke when sysroot got componentized). | 09:48 |
*** yacar_ <yacar_!~yacar@80.215.195.222> has quit IRC | 09:55 | |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 09:57 | |
feilz | qschulz: tried that multiple times. I tried following the instructions I found online, however to no avail. One issue I found (not sure if every time was cause of this) was that sometimes the menuconfig opened the kernel of the local system I was using | 10:02 |
feilz | I believe that happened if I was using the menuconfig through bitbake, but if I used 'make menuconfig' in the temp work directory of the kernel, it built using the virtual kernel I was working | 10:03 |
qschulz | feilz: you did bitbake virtual/kernel -c menuconfig right? | 10:03 |
feilz | i used that command, yes. | 10:04 |
qschulz | you have to use this command after the do_configure of the kernel I think, otherwise there is no .config | 10:04 |
feilz | problem with the .config was as well since every build I made I basically rewrote the temp kernel (through changes). | 10:05 |
feilz | and it usually got lost. | 10:05 |
feilz | hence after doing menuconfig (before I gave up on using it), I looked through the actual .config value changes, and noted them manually into our custom defconfig file. | 10:06 |
feilz | that way I got them incorporated | 10:06 |
feilz | later on I just learned to read the Kconfig files to find the correct config values to get what I needed | 10:07 |
qschulz | feilz: not ideal as .config has way more info than necessary compared to a defconfig | 10:07 |
qschulz | feilz: don't do that please, use menuconfig and savedefconfig | 10:07 |
qschulz | you'll get into trouble faster than you think | 10:07 |
qschulz | pulling your hair for no reason | 10:08 |
qschulz | because you forgot that one depends on that this Kconfig option relied one through the 10th selects Kconfig | 10:08 |
feilz | well... I got a successful delivery eventually on the first project for this client, and using the method I described. On the second project now, and the method hasn't failed me yet, where the menuconfig and savedefconfig commands failed me | 10:09 |
feilz | grep is quite a handy command to find all the dependencies | 10:09 |
feilz | not ideal, I agree. | 10:10 |
*** lfa <lfa!~lfa@217.19.35.51> has quit IRC | 10:10 | |
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC | 10:14 | |
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto | 10:17 | |
rburton | ok any MIPS experts around? | 10:19 |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 10:20 | |
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 10:30 | |
*** camus <camus!~Instantbi@183.128.237.44> has joined #yocto | 10:32 | |
*** kaspter <kaspter!~Instantbi@183.128.237.44> has quit IRC | 10:34 | |
*** saraf <saraf!~a_saraf@123.252.238.18> has quit IRC | 10:46 | |
*** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-046-005-020-206.hsi8.kabel-badenwuerttemberg.de> has joined #yocto | 11:04 | |
*** yacar_ <yacar_!~yacar@80.215.195.222> has joined #yocto | 11:08 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 11:35 | |
nrossi | RP: i think i've sorted those gcc test issues i linked yesterday, https://github.com/nathanrossi/openembedded-core/commit/5cbb4f9fad777d20a5905ad305ed54fe2a618e81 | 11:36 |
nrossi | RP: also, khem's comment about needing to set TOOLCHAIN for glibc-testsuite made me think of various other glibc overrides. So i think this change is needed too https://github.com/nathanrossi/openembedded-core/commit/fa9f3d3af965bcb9598661e62003595683045493 | 11:38 |
nrossi | RP: and just a side query, glibc-initial is definitely gone yes? there are still some overrides remaining for it in security_flags and other various comments, are those still applicable or should they be cleaned up? | 11:39 |
rsalveti | khem: thanks for sending the patch! | 11:39 |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 11:42 | |
*** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:44 | |
RP | nrossi: first change looks good, we should probably duplicate entries for the second, I'm curious which other pn overrides there would be? | 11:44 |
RP | nrossi: glibc-initial is definitely gone, those are just leftovers and should be cleaned up | 11:44 |
RP | nrossi: I've been thinking about the autobuilder integration of this and have run into a few challenges. | 11:44 |
RP | nrossi: resulttool doesn't seem to be processing things entirely correctly :/ | 11:45 |
nrossi | RP: by duplicate entries you mean add duplicate entries to e.g. security_flags? or something else? | 11:46 |
RP | nrossi: https://autobuilder.yocto.io/pub/non-release/20190904-7/testresults/testresult-report.txt - no gcc results in the ptest tables | 11:46 |
nrossi | RP: other layers override based on glibc, e.g. https://github.com/kraj/meta-clang/blob/master/conf/nonclangable.conf#L12 | 11:46 |
RP | nrossi: yes, security_flags | 11:46 |
RP | nrossi: those other layers should really adapt to the change | 11:46 |
nrossi | RP: yes i noticed the missing results, was very confused | 11:46 |
RP | nrossi: the results are there, its just not processing them as we'd want | 11:47 |
nrossi | RP: are you sure? i looked at the testresults.json file from one of those builds and the ptestresults entries were not there | 11:47 |
nrossi | RP: https://autobuilder.yocto.io/pub/non-release/20190904-7/testresults/qemux86-64/testresults.json <- or are they trimmed somewhere? | 11:48 |
RP | nrossi: ah, you're right. They're not in https://autobuilder.yocto.io/pub/non-release/20190904-7/testresults/qemux86-64/testresults.json | 11:48 |
RP | nrossi: ok, need to investigate that | 11:49 |
RP | nrossi: we also have a timeout problem on long running tests | 11:49 |
RP | nrossi: bitbake prints a "keepalive" to the console but oe-selftest does not | 11:49 |
nrossi | RP: by keepalive, you just mean like a newline or similar yes? | 11:50 |
nrossi | RP: not a special string | 11:50 |
RP | nrossi: It just prints "still alive <time>" or similar | 11:51 |
nrossi | RP: I can look at doing that | 11:51 |
RP | nrossi: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=fcec90de9c2c4abb64780628193f0631c0b296ad | 11:51 |
RP | nrossi: devil is in the detail now :) | 11:52 |
nrossi | RP: oh btw, you left the pexpect commit in master-next when you rebased | 11:52 |
RP | nrossi: yes, sorry. won't hurt anything | 11:56 |
*** yacar_ <yacar_!~yacar@80.215.195.222> has quit IRC | 11:56 | |
RP | nrossi: gone now :) | 11:56 |
nrossi | RP: also i had some ideas about how to do the autobuilder selftest with exclusion of qemu sys tests. Wondering if you had any opposition to the tests being "skipped" instead of filtered | 11:57 |
RP | nrossi: no objection as such | 11:57 |
*** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has quit IRC | 11:57 | |
nrossi | RP: the idea is that instead of tags being special, they simply follow a tags_filter expression and then cause a skip if the tag filter is not met | 11:58 |
*** berton <berton!~berton@181.220.83.67> has quit IRC | 11:59 | |
*** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:59 | |
nrossi | RP: the idea then is to have that work with the datavar decorator, so that it can check if the tags match or if the machine==x86-64. Allowing for the glibc-sys for only x86 | 11:59 |
RP | nrossi: how does that help compared to what is there now? | 12:02 |
RP | nrossi: FWIW I've been wondering about marking the system and user tests with a specific tag, having the autobuilder select both, then let the class setup decide whether to run or skip based on the host arch | 12:03 |
nrossi | RP: that works too, but how would you run the glibc system tests for all machines? | 12:05 |
*** yacar_ <yacar_!~yacar@80.215.195.222> has joined #yocto | 12:05 | |
RP | nrossi: not sure I understand the question? | 12:06 |
nrossi | RP: if the class decides to run or skip based on host, would it be skipping all non-kvmable hosts? and if so then how do you get the class to execute e.g. say locally or for release testing | 12:07 |
RP | nrossi: I'd guess that piece of policy would be down to some variable doing configuration | 12:08 |
RP | nrossi: or we just markup with extra tags to match the pattern we need? | 12:08 |
*** nabokov <nabokov!~armand@67.218.223.154> has joined #yocto | 12:08 | |
RP | nrossi: I assume a test or class can have more than one tag? | 12:08 |
nrossi | RP: yes | 12:09 |
*** lexano <lexano!~lexano@CPE64777d52fed3-CM64777d52fed0.cpe.net.cable.rogers.com> has quit IRC | 12:09 | |
nrossi | RP: but the slight annoyance is that classes will inherit tags, so might need to sort that out | 12:10 |
*** lexano <lexano!~lexano@CPEa021b7ac59c9-CMf0f249028110.cpe.net.cable.rogers.com> has joined #yocto | 12:12 | |
RP | nrossi: you mean all tests within a class inherit tags and all subclasses of a class? | 12:13 |
nrossi | RP: yer | 12:13 |
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 12:16 | |
*** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC | 12:25 | |
*** nabokov <nabokov!~armand@67.218.223.154> has quit IRC | 12:26 | |
*** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto | 12:27 | |
*** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto | 12:28 | |
*** nabokov <nabokov!~armand@67.218.223.154> has joined #yocto | 12:39 | |
*** alimon <alimon!alimon@gateway/shell/linaro/x-kdxwurhyvcmjuqof> has joined #yocto | 13:00 | |
*** bisbarn <bisbarn!~bisbarn@edge1.crosscan.com> has quit IRC | 13:03 | |
RP | zeddii: figured out the qemuarm systemtap issue | 13:04 |
zeddii | lol. I was just about to say "i reproduced it!" | 13:08 |
zeddii | from /tmp/stapy2SORD/stap_1381_src.c:26: | 13:08 |
zeddii | 261 | get_fs() == get_ds() ? "kernel" : "user"); | 13:08 |
zeddii | | ^~~~~~ | 13:08 |
zeddii | | get_fs | 13:08 |
zeddii | cc1: all warnings being treated as errors | 13:08 |
zeddii | make[1]: *** [scripts/Makefile.build:278: /tmp/stapy2SORD/stap_1381_src.o] Error 1 | 13:08 |
* zeddii feels the need to prove it :D | 13:08 | |
zeddii | I bumped the stap srcrev here as well. but it takes about 10 minutes for the case to error when I run it. + time to make scripts prepare, so it was about an hour round trip from the update to the error :D | 13:09 |
RP | zeddii: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-kernel/systemtap/systemtap/fixarm.patch?h=master-next&id=e1dddc042ad1396af045e701adc9488715b1b22c | 13:09 |
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 13:10 | |
zeddii | yah. last night in my kernel checking I saw that it had been removed. that | 13:10 |
zeddii | that's the right thing to do to get it back up and running. | 13:10 |
RP | zeddii: mentioning to upstream, see if they like the patch | 13:10 |
zeddii | I don't see why they wouldn't. That's what it was being resolved to anyway. so outside of dropping the use of get_ds (kernel_ds) completely .. that's the only way to go. | 13:11 |
zeddii | so it is just the mips highmem lockup now ? and that beastie is not 100% reproducible ? | 13:13 |
rburton | zeddii: know anyone who knows mips memory layout? | 13:13 |
rburton | my limited understanding is that mips 32-bit is a bit of a mess but linux appears to be doing the right thing | 13:13 |
rburton | but hey i know nothing about mips | 13:13 |
rburton | [ 0.000000] Zone ranges: | 13:14 |
rburton | [ 0.000000] DMA [mem 0x0000000000000000-0x0000000000ffffff] | 13:14 |
rburton | [ 0.000000] Normal [mem 0x0000000001000000-0x000000001fffffff] | 13:14 |
rburton | [ 0.000000] HighMem [mem 0x0000000020000000-0x000000009fffefff] | 13:14 |
rburton | seems right i guess | 13:14 |
zeddii | I'd have to raise RalfB from whereever he's been hiding. | 13:14 |
zeddii | yah. to my non-mips eye, it looks reasonable. | 13:15 |
zeddii | can we leave 32 bit mips slumming with 256M or memory ? I'll have to check the list to see what was breaking with it that low. | 13:15 |
rburton | its the gl stuff kanavin_ added that breaks with not enough ram | 13:16 |
khem | zeddii:whats up with qemumips ? running out of mem ? | 13:17 |
zeddii | khem. its (sometimes) hanging when the mem is bumped to 512M | 13:18 |
zeddii | RP or rburton may have a more technical description than that though. | 13:18 |
rburton | thats the gist of it :) | 13:18 |
rburton | my hunch is that selftest uses more of the ram and qemu doesn't like it and dies | 13:18 |
khem | rburton:does it function fine with 256 ? | 13:18 |
rburton | sort of. the gl pieces need more than 256 to work. | 13:19 |
rburton | paging kanavin for more context there | 13:19 |
rburton | khem: if you understand the traditional mips memory model then looking at what the kernel thinks it found, and what qemu is doing, would be appreciated | 13:20 |
khem | mips memory accesses are a bit different when its more than 256M it needs to use highmem | 13:20 |
rburton | right | 13:21 |
khem | we do have CONFIG_HIGHMEM enabled right | 13:21 |
rburton | we do | 13:21 |
rburton | khem: https://pastebin.com/qMvjJEum <-- boot with 512mb | 13:22 |
rburton | my working theory is that qemu-system-mips is broken in some way for high memory accesses | 13:22 |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 13:22 | |
rburton | i guess writing an app to grab all the memory is a way to find out | 13:22 |
*** bisbarn <bisbarn!~bisbarn@edge1.crosscan.com> has joined #yocto | 13:23 | |
nrossi | rburton: you could try this, https://github.com/nathanrossi/meta-random/blob/master/recipes-tests/tests/files/test-malloc-balloon.c used it to find some microblaze memory bugs previously | 13:24 |
rburton | that saves ten minutes thanks | 13:25 |
nrossi | rburton: if i remember correctly they were highmem bugs as well :| | 13:25 |
nrossi | RP: this look like a ok implementation for keepalive messages? https://github.com/nathanrossi/openembedded-core/commit/39ccda0852f3e286693afcba2098f15bba6b50e4 | 13:26 |
*** nabokov <nabokov!~armand@67.218.223.154> has quit IRC | 13:27 | |
kayterina | in my-machine.conf I add: APPEND += "lpj=192000" .and it does nothing to cmdline.txt., anyone know why? | 13:27 |
RP | nrossi: yes, looks good at a quick glance | 13:27 |
*** nabokov <nabokov!~armand@67.218.223.154> has joined #yocto | 13:27 | |
*** nabokov <nabokov!~armand@67.218.223.154> has quit IRC | 13:28 | |
RP | zeddii: its in systemtap master | 13:28 |
zeddii | commit a25199c9580b9b66424c494d3bf39c4d1b7e1f7b (HEAD -> master, origin/master, origin/HEAD) | 13:28 |
zeddii | Author: Richard Purdie <richard.purdie@linuxfoundation.org> | 13:28 |
zeddii | Date: Thu Sep 5 09:13:13 2019 -0400 | 13:28 |
zeddii | these folks need a hobby ;) | 13:29 |
*** bisbarn <bisbarn!~bisbarn@edge1.crosscan.com> has quit IRC | 13:29 | |
rburton | nrossi: in return my random layer is rossburton/meta-ross on github :) | 13:31 |
nrossi | rburton: its got unigine.... :) | 13:32 |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 13:32 | |
khem | rburton:secondly do we have CONFIG_NO_BOOTMEM set in kernel | 13:34 |
rburton | $ git grep NO_BOOTMEM|wc -l | 13:35 |
rburton | 0 | 13:35 |
kanavin_ | rburton, core-image-sato got bumped to 512M because on qemux86-64 X would otherwise fail to start | 13:35 |
rburton | (linux-yocto, so i'm grepping yocto-kernel-cache) | 13:36 |
rburton | kanavin_: maybe thats a x86-64 specific thing and we should just bump that machine? | 13:36 |
kanavin_ | rburton, I would rather bump mips down to 256M actually | 13:37 |
kanavin_ | because it is not using GL | 13:37 |
kanavin_ | and thus doesn't actually need that extra RAM | 13:37 |
rburton | just mips specifically | 13:37 |
rburton | ? | 13:37 |
kanavin_ | yes - qemumips still defaults to cirrus hardware, and who am I to argue against that :) | 13:38 |
rburton | we can fix that :) | 13:38 |
kanavin_ | rburton, it wasn't obvious to me, but various qemu-system targets have totally different lists of what graphical hardware they can emulate, and what is the default choice in those lists | 13:38 |
rburton | yes | 13:39 |
rburton | virtio *should* work but would need turning on and testing in qemu | 13:39 |
kanavin_ | so even if you drop -vga cirrus for qemu mips, it will still use it :) | 13:39 |
kanavin_ | virtio is not in the list for mips from what I recall | 13:39 |
rburton | right this is roughly where i got to when exploring this a while back | 13:40 |
rburton | at some point you reach 'nobody has tried this, but it should work...' | 13:40 |
kanavin_ | I'd suggest just bumping RAM down for mips :-/ | 13:40 |
kanavin_ | if we can't get to the bottom of 512M issues | 13:40 |
rburton | 1) bump ram back down 2) investigate memory issue | 13:40 |
rburton | so at least we can ship | 13:40 |
* zeddii knows where his vote would land | 13:41 | |
rburton | oh i meant both in order | 13:41 |
rburton | drop the memory as its not needed, and look to see if fixing the memory thing is easy for later | 13:41 |
RP | rburton: I'm leaning to dropping the ram for mips so we can move forward | 13:42 |
zeddii | you needed to put 3) all of the above, to keep some of us from taking the easy way out :D | 13:42 |
rburton | haha | 13:42 |
kanavin_ | the alternative is to bump RAM up only for x86(64) and see if any other target breaks like x86 did | 13:42 |
rburton | i'm happy with marking mips as special here | 13:43 |
kanavin_ | rburton, alexander@alexander-box:~/development/poky/build-virgl-gtk-64/tmp$ ./work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/qemu-system-mips64 -vga help | 13:44 |
kanavin_ | none no graphic card | 13:44 |
kanavin_ | std standard VGA | 13:44 |
kanavin_ | cirrus Cirrus VGA (default) | 13:44 |
kanavin_ | vmware VMWare SVGA | 13:44 |
kanavin_ | xenfb Xen paravirtualized framebuffer | 13:44 |
kanavin_ | (same for mips 32) | 13:44 |
rburton | kanavin_: yeah, there's a load of kconfig pieces in qemu, need to turn the virtio bits on | 13:44 |
kanavin_ | rburton, I am not sure if that can be configured at all, I believe it is hardcoded | 13:45 |
kanavin_ | for comparison alexander@alexander-box:~/development/poky/build-virgl-gtk-64/tmp$ ./work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/qemu-system-x86_64 -vga help | 13:45 |
kanavin_ | none no graphic card | 13:45 |
kanavin_ | std standard VGA (default) | 13:45 |
kanavin_ | cirrus Cirrus VGA | 13:45 |
kanavin_ | vmware VMWare SVGA | 13:45 |
nrossi | RP: just sent those patches for -initial cleanup, security flags and oe-selftest keepalive | 13:45 |
kanavin_ | xenfb Xen paravirtualized framebuffer | 13:45 |
kanavin_ | virtio Virtio VGA | 13:45 |
RP | nrossi: thanks. There was one other issue I noticed, the glibc-testsuite recipe breaks the source archiver :/ | 13:54 |
RP | nrossi: https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/685 | 13:55 |
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 13:56 | |
nrossi | RP: will have a look | 13:56 |
*** jofr <jofr!~jofr@193.182.166.3> has quit IRC | 13:57 | |
*** jofr <jofr!~jofr@193.182.166.3> has joined #yocto | 13:57 | |
RP | nrossi: a quick guess says PACKAGES = "" may "fix" it | 13:57 |
RP | nrossi: sorry, I'm kind of thiniking out loud | 13:58 |
RP | nrossi: I'll throw that into the recipe for the next set of tests | 13:58 |
nrossi | RP: makes you wonder if nopackages should set PACKAGES = "" | 14:02 |
RP | nrossi: actually, I think archiver should test for the existence of the task | 14:03 |
RP | nrossi: we were trying to get away from the zeroing of PACKAGES as that can have unintended side effects | 14:03 |
RP | In this recipe it doesn't matter | 14:03 |
nrossi | RP: ok, I will look at adding the check, you go ahead with ""ing | 14:04 |
RP | nrossi: thanks | 14:04 |
RP | nrossi: error: argument -r/--run-tests: not allowed with argument -t/--run-only-tags | 14:07 |
RP | nrossi: can we change that? I think the autobuilder will need to do that :/ | 14:07 |
*** likewise <likewise!~leon@213.34.54.210> has quit IRC | 14:07 | |
nrossi | RP: aka mixing tags and specific tests? | 14:08 |
RP | nrossi: yes | 14:08 |
nrossi | RP: would have to make -t as option instead | 14:08 |
nrossi | RP: aka -t <foo> -t <bar> | 14:08 |
RP | nrossi: so be it, we're going to need to be able to list specific tests to exclude | 14:09 |
nrossi | RP: so i should make the -T the same as well? | 14:09 |
RP | e.g. -T machine -R sourcemirror test | 14:10 |
RP | nrossi: please | 14:10 |
*** yacar_ <yacar_!~yacar@80.215.195.222> has quit IRC | 14:16 | |
RP | nrossi: just realised that if I tag the tests we include/exclude I could avoid having to use -R and use -T/-t instead | 14:17 |
RP | nrossi: may still be better to allow the combinations though | 14:17 |
nrossi | RP: you can just use "-a -T ..." :) | 14:18 |
RP | nrossi: I'm puzzled where these ptestresults are disappearing | 14:19 |
RP | nrossi: I see them locally | 14:19 |
*** griffinp <griffinp!griffinp@gateway/shell/linaro/x-glcajiuzjrhmniyg> has joined #yocto | 14:27 | |
*** vmeson <vmeson!~rmacleod@128.224.252.2> has quit IRC | 14:31 | |
nrossi | RP: I did initially think it might have something to do with the fact that the tests are now "passing" | 14:33 |
nrossi | RP: archiver fix patch sent | 14:42 |
*** yacar_ <yacar_!~yacar@80.215.203.171> has joined #yocto | 14:52 | |
*** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 14:55 | |
Crofton|work | RP, https://twitter.com/nixcraft/status/1169570226221961217?s=20 | 15:02 |
*** frsc <frsc!~frsc@200116b824d1b50049623ff52895edd0.dip.versatel-1u1.de> has quit IRC | 15:05 | |
smurray | I hit fetcher failures with libedit trying to build world on latest master last night, anyone else see that | 15:13 |
smurray | error is: ERROR: libedit-20190324-3.1-r0 do_fetch: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; unset _PYTHON_SYSCONFIGDATA_NAME; export PATH="/ws/scottm/dev/oe/test.systemd/test/tmp/sysroots-uni: /bin/sh: 1: -U: not found | 15:13 |
smurray | almost looks like it happens because it falls back to trying a mirror because upstream is unavailable | 15:15 |
smurray | ah, no, it's FETCHCMD_wget tinkering seems wrong. Now I'm confused as to how it worked previously | 15:19 |
RP | nrossi: it breaks for oe-selftest -j X | 15:21 |
RP | nrossi: i.e. when we enable paralleliam | 15:21 |
nrossi | RP: what breaks? the keepalive? | 15:22 |
RP | nrossi: the reason the ptestresults don't make the json file | 15:24 |
RP | nrossi: I've proven it locally | 15:25 |
nrossi | RP: ah that explains why i never saw it. Do you know if its a general issue with how tc.extra is accessed or specific to how the toolchain cases populate it? | 15:25 |
RP | nrossi: probably related to how tc.extra is processed | 15:26 |
RP | nrossi: selftest doesn't usually add ptest results until now and runtime never uses -j | 15:26 |
RP | nrossi: I've not looked at why yet but at least we now know how to reproduce | 15:27 |
nrossi | RP: I wont be able to look at it today, will look at it tomorrow along with -t/-T changes | 15:29 |
RP | nrossi: no problem, thanks for the heads up. I'll let you know if I've looked at it | 15:30 |
* RP isn't sure how much of a chance he'll get | 15:31 | |
rburton | smurray: delete the tinkering (patch on the list) | 15:33 |
*** berton_ <berton_!~berton@181.220.83.67> has joined #yocto | 15:33 | |
*** xtron <xtron!~xtron@110.93.212.98> has quit IRC | 15:34 | |
smurray | rburton: ah, I did a quick look, missed | 15:34 |
smurray | rburton: it's not clear to me how that worked before, given the way FETCHCMD_wget is used | 15:36 |
*** berton <berton!~berton@181.220.83.67> has quit IRC | 15:36 | |
*** kaspter <kaspter!~Instantbi@2409:8928:64e:1680:545a:12f3:1e8b:5f80> has joined #yocto | 15:48 | |
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 15:52 | |
*** kaspter <kaspter!~Instantbi@2409:8928:64e:1680:545a:12f3:1e8b:5f80> has quit IRC | 15:53 | |
*** yacar_ <yacar_!~yacar@80.215.203.171> has quit IRC | 15:55 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:07 | |
kergoth | huh, vscode with Remote - SSH is pretty nice, even with bitbake stuff | 16:07 |
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:10 | |
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 16:10 | |
*** kaspter <kaspter!~Instantbi@2409:8928:64e:1680:545a:12f3:1e8b:5f80> has joined #yocto | 16:13 | |
*** yann <yann!~yann@85.118.38.73> has quit IRC | 16:15 | |
rburton | kergoth: yeah tried it yesterday | 16:16 |
rburton | presumably the git stuff all works too | 16:16 |
rburton | haven't yet tried that | 16:16 |
rburton | is there a proper bitbake extension yet that does more than just syntax highlighting? | 16:17 |
kergoth | it does, though can get a little slow and can run into inotify limits on file monitoring | 16:17 |
kergoth | good question | 16:17 |
rburton | right, had to bump the inotify limit already | 16:17 |
kergoth | huh, ctrl+click will open an included/inherited/reuiqred file, and ctrl+space will complete inherit/etc, it seems? | 16:19 |
kergoth | in the most popular bitbake extension | 16:19 |
* kergoth tries ti | 16:19 | |
rburton | holy crap | 16:22 |
rburton | thats witchcraft | 16:22 |
*** mckoan is now known as mckoan|away | 16:27 | |
*** aehs29 <aehs29!~aehs29@149.199.62.129> has quit IRC | 16:35 | |
*** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC | 16:36 | |
*** aehs29 <aehs29!~aehs29@149.199.62.131> has joined #yocto | 16:39 | |
tgoodwin | I'm trying to run bitbake in a container drived from CROPS/poky:ubuntu-18.04 via gitlab-ci and am running a sanity check "bitbake -n world", but bitbake fails parsing serf no matter which branch of poky I use. Has anyone ever seen that? | 16:48 |
Crofton|work | perf? | 16:49 |
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 16:49 | |
smurray | heh, that was my first thought. Seems there's a serf recipe | 16:49 |
Crofton|work | vscode? | 16:49 |
smurray | "High-Performance Asynchronous HTTP Client Library" | 16:50 |
smurray | it looks to be the only thing that uses the scons.bbclass | 16:50 |
tgoodwin | smurray: yes, it's over in recipes-support/serf | 16:50 |
Crofton|work | and depends on py and py3 versions | 16:50 |
smurray | Crofton|work: ? not in master afaics | 16:51 |
Crofton|work | http://layers.openembedded.org/layerindex/recipe/28439/ | 16:51 |
Crofton|work | weird | 16:52 |
smurray | Crofton|work: I can't see how that can be correct, neither the recipe nor scons.bbclass refer to python-scons-native | 16:52 |
smurray | Crofton|work: and it built for me when I tested last week in a container w/o python2 | 16:53 |
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 16:53 | |
smurray | tgoodwin: can you pastebin the parse error? | 16:53 |
tgoodwin | smurray: sure; https://pastebin.com/uweLnrmK | 16:54 |
smurray | Crofton|work: heh, subversion requires serf | 16:54 |
smurray | tgoodwin: which branch was that from? | 16:55 |
smurray | tgoodwin: warrior, I'm guessing? | 16:56 |
tgoodwin | smurray: that one was master. I've tried thud; it dies in the same spot. | 16:58 |
smurray | tgoodwin: I'd have to guess you've maybe set PARALLEL_MAKE or the like? | 16:58 |
tgoodwin | smurray: yes | 16:58 |
smurray | tgoodwin: can't have been master, it does not have anything to muck with -j that I can see in scons.bbclass | 16:58 |
smurray | the do_compile in the serf recipe in warrior does, though | 16:59 |
tgoodwin | When I run this outside of the gitlab-runner environment, it's fine... Weird. | 17:00 |
smurray | tgoodwin: are you trying to set PARALLEL_MAKE globally, or BB_NUMBER_THREADS? | 17:01 |
tgoodwin | smurray: both, globally | 17:01 |
tgoodwin | in an auto.conf | 17:01 |
smurray | tgoodwin: hrm, you shouldn't need to change PARALLEL_MAKE afaik | 17:01 |
smurray | ah, there is a use of PARALLEL_MAKE in scons.bbclass in master, missed it the first time I looked | 17:03 |
Crofton|work | is the use of subversion my fault? | 17:03 |
tgoodwin | smurray: I'm porting over a build from the autobuilder2 setup where the default sets both values; I can remove them. I think I just found a typo actually in PARALLEL_MAKE. | 17:03 |
RP | tgoodwin: you're moving from ab-2 to gitlab-ci? | 17:03 |
smurray | Crofton|work: no, just amuses me that library is included just for subversion | 17:03 |
smurray | tgoodwin: it does look like a quoting issue or the like | 17:04 |
tgoodwin | RP: testing it out; we use it for everything else. | 17:04 |
RP | tgoodwin: fair enough, just curious | 17:04 |
RP | rburton: second mention of gitlab today... | 17:04 |
tgoodwin | smurray: I was missing a trailing } in PARALLEL_MAKE = "-j ${BB_NUMBER_THREADS" | 17:04 |
Crofton|work | heh | 17:04 |
tgoodwin | That fixed it. | 17:05 |
* tgoodwin doh! | 17:05 | |
tgoodwin | Thanks y'all. | 17:05 |
smurray | all good | 17:05 |
Crofton|work | people like to minimize the number of tools used. Why I use git submodules for layer management, not perfect, but I alady know 90% of what I need to know | 17:05 |
Crofton|work | fascinating error for that case :) | 17:05 |
smurray | Crofton|work: heh, I always have to do "git submodule --help" | 17:05 |
kergoth | when i use submodules, i also use 'mr' to avoid using submodule commands more often than not | 17:06 |
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has joined #yocto | 17:11 | |
tgoodwin | RP: depending on how this works out, I'll probably post how to do it. I patched the crops/poky container builds (on my end) to allow for scripts to be passed as arguments (making it compatible with Docker's ENTRYPOINT needs with the runner). Then the gitlab docker runner, it has a volume mount to the output shared directory for sstate, etc. and am using "cache" between jobs to pass what few artifacts we need (build/conf | 17:12 |
tgoodwin | and layers). | 17:12 |
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 17:13 | |
tgoodwin | The frustrating part of it so far is not being able to use cache at the local workstation to test each stage. | 17:13 |
tgoodwin | At this point though it's running into the same mechanical problems as AB2's helper. | 17:13 |
tgoodwin | (our problems, obviously, because of what we're trying to accomplish) | 17:18 |
*** kaspter <kaspter!~Instantbi@2409:8928:64e:1680:545a:12f3:1e8b:5f80> has quit IRC | 17:27 | |
rburton | RP: i've got travis doing dumb ci for meta-acrn, it's just a parse and dry-run build but that's better than nothing | 18:23 |
rburton | (on the free travis plan) | 18:23 |
rburton | next step is to run a container here and get it doing actual builds | 18:23 |
rburton | obviously just a very quick smoketest, but again better than nothing | 18:26 |
rburton | for meta-acrn we've a nice small subset that we care about | 18:26 |
*** berton_ <berton_!~berton@181.220.83.67> has quit IRC | 18:54 | |
*** berton <berton!~berton@181.220.83.67> has joined #yocto | 18:58 | |
khem | rburton: I use drone.io and have put in for meta-clang | 18:59 |
khem | works nicely, its all docker based flow as well, even drone.io runs on docker itself | 18:59 |
khem | so my server can be torn and rebuilt in mins | 19:00 |
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> | 19:17 |
*** berton <berton!~berton@181.220.83.67> has quit IRC | 19:40 | |
*** berton <berton!~berton@181.220.83.67> has joined #yocto | 19:45 | |
*** armpit <armpit!~armpit@2601:202:4180:c33:811a:fbd5:24bc:2160> has quit IRC | 19:49 | |
*** armpit <armpit!~armpit@2601:202:4180:c33:1428:d184:917c:1fd5> has joined #yocto | 20:01 | |
*** sa2ajj <sa2ajj!~quassel@dsl-hkibng21-54f86f-36.dhcp.inet.fi> has quit IRC | 20:07 | |
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC | 20:13 | |
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 20:17 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 20:17 | |
*** rewitt <rewitt!rewitt@nat/intel/x-hrzfvohlnvxyqomo> has joined #yocto | 20:29 | |
*** JPEW <JPEW!~JPEW@2600:1f16:181:f300:d350:982:b6f5:216c> has quit IRC | 20:46 | |
*** JPEW <JPEW!~JPEW@2600:1f16:181:f300:d350:982:b6f5:216c> has joined #yocto | 20:47 | |
*** zbooth <zbooth!~zbooth@2600:1f16:181:f300:d350:982:b6f5:216c> has joined #yocto | 20:52 | |
*** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto | 20:54 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 20:57 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 20:59 | |
*** berton <berton!~berton@181.220.83.67> has quit IRC | 21:15 | |
yocti | New news from stackoverflow: YOCTO : remove all my led drivers from my yocto linux os image <https://stackoverflow.com/questions/57812953/yocto-remove-all-my-led-drivers-from-my-yocto-linux-os-image> | 21:17 |
*** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has joined #yocto | 21:20 | |
RP | tgoodwin: definitely worth posting about, I'm curious | 21:21 |
RP | rburton: makes sense | 21:22 |
rburton | khem: can you share your setup for that? | 21:49 |
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 21:55 | |
*** diego_r <diego_r!~diego@81.29.205.101> has quit IRC | 21:56 | |
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 22:26 | |
rburton | zeddii: can i blame you for https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/341/steps/8/logs/step1c | 23:09 |
zeddii | not easily. :D this is the kernel module test that marka from wind river is trying to replace. | 23:10 |
zeddii | out of tree modules build fine. that one just has some sort of config issues that Mark was describing. | 23:10 |
zeddii | but I can check to see if something it requires is not removed, renamed or just gone. | 23:11 |
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC | 23:24 | |
*** stephano <stephano!~stephano@2620:10d:c090:380::1:132d> has joined #yocto | 23:27 | |
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC | 23:38 | |
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 23:40 | |
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 23:51 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!