Friday, 2024-01-26

*** khem <khem!> has quit IRC (Quit: Connection closed for inactivity)00:00
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 264 seconds)00:01
landgrafYocto is a tool as well as other buildsystem/traditional distro  and it's up to user to choose proper tool for the task. and people choose the tool they know/have. That's why I use CNC router to cut simple shapes from plywood even if table saw will do the job better, because I don't know how to use table saw and I don't own one :-)00:05
*** mvlad <mvlad!~mvlad@2a02:2f08:e805:bb00:ae21:37e3:8f38:323d> has quit IRC (Remote host closed the connection)00:12
*** Guest19 <Guest19!> has joined #yocto00:18
Guest19The team maintaining the [__meta-raspberrypi__]( layer just added RaspberryPi5 support on master. Does anyone know how that ends up going from master to nanbield, or will it? I don't understand how that release flow works and I'm not sure who to ask.00:20
Guest19I'm realizing that this is controlled by other maintainers not the Yocto team so probably the wrong place to ask this question.00:22
landgrafGuest19: rpi5 support has been added few hours ago. I guess it's too early to merge into "stable" branches however you can ask maintainer in github issue (better with results of testing :) )00:27
Guest19Gotcha. Thanks for the reply00:27
*** Guest19 <Guest19!> has quit IRC (Quit: Client closed)00:29
*** kpo <kpo!> has joined #yocto00:50
*** kpo <kpo!> has quit IRC (Ping timeout: 256 seconds)00:59
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)01:23
*** lexano <lexano!~lexano@> has quit IRC (Ping timeout: 264 seconds)01:41
*** davidinux <davidinux!> has quit IRC (Ping timeout: 264 seconds)02:04
*** davidinux <davidinux!> has joined #yocto02:10
*** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Ping timeout: 276 seconds)03:33
*** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto03:36
*** jclsn <jclsn!~jclsn@2a04:4540:6545:3a00:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 260 seconds)03:55
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto03:55
*** jclsn <jclsn!~jclsn@2a04:4540:6500:c200:2ce:39ff:fecf:efcd> has joined #yocto03:57
*** sakman <sakman!~Thunderbi@> has joined #yocto04:04
*** sakman <sakman!~Thunderbi@> has quit IRC (Client Quit)04:08
*** sakman <sakman!~Thunderbi@> has joined #yocto04:15
*** mulk <mulk!> has quit IRC (Ping timeout: 264 seconds)06:04
*** olani <olani!> has quit IRC (Ping timeout: 260 seconds)06:06
*** mulk <mulk!> has joined #yocto06:10
*** astlep5504018 <astlep5504018!> has quit IRC (Quit: Ping timeout (120 seconds))06:11
*** astlep5504018 <astlep5504018!> has joined #yocto06:15
*** mulk <mulk!> has quit IRC (Ping timeout: 264 seconds)06:20
*** Saur <Saur!> has quit IRC (Ping timeout: 260 seconds)06:20
*** mulk <mulk!> has joined #yocto06:21
*** Kubu_work <Kubu_work!> has joined #yocto06:46
*** linfax <linfax!> has joined #yocto07:14
*** khazakar <khazakar!> has joined #yocto07:19
*** rob_w <rob_w!> has joined #yocto07:19
*** mckoan|away is now known as mckoan07:24
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 260 seconds)07:24
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto07:30
*** mulk <mulk!> has quit IRC (Ping timeout: 256 seconds)07:47
*** mulk <mulk!> has joined #yocto07:48
LetoThe2ndlandgraf: just looked at that sure thing, and my understanding is that it basically advertises - which is a re-load of meta-delian.07:54
*** vladest <vladest!> has quit IRC (Quit: vladest)07:56
*** sakman <sakman!~Thunderbi@> has quit IRC (Ping timeout: 246 seconds)07:59
*** rfuentess <rfuentess!~rfuentess@2a01:cb14:11e8:f400:be57:9a40:6c36:464> has joined #yocto08:00
landgrafLetoThe2nd: yes, pretty much. More like meta-suse08:13
LetoThe2ndlandgraf: *sigh*08:13
LetoThe2ndexactly what the world needs. another clever person shoehorning their own distribution into a Bitbake build. erm wait, in that case even explicitly into poky. *facepalm*08:14
*** florian <florian!> has joined #yocto08:20
*** rber|res <rber|res!~rber|> has joined #yocto08:25
*** rber|res <rber|res!~rber|> has quit IRC (Remote host closed the connection)08:25
*** rber|res <rber|res!~rber|> has joined #yocto08:25
*** Tyaku <Tyaku!> has joined #yocto08:31
TyakuHello, I have a variable in a recipe. How to make it configurable using a variable at build time ? I have it 'SW_REV ?= "Dirty"' in, it's not taking the value passed at buildtime (like: SW_REV='xxx' bitbake {...})08:32
*** olani <olani!> has joined #yocto08:47
* RP notes his patch doesn't work08:47
LetoThe2ndTyaku: you mean, passing something into the build from the invoking environment?08:48
*** rfuentess <rfuentess!~rfuentess@2a01:cb14:11e8:f400:be57:9a40:6c36:464> has quit IRC (Remote host closed the connection)08:50
*** rfuentess <rfuentess!~rfuentess@2a01:cb14:11e8:f400:a7c1:8c29:8324:6ff8> has joined #yocto08:51
*** vladest <vladest!~Thunderbi@> has joined #yocto08:55
*** goliath <goliath!~goliath@user/goliath> has joined #yocto09:09
chepHi, I'm trying to add python3 to my image (kirkstone branch). When I add « python3 » to CORE_IMAGE_EXTRA_INSTALL I got this error : « The following packages have unmet dependencies:09:14
chep python3-modules : Depends: python3-fcntl but it is not installable ». When I try to add « python3-fcntl » bitbake says that python3 RPROVIDES python3-fcntl. What should I do?09:14
*** Saur <Saur!> has joined #yocto09:18
TyakuLetoThe2nd Yes, Currently this is what I do: export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE SW_REV"     export SW_REV="${DIRTY_REV}"   and then In the receipe I have SW_REV ?= "Unknown"09:19
TyakuI don't know if it's the right way09:19
*** xmn <xmn!> has quit IRC (Ping timeout: 255 seconds)09:20
LetoThe2ndTyaku: shouldn't it just be BB_ENV_EXTRAWHITE:append = "SW_REV"?09:29
LetoThe2ndin a conf file, obviously09:29
*** michalsieron <michalsieron!~michalsie@> has joined #yocto09:43
*** alessioigor <alessioigor!~alessioig@> has joined #yocto09:47
michalsieronhello there o/ does anyone know what's the purpose of the `try_premirror` check in bitbake?
michalsieronthe only place where it is being used is here
michalsieronbut at this point we have checked for donestamp and whether something needs update. so we *do* need to make a download09:52
michalsieronso why would we decide (after checking that repo in the download dir doesn't contain the commit we need) doesn't need to be downloaded from a PREMIRROR just because its directory already exists on the disk?09:53
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)09:56
*** alessioigor <alessioigor!~alessioig@> has joined #yocto09:57
landgrafmichalsieron: we don't need to make a download from upstream if the revision is in PREMIRROR10:01
landgrafmichalsieron: even more if PREMIRRORONLY is set we are not allowed to download from the network outside of premirror10:02
michalsieronlandgraf: ok. so here is an example situation where I think the behaviour is buggy:10:04
michalsieronWe have a recipe which requires commit 'abcd'.10:04
michalsieronWe run `do_fetch` task for it, it clones the repository from let's say a premirror.10:04
michalsieronLater new commit appears for example 'wxyz'.10:04
michalsieronWe update our recipe to require it and run `do_fetch` again (this time it has to be from a premirror).10:04
michalsieronFirst bitbake checks for `donestamp`, which exists, but then `need_update` returns true as we do need an update.10:04
michalsieronBut then in `try_premirror` we check that the directory exists and decide we don't need to download from premirrors, even though just moment ago we concluded that we need to update.10:04
michalsieronThis way we skip premirrors even though we really shouldn't.10:04
*** olani- <olani-!~olani@> has joined #yocto10:04
landgrafmichalsieron: which version? iirc we have test to cover this exact case10:05
landgrafif we don't it should be created10:05
michalsieronI am on kirkstone, but when I look at master it *looks* the same to me10:07
michalsieronlandgraf: this is even more prone to happen if your premirror is a storage for git tarballs10:10
michalsieronthen you run a build for one machine, which downloads full tarball (it wasn't updated to require shallow tarball)10:10
michalsieronand then another build for the second machine wants to download updated sources with a newer hash not present in the full tarball, which are present on premirror in a shallow tarball10:10
landgrafmichalsieron: Doesn't this test cover behaviour you mentioned ?10:18
landgrafmichalsieron: kirkstone doesn't have this fix iirc10:19
landgrafit was merged right after kirkstone has been released10:19
*** olani- <olani-!~olani@> has quit IRC (Remote host closed the connection)10:25
*** olani- <olani-!~olani@> has joined #yocto10:25
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto10:27
michalsieronlandgraf: I don't think it's the same. Please correct me if I understood the test incorrectly:10:39
michalsieron1. First we setup the test by downloading and preparing some tarball in our local premirror.10:39
michalsieron2. Then we set PREMIRRORS, BB_FETCH_PREMIRRORONLY and BB_NO_NETWORK10:39
michalsieron3. Finally we check we correctly downloaded from our premirror10:39
michalsieronFor this to test the behaviour I described, it would require few more steps:10:39
michalsieron- In preparation you would need to have a shallow tarball with a commit not present in the normal one.10:39
michalsieron- After downloading the normal tarball, you would change SRCREV to one from the shallow tarball and try to download afterwards10:39
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto10:50
*** prabhakar <prabhakar!~prabhakar@> has joined #yocto10:51
landgrafmichalsieron: not sure I got the last point. Do you SRCREV presents in PREMIRROR's shallow clone but not in local clonedir ("normal tarball") ?10:51
landgraf*Do you mean10:51
landgrafmichalsieron: or SRCREV is in PREMIRROR but not in DL_DIR?10:51
*** ptsneves <ptsneves!> has joined #yocto10:58
michalsieronlandgraf: SRCREV is present in shallow tarball, but not in not-shallow tarball10:59
michalsieronThink of it as shallow tarball was created for a commit after the non-shallow one was created10:59
landgrafmichalsieron: not sure if shallow tarball is important here. For me it looks like: 1) make a tarball in the premirror 2) download(from the premirror)/build SRCREV1 3) add a commit SRCREV2 into premirror 4) download(from premirror)/build SRCREV211:11
landgrafat step 3 you have premirror tarball with new srcrev and "original" one without11:12
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)11:12
*** alessioigor <alessioigor!~alessioig@> has joined #yocto11:12
*** michalsieron <michalsieron!~michalsie@> has quit IRC (Ping timeout: 250 seconds)11:18
*** michalsieron <michalsieron!~michalsie@> has joined #yocto11:21
michalsieronlandgraf: sorry, some internet issues11:22
michalsieronyes, you are right. shallow tarball is not actually required for this to manifest.11:22
michalsieronin both cases bitbake would incorrectly skip downloading from a premirror11:22
landgrafmichalsieron: it was the case for kirkstone but should be fixed in master with
*** alperak <alperak!~alperak@> has joined #yocto11:28
michalsieronlandgraf: let me check if it  solves the problem for me11:32
landgrafmichalsieron: if it's not then let's open a bug. looks like I need more time to reproduce the issue11:32
michalsieronlandgraf: because the commit subject says "fetch2: Honour BB_FETCH_PREMIRRORONLY option", but you don't need PREMIRRORONLY to say this is an issue11:33
michalsieronis some cases you want some sources to be fetched from a premirror, and some from your own upstream11:33
landgrafyes. you're right11:34
landgrafmichalsieron: do you have YP bugzilla account?11:35
landgrafmichalsieron: I'll create bug report then to not have it lost in the irc conversation.11:36
michalsieronsure. if anything it will be closed as already fixed11:36
michalsieronlandgraf: ok. I cherry-picked the commit and it still fails11:52
landgrafmichalsieron: right. I see the issue now.11:56
landgrafmichalsieron: it was masked by PREMIRRORONLY as you mentioned because there's check for it in try_premirror11:57
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)11:59
michalsieronlandgraf: oh. and you know what's the best thing? In my case all the actual mirrors are not trusted, so the build fails after skipping premirrors.12:02
michalsieronBut if I run the build a second time, it will work again.12:02
michalsieronThat's because bitbake will delete the tarball after failing to download from a mirror12:02
*** RobW <RobW!~rcwoolley@> has quit IRC (Quit: Leaving)12:04
*** vladest <vladest!~Thunderbi@> has quit IRC (Ping timeout: 246 seconds)12:13
landgrafmichalsieron: and I have reproducer now.12:18
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto12:21
michalsieronlandgraf: great, so we can have a test for it. but there is still a question of how to fix it :D12:21
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)12:27
landgrafmichalsieron: well. fix something in fetcher code is not so difficult. the question is how to fix it and not break something else :D12:30
*** alperak <alperak!~alperak@> has quit IRC (Quit: Client closed)12:32
RPrburton: - debuginfod :/12:35
*** vladest <vladest!> has joined #yocto12:39
landgrafmichalsieron: here is your problem :-/ Well, one of them actually13:02
*** Tyaku <Tyaku!> has quit IRC (Quit: Lost terminal)13:02
landgrafI know how to "fix" that in Q&D way but RP will not be happy with the fix :)13:03
landgrafRP: long story short `git branch --contains` doesn't look into FETCH_HEAD so this part of code is useless :(13:04
*** lexano <lexano!~lexano@> has joined #yocto13:08
michalsieronlandgraf: threre is still one thing I don't understand about this code.13:20
michalsieronFrom what I looked at this `` method, it tries to fetch changes with `git` not redownload actual tarball.13:20
michalsieronSo if I have a generated tarball, which originates from the upstream, and the requested commit is not there, wouldn't `git fetch` access this upstream repository?13:20
michalsieronI would think, that download of the entire tarball is required, because that's how it is stored on the premirror. Binary storage can't really send you only things you are missing in your unpacked tarball.13:20
landgrafmichalsieron: git fetch will try upstream if revision is in neither clonedir nor in premirror (unless premirroronly specified)13:25
*** michalsieron <michalsieron!~michalsie@> has quit IRC (Quit: Client closed)13:26
*** michalsieron <michalsieron!~michalsie@2a03:5342:1f:b::3> has joined #yocto13:26
michalsieronlandgraf: it's the `--mirror` flag for `git clone`?
landgrafmichalsieron: clonedir -> premirror -> mirror -> upstream that's the proper order afaik but because of the bug you've found today premirror is effectively excluded from this if clonedir exists13:27
landgrafmichalsieron: not really.13:28
michalsieronlandgraf: I am not talking about order in which bitbake tries to download stuff13:28
rburtonRP: ARGH13:29
landgrafmichalsieron: --mirror is to setup a mirror of the repo, not to clone the mirror in bitbake terms13:30
landgrafmichalsieron: in your case there're two issues. First (as you pointed out correctly) is the fact that premirror is set to false if clonedir exists and PREMIRRORONLY not specified, this is easy to fix. Second issue is the fact that fetcher doesn't see updated revision in the premirror, fixing this is more complicated13:36
*** sakman <sakman!~Thunderbi@> has joined #yocto13:42
RPlandgraf: this could be the issue paulg was asking about? :/13:45
*** florian_kc <florian_kc!> has joined #yocto13:45
landgrafRP: Not with premirrors "2023-12-07 18:05:33     paulg   no PREMIRRORS set". But we may have similar issue with another git fetch call below.13:52
*** prabhakarlad <prabhakarlad!~prabhakar@> has quit IRC (Quit: Client closed)13:59
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto14:11
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 268 seconds)14:47
*** Xagen <Xagen!> has joined #yocto14:48
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto14:53
*** ernstp <ernstp!> has quit IRC (Ping timeout: 268 seconds)14:57
*** Xagen <Xagen!> has quit IRC (Ping timeout: 264 seconds)14:58
*** nohit <nohit!> has quit IRC (Ping timeout: 268 seconds)14:58
*** roussinm <roussinm!~mroussin@> has joined #yocto15:00
*** ernstp <ernstp!> has joined #yocto15:00
*** nohit <nohit!> has joined #yocto15:00
*** Xagen <Xagen!> has joined #yocto15:02
*** Tyaku_ <Tyaku_!> has joined #yocto15:10
Tyaku_Hello, I'm back. These days I have serious problems, I don't know what my collegue do but lot of things are broken in our yocto projects. This is after some "refactoring" he split the image in multiples images, each one including another.15:11
Tyaku_Problem of the day:15:11
Tyaku_IMAGE_FEATURES:append = " ssh-server-dropbear allow-root-login allow-empty-password "15:12
Tyaku_*In the rootfs in /etc/default/dropbear I still have "-w" arguments15:12
Tyaku_So it seems that IMAGE_FEATURES is not taken.15:13
Tyaku_But, in 'bitbake -e MY_IMAGE' it seems that IMAGE_FEATURES contains allow-root-login15:13
*** michalsieron <michalsieron!~michalsie@2a03:5342:1f:b::3> has quit IRC (Ping timeout: 250 seconds)15:14
mattsmis there a list of organizations that can do security scans for yocto based on spdx/sbom? e.g. is one, but are there others?15:19
roussinmWhen image is trying to do do_rootfs, it fails on: `file /etc/polkit-1/rules.d conflicts between attempted installs of polkit-group-rule-network-1.0-r0.zen2 and polkit-123-r0.zen2`, I tried to fix the bug, but can't figure out how do it since both recipe requires the pokit-1/rules.d directory. But recipes haven't changed in a while, so wondering if maybe it's not that used and we caught a bug in how15:22
roussinmthose recipes are setup?15:22
*** prabhakarlad <prabhakarlad!~prabhakar@> has quit IRC (Quit: Client closed)15:26
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)15:30
yoctonroussinm: check the ownership and rights of /etc/polkit-1/rules.d from both rules, they need to be the same15:31
roussinmyocton: chow and chmod needs to be the same I guess?15:33
yoctonroussinm: yes15:38
*** simonew <simonew!> has joined #yocto16:02
*** rfuentess <rfuentess!~rfuentess@2a01:cb14:11e8:f400:a7c1:8c29:8324:6ff8> has quit IRC (Remote host closed the connection)16:03
*** xmn <xmn!> has joined #yocto16:03
*** linfax <linfax!> has quit IRC (Ping timeout: 264 seconds)16:07
*** simonew <simonew!> has quit IRC (Quit: Client closed)16:21
qschulzRP: tlwoerner: JPEW: moto-timo: re: bmap-tools: meta-raspberrypi has a GitHub+ML contribution workflow already BTW, and it is hosted on
moto-timoas does meta-java (which is also on gitlab)... I am agnostic16:22
qschulz(I can comment on the ML, but here seems a bit more "private" to not make this blow out of proportions; I remember the few lengthy emails about webgui contributions in the past, don't want to revive those :) )16:23
qschulzdoes anyone have any idea why Intel is abandoning it? I'm quite surprised actually16:26
tlwoerneri don't think "intel" is abandoning ig16:26
RPqschulz: they don't have anyone working in this area anymore16:26
tlwoernermy understanding is that it was always the private project of the author... who happened to publish it on the corporate intel github account16:26
RPqschulz: the difference with rpi is which github account16:27
rburtoniirc it was started by artem but very much used by some intel projects at the time16:27
RPtlwoerner: not really true, it was part of the tizen work originally16:27
* tlwoerner lives in his own reality which rarely intersects with actual reality16:29
tlwoernerintersects? interacts?16:29
JPEWWell, if you all are figments of my imagination, at least my imagination figmented nice people :)16:38
RPtlwoerner: I think I should try that more! :)16:39
JaMawhat is reality?16:47
*** florian <florian!> has quit IRC (Quit: Ex-Chat)16:47
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 246 seconds)16:49
mischiefnobody's real!16:52
*** mckoan is now known as mckoan|away16:57
*** kpo <kpo!> has joined #yocto17:01
*** risca_ <risca_!> has joined #yocto17:13
*** risca <risca!> has quit IRC (Ping timeout: 264 seconds)17:14
*** jmd <jmd!~user@2001:a61:2a5a:f701:bd45:e9a8:6384:9d60> has joined #yocto17:15
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 264 seconds)17:16
*** pbsds <pbsds!~pbsds@> has quit IRC (Ping timeout: 276 seconds)17:31
*** pbsds <pbsds!~pbsds@> has joined #yocto17:32
*** Tyaku_ <Tyaku_!> has quit IRC (Quit: Lost terminal)17:38
*** khem <khem!> has joined #yocto17:40
*** florian_kc <florian_kc!> has joined #yocto18:04
*** bhstalel <bhstalel!~bhstalel@> has joined #yocto18:19
*** risca_ <risca_!> has quit IRC (Quit: - Chat comfortably. Anywhere.)18:35
*** vladest <vladest!> has quit IRC (Remote host closed the connection)18:38
*** risca <risca!> has joined #yocto18:43
*** sotaoverride is now known as Guest615118:58
*** Guest6151 <Guest6151!~ctraven@> has quit IRC (Killed ( (Nickname regained by services)))18:58
*** sotaover1ide is now known as sotaoverride18:58
*** ctraven <ctraven!~ctraven@> has joined #yocto19:04
*** vladest <vladest!> has joined #yocto19:11
*** sakman <sakman!~Thunderbi@> has quit IRC (Ping timeout: 264 seconds)19:22
*** alessioigor <alessioigor!~alessioig@> has joined #yocto19:27
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 246 seconds)19:59
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto20:01
*** sakman <sakman!~Thunderbi@> has joined #yocto20:08
*** sakman1 <sakman1!~Thunderbi@> has joined #yocto20:09
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)20:12
*** alessioigor <alessioigor!~alessioig@> has joined #yocto20:12
*** sakman <sakman!~Thunderbi@> has quit IRC (Ping timeout: 268 seconds)20:13
*** sakman1 is now known as sakman20:13
moto-timoclasses-global and classes-recipe now showing on Layerindex
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)20:24
*** simonew <simonew!~ile@2a02:810d:a940:35fc:266b:d62d:85f7:47a1> has joined #yocto20:44
*** ptsneves <ptsneves!> has joined #yocto20:57
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)21:01
*** geoffhp <geoffhp!> has quit IRC (Remote host closed the connection)21:08
*** simonew <simonew!~ile@2a02:810d:a940:35fc:266b:d62d:85f7:47a1> has quit IRC (Quit: Konversation terminated!)21:14
roussinmLooking at documentation for BB_PRESSURE_MAX_MEMORY saying maximum is 1000000 but I see: full avg10=1.49 avg60=14.77 avg300=37.99 total=297837869, on my system. Using Kernel 5.4 did the value was changed since 4.20 ?21:16
roussinmSame for CPU actually: some avg10=0.01 avg60=5.08 avg300=29.38 total=18393902580 do I have to divide by the amount of threads ?21:18
roussinmRTFM I guess... found it...21:26
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 264 seconds)21:29
*** wyre <wyre!~wyre@user/wyre> has quit IRC (Quit: ZNC 1.8.2 -
*** wyre <wyre!~wyre@user/wyre> has joined #yocto21:51
*** bhstalel <bhstalel!~bhstalel@> has quit IRC (Read error: Connection reset by peer)22:08
*** bhstalel <bhstalel!~bhstalel@> has joined #yocto22:27
*** Kubu_work <Kubu_work!> has quit IRC (Quit: Leaving.)22:34
*** davidinux <davidinux!> has quit IRC (Ping timeout: 260 seconds)22:42
*** bhstalel <bhstalel!~bhstalel@> has quit IRC (Read error: Connection reset by peer)22:46
*** olani- <olani-!~olani@> has quit IRC (Ping timeout: 268 seconds)23:50
*** sakman1 <sakman1!~Thunderbi@> has joined #yocto23:53
*** sakman <sakman!~Thunderbi@> has quit IRC (Ping timeout: 264 seconds)23:55
*** sakman1 is now known as sakman23:55

Generated by 2.17.2 by Marius Gedminas - find it at!