Friday, 2020-09-18

*** ericch <ericch!> has quit IRC00:06
*** leon-anavi <leon-anavi!~Leon@> has quit IRC00:10
*** kiwi_29 <kiwi_29!> has joined #yocto00:29
*** goliath <goliath!> has quit IRC00:33
*** kiwi_29 <kiwi_29!> has quit IRC00:34
*** kvpnet <kvpnet!cdfbe9b3@> has quit IRC00:50
*** moosnat <moosnat!> has quit IRC00:54
*** bradleyb <bradleyb!> has joined #yocto01:17
*** Ad0 <Ad0!~Ad0@> has joined #yocto01:17
*** Ad0_ <Ad0_!~Ad0@> has quit IRC01:19
*** radsquirrel <radsquirrel!> has quit IRC01:19
*** stephano <stephano!> has quit IRC01:35
*** mckoan|away <mckoan|away!~marco@unaffiliated/mckoan> has quit IRC02:07
*** mckoan|away <mckoan|away!> has joined #yocto02:09
*** kpo_ <kpo_!> has quit IRC02:15
*** kpo_ <kpo_!> has joined #yocto02:15
*** kiwi_29 <kiwi_29!> has joined #yocto02:48
*** kiwi_29 <kiwi_29!> has quit IRC02:53
*** toast963 <toast963!7bc93410@> has joined #yocto02:55
*** kiwi_29 <kiwi_29!> has joined #yocto02:56
*** p4p4 <p4p4!~p4p4@2605:a000:132b:80c::392> has joined #yocto02:59
*** kiwi_29 <kiwi_29!> has quit IRC03:01
*** manuel1985 <manuel1985!> has quit IRC03:03
*** rcw <rcw!~rcw@> has quit IRC03:09
*** manuel1985 <manuel1985!> has joined #yocto03:19
*** master007__ <master007__!~master007@> has joined #yocto03:43
*** master007_ <master007_!~master007@> has quit IRC03:47
*** toast963 <toast963!7bc93410@> has quit IRC04:16
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC04:35
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC04:38
*** master007_ <master007_!~master007@> has joined #yocto04:58
*** master007__ <master007__!~master007@> has quit IRC05:01
*** master007 <master007!~master007@> has joined #yocto05:01
*** master007_ <master007_!~master007@> has quit IRC05:04
*** agust <agust!> has joined #yocto05:38
*** AndersD <AndersD!> has joined #yocto05:39
RPpaulg: its a huge amount of work!05:43
*** mbulut <mbulut!> has joined #yocto05:46
*** AndersD <AndersD!> has quit IRC05:46
*** pohly <pohly!> has joined #yocto05:48
*** beneth <beneth!> has joined #yocto05:55
*** jobroe <jobroe!> has joined #yocto05:56
*** sven^ <sven^!~quassel@unaffiliated/sven/x-8293843> has quit IRC05:58
*** sven^ <sven^!> has joined #yocto05:58
*** sven^ <sven^!~quassel@unaffiliated/sven/x-8293843> has joined #yocto05:58
*** sxiii <sxiii!> has quit IRC06:01
*** master007_ <master007_!~master007@> has joined #yocto06:13
*** fatalhalt <fatalhalt!> has joined #yocto06:14
*** master007 <master007!~master007@> has quit IRC06:16
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto06:22
*** rcoote <rcoote!> has joined #yocto06:24
*** feddischson <feddischson!> has joined #yocto06:24
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:e578:ceb8:2d49:5a08> has joined #yocto06:31
*** ilkappe <ilkappe!c65a42b1@gateway/web/cgi-irc/> has joined #yocto06:36
ilkappeHello guys, this is not strictly yocto related, but I'm not sure what the following line of code does in a recipe: DTC_FLAGS_append = "${@['', ' -@'][d.getVar('YAML_ENABLE_DT_OVERLAY') == '1']}"06:37
ilkappecan anyone explain that to me ?06:37
RPilkappe: its a bit 'clever'. d.getVar('YAML_ENABLE_DT_OVERLAY') == '1' is either true or false (0 or 1)06:39
RPilkappe: that then becomes ['', ' -@'][0] or ['', ' -@'][1], i.e. the first or second elements of the list06:40
ilkappeRP, thanks06:40
ilkappeso basically it checks if YAML_ENABLE_DT_OVERLAY is 1 or 0 right ?06:40
RPilkappe: and returns a different value for each case, yes06:41
RP'' or '-@'06:41
*** gsalazar <gsalazar!955ab50e@gateway/web/cgi-irc/> has joined #yocto06:41
*** Ninic0c0 <Ninic0c0!> has joined #yocto06:47
*** micka_ <micka_!> has joined #yocto06:48
Ninic0c0Hi all, in order to keep a really tiny rootfs size I would like to remove zImage and uImage from the kernel but I would like to keep this artifacts built. Any clue ? Thx :)06:48
Ninic0c0remove from the rootfs of course... #Morning06:48
*** lxc <lxc!> has joined #yocto06:49
henriknjimage postprocess command?06:49
henriknjor rootfs06:50
Ninic0c0henriknj Yes but not sure that is the proper way to do :S06:50
Ninic0c0Thx for replying btw :)06:50
lxcI want to create a docker image by importing the rootfs. how can I get the rootfs name from the image bb?06:52
*** andycooper <andycooper!uid246432@gateway/web/> has quit IRC06:53
*** mdp <mdp!sid49840@gateway/web/> has quit IRC06:53
*** jonmason <jonmason!sid36602@gateway/web/> has quit IRC06:53
*** awafaa <awafaa!sid716@gateway/web/> has quit IRC06:53
*** smurray <smurray!sid98062@gateway/web/> has quit IRC06:53
*** mithro <mithro!sid24875@gateway/web/> has quit IRC06:53
*** darknighte <darknighte!sid214177@pdpc/supporter/professional/darknighte> has quit IRC06:53
*** ernstp <ernstp!sid168075@gateway/web/> has quit IRC06:53
*** tardyp <tardyp!sid45259@gateway/web/> has quit IRC06:53
*** dl9pf <dl9pf!sid395223@opensuse/member/dl9pf> has quit IRC06:53
*** ric96 <ric96!sid234506@gateway/web/> has quit IRC06:53
*** mirzak <mirzak!sid303002@gateway/web/> has quit IRC06:53
*** jonmason <jonmason!sid36602@gateway/web/> has joined #yocto06:54
*** mdp <mdp!sid49840@gateway/web/> has joined #yocto06:55
Ninic0c0@lxc rootfs folder or .cpio ? tar.gz ?06:55
lxcNinic0c0 tar.gz06:55
*** mirzak <mirzak!sid303002@gateway/web/> has joined #yocto06:55
*** ernstp <ernstp!sid168075@gateway/web/> has joined #yocto06:55
Ninic0c0lxc ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar.gz ?06:55
*** awafaa <awafaa!sid716@gateway/web/> has joined #yocto06:56
*** andycooper <andycooper!uid246432@gateway/web/> has joined #yocto06:56
*** darknighte <darknighte!sid214177@pdpc/supporter/professional/darknighte> has joined #yocto06:56
*** mithro <mithro!sid24875@gateway/web/> has joined #yocto06:56
*** ric96 <ric96!sid234506@gateway/web/> has joined #yocto06:56
*** dl9pf <dl9pf!sid395223@opensuse/member/dl9pf> has joined #yocto06:56
*** tardyp <tardyp!sid45259@gateway/web/> has joined #yocto06:56
*** smurray <smurray!sid98062@gateway/web/> has joined #yocto06:57
lxcNinic0c0 that was what I was trying but the IMGDEPLOYDIR was empty. Is it possible to invoke docker in the do_rootfs_append callpoint?06:57
Ninic0c0@lxc Why don't use Yocto output as Docker input ? Not sure if Yocto is able to manage Docker itself06:58
Ninic0c0wait for a super user :)06:58
lxcNinic0c0 true, but want to integrate the docker creation into the yocto build environment rather than having a separate build step for creating the docker.06:59
*** bradfa <bradfa!sid297668@gateway/web/> has quit IRC07:00
Ninic0c0@lxc ok so maybe take a look to
RPNinic0c0: I think those are in separate packages so its a question of stopping those packages being installed into the rootfs07:01
Ninic0c0RP I have tried to use RDEPENDS_kernel-base = "" to clear but no succes07:02
*** bradfa <bradfa!sid297668@gateway/web/> has joined #yocto07:04
*** fatalhalt <fatalhalt!> has quit IRC07:04
*** sagner <sagner!~ags@2a02:169:3df5::edf> has joined #yocto07:07
*** sxiii <sxiii!~sw@2a02:20c8:5640::2> has joined #yocto07:08
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:09
*** manuel1985 <manuel1985!> has quit IRC07:20
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC07:21
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:21
*** cbs <cbs!~cbs@> has quit IRC07:23
*** cbs <cbs!~cbs@> has joined #yocto07:28
qschulzNinic0c0: where did you put this line?07:55
Ninic0c0tried inside conf/local.conf and image recipe. Warning because value ahs been overrided07:56
qschulzNinic0c0: RDEPENDS_${KERNEL_PACKAGE_NAME}-base = ""07:57
qschulzin conf/local.conf or a bbappend for your kernel recipe07:57
qschulzif it is not enough, something else wants to install it and you'll have to look for it with bitbake -g <recipe> and inspect the dot files manually07:57
Ninic0c0qschulz Thx for insfo :)08:02
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC08:02
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto08:02
*** NiksDev <NiksDev!~NiksDev@> has quit IRC08:06
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto08:07
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto08:08
*** PaowZ_ <PaowZ_!~Vince@> has quit IRC08:08
LetoThe2ndyo dudes08:09
*** sh00p <sh00p!> has joined #yocto08:12
sh00pHi all, I'm wondering whether or not I should depend on the master branch of meta-poky or the dunfell branch... It seems that stuff on master isn't necessarily backported to dunfell08:12
sh00pI realize this question might be absurd, like 'how are we supposed to know what branch you want', but I'm really just confused - what's the idiomatic way?08:13
LetoThe2ndif everything was backported, what would the difference and therefore point of an LTS be at all?08:13
LetoThe2ndsh00p: dunfell/LTS is meant for usage in projects right now. master is where the magic happens08:13
sh00pright, but now I found this bug in the golang version shipped in LTS, so I need a fix from master08:14
sh00pI guess i should backport that recipe myself then08:14
LetoThe2ndthere is a clear policy on what gets backported. if you need somthing else, then rip it out of master and put it into your own additional layer08:15
*** PaowZ_ <PaowZ_!~Vince@> has joined #yocto08:16
sh00pgotcha LetoThe2nd, thanks08:17
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:20
Ninic0c0qschulz Thx for the solution that makes the trick :)08:23
qschulzsh00p: though... if it is a patch backport from master and not a recipe version bump, please send a backport patch for what you need so others benefit from it :)08:26
sh00pqschulz, yeah the thought struck me as well.. I might give that a try :)08:27
qschulzNinic0c0: warnings aren't good, this one is pretty well known (some other too) so when you have one, try working on it a bit and see if it makes the situation better. Worst case scenario, you have one less warning :)08:27
Ninic0c0qschulz :)  :)08:28
qschulzLetoThe2nd: hello from the top of my tree house built around an explosive tree08:29
LetoThe2ndAh that.08:32
LetoThe2ndTBH, its awesome to be quite decoupled from the wide world for some time.08:32
*** camus <camus!~Instantbi@> has joined #yocto08:33
*** kaspter <kaspter!~Instantbi@> has quit IRC08:34
*** camus is now known as kaspter08:34
qschulzwho would have thought in 2020 :)08:38
*** florian_kc is now known as florian08:41
lxcWhen is ROOTFS_POSTPROCESS_COMMAND invoked? Before or after rootfs.tar.gz is created?08:44
qschulzlxc: before08:46
lxcqschulz thanks!08:47
*** clementp[m] <clementp[m]!cperonmatr@gateway/shell/> has quit IRC08:52
*** henriknj <henriknj!hnjematrix@gateway/shell/> has quit IRC08:52
*** f0h[m] <f0h[m]!f0hmatrixo@gateway/shell/> has quit IRC08:52
*** silviof <silviof!silv-iomat@gateway/shell/> has quit IRC08:52
*** xicopitz[m] <xicopitz[m]!xicopitzma@gateway/shell/> has quit IRC08:53
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/> has quit IRC08:53
*** kayterina <kayterina!kayterina-@gateway/shell/> has quit IRC08:53
*** nrossi <nrossi!nrossimatr@gateway/shell/> has quit IRC08:53
LetoThe2ndhows stuff these days?08:56
derRichardis it safe to share sstate-cache and downloads among concurrent yocto builds?08:57
qschulzLetoThe2nd: new docs generated by sphinx \o/ (in yocto-docs master since yesterday)09:02
LetoThe2ndqschulz: \m/09:02
rburtonderRichard: yes09:10
*** aurelien <aurelien!~user@fsf/member/aurelien> has quit IRC09:15
*** yangm <yangm!yanyetanot@gateway/shell/> has joined #yocto09:15
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto09:15
derRichardrburton: good :)09:18
*** yangm <yangm!yanyetanot@gateway/shell/> has quit IRC09:19
*** aurelien <aurelien!~user@fsf/member/aurelien> has joined #yocto09:22
*** yangm <yangm!yanyetanot@gateway/shell/> has joined #yocto09:24
*** lxc <lxc!> has quit IRC09:27
rburtonDL_DIR uses a lockfile when writing and sstate writes are atomic09:28
derRichardmakes sense09:32
*** henriknj <henriknj!hnjematrix@gateway/shell/> has joined #yocto09:42
*** nrossi <nrossi!nrossimatr@gateway/shell/> has joined #yocto09:42
*** kayterina <kayterina!kayterina-@gateway/shell/> has joined #yocto09:42
*** hmw1 <hmw1!hmwmatrixo@gateway/shell/> has joined #yocto09:42
*** clementp[m] <clementp[m]!cperonmatr@gateway/shell/> has joined #yocto09:42
*** f0h[m] <f0h[m]!f0hmatrixo@gateway/shell/> has joined #yocto09:42
*** crazoes[m] <crazoes[m]!crazoesmat@gateway/shell/> has joined #yocto09:42
*** xicopitz[m] <xicopitz[m]!xicopitzma@gateway/shell/> has joined #yocto09:42
*** silviof <silviof!silv-iomat@gateway/shell/> has joined #yocto09:42
*** master007_ <master007_!~master007@> has quit IRC09:55
*** Ninic0c0 <Ninic0c0!> has quit IRC10:07
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC10:07
rburtonRP: "The extensible SDK can currently only be built for the same architecture as the machine being built on - SDK_ARCH is set to x86_64 (likely via setting SDKMACHINE) which is different from the architecture of the build machine (aarch64). Unable to continue."  <-- should we just default SDKMACHINE to the build machine's arch?10:09
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto10:10
*** carlsb3rg <carlsb3rg!c147afcf@> has joined #yocto10:14
*** Klanticus <Klanticus!~quassel@> has joined #yocto10:15
carlsb3rgI'm going through @LetoThe2nd 's live series and on the 3rd video he splits the package so the examples get split out into their own package...when Leto changes the .bb files and runs bitbake libanswer, then bitbake example-image, these changes work...when I do it, my image isn't getting updaate10:17
qschulzcarlsb3rg: have you used the exact same variables and operators?10:19
carlsb3rgif I touch a file and poweroff and run bitbake example-image...the file I touched is still on the there is something persistent about the image10:19
qschulzcarlsb3rg: I'm confused by your last message...10:21
carlsb3rgyeah...think everythin is correct and bitbake works etc...but the actual image that gets booted seems to be stuck10:21
qschulzcarlsb3rg: you're not giving us enough information so that we can help you :)10:21
qschulzgive us logs and the changes yoiu did to the recipe or bbappend10:21
qschulzand what you were excpeting and what's happening :)10:21's confusing for me seems that bitbake_doimage etc isn't actually updating the image...because if i do runqemu - a file I touched before I powered off, ran bitbake, and powered on again is still in the image10:22
carlsb3rgand since the image isn't getting updated, the package splitting isn't having any effect either10:23
qschulzcarlsb3rg: have you rebuilt the whole image or just the recipe?10:27
*** camus <camus!~Instantbi@> has joined #yocto10:29
*** kaspter <kaspter!~Instantbi@> has quit IRC10:30
*** camus is now known as kaspter10:30
*** PaowZ_ <PaowZ_!~Vince@> has quit IRC10:31
*** ilkappe <ilkappe!c65a42b1@gateway/web/cgi-irc/> has quit IRC10:31
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC10:45
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto10:45
*** kaspter <kaspter!~Instantbi@> has quit IRC11:07
*** kaspter <kaspter!~Instantbi@> has joined #yocto11:07
carlsb3rgin his example he splits a library package so the example executable gets split into another package...when he does that in the video, the executable isn't installed...11:09
carlsb3rgwhen I do it the executable is still there11:09
*** goliath <goliath!> has joined #yocto11:12
*** pbb <pbb!~quassel@2a0f:4ac0::7> has quit IRC11:23
*** pbb <pbb!~quassel@2a0f:4ac0::7> has joined #yocto11:24
LetoThe2ndcarlsb3rg: If you want the as splitter package to be installed, the you also have to add it to the image m11:29
carlsb3rgnote to self: use prepend (instead of append) when adding to PACKAGES11:29
carlsb3rgthe splitter package was getting installed without adding it11:30
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto11:30
rburtonoe-pkgdata-util can show you from a recipe name what packages were generated, and what they contained11:30
rburtonmuch easier than putting stuff into an image to see11:30
carlsb3rgbut I noticed you were using prepend instead of append in the PACKAGES =+ "${PN}-example" line...I'm guessing this was significant somehow11:31
LetoThe2ndYes it is :-)11:31
carlsb3rgfirst package is "default" or something?11:32
LetoThe2ndKind of. Look at bitbake -e to get the details.11:32
rburtonfiles are put into packages in the order of PACKAGES11:32
erboThe files end up in the first package they match the FILES_${PN} for11:32 that I found the source of the error, it's actually possible to learn where I should have looked all along :)11:33
* LetoThe2nd is out again, plus there are way more competent folks than me around.11:33 seems so obvious now :\11:34
carlsb3rgthanks :)11:34
qschulzcarlsb3rg: I asked about the operators :)11:35
*** berton <berton!~berton@> has joined #yocto11:43
*** rizzitello <rizzitello!~quassel@> has joined #yocto12:20
*** gsalazar <gsalazar!955ab50e@gateway/web/cgi-irc/> has quit IRC12:34
carlsb3rgyes, did...but I genuinely didn't say that he used prepend instead of append so in my eyes everything was correct :D12:44
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC12:45
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto12:45
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC12:49
qschulzLetoThe2nd: BTW, PACKAGE_BEFORE_PN might be a better solution than prepending :)12:49
carlsb3rgthanks for the tip about oe-pkgdata-util, rburton...very useful12:50
carlsb3rgbitbake -e seems so overwhelming to a n00b...but I'll try it out a bit more12:51
rburtonits a dump of the data store so sometimes incredibly useful, sometimes not useful at all12:51
rburtonie for debugging package contents, it doesn't help12:51
carlsb3rgI would have seen that libanswer-example got appended rather than prepended...but that wouldn't have helped much before the rest of the assistance I got here :D12:53
*** lxc <lxc!> has joined #yocto12:54
carlsb3rgglad I made the mistake though...learnt something I wouldn't have learned from the video series otherwise12:54
carlsb3rgwatching the videos at 125% speed so I get to see Josef munching cookies like a boss12:57
rburtonnew name: cookie monster12:58
*** WillMiles <WillMiles!~Will@> has joined #yocto13:11
*** kaspter <kaspter!~Instantbi@> has quit IRC13:13
*** kaspter <kaspter!~Instantbi@> has joined #yocto13:13
lxchow can I capture console output from image generation command and show stdout? E.g. redirect ROOTFS_POSTPROCESS_COMMAND to stdout.13:23
qschulzlxc: the stdout/stderr is stored in WORKDIR/temp/log.do_<task> of your recipe13:23
qschulzor you can use bbnote13:24
*** gsalazar <gsalazar!955ab50e@gateway/web/cgi-irc/> has joined #yocto13:28
lxcqschulz bbnote is not visible if done from a ROOTFS_POSTPROCESS_COMMAND function.13:28
qschulzlxc: are you using bitbake -DDD?13:30
qschulz(bbwarn otherwise if you don't want to increase hte log level of bitbake)13:30
*** shan1 <shan1!> has joined #yocto13:38
*** rcoote <rcoote!> has quit IRC13:38
rburtonlxc: won't be visible on the console, will be written into the log files that qschulz said13:39
lxcrburton no way to force that output on stdout?13:40
rburtonbbwarn. or turning up the log level with -D should do it13:41
shan1Hi guys there seems to be a bug with `devtool` or at least when I am working with it. I had previously ported a python app using `devtool add python3-gpsfluxlite <tar.gz file github archive>` and everything works perfect. I clean up using `devtool finish python3-gpsfluxlite ../to/my/layer` and `devtool reset python3-gpsfluxlite`. To be even more13:43
shan1sure I do `rm -rf workspace/sources/python3-gpsfluxlite` and remove the source code from the workspace. Now I wish to port another app called bnofluxlite and when I do `devtool add python3-bnofluxlite <tar.gz from github archive>` and edit the recipe using `devtool edit-recipe python3-bnofluxlite` I still see the Source directory `S` set to13:43
shan1Even the `devtool` log still mentions the other `INFO: Scanning paths for packages & dependencies: gpsinfluxlite, bin/gpsinfluxlite` which is not at all the source added13:44
shan1what am I doing wrong here?13:50
qschulzshan1: are you sure the github archive is correct for python3-bnofluxlite?13:53
qschulzalso what's inside this tarball (like the name of the first directory in the archive)13:53
shan1my recipe even shows the write URL for the repository:
*** ericch <ericch!> has joined #yocto13:55
shan1qschulz here is the recipe created
shan1The only thing I changed is the `RDEPENDS_${PN}` from `python-dep_name` to `${PYTHON_PN}-dep_name` so that it is python3 compatible13:58
qschulzshan1: no idea... However, since it's a git repo, just use the git protocol instead of using a tarball :)14:00
erboshan1: What was the exact parameters you passed to devtool add, including the path to the github tar.gz?14:00
shan1I would like to write the recipe by hand but then what would be the point of `devtool` if it worked just one and I am sticking to tim orling's philosophy by using `devtool` as much as possible14:00
shan1qschulz : `devtool add python3-bnofluxlite `14:01
qschulzshan1: no tool is ever perfect :)14:01
shan1I am using `warrior` branch because the PHYTEC boards for the particular hardware have works based on `warrior`14:02
qschulz(though it needs to be reported if there's a bug obviously)14:02
qschulzwell.. not on warrior :p14:02
marexshan1: which board is that ?14:05
shan1Also I edited the recipe for the `S = "${WORKDIR}/bnofluxlite-${PV}" and adapted my recipe to accept python3 runtime deps and install the systemd script. I refactored the recipe to look like standard python recipes i.e. `` and `` but then I keep getting an error stating that `LICENSE` field is not14:05
shan1set even though it it14:05
shan1phyBOARD-MIRA imx614:06
marexshan1: imx6 has fantastic mainline support, why use any of the phytec layers ?14:06
shan1due to device mappings and other hardware stuff, plus I am too deep into the whole phytec stuff in order to change now14:07
erboshan1: Hmm, seems like a second "devtool add something http://path/to/same/filename.tar.gz" doesn't cause the tarball in the downloads folder to be updated14:08
erboUnless I'm just to friday tired14:08
shan1If you guys want I can write up the complete steps to reproduce this error and all the ways I changed things on StackOverflow or any other method you prefer14:09
*** NiksDev <NiksDev!~NiksDev@> has quit IRC14:10
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto14:11
erboshan1: that seems to be the bug though, if a file with the same name is already in downloads/ it won't be replaced.14:11
shan1erbo from my findings I stick to `python3-appname` for recipes because the apps are in python3. If you want I can try `devtool add bnofluxlite <tarball archive link>` and see if the recipe actually adapts14:13
erboshan1: The problem is that the tarball you pass at the end of devtool add has the same name. You could instead just point it to the git repo, so it will fetch using git instead and it will work.14:14
erboshan1: but you still found a bug in devtool though14:15
shan1I hope the OE/Yocto Gods don't rain their anger on me for a bug! :nervous:14:15
shan1also do the pros in the chat open a bug report or do I have to do it?14:16
*** sxiii <sxiii!~sw@2a02:20c8:5640::2> has quit IRC14:17
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC14:19
*** jobroe <jobroe!> has quit IRC14:19
shan1Okay lesson learnt I would stick to `--srcrev` with `devtool add` for the time being, this works well14:22
erboshan1: I think it would be good if you file a bug, that way it won't be missed. (I am by no means one of the "pros")14:24
*** nslu2-log <nslu2-log!> has joined #yocto14:26
*** nslu2-log_ <nslu2-log_!> has joined #yocto14:31
*** ibinderwolf <ibinderwolf!> has quit IRC14:32
*** nslu2-log <nslu2-log!> has quit IRC14:34
*** nslu2-log_ is now known as nslu2-log14:35
*** kpo_ <kpo_!> has quit IRC14:36
*** kpo_ <kpo_!> has joined #yocto14:37
shan1anyone know if the bugr report happens through bugzilla or a mailing list?14:40
RPshan1: its expected you open a bug in bugzilla14:44
zeddiiand then send a patch! ;)14:44
RPyes, it depends where the issue is. meta-oe stuff would be the mailing list and not the bugzilla as the bugzilla basically only covers oe-core/bitbake14:45
shan1devtool is on bugzilla right?14:45
* zeddii goes back to his yocto project summit CFP hackery.14:45
RPshan1: its an oe-core tool, so ye14:47
RPas zeddii says, patches are very welcome, we don't have many people working on bugs atm sadly14:48
*** C-o-r-E <C-o-r-E!> has joined #yocto14:48
*** nslu2-log <nslu2-log!> has quit IRC14:51
zeddiiindeed. take my comment as a friendly joke :D bug reports are important. Just know they are landing on a pile.14:51
*** nslu2-log <nslu2-log!> has joined #yocto14:51
*** pev <pev!> has joined #yocto14:53
pevHeya... What strategies do you guys have for splitting build directories, downloads and sstate-cache dirs? I've got maybe 5-10 target machines that I build over a few different Yocto versions. I kind of feel like keeping separate download and sstate cache dirs per major yocto release makes sense. However what about build dirs? One per CPU type, assuming the same yocto version and that no major different component differences? Or14:56
pevshould I literally keep it to one build per target machine ever?14:56
*** kpo_ <kpo_!> has quit IRC14:56
*** kpo_ <kpo_!> has joined #yocto14:56
pevI can't seem to find anything about the intended way of doing things for anything more than building one target at a time and I'm sure lots of people must do multiple builds...?14:56
*** PaowZ_ <PaowZ_!~Vince@> has joined #yocto14:57
RPpev: DL_DIR can be shared between all, SSTATE_DIR probably makes sense per release series. build directories are safe for multiple machines, not multiple distro configs though15:00
RPyou can safely put all sstate in one too, I've just found it easier to keep separate for deletion15:01
*** sxiii <sxiii!> has joined #yocto15:01
pevRP: Ah OK, I think i was going to split DL_DIR so I could bundle and re-distribute per-release to other machines rather than doing the whole lot. sstate I'd wondered about per-release as occasionally I've had weird things happen and I've found myself deleting the sstate-cache and things recovering after...15:03
*** nslu2-log_ <nslu2-log_!> has joined #yocto15:04
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto15:04
shan1@zeddi I am willing to submit a patch, where is the source code and where should I be looking for `devtool` scripts?15:05
*** nslu2-log <nslu2-log!> has quit IRC15:07
*** nslu2-log_ is now known as nslu2-log15:08
shan1zeddii am willing to submit a patch, where is the source code? on github?15:09
*** nslu2-log_ <nslu2-log_!> has joined #yocto15:10
pevRP: If you don't mind sanity checking, would the following look like it makes sense?
*** nslu2-log <nslu2-log!> has quit IRC15:13
zeddiishan1: you should have cloned the repos to start working with devtool, that's the source code. here's a link to the yoctoproject wiki on patch submission
*** sxiii <sxiii!> has quit IRC15:13
zeddiiother's might know if there's a newer reference than that.15:13
*** nslu2-log <nslu2-log!> has joined #yocto15:13
*** nslu2-log_ <nslu2-log_!> has quit IRC15:15
*** carlsb3rg <carlsb3rg!c147afcf@> has quit IRC15:21
*** mbulut <mbulut!> has quit IRC15:24
*** rcw <rcw!~rcw@> has joined #yocto15:28
*** shan1 <shan1!> has quit IRC15:31
*** Jebee <Jebee!> has joined #yocto15:37
RPpev: its ok, but I'd combine stuff personally. sstate should not break over different releases, its just a convenience thing that I end up splitting them15:38
JebeeHi, I'm trying to automatically load the spidev kernel module on boot. I've added KERNEL_MODULE_AUTOLOAD += "spidev" into my .conf file and now there is a /etc/modules-load.d/spidev.conf file with spidev in there. But for some reason it doesn't load on boot. If i use insmod or modprobe it is loaded just fine. Is there anything else I have to do? It15:38
Jebeeseems like its ignoring the /etc/module-load.d/ conf files.15:38
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:38
*** kaspter <kaspter!~Instantbi@> has quit IRC15:41
*** nslu2-log_ <nslu2-log_!> has joined #yocto15:49
*** sagner <sagner!~ags@2a02:169:3df5::edf> has quit IRC15:51
*** nslu2-log <nslu2-log!> has quit IRC15:52
*** nslu2-log_ is now known as nslu2-log15:53
JPEWpev: We share sstate and DL_DIR across all our "products" but each product has it's own build directory. We have about ~50 products across 5 different yocto version (2.1 - 3.1)15:57
*** Klanticus <Klanticus!~quassel@> has quit IRC15:57
*** sxiii <sxiii!> has joined #yocto16:03
*** aurelien <aurelien!~user@fsf/member/aurelien> has quit IRC16:03
*** nslu2-log_ <nslu2-log_!> has joined #yocto16:08
*** dev1990 <dev1990!~dev@> has quit IRC16:10
*** nslu2-log <nslu2-log!> has quit IRC16:11
*** nslu2-log_ is now known as nslu2-log16:11
khemJebee: perhaps it has dependency on other modules, check the error logs since KERNEL_MODULE_AUTOLOAD will add it to module-load time which might be early in boot.16:26
Jebeekhem: there should be an error in dmesg correct?16:28
pevRP: Copy that, thanks. At the moment I want to keep DL_DIR cache split as we can use it to package and distribute along side release for offline build but yeah, combining sstate I dont see as so compelling bar needing to delete occasionally. I still feel like I really should wipe it (or not reference) before doing formal release builds though...16:28
pevJPEW: Thanks... Even 'products' that share same CPU / reference design?16:28
pevJPEW: I mean I think separation is what comes naturally to me, but struggle to work out how Yocto expects me to behave..!16:29
JPEWYa, we separate each product because there are "product specific" recipe changes (although, I don't personally *like* that)16:30
JPEWSince sstate is shared between all products, it makes it fast to build a similar product b/c most of it pulls from sstate16:30
JPEWIt's also easier to have the consistent rule that all products have their own directory than try to codify a mechanism where the could share :)16:31
*** manuel1985 <manuel1985!> has joined #yocto16:35
khemJebee: yes or on journal if you use systemd16:37
*** micka_ is now known as micka16:38
khempev: you can create a source mirror ( outside dl_dir) and rsync your dl_dir to it, then you can do clean production builds with clean dl_dir16:39
*** nslu2-log_ <nslu2-log_!> has joined #yocto16:42
khemRP: looking at test_gdb_hardlink_debug are there more msgs coming from gdbtest() ? I dont see much in logs16:43
khemAssertionError: GDB /usr/bin/hello1 failed16:43
*** moosnat <moosnat!> has joined #yocto16:44
*** nslu2-log <nslu2-log!> has quit IRC16:44
*** aurelien <aurelien!~user@fsf/member/aurelien> has joined #yocto16:44
zeddiiother's might know if there's a newer reference than that.16:44
zeddiihistory and enter!16:45
*** nslu2-log_ is now known as nslu2-log16:45
zeddiiignore the stutter16:45
khemRP: I was expecting some logs from gdbtest() function since it seems to print stuff before returning False on error16:46
RPkhem: good question16:47
sgwRP: got back to running the qemumips with the altcfg and my initial timing to about 19 seconds, still seems faster16:49
RPsgw: does sound faster. Wonder how...16:49
RPkhem: if you look earlier in the logs there is some stuff there16:52
RPrather than the summary at the end16:52
zeddiiheadscratcher of the day. if I copy the busybox recipe exactly, rename it to busybox-foo, adjust ${S} and that's it .. it blows up on Werorr. but yet the original doesn't17:04
dl9pfzeddii: some CFLAGS_pn-busybox hidden somewhere ?17:19
dl9pfzeddi: poky/meta/conf/distro/include/ = ""17:19
zeddiiheheheh. that's one of the things i'm trying to patch out of the Makefiles.17:21
zeddiiand yes, of course. that wouldn't match my new name.17:21
*** gsalazar <gsalazar!955ab50e@gateway/web/cgi-irc/> has quit IRC17:24
*** manuel1985 <manuel1985!> has quit IRC17:24
* xicopitz[m] sent a long message: < >17:32
*** kiwi_29 <kiwi_29!> has joined #yocto17:46
*** kiwi_29 <kiwi_29!> has quit IRC17:50
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC17:59
*** nslu2-log_ <nslu2-log_!> has joined #yocto18:00
khemRP: I was reading through your system/nice patch, I wonder if we have entropy generation problem on builders18:01
khemRP: see
khemRP: have you oberved these failures on a particular distro ?18:02
*** nslu2-log <nslu2-log!> has quit IRC18:02
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto18:02
*** nslu2-log_ is now known as nslu2-log18:03
khemRP: maybe installing haveged on the builders could atleast validate if this is the issue18:03
khemor perhaps see if kernels on builders are using CONFIG_RANDOM_TRUST_CPU18:03
RPkhem: we're specifically pointing the virtio rng at /dev/urandom so it has a free source of random data18:05
RPkhem: we did once have entropy issues but this doesn't look like it to me18:06
RPkhem: the gdb failures are <<< run_serial(): command timed out after 60 seconds without output >>> - i.e. the serial commands are timing out18:06
RPI commented in the bug18:06
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto18:08
*** Jebee <Jebee!> has quit IRC18:13
khemRP: yeah it seem hello1 debug hangs18:17
RPkhem: I suspect its just a slow to boot image :/18:18
khemRP: I would still like to see haveged experiment if we can easily18:18
RPkhem: just a question of someone doing the work :/18:19
RPkhem: I'm not convinced its an entropy problem18:19
khemthe gdb case is not generally reproducible it seems I tried it here and it works all the time18:19
khemRP: Agreed, but symptoms seems to be so18:19
RPkhem: right, works for me locally and worked on that worker when I reran the test with the same builddir18:19
*** nslu2-log_ <nslu2-log_!> has joined #yocto18:20
khemRP: is qemu loaded with other stuff when hello1 is being run in gdb I wonder18:20
RPkhem: no, the symptoms are not. For example look at the systemd boot chart Joshua put in the bug - shows heavy CPU usage by openssh continually.18:20
RPif it were blocked on entropy it would stutter18:20
*** kiwi_29 <kiwi_29!> has joined #yocto18:20
RPalso, the getty isn't blocked on the ssh daemon coming up18:21
khemis bootchart on ml somewhere ?18:21
RPits just the ssh keygen pinches the cpu cycles18:21
RPkhem: its attached to
khemand do we see it with dropbear in same fashion18:22
RPkhem: no, qemu shouldn't be. but it is freshly booted when running the gdb test18:22
*** nslu2-log <nslu2-log!> has quit IRC18:22
*** nslu2-log_ is now known as nslu2-log18:22
RPkhem: we don't see it with dropbear, I suspect as its keygen is less cpu sensitive18:22
khemssh-keygen is taking long but I dont think its indicative of CPU load18:24
khemits just showing how long its taking to finish18:24
*** nslu2-log_ <nslu2-log_!> has joined #yocto18:24
khemrun-postinsts.service takes 26s so ssh-keygen waits for that to finish hmm18:26
*** sxiii <sxiii!> has quit IRC18:26
RPkhem: but the logind which is blocking things isn't waiting on the keygen18:27
*** sxiii <sxiii!> has joined #yocto18:27
*** nslu2-log <nslu2-log!> has quit IRC18:27
*** nslu2-log_ is now known as nslu2-log18:27
khemright, it waits on post-installs though18:29
*** Klanticus <Klanticus!~quassel@> has joined #yocto18:32
*** lxc <lxc!> has quit IRC18:37
*** meow`_ <meow`_!> has joined #yocto18:38
khemRP: here is what I see for qemumips on my machine
*** meow` <meow`!~sbourdeli@> has quit IRC18:39
khem2.642s dropbearkey.service18:39
khemnow let me try with openssh as well18:39
khemthis is minimal image btw18:40
*** rizzitello <rizzitello!~quassel@> has quit IRC18:46
*** nslu2-log_ <nslu2-log_!> has joined #yocto18:49
*** zandrey <zandrey!> has joined #yocto18:52
*** nslu2-log <nslu2-log!> has quit IRC18:52
*** nslu2-log_ is now known as nslu2-log18:52
khemRP: I was wondering if we should do socket activation for ssh instead18:56
khemthat atleast will defer the first time key generation18:56
khemuntill 1st ssh connection18:56
ecdheI have a vendor-provided buildroot bsp (which builds U-Boot, a kernel Image, and a rootfs) that I want to convert to yocto.  I can see from googling that people have done this before, but I haven't seen much in the way of guidance.19:16
ecdheAny resources for making the transition?19:16
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC19:17
RPkhem: we do socket activation don't we?19:26
RPkhem: the issues we're seeing are with pam enabled with systemd19:26
*** mbulut <mbulut!> has joined #yocto19:27
*** meow`_ <meow`_!> has quit IRC19:38
*** meow` <meow`!~sbourdeli@> has joined #yocto19:38
tlwoernerbluelightning_: i'm trying to get devtool to create a recipe with a version number in the recipe name instead of recipe_git.bb19:50
tlwoernerbluelightning_: it looks like recipetool supports that with the -o|--outfile option19:50
tlwoernerbluelightning_: but there's no pass-through from "devtool add"?19:51
tlwoernerwhen i see "" in a recipe name, i tend to assume it's an autorev recipe. is that a silly assumption?19:52
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC20:02
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto20:02
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC20:03
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto20:04
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto20:05
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC20:05
*** kiwi_29 <kiwi_29!> has quit IRC20:06
khemRP: with pam I am seeing 56.963s sshdgenkeys.service but dropbear is better 22.184s dropbearkey.service20:06
khemthe previous numbers I gave were with musl20:07
*** feddischson <feddischson!> has quit IRC20:08
*** kiwi_29 <kiwi_29!> has joined #yocto20:08
*** kiwi_29_ <kiwi_29_!> has joined #yocto20:09
*** kiwi_29 <kiwi_29!> has quit IRC20:09
RPkhem: right, that sounds more like what we were seeing too20:12
RPkhem: with a 60s timeout on the getty logging in, it was sometimes hitting the timeout, sometimes not20:12
khemperhaps we should use dropbear exclusively on mips images20:12
RPkhem: well, we just increase the timeout20:12
khemmost of mips users are using dropbear20:13
khemsame for arm/ppc perhaps20:13
neverpanicIs there no HW RNG on MIPS?20:13
khemthere is20:14
neverpanicThere is on most ARM chips, I guess, so enabling that would help?20:14
khemwe are talking qemu here20:14
neverpanicAh, I see.20:14
*** nslu2-log_ <nslu2-log_!> has joined #yocto20:16
*** nslu2-log <nslu2-log!> has quit IRC20:18
*** nslu2-log_ is now known as nslu2-log20:19
*** nslu2-log_ <nslu2-log_!> has joined #yocto20:21
khemRP: but pam/systemd/musl combo is pretty fast I wonder why20:21
*** kiwi_29_ <kiwi_29_!> has quit IRC20:21
khem2.642s vs 22.184s20:21
khemRP: in real world I think no one generate the sshkeys on fly, so another solution could be to add pregenerated keys to qemu images20:23
*** nslu2-log <nslu2-log!> has quit IRC20:24
*** nslu2-log_ is now known as nslu2-log20:24
*** kiwi_29 <kiwi_29!> has joined #yocto20:24
armpitdoes generating them while flying count ?20:26
neverpanicOnly if you drop physical dices from more than 1000 ft to generate them.20:27
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC20:30
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto20:31
*** kiwi_29 <kiwi_29!> has quit IRC20:35
RPkhem: interesting, I keep wondering why pam is so slow :/20:36
RPkhem: didn't musl systemd disable some things?20:38
*** berton <berton!~berton@> has quit IRC20:38
*** sbach <sbach!~sbach@> has joined #yocto20:41
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC20:46
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto20:47
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC20:48
*** nslu2-log_ <nslu2-log_!> has joined #yocto20:49
*** WillMiles <WillMiles!~Will@> has quit IRC20:50
*** nslu2-log <nslu2-log!> has quit IRC20:51
*** nslu2-log_ is now known as nslu2-log20:52
*** yann <yann!~yann@> has joined #yocto20:55
ecdheI am porting a buildroot BSP/distro to yocto.  I thought I'd start with U-Boot; I was able to get a recipe which causes yocto to build the same source tree that Build Root uses.20:59
ecdheHowever, buildroot doesn't just build the tree; it has a pre-build command that concatenates two U-Boot configuration files together `cat module.conf baseboard.conf > actual_uboot_defconfig'21:00
ecdheI'm trying to determine how to best replicate this in yocto21:01
ecdheI'm guessing yocto won't let me cd uboot/config and start modifying files in the source tree21:01
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto21:01
ecdheSo I COULD use a patch to the vendor's uboot repo that merges the configuration I'm intersted in and supplies it as config/myproject_deconfig21:02
ecdhehowever, the vendor may well update the original configurations and I want to be able to access them by bumping my SRCREV without having to regenerate the patch21:03
ecdheAlso, it seems like I should probably have a meta-module layer and a meta-baseboard layer; each one would override its respective variable in the meta-vender-core layer, then meta-vendor-core would be responsible for performing the concatenation step21:04
ecdheThat would be the most extensible path (in case I have to work with different modules or baseboards from the vendor in the future)21:05
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto21:15
alejandrohsecdhe: yocto would allow you to do that, you can modify for example the do_configure function on the recipe, or prepend to it to concatenate those two files21:16
alejandrohsecdhe: you can look at the libpcap or nfs-utils recipe for an example, those two both modify a file before building the source code21:19
alejandrohssakoman: Would the recent patches to the cve-db recipe make sense to backport to dunfell? (the ones sent right after you backported some of them)21:21
alejandrohssakoman: specifically the one that avoids using anonymous python21:21
sakomanalejandrohs: I think so.  I'm inclined to take them because one of the main goals of LTS is to keep up with CVE fixes, and improving the cve code seems in line with that goal21:22
*** nslu2-log_ <nslu2-log_!> has joined #yocto21:23
sakomanI'm just about to release 3.1.3, so I won't take them till after that21:23
sakomanI don't like last minute changes, they usually bite me :-)21:24
*** nslu2-log <nslu2-log!> has quit IRC21:25
*** nslu2-log_ is now known as nslu2-log21:26
alejandrohssakoman: I did get a failure after the ones you already pulled, I'm currently testing the new ones, but I do think moving stuff out of the anon python was a good idea21:28
alejandrohssakoman: sure, sounds good, thanks21:28
sakomanalejandrohs: Is it a serious failure?21:29
sakomanSomething I should revert before releasing?21:29
ecdhethanks alejandrohs21:29
*** pohly <pohly!> has quit IRC21:38
alejandrohssakoman: same as before, failed on the race condition21:43
sakomanalejandrohs: OK, so not a new failure?21:44
sakomanIf that's the case, then no need to revert anything21:45
alejandrohssakoman: yeah no need for that21:51
*** nslu2-log_ <nslu2-log_!> has joined #yocto21:52
*** nslu2-log <nslu2-log!> has quit IRC21:55
*** nslu2-log <nslu2-log!> has joined #yocto21:56
*** beneth <beneth!> has left #yocto21:58
*** nslu2-log_ <nslu2-log_!> has quit IRC21:58
*** nslu2-log_ <nslu2-log_!> has joined #yocto22:03
*** nslu2-log <nslu2-log!> has quit IRC22:05
*** nslu2-log_ is now known as nslu2-log22:05
*** nslu2-log_ <nslu2-log_!> has joined #yocto22:10
*** nslu2-log <nslu2-log!> has quit IRC22:12
*** nslu2-log_ is now known as nslu2-log22:12
*** yann <yann!~yann@> has quit IRC22:38
*** mbulut <mbulut!> has quit IRC22:39
*** nslu2-log_ <nslu2-log_!> has joined #yocto22:47
*** nslu2-log <nslu2-log!> has quit IRC22:49
*** nslu2-log_ is now known as nslu2-log22:49
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC22:50
*** rcw <rcw!~rcw@> has quit IRC23:07
*** dev1990 <dev1990!> has joined #yocto23:13
*** creich <creich!> has quit IRC23:19
*** creich <creich!> has joined #yocto23:19
khemRP: yeah it disables gshadow I wonder if that does it23:20
*** moosnat <moosnat!> has quit IRC23:27
*** Klanticus <Klanticus!~quassel@> has quit IRC23:32
*** agust <agust!> has quit IRC23:44
*** ericch <ericch!> has quit IRC23:50
*** Ad0 <Ad0!~Ad0@> has quit IRC23:52
*** leon-anavi <leon-anavi!~Leon@> has quit IRC23:54
*** nslu2-log_ <nslu2-log_!> has joined #yocto23:57
*** Ad0 <Ad0!~Ad0@> has joined #yocto23:59
*** nslu2-log <nslu2-log!> has quit IRC23:59

Generated by 2.17.2 by Marius Gedminas - find it at!