*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto | 00:08 | |
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 245 seconds) | 00:17 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 01:03 | |
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 01:14 | |
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 01:20 | |
*** RobertBerger <RobertBerger!~rber|res@185-232-103-115.xdsl.philuweb.net> has joined #yocto | 01:32 | |
*** rber|res <rber|res!~rber|res@185-232-103-115.xdsl.philuweb.net> has quit IRC (Ping timeout: 252 seconds) | 01:34 | |
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 01:49 | |
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto | 02:14 | |
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 245 seconds) | 02:21 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…) | 03:26 | |
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto | 04:18 | |
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 245 seconds) | 04:27 | |
*** amitk <amitk!~amit@103.208.71.87> has joined #yocto | 04:30 | |
*** mischief1 <mischief1!~mischief@wopr.sciops.net> has quit IRC (*.net *.split) | 04:36 | |
*** ykrons_ <ykrons_!~guillaume@62.192.23.101> has quit IRC (*.net *.split) | 04:36 | |
*** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has quit IRC (*.net *.split) | 04:36 | |
*** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has quit IRC (*.net *.split) | 04:36 | |
*** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has joined #yocto | 04:36 | |
*** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has joined #yocto | 04:37 | |
*** ykrons_ <ykrons_!~guillaume@62.192.23.101> has joined #yocto | 04:37 | |
*** mischief1 <mischief1!~mischief@wopr.sciops.net> has joined #yocto | 04:37 | |
*** mcfrisk <mcfrisk!mcfrisk@kapsi.fi> has quit IRC (*.net *.split) | 04:41 | |
*** zbr <zbr!zibri@shell.x20.se> has quit IRC (*.net *.split) | 04:41 | |
*** zibri <zibri!zibri@shell.x20.se> has joined #yocto | 04:41 | |
*** mcfrisk <mcfrisk!mcfrisk@kapsi.fi> has joined #yocto | 04:41 | |
*** smurray <smurray!sid98062@stonehaven.irccloud.com> has quit IRC (*.net *.split) | 04:57 | |
*** darknighte <darknighte!sid214177@user/darknighte> has quit IRC (*.net *.split) | 04:57 | |
*** mckoan|away <mckoan|away!~marco@host-79-3-92-72.business.telecomitalia.it> has quit IRC (*.net *.split) | 04:57 | |
*** Chaser <Chaser!~Chaser@user/chaser> has quit IRC (*.net *.split) | 04:57 | |
*** r4ge <r4ge!~timp@114-134-7-183.static.lightwire.co.nz> has quit IRC (*.net *.split) | 04:57 | |
*** beneth <beneth!~beneth@ip208.ip-54-36-198.eu> has quit IRC (*.net *.split) | 04:57 | |
*** chrysh <chrysh!~chrysh@someserver.de> has quit IRC (*.net *.split) | 04:57 | |
*** mfe <mfe!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has quit IRC (*.net *.split) | 04:57 | |
*** michaelo <michaelo!~mike@shells.bootlin.com> has quit IRC (*.net *.split) | 04:57 | |
*** mckoan|away <mckoan|away!~marco@host-79-3-92-72.business.telecomitalia.it> has joined #yocto | 04:57 | |
*** chrysh <chrysh!~chrysh@someserver.de> has joined #yocto | 04:57 | |
*** michaelo <michaelo!~mike@shells.bootlin.com> has joined #yocto | 04:57 | |
*** r4ge <r4ge!~timp@114-134-7-183.static.lightwire.co.nz> has joined #yocto | 04:57 | |
*** smurray <smurray!sid98062@id-98062.stonehaven.irccloud.com> has joined #yocto | 04:57 | |
*** mfe <mfe!~marc@ipagstaticip-ad9375f2-382c-b511-8ac1-9541f69fe50f.sdsl.bell.ca> has joined #yocto | 04:57 | |
*** darknighte <darknighte!sid214177@id-214177.stonehaven.irccloud.com> has joined #yocto | 04:58 | |
*** Chaser <Chaser!~Chaser@user/chaser> has joined #yocto | 04:59 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 05:53 | |
*** creich_ <creich_!~creich@p200300f6af1b6910676a437eca11f5a9.dip0.t-ipconnect.de> has joined #yocto | 06:09 | |
*** creich <creich!~creich@p200300f6af1cc310000000000000039b.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 245 seconds) | 06:10 | |
*** tgamblin_ <tgamblin_!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has joined #yocto | 06:14 | |
user_ | https://pastebin.com/xKsHDJJB can anyone help me resolving this error,iam trying to build a multimedia image with multilib support | 06:15 |
---|---|---|
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has quit IRC (Ping timeout: 250 seconds) | 06:16 | |
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto | 06:24 | |
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 252 seconds) | 06:32 | |
*** mckoan|away is now known as mckoan | 06:36 | |
*** frieder <frieder!~frieder@mue-88-130-75-072.dsl.tropolys.de> has joined #yocto | 06:36 | |
mckoan | good morning | 06:36 |
*** Guest9959 <Guest9959!~Guest99@host-79-3-92-72.business.telecomitalia.it> has joined #yocto | 06:50 | |
*** Guest9959 <Guest9959!~Guest99@host-79-3-92-72.business.telecomitalia.it> has quit IRC (Client Quit) | 06:53 | |
*** zpfvo <zpfvo!~fvo@88.130.221.206> has joined #yocto | 06:55 | |
*** user_ is now known as user_123 | 06:56 | |
user_123 | Hi | 06:56 |
user_123 | I need to enable multilib support in My yoctobuild | 06:56 |
*** creich_ <creich_!~creich@p200300f6af1b6910676a437eca11f5a9.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving) | 06:57 | |
*** creich <creich!~creich@p200300f6af1b6910676a437eca11f5a9.dip0.t-ipconnect.de> has joined #yocto | 06:57 | |
user_123 | I am getting errors when local.conf is modified as suggested by NXP | 06:57 |
user_123 | https://pastebin.com/xKsHDJJB i added the error log | 06:58 |
*** zyga-mbp <zyga-mbp!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 06:58 | |
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 06:58 | |
mckoan | user_123: no clue. Maybe describe what you are doing | 06:58 |
user_123 | I am running bitbake imx-image-multimedia | 06:59 |
user_123 | I am getting errors | 06:59 |
user_123 | Please see https://pastebin.com/xKsHDJJB | 07:00 |
user_123 | For error log | 07:00 |
RP | user_123: it is really hard to know what the problem is there. If this has the freescale layer involved you probably need to ask NXP as that layer changes a lot. Have you tried to do this with just plain poky? | 07:07 |
user_123 | RP: no, i have not tried with plain poky | 07:21 |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 07:23 | |
*** Guest39 <Guest39!~Guest39@145.253.222.69> has joined #yocto | 07:23 | |
Guest39 | Hi, I have a problem with the Freescale ethernet driver, likely dpaa_eth.c. Sometimes I see rotten packets which are not dropped but handled much too late, and such packets have a hardware timestamp in the future then. Is any developer here who wants to see the wireshark recording? I use dunfell for imx8 with a Linux kernel of one year ago. | 07:35 |
qschulz | Guest39: if it's a HW timestamp, i'm pretty sure it's not an issue with Yocto? so might want to contact your vendor (NXP or the OEM using NXP SoCs and/or the one selling the Ethernet PHY) | 07:42 |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 07:42 | |
Guest39 | I measure with tcpdump -i eth0 --time-stamp-precision=nano --time-stamp-type=adapter_unsynced ... and I think this switches HW timestamps on. | 07:48 |
Guest39 | Anyway this is how I understand the tcpdump options | 07:49 |
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 256 seconds) | 08:01 | |
*** Xagen <Xagen!~Xagen@2600:1700:211:7e60:5014:2675:6930:a231> has quit IRC (Ping timeout: 245 seconds) | 08:09 | |
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto | 08:12 | |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 08:12 | |
mckoan | Guest39: 99% HW issue | 08:20 |
*** zyga-mbp <zyga-mbp!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has quit IRC (Read error: Connection reset by peer) | 08:21 | |
*** zyga-mbp <zyga-mbp!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 08:22 | |
Guest39 | Is it the PHY which sets HW timestamps on an imx8? | 08:24 |
qschulz | Guest39: I doubt there's an Ethernet PHY embedded in the i.MX8 so it depends on the board you're using | 08:25 |
qschulz | your PHY needs to support it, and the driver driving your PHY needs to support it too | 08:25 |
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto | 08:29 | |
kanavin | RP: I have reproduced https://bugzilla.yoctoproject.org/show_bug.cgi?id=14342#c20 with master (Setscene tasks in both covered and notcovered errors at the end of build) | 08:35 |
kanavin | RP: can you suggest where I could start with figuring out what goes wrong there? | 08:35 |
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 265 seconds) | 08:37 | |
RP | kanavin: you can look at the patches I previously added to runqueue around this area. Oddly enough I was planning to take a look at that again today | 08:41 |
RP | kanavin: there isn't a simple/easy way to even explain where to start on that one :/ | 08:42 |
kanavin | RP: right, if you do that'd be appreciated - a customer is asking me to prioritize this, but I have no idea where to start without a bit of help from you | 08:42 |
kanavin | RP: but it does reproduce fairly easily, so hopefully that helps you | 08:42 |
RP | kanavin: there is a logic glitch somewhere. A task should never be both covered and notcovered, it should be one or the other | 08:43 |
RP | kanavin: the question is therefore which codepath ends up with an item on both | 08:43 |
RP | kanavin: which reproducer did you use? | 08:43 |
kanavin | RP: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14342#c20 | 08:43 |
kanavin | one in that last comment | 08:44 |
RP | ok, the new one. I've not tried that | 08:44 |
RP | kanavin: I think something in the last patches I merged "regressed" this. Would be interesting to know if this test case worked before that set of patches | 08:48 |
kanavin | RP: I can try if you point me to suspected good commit | 08:49 |
RP | kanavin: I say "regressed" as there is a lot I like about that last patchset, so it is a question of trying to fix whatever cornercase broke rather than revert it | 08:49 |
RP | kanavin: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a15eea5077506111e4167a2361da0306d23543f3 | 08:50 |
*** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 08:52 | |
RP | kanavin: basically revert that, I was thinking it was a set but I think it was just the one | 08:53 |
*** SamuelDolt[m] <SamuelDolt[m]!~samdoltma@2001:470:69fc:105::4898> has quit IRC (Quit: You have been kicked for being idle) | 09:00 | |
kanavin | RP: will run before&after test on that now | 09:00 |
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 09:04 | |
*** bps <bps!~bps@user/bps> has quit IRC (Remote host closed the connection) | 09:16 | |
*** zyga-mbp <zyga-mbp!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has quit IRC (Read error: Connection reset by peer) | 09:29 | |
*** zyga <zyga!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 09:29 | |
kanavin | RP: yes, that is the offending commit | 09:34 |
RP | kanavin: I can confirm it does reproduce here too | 09:44 |
*** obcecado <obcecado!pcaetano@tilde.institute> has quit IRC (Quit: leaving) | 09:46 | |
kanavin | RP: and gone with the revert | 09:47 |
RP | kanavin: right :/ | 09:50 |
RP | kanavin: although it does always print about deadlock first so I think the bug may be that the deadlock code adds to both covered and not covered | 09:51 |
RP | kanavin: so two issues: a) why does it deadlock and should it? b) does the deadlock code do something incorrectly | 09:52 |
kanavin | RP: even before it prints about deferring (and does not with the revert), so I'm not sure if that is an issue too | 09:52 |
RP | kanavin: The deferring would be expected for builds with multiple similar tasks | 09:53 |
wCPO | Is there any convention for where to put recipe? recipes-foo/foo ? | 09:55 |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 09:56 | |
kanavin | wCPO, recipes-domain/foo | 09:56 |
rburton | wCPO: your layer, so you get to define the recipes-* namespaces | 09:56 |
wCPO | kanavin, rburton: naming is always hard :) I will try to stick with recipes-domain/foo | 09:59 |
rburton | your layer will basically enforce that unless you change layer.conf | 09:59 |
RP | kanavin: I think if setscene is present, tasks in the deferred list aren't being made available. The logs are odd | 10:00 |
*** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has quit IRC (Ping timeout: 252 seconds) | 10:04 | |
*** derRichard <derRichard!~derRichar@static.16.105.130.94.clients.your-server.de> has quit IRC (Ping timeout: 245 seconds) | 10:04 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:18 | |
*** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 10:22 | |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 10:27 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 265 seconds) | 10:33 | |
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto | 10:34 | |
*** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has joined #yocto | 10:34 | |
*** derRichard <derRichard!~derRichar@static.16.105.130.94.clients.your-server.de> has joined #yocto | 10:35 | |
RP | kanavin: I think http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=1cd2b6defa1e77d84cb268571edc1cacf9b57cd1 is a decent workaround | 10:39 |
RP | kanavin: I'm still not quite show whether there is a better fix for this | 10:39 |
wCPO | Is there any reason for some recipe using not following the "Packages should install their configuration files in /usr/lib/tmpfiles.d." convention for tmpfiles.d? (connman, cups, bind) | 10:40 |
RP | wCPO: where is that a quote from? | 10:41 |
wCPO | RP: the manpage: https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html . It is the same for systemd service file | 10:41 |
RP | wCPO: I suspect the guidance from systemd has changed over time and the recipes aren't keeping up | 10:42 |
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 260 seconds) | 10:42 | |
wCPO | RP: I see. I'm coming from Arch Linux where packages must never install anything into /etc/tmpfiles.d or /etc/systemd/system, so just wanted to know if the recipe was out-of-date or I missed something :) | 10:43 |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:45 | |
rburton | wCPO: if the bug is in the recipe itself, send a patch, otherwise send a bug report/patch upstream | 10:50 |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 252 seconds) | 10:51 | |
kanavin | RP: sleep on it? | 10:54 |
RP | kanavin: I'm staring at the code a bit. There is something just slightly out of reach with regard to fixing this | 10:54 |
frosteyes1 | Hi folks. I just have an interresting issue while trying to upgrade poky / dunfell on a platform I am working with. The issue is a permission issue. | 10:56 |
frosteyes1 | The issue is this - Exception: bb.process.ExecutionError: Execution of '/builds/x/x/x/x/build/tmp/work/x/x/1.0-r0/temp/run.reproducible_final_image_task.34850' failed with exit code 123: | 10:57 |
frosteyes1 | With a bunch of Exception: bb.process.ExecutionError: Execution of '/builds/x/x/x/x/build/tmp/work/x/x/1.0-r0/temp/run.reproducible_final_image_task.34850' failed with exit code 123: | 10:57 |
frosteyes1 | For the different license files. | 10:57 |
frosteyes1 | Notice it is not an issue when building local - but it is an issue when building on our build server. | 10:58 |
frosteyes1 | As it was working with the older dunfell release, I have looked into what have changed and found this one liner.. | 10:59 |
mihai | frosteyes1: check the equivalent log file log.reproducible_final... | 11:00 |
*** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has joined #yocto | 11:01 | |
mihai | exit code 123 smells like pseudo abort | 11:01 |
frosteyes1 | https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg148651.html | 11:01 |
frosteyes1 | mihai: thanks. | 11:02 |
frosteyes1 | The commit I linked to was a change from using a single process with find to touch the files, to now using a pipe with xargs and touch. | 11:02 |
frosteyes1 | So was wandering if this change also changed how interitance of permission for the touch process with regards to fakeroot / pseudo.. | 11:04 |
*** frosteyes1 is now known as frosteyes | 11:04 | |
mihai | or arguments list too long | 11:09 |
frosteyes | Good point.. | 11:09 |
RP | kanavin: two patches sent to the bitbake list which I think should resolve this | 11:16 |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 11:29 | |
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto | 11:30 | |
*** TrevorWoerner[m] <TrevorWoerner[m]!~trevorwoe@2001:470:69fc:105::4e57> has joined #yocto | 11:45 | |
*** beneth <beneth!~beneth@2001:41d0:c:a71:1000:25::> has joined #yocto | 12:02 | |
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Remote host closed the connection) | 12:11 | |
*** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto | 12:11 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 12:17 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 12:19 | |
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:9c94:7807:4c0c:960> has joined #yocto | 12:19 | |
*** andy99 <andy99!~andy@165.225.26.249> has joined #yocto | 12:23 | |
*** TrevorWoerner[m] <TrevorWoerner[m]!~trevorwoe@2001:470:69fc:105::4e57> has left #yocto | 12:23 | |
*** xicopitz[m] <xicopitz[m]!~xicopitzm@2001:470:69fc:105::4869> has joined #yocto | 12:24 | |
andy99 | Hello everyone. can I ask you a question about the kernel-fitimage? | 12:25 |
mihai | andy99: don't ask to ask, just ask :) | 12:28 |
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 12:28 | |
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 12:28 | |
*** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 12:29 | |
andy99 | :) ok, so ... what's the current status of usage kernel-fitimage including initrams? Why is not part of rootfs? Or even better, how to get the image into rootfs? | 12:30 |
*** tgamblin_ <tgamblin_!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has quit IRC (Quit: Leaving) | 12:32 | |
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has joined #yocto | 12:33 | |
Guest39 | andy99: Is kernel-fitimage one of the available initramfs image types? | 12:35 |
andy99 | I think so, because it's being produced into deploydir but not into rootfs | 12:36 |
Guest39 | andy99: The initramfs is an image which will be bundled to the kernel image | 12:37 |
andy99 | yes, and the kernel is deployed into deploydir instead of rootfs | 12:37 |
Guest39 | andy99: The kernel is a file in the boot partition. When the kernel starts as a process it loads the initramfs from its appendix on the kernel image. After the initramfs is loaded a script in the initramfs will load the rootfs. Usually the rootfs is located in another partition. | 12:40 |
andy99 | I think, that I know, how the initramfs works :). The main problem is, that this type of image is created after packing, so it's not inside any package. So it can't be installed. | 12:41 |
Guest39 | andy99: So I suppose your problem is the initramfs is not bundled to the kernel image, right? | 12:42 |
Guest39 | andy99: I don't know if that helps for you since I use core-image-tiny-imageramfs but maybe you can adapt my .conf file: | 12:46 |
Guest39 | INITRAMFS_IMAGE = "core-image-tiny-initramfs" | 12:47 |
Guest39 | INITRAMFS_IMAGE_BUNDLE = "1" | 12:47 |
Guest39 | INITRAMFS_KERNEL_IMAGE="${KERNEL_IMAGETYPE}-initramfs-${MACHINE}.bin" | 12:47 |
andy99 | no, initramfs is created, but not inside the pckage | 12:47 |
Guest39 | VIRTUAL-RUNTIME_dev_manager = "busybox-mdev" | 12:47 |
Guest39 | IMAGE_BOOT_FILES_append = " ${INITRAMFS_KERNEL_IMAGE};${KERNEL_IMAGETYPE}" | 12:47 |
andy99 | because it's created afterwards the packaging process | 12:48 |
Guest39 | andy99: it's created in the second step but will be bundled to the kernel afterwards | 12:50 |
Guest39 | andy99: ... if you configure the bundling properly as shown above | 12:50 |
andy99 | Yes, I have the similar setup | 12:51 |
smurray | andy99: one way would be to add it to IMAGE_BOOT_FILES if using the bootimg-partition partition type | 12:52 |
andy99 | no, I don't have a boot partition | 12:52 |
andy99 | everything is inside rootfs/boot folder | 12:52 |
smurray | afaik you'll need to do up a custom image recipe that depends upon the initramfs and copies it in | 12:53 |
smurray | if you're using wic and /boot has the usual stuff in it, living with a second partition and using bootimg-partition might be simpler | 12:55 |
*** Guest60 <Guest60!~Guest60@95-105-142-182.dynamic.orange.sk> has joined #yocto | 12:55 | |
andy99 | but is it a problem to have it inside rootfs? | 12:59 |
*** paulg <paulg!~boodler@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 13:02 | |
qschulz | andy99: so you want your kernel with an initramfs inside the actual initramfs? | 13:02 |
qschulz | There is an egg/chicken issue there | 13:03 |
andy99 | no, maybe I didn't write it correctly. Currently I was using the generic kernel. Now I would like to switch into signing one. The bootloader (u-boot) should unpack the initramfs from kernel and verify the signature. Afterwards the device will be booted. | 13:04 |
andy99 | so I need to have bundled initramfs inside the kernel. But the artifacts is not being created inside any package, just in the deploy folder. | 13:05 |
andy99 | I would like to "take" the artifacts from deploy folder and install it into rootfs | 13:05 |
Guest39 | andy99: It makes more sense to put the key files which you need for verifying into the boot partition but not in a folder of the root partition | 13:10 |
andy99 | currently I have only one partition | 13:10 |
andy99 | Does it mean, to have a separated /boot partition is better idea? | 13:11 |
Guest39 | andy99: Separating is a better idea in my opinion, and it works :) | 13:11 |
Guest39 | andy99: The bootloader must not mount the whole disk just for running the kernel | 13:13 |
andy99 | What I heard, the reason why is "disabled" on the master is, that there was some kind of circular dependency, but I don't have a more info. | 13:13 |
qschulz | your rootfs is not your initramfs is it? | 13:19 |
qschulz | your initramfs is here just to do a dm_verity of the actual rootfs and then switch_root to it? | 13:20 |
Guest60 | qschulz: yes, this is the design | 13:20 |
qschulz | Guest60: that was not clear, because the initramfs can be the rootfs (and actually is, just a temporary one in your case) | 13:21 |
qschulz | yeah there was (and maybe still is) a circular dependency | 13:21 |
qschulz | you need a handcrafted kernel-fitimage class | 13:22 |
qschulz | or check what Bartosz from Baylibre tried to upstream a few months ago | 13:22 |
qschulz | I don't remember if it was ever merged but I think not | 13:22 |
Guest39 | andy99: I understood your folder with the key files for verifying is in the rootfs. But do you mean that folder is in the initramfs? | 13:24 |
andy99 | do you have the link somewhere? | 13:24 |
qschulz | https://bootlin.com/pub/conferences/2018/elc/josserand-schulz-secure-boot/josserand-schulz-secure-boot.pdf slide 42 | 13:25 |
qschulz | is the issue we ran into | 13:25 |
Guest60 | Guest39: the key files are in the initramfs, the signatures are passed in the kernel cmdline from u-boot environment | 13:26 |
qschulz | and that you'll run into | 13:27 |
qschulz | seems like it was merged in meta-security | 13:28 |
qschulz | https://git.yoctoproject.org/cgit/cgit.cgi/meta-security/tree/classes/dm-verity-img.bbclass | 13:28 |
qschulz | you probably need other stuff too | 13:28 |
qschulz | https://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/?id=b329e1650daa860c7dfdbd771ddff611452c382b | 13:29 |
qschulz | https://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/?id=d6369c9aafc433b08f9bb000142b274738be3fb3 | 13:29 |
qschulz | this is not using the u-boot script/fitimage mechanism though\ | 13:29 |
Guest60 | Just to be clear - we don't use dm-verity - problem is that our embedded device can't crash on integrity error during the runtime, so we check on boot. | 13:31 |
Guest60 | But maybe we can get some bits and pieces for our implementation. | 13:31 |
qschulz | https://lists.openembedded.org/g/openembedded-core/message/136614?p=,,,20,0,0,0::created,0,bartosz,20,2,0,72497789 | 13:33 |
qschulz | https://lists.openembedded.org/g/openembedded-core/topic/74158924 last version | 13:34 |
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:9c94:7807:4c0c:960> has quit IRC (Ping timeout: 260 seconds) | 13:35 | |
Guest60 | qschulz: Thank you. I'll take a look and contact you in the case of other questions. | 13:36 |
andy99 | qschulz: that's the right link ;). But it's from 2020, so no further movement? | 13:37 |
qschulz | andy99: not that I know | 13:38 |
qschulz | Guest60: not personally please :) continue the discussion here, on the mailing list or contact the people who worked on this, they *might* be ok with you contacting thm direclty | 13:38 |
Guest60 | qschulz: Ok, i completely understand. I'll proccess the links you provided, and then try the mailing list. Thanks for the info provided so far. | 13:42 |
*** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-21-184-145-222-193.dsl.bell.ca> has joined #yocto | 13:42 | |
qschulz | Guest60: my pleasure. Wondering what you have decided to go for instead of dm-verity though :) | 13:43 |
Guest60 | Just to check the whole partition signature using dd & openssl. The issue is, that the device does some things very rarely, and when we check the blocks on access, the kernel panic or other indication can occur in a very critical time. | 13:47 |
*** angolini <angolini!uid62003@id-62003.helmsley.irccloud.com> has joined #yocto | 13:49 | |
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Quit: camus) | 13:53 | |
Guest39 | that's why it's better to load the kernel before that partition becomes actively mounted | 13:55 |
*** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 14:00 | |
Guest60 | Guest39: Crash during the startup is not critical at all, but the crash during runtime can be an issue. | 14:01 |
Guest39 | ok, I see | 14:07 |
*** Guest60 <Guest60!~Guest60@95-105-142-182.dynamic.orange.sk> has quit IRC (Quit: Client closed) | 14:20 | |
smurray | qschulz: the circular dependency issue with dm-verity comes from e.g. needing kernel modules in the rootfs, but the rootfs hash is needed for the initramfs that gets built in the kernel recipe | 14:24 |
qschulz | smurray: we had the circular depenedency because of u-boot script storing the root hash needed by dm_verity stored in the kernel fitimage | 14:25 |
qschulz | except the kernel fitimage is created after the rootfs | 14:25 |
qschulz | (in yocto) | 14:25 |
smurray | qschulz: yes, it's easy to get there with the fitimage | 14:25 |
qschulz | or is it before, eh don't remember, long time ago | 14:26 |
qschulz | it was in the slides I linked :p | 14:26 |
smurray | qschulz: aiui there are some standalone initramfs recipes floating around, but nothing upstreamed | 14:26 |
* qschulz hides | 14:26 | |
smurray | heh, I've thought about working one up, but have not, so I can't point any fingers | 14:27 |
qschulz | I left the company so can't upstream this anymore as I don't recall any of it | 14:27 |
qschulz | and it would have been probably a bit too hacky | 14:27 |
qschulz | maybe we should ping bartosz/rp again on that topic | 14:27 |
smurray | it's going to become a more common issue as dm-verity shows up on more reqts lists, so sooner or later something will be needed upstream | 14:28 |
* qschulz nods | 14:29 | |
*** marex <marex!~marex@195.140.253.44> has joined #yocto | 14:33 | |
andy99 | yes, the artifacts are created afterwards | 14:35 |
kanavin | RP: thanks, I am not setting up the previous reported build which presumably regressed due to these fixes, to confirm (or not) | 14:49 |
*** andy99 <andy99!~andy@165.225.26.249> has quit IRC (Quit: Leaving) | 15:00 | |
kanavin | RP: and sadly... yes. Wrote a comment in https://bugzilla.yoctoproject.org/show_bug.cgi?id=14342 | 15:07 |
thekappe | hello guys.. I need a hint | 15:07 |
thekappe | I have a kernel recipe append file that install some .bin in ${D}/lib/firmware | 15:08 |
*** Guest39 <Guest39!~Guest39@145.253.222.69> has quit IRC (Quit: Guest39) | 15:09 | |
thekappe | by the way, when the image is built, in build/tmp/work/machine/image/image/ver/rootfs/lib/firmware I have just one .bin file instead of the two of them | 15:09 |
thekappe | the strange thing is that in in build/tmp/work/machine/kernel/ver/image/lib/firmware I have both of them | 15:10 |
qschulz | thekappe: I guess they are split in different packages and you only install one of them? | 15:10 |
qschulz | oe-pkgdata-util find-path '*yourbin.bin' | 15:11 |
thekappe | mmm | 15:12 |
thekappe | you are always right qschulz | 15:12 |
*** camus <camus!~Instantbi@2409:8a1e:911c:bc40:e4e3:c8f8:b37f:894f> has joined #yocto | 15:13 | |
yannd | in yocto 1.6 we had a basepath= parameter for file: SRC_URI's, and this old manual version keeps coming up in searches, while the parameter does not exist any more and was never mentionned in "Upgrading to ..." sections. | 15:16 |
yannd | did anything replaced it ? | 15:18 |
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 15:25 | |
kanavin | RP: *not ---> now | 15:32 |
kanavin | (I am *now* setting up...) | 15:33 |
qschulz | yannd: what was the purpose of such a parameter? | 15:36 |
*** dev1990 <dev1990!~dev@dynamic-78-8-55-226.ssp.dialog.net.pl> has quit IRC (Remote host closed the connection) | 15:37 | |
*** dev1990 <dev1990!~dev@dynamic-78-8-55-226.ssp.dialog.net.pl> has joined #yocto | 15:39 | |
yannd | qschulz: I'd have used it to shorten paths under ${S}. Currently using an absolute file:// URI just copies the full absolute path (under ${WORKDIR} by default) | 15:48 |
yannd | yes, I know absolute file:// is not a good idea, but in some corporate environments that can be the only available way to get to some files | 15:49 |
*** sakoman <sakoman!~steve@172.243.4.16> has quit IRC (Read error: Connection reset by peer) | 15:50 | |
yannd | here is how it has to be handled AFAIK: https://stackoverflow.com/a/69091155/6285023 | 15:51 |
*** mckoan is now known as mckoan|away | 15:52 | |
qschulz | yeah I would have said subdir too | 15:53 |
yannd | my first try after googling for unpack parameters (yes I'm kinda lazy with the docs) was to use both subdir and basepath... until I realized basepath is just doing nothing and I was looking at an outdated doc. Then I googled to know what replaced that parameter and only found that unanswered question ... | 15:56 |
yannd | in fact I'm pretty sure now I already got hit by that old doc item in the past, so my SA answer is as much a reminder to a future self as to anyone else... | 15:58 |
qschulz | yannd: removed in 2016 | 15:59 |
qschulz | (Bitbake rev: e659a3b0c2771679057ee3e13cd42e6c62383ff2) | 15:59 |
qschulz | removed from the docs only recently | 16:00 |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 16:03 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 16:03 | |
*** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 16:08 | |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:08 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 260 seconds) | 16:13 | |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 16:14 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 16:19 | |
*** zpfvo <zpfvo!~fvo@88.130.221.206> has quit IRC (Quit: Leaving.) | 16:24 | |
RP | kanavin: Shame it regresses the other test case :( | 16:25 |
RP | kanavin: that is quite frustrating | 16:26 |
smurray | oh boy, OpenSSL 3.0 has officially released | 16:45 |
*** cocoJoe <cocoJoe!~cocoJoe@xb9b5dc3e.cust.hiper.dk> has quit IRC (Quit: Client closed) | 16:46 | |
RP | kanavin: hmm, I do understand what breaks in that other test case | 16:48 |
fray | smurray thanks for the heads up.. | 16:48 |
RP | smurray: should we try and get that into 3.4? :) | 16:51 |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 16:52 | |
smurray | RP: heh, definitely not | 16:52 |
RP | smurray: I don't think I could take it (and more seriously, the user projects need to adapt first) | 16:52 |
smurray | RP: yeah, I'll be curious to see how quick Fedora jumps on it | 16:54 |
smurray | RP: I suspect the bigger pain comes whenever they do a release that drops the piles of APIs they've marked as deprecated in 3.0 | 16:56 |
*** frieder <frieder!~frieder@mue-88-130-75-072.dsl.tropolys.de> has quit IRC (Remote host closed the connection) | 16:59 | |
wCPO | RP: Is it the fix or the broken commit you linked here? https://lore.kernel.org/qemu-devel/709a88a0f24ed8fd5399a2be88fb9d57ceb0a25a.camel@linuxfoundation.org/ | 16:59 |
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has joined #yocto | 17:00 | |
RP | wCPO: Not sure I understand your question? | 17:00 |
wCPO | RP: it is your mail right? You linked the same commit twice | 17:01 |
RP | wCPO: ah,yes, I did mess that up | 17:01 |
RP | wCPO: that commit broke things iirc and the fix was https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?h=rcu/next&id=dc87740c8a6806bd2162bfb441770e4e53be5601 | 17:05 |
wCPO | RP: thanks, we started seeing some "rcu_preempt detected stalls" recently in Arch Linux CI. Not sure it is related tho | 17:09 |
RP | wCPO: can have many causes, if it locks the system up entirely this one could be a cause though | 17:10 |
*** robbawebba <robbawebba!~rob@12.206.203.186> has joined #yocto | 17:10 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 17:14 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 252 seconds) | 17:15 | |
RP | kanavin: ok, I think my fix was the right idea, wrong function: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=e6ec662c597cdad358f08a9ec9a5effea28978d1 | 17:20 |
RP | kanavin: master-next updated | 17:24 |
robbawebba | Hello, I have a question about premirrors, specifically using the "own-mirrors" bbclass. I noticed that the DL_DIR contains the source code archives as well as a .done file for each archive. Should the .done files be served from a mirror along with the actual source code archives, or will the .done file be created by the client after downloading from the mirror? | 17:32 |
kergoth | robbawebba: the latter | 17:32 |
fray | .done files won't cause failures from the mirror server, but they also don't do anything. I usually remove them from the server | 17:46 |
whuang0389 | I need to provide my own hostapd.conf file | 17:49 |
whuang0389 | whats the preferred way of doing it? | 17:50 |
kanavin | RP: thanks, I'll try that once I get out of cycling kit and shower ;) | 17:57 |
RP | kanavin: I think the test case in c13 will throw "errors" but I'm not sure these new ones are the fault of runqueue | 18:03 |
kanavin | RP: I'll try. And gah, that Damian guy on bitbake-devel :-/ | 18:04 |
kanavin | RP: meanwhile, I have some results from lttng-tools 10x ptests | 18:05 |
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 18:07 | |
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 18:09 | |
RP | kanavin: I think I understand what is going on with the new errors. Trying to decide if I want to fix the sstate hashes or runqueue further | 18:10 |
robbawebba | Thanks kergoth and fray :) | 18:11 |
robbawebba | whuang0389: The preferred way of doing it should be creating your own bbappend file for the hostapd package. In this bbappend file, you'll want to append the path to your custom file to the FILES variable, and you'll probably need a custom do_install_append function to overwrite the default config. | 18:16 |
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has quit IRC (Quit: Client closed) | 18:18 | |
robbawebba | whoops, I said FILES, but I meant SRC_URI | 18:18 |
kanavin | RP: let me know when you have something you'd like me to test | 18:19 |
*** angolini <angolini!uid62003@id-62003.helmsley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 18:19 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Ping timeout: 260 seconds) | 18:20 | |
*** zyga <zyga!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has quit IRC (Ping timeout: 252 seconds) | 18:24 | |
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 18:27 | |
RP | kanavin: master-next has a tweaked patch which is ready for wider testing again. I'll continue to run local tests too | 18:35 |
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Read error: Connection reset by peer) | 18:36 | |
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 18:37 | |
abelloni | RP: I just sent the previous one to the AB, should I restart ? | 18:38 |
abelloni | well, 42 minutes ago | 18:38 |
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has joined #yocto | 18:50 | |
*** BobPungartnik <BobPungartnik!~Pung@187.113.138.128> has joined #yocto | 18:51 | |
*** BobPungartnik <BobPungartnik!~Pung@187.113.138.128> has quit IRC (Client Quit) | 18:52 | |
whuang0389 | robbawebba thanks, it worked! I guess Yocto wasn't happy when I overwrote the hostapd.conf file with the one in application recipe | 18:52 |
*** camus <camus!~Instantbi@2409:8a1e:911c:bc40:e4e3:c8f8:b37f:894f> has quit IRC (Quit: camus) | 18:52 | |
RP | abelloni: please | 19:05 |
RP | abelloni: it would be worth testing these two properly as my local testing shows they're better | 19:06 |
*** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 19:17 | |
vd | Is it OK to use the deploy class to copy a final image to a specific (CI/CD) directory (not DEPLOYDIR/DEPLOY_DIR_IMAGE)? | 19:32 |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 19:39 | |
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.96.230> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 19:42 | |
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.96.230> has joined #yocto | 19:42 | |
JPEW | vd: You might have touble with task reruns if you try to do that | 19:50 |
JPEW | I wouldn't recommend it at least | 19:50 |
vd | JPEW so I shouldn't inherit the deploy class? | 19:55 |
*** RobertBerger <RobertBerger!~rber|res@185-232-103-115.xdsl.philuweb.net> has quit IRC (Ping timeout: 252 seconds) | 20:06 | |
JPEW | vd: You cause use it, but it might cause some issues if you don't deploy to DEPLOYDIR | 20:19 |
*** Guest98 <Guest98!~Guest98@2001:16b8:57b3:5e00:4013:76ec:9bb4:ec66> has joined #yocto | 20:20 | |
JPEW | vd: What is it you want to accomplish? | 20:20 |
*** Guest98 <Guest98!~Guest98@2001:16b8:57b3:5e00:4013:76ec:9bb4:ec66> has quit IRC (Client Quit) | 20:21 | |
vd | JPEW a bit like you alias deploy whisk class, I need the CI/CD to copy the interesting output files (not all of them) to a different local directory | 20:23 |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 20:38 | |
JPEW | vd: Copy files out of deploydir? | 20:42 |
JPEW | or DEPLOY_DIR_IMAGE more specifically? | 20:42 |
JPEW | My first thought would be "Do you really need to run that as a bitbake task for some reason?" It seems like your CI/CD could have a post-build script that copies the output from deploy dir to where ever you want it | 20:43 |
JPEW | (But I might be misunderstanding what you are trying to do) | 20:44 |
vd | out of DEPLOY_DIR_IMAGE. I could simply upload DEPLOY_DIR_IMAGE but there is so much image files we don't need in there, it's confusing. I only need to copy a few final image files to a locally mounted server directory. | 20:44 |
vd | good question. The thing is that only bitbake knows about specific path for a multiconfig (e.g. DEPLOY_DIR_IMAGE, BB_CURRENT_MC, etc.) | 20:45 |
JPEW | vd: Ah, ya, that's a common problem; the best solution (that I've found) is to fix it by having a convention for how your files and directories are named; the is effectively what whisk does, although it has the convenience of setting some variables for you to make it a little easier. | 20:47 |
JPEW | vd: But, there is another way; you can actually ask bitbake the value of those variables. Sort of like you do manually with `bitbake -e` | 20:48 |
JPEW | vd: I think there is a command or library that can be used to query that programatically? | 20:48 |
RP | JPEW: bitbake-getvar ? | 20:59 |
RP | or tinfoil | 21:00 |
*** florian <florian!~florian@dynamic-093-135-141-137.93.135.pool.telefonica.de> has joined #yocto | 21:03 | |
vd | hum, I donno. I have a dummy recipe to group all interesting images, and I build this dummy recipe for all my multiconfig (these are build profiles). I think the simplest is still to have a simple additional task in this dummy recipe to copy its images to a custom directory. | 21:11 |
*** creich_ <creich_!~creich@p200300f6af262d106bbd1ab975fe5d89.dip0.t-ipconnect.de> has joined #yocto | 21:12 | |
*** creich <creich!~creich@p200300f6af1b6910676a437eca11f5a9.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 252 seconds) | 21:14 | |
*** amitk_ <amitk_!~amit@103.208.69.28> has joined #yocto | 21:20 | |
*** amitk <amitk!~amit@103.208.71.87> has quit IRC (Ping timeout: 252 seconds) | 21:23 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 21:35 | |
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has quit IRC (Quit: Client closed) | 21:39 | |
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has joined #yocto | 21:40 | |
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 21:43 | |
*** whuang0389 <whuang0389!~whuang038@cpeac202ebbe763-cmac202ebbe760.cpe.net.fido.ca> has quit IRC (Client Quit) | 21:44 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 22:11 | |
*** amitk_ <amitk_!~amit@103.208.69.28> has quit IRC (Quit: leaving) | 22:13 | |
*** tlwoerner <tlwoerner!~tlwoerner@pppoe-209-91-167-254.vianet.ca> has quit IRC (Quit: Leaving) | 22:19 | |
*** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has quit IRC (Remote host closed the connection) | 22:25 | |
*** otavio <otavio!~otavio@201-34-65-230.user3p.brasiltelecom.net.br> has joined #yocto | 22:27 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 22:37 | |
*** florian <florian!~florian@dynamic-093-135-141-137.93.135.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 22:58 | |
*** yannd <yannd!~yann@88.120.44.86> has quit IRC (Ping timeout: 240 seconds) | 22:59 | |
*** yannd <yannd!~yann@88.120.44.86> has joined #yocto | 23:41 | |
*** yannd <yannd!~yann@88.120.44.86> has quit IRC (Ping timeout: 260 seconds) | 23:46 | |
*** yannd <yannd!~yann@88.120.44.86> has joined #yocto | 23:58 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!