| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 00:19 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 00:37 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 01:01 | |
| *** ckalluri731 <ckalluri731!~ckalluri@2601:647:5b00:64f0:9903:9d60:27da:f63a> has quit IRC | 01:56 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 02:54 | |
| *** d_thomas <d_thomas!cffae6c2@207.250.230.194> has quit IRC | 03:41 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 04:52 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 05:16 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 05:22 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 05:59 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 06:04 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.187> has quit IRC | 06:11 | |
| *** kaspter <kaspter!~Instantbi@222.67.152.154> has joined #yocto | 06:11 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 06:21 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 06:27 | |
| *** kaspter <kaspter!~Instantbi@222.67.152.154> has quit IRC | 06:28 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.177> has joined #yocto | 06:28 | |
| *** Scoutboy <Scoutboy!~quassel@213-73-234-40.cable.dynamic.v4.ziggo.nl> has quit IRC | 06:57 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 07:04 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 07:05 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 07:06 | |
| *** alessioigor <alessioigor!~alessioig@140.105.207.227> has quit IRC | 07:12 | |
| *** alessioigor <alessioigor!~alessioig@140.105.207.227> has joined #yocto | 07:15 | |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto | 07:15 | |
| *** dv_ <dv_!~dv@62.178.50.190> has joined #yocto | 07:19 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto | 07:26 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 07:37 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto | 07:48 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 07:55 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 07:56 | |
| *** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto | 08:00 | |
| mckoan | good morning | 08:00 |
|---|---|---|
| frosteyes | mckoan: morning | 08:02 |
| alessioigor | good morning | 08:23 |
| kayterina | hello hello | 08:23 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 08:31 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:51 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 09:09 | |
| *** goliath <goliath!~goliath@82.150.214.1> has joined #yocto | 09:10 | |
| *** camus <camus!~Instantbi@101.93.194.160> has joined #yocto | 09:12 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 09:12 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.177> has quit IRC | 09:14 | |
| *** camus is now known as kaspter | 09:14 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 09:24 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-bjvnvqvazmfeowhb> has joined #yocto | 09:24 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 09:31 | |
| *** nayfe <nayfe!uid259604@gateway/web/irccloud.com/x-iybayhxvnvcxinuw> has joined #yocto | 09:48 | |
| *** bojones <bojones!~jonas@customer-2a00-7660-0846-0001-020c-29ff-fed5-d5b4.ip6.gigabit.dk> has quit IRC | 10:04 | |
| *** yann <yann!~yann@85.118.38.73> has joined #yocto | 10:13 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 10:26 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 10:27 | |
| *** goliath <goliath!~goliath@82.150.214.1> has quit IRC | 10:59 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 11:13 | |
| *** litb <litb!~jschaub@pd907fca9.dip0.t-ipconnect.de> has joined #yocto | 11:13 | |
| litb | hello folks | 11:13 |
| litb | what is the meaning of ?= together with override statements? | 11:13 |
| litb | like FOO_myoverride ?= baz | 11:13 |
| litb | will it be like "if Foo is not assigned yet, then if 'myoverride' is active, assign baz" ? | 11:14 |
| mcfrisk | litb: yes, allows recipe, appends and classes to override variables | 11:14 |
| mcfrisk | https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#setting-a-default-value | 11:15 |
| *** JaMa <JaMa!~martin@217.30.64.102> has joined #yocto | 11:15 | |
| *** kanavin <kanavin!~kanavin@141.113.66.202> has joined #yocto | 11:21 | |
| litb | mcfrisk, thanks! | 11:25 |
| litb | what's the equivalent of a packagegroup for buildtime dependency grouping? | 11:26 |
| *** hpsy <hpsy!~hpsy@85.203.15.50> has quit IRC | 11:26 | |
| litb | i have a "packagegroup-graphics.bb" that groups required libraries for the GUI. now I need to group build time dependencies. I would think packagegroup should be usable aswell, but I'm not sure | 11:27 |
| *** hmw1 <hmw1!hmwmatrixo@gateway/shell/matrix.org/x-vatbfkmksuyhcndv> has joined #yocto | 11:29 | |
| yocti | New news from stackoverflow: In poky-tiny, why adding openssh also adds bash? <https://stackoverflow.com/questions/58692461/in-poky-tiny-why-adding-openssh-also-adds-bash> | 11:30 |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:33 | |
| rburton | litb: ?= with overrides is meaningless | 11:34 |
| litb | rburton, oh | 11:34 |
| rburton | at least, thats my understanding of how overrides are parsed. | 11:35 |
| rburton | RP: ^ | 11:35 |
| litb | rburton, I found instances in the manual that combine them both | 11:35 |
| rburton | lets get RPs statement then we can either fix the docs or i've learnt something new already | 11:36 |
| litb | SRCREV_pn-matchbox-panel-2 ?= "${AUTOREV}" | 11:36 |
| * rburton tests | 11:37 | |
| litb | ah at least that thing with SRCREV makes intuitive sense! | 11:37 |
| rburton | right so i did PV_pn-m4 ?= "1.2.3" | 11:38 |
| rburton | where bitbake.conf has PV= | 11:38 |
| rburton | and the override took | 11:38 |
| rburton | which you'd expect, no value already to it i assigned | 11:39 |
| litb | at first I was confused because it could also check whether there was already an override-assignment with that exact override flags, rather than only checking for the "base" variable | 11:39 |
| rburton | ok looks like it does what you'd expect, but that behaviour isn't really useful? | 11:39 |
| litb | makes sense to me now | 11:40 |
| rburton | in that you can't have conditional overrides. the override *will* happen | 11:40 |
| rburton | if you have multiple overrides set with ?= then they do chain in that the second ?= doesn't happen | 11:40 |
| rburton | i guess that could be useful if you're layering pieces together | 11:41 |
| litb | oh I see now. it checks for a previous assignment of the base-variable combined with the exact combination of overrides? | 11:42 |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 11:42 | |
| rburton | no | 11:42 |
| rburton | bitbake.conf does PV={take version from filename} | 11:42 |
| rburton | if you do PV_override ?= "2" then if the override is triggered, that happens. | 11:42 |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 11:42 | |
| rburton | another PV_override ?= "3" doesn't override 2 to 3 | 11:43 |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:43 | |
| litb | with potentially a different override even | 11:43 |
| litb | not sure whether I expect PV=... PV_override ?= ,,, to override the value set with "=". I guess I wouldn't | 11:44 |
| rburton | the entire point of an override is that it overrides the value | 11:44 |
| litb | hm, I see | 11:45 |
| mcfrisk | After all the BSP bashing in Lyon, nice to be back at $work and start bashing BSP layer crap. BBMASK += "meta-*bsp*" | 11:54 |
| letothe2nd | mcfrisk: :) | 11:55 |
| RP | rburton: its not exactly useful | 11:55 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 12:00 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 12:02 | |
| letothe2nd | mcfrisk: but, there certainly was no bashing. just very polite, gentle reminders. with a sledge hammer. | 12:13 |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC | 12:14 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto | 12:15 | |
| *** kroon_ <kroon_!~kroon@213.185.29.22> has joined #yocto | 12:16 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 12:17 | |
| *** kroon_ <kroon_!~kroon@213.185.29.22> has quit IRC | 12:20 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 12:20 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has quit IRC | 12:22 | |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 12:49 | |
| litb | my package has a config "debug=0|1", "context=release|develop" and a GUI can be included or not (which will add "gui" at compile time and "install-gui" at install time). | 12:51 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 12:53 | |
| litb | is it a bad idea to "abuse" PACKAGECONFIG for this? the individual groups will then be empty like "PACKAGECONFIG[debug] = ",,". individual variables will query PACKAGECONFIG, like GUI_INSTALLFLAG = "${@oe.utils.contains('PACKAGECONFIG', 'gui', 'install-gui', '')}" | 12:53 |
| litb | and they will be passed in do_compile and do_install such as "./buildscript ${GUI_INSTALLFLAG} dest=${D}" in do_install | 12:54 |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has joined #yocto | 13:01 | |
| letothe2nd | litb: its certainly a way of getting it done. one would probably not do this in a public upstream layer but if it suits your usecase, why not | 13:01 |
| letothe2nd | litb: i'd add that it depends a bit on if you have more packages behaving like that, and if you need to be able to tune them independently. otherwise it might be simpler to add a distro flag like "mycompany-debugtweaks" | 13:03 |
| litb | hm, I see. | 13:03 |
| letothe2nd | so, "it depends" (TM) | 13:03 |
| * mcfrisk rants: why would a BSP layer set GCCVERSION?! | 13:07 | |
| * mcfrisk rants: it only results in a huge list of: NOTE: preferred version 8.2% of gcc-runtime not available (for item gcc-runtime) | 13:09 | |
| letothe2nd | mcfrisk: because $VENDORKERNEL or $VERNDORBOOTLOADER need $OLDGCC to even build | 13:09 |
| letothe2nd | a true classic | 13:09 |
| mcfrisk | except that they dont :) | 13:10 |
| letothe2nd | there's always the possibility that its just a crappy bsp | 13:10 |
| mcfrisk | and I need to explain why mixing clang and gcc for kernel and external kernel modules is "a bad idea (TM)" | 13:11 |
| letothe2nd | (TM) | 13:12 |
| nayfe | Hi any meta-java maintainer here or news about Richard Leitner? or maybe openjre is not embedded jre choice now? ;) | 13:13 |
| qschulz | mcfrisk: can I ask how this clang+gcc mixing is handled in your Yocto? I'm interested in having IRL examples on how people implemented this to find the best way to do it | 13:14 |
| letothe2nd | nayfe: did you reach out for him by mail? thats usually his favorite way of interaction, IIRC | 13:14 |
| mcfrisk | qschulz: inherit clang in recipes, meta-clang as layers. switch from default toolchain gcc to clang using that inherit. | 13:16 |
| mcfrisk | oh, TOOLCHAIN = "clang" is needed too in the recipes. | 13:18 |
| nayfe | letothe2nd> mails on openembedded-devel with meta-java prefix and maintainers in CC do not get answers, it's been a while layer had no activity | 13:19 |
| letothe2nd | nayfe: hm i'm quite sure i readhim in the last couple of weeks | 13:21 |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto | 13:22 | |
| letothe2nd | bu tno time to go searching right now, sorry. | 13:22 |
| qschulz | mcfrisk: ok thanks | 13:24 |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 13:26 | |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has quit IRC | 13:28 | |
| litb | having the paragraph-character available helps quite a lot when searching in the manual | 13:28 |
| litb | often I have to copy the paragraph character out of the manual and paste it into the firefox search field. | 13:29 |
| litb | I guess I should install some "enter unicode character" plugin for this | 13:29 |
| rburton | litb: most environments have a character picker hidden away | 13:33 |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has joined #yocto | 13:34 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 13:35 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 13:40 | |
| *** d_thomas <d_thomas!cffae6c2@207.250.230.194> has joined #yocto | 13:43 | |
| litb | is it a good idea to use weak default assignments "??=" in classes, and normal default assignments "?=" in .bb files? That way, bb files can override choices of classes, but distribs/local.confs can override choices of recipes | 13:44 |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 13:49 | |
| mcfrisk | litb: sounds good to me | 13:52 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 14:04 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 14:11 | |
| litb | sorry, another question! I see class names that contain dashes, but also underscores over the place in the oe-core layer | 14:12 |
| litb | what's the guideline? I wish to use EXPORT_FUNCTIONS, and I suspect it requires the class name to not contain dashes. but beyond that? | 14:13 |
| rburton | why do you want to use EXPORT_FUNCTIONS? | 14:15 |
| litb | rburton, i wrote a class company_scons.bbclass that executes scons with a defined set of targets at compile time and install tim | 14:18 |
| rburton | thats good | 14:18 |
| rburton | so why do you want to use EXPORT_FUNCTIONS? | 14:18 |
| *** copycat88 <copycat88!~copy@195.20.130.1> has joined #yocto | 14:19 | |
| litb | the set of targets can be defined as SCONS_COMPANY_TARGETS and do_install takes the targets and prefixes them with 'install-' and passes those as targets | 14:19 |
| litb | rburton, i wanna provide them as default implementations | 14:19 |
| rburton | as in so a recipe can do do_install() { something; company_scons_do_install ; somethingelse} | 14:20 |
| rburton | ? | 14:20 |
| rburton | 99% of people who write export_functions in a class don't know what it actually does you see | 14:21 |
| litb | hm, maybe it's not worth it. I suspect I can just define do_install() and if the user overrides it, they can just use my scons_company_runscons <myowntargets> | 14:21 |
| rburton | use it if you want, i just wanted to check that you understood what it does | 14:22 |
| litb | rburton, I think of it as providing a do_install() { company_scons_do_install; } . but now I see I don't really need it | 14:22 |
| rburton | some people think it means 'make this function public' and to be honest given the name that makes sense | 14:23 |
| litb | hm, I see. I think I fell into this trap before | 14:24 |
| litb | rburton, I think this task of providing default implementations of do_install that call a classes' function cannot be provided by another class, i.e "exportfunctions.bbclass" ? | 14:27 |
| alessioigor | Has someone idea why few BSP (e.g. meta-ti) seems to ignore the .cfg snippets to change Linux kernel configuration? | 14:27 |
| rburton | alessioigor: because the maintainers of those kernels use a defconfig instead of the kernel fragments framework | 14:27 |
| letothe2nd | alessioigor: IIRC that happens if a kernel is not yocto-ized | 14:28 |
| rburton | as to why they do that, ask them | 14:28 |
| alessioigor | Also meta-intel does it :-( | 14:29 |
| alessioigor | rburton, letothe2nd: Thanks | 14:29 |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has joined #yocto | 14:33 | |
| qschulz | rburton: two included fragments can collide and disable one another, while defconfig guarantees it works well with Kconfig. | 14:34 |
| rburton | why not ship a known good configuration using fragments and then say if you fiddle the config then obviously its your problem | 14:36 |
| rburton | i doubt they'll support someone fiddling the defconfig randomly either | 14:36 |
| rburton | anyway, because they wanted to use a defconfig is the answer. | 14:36 |
| rburton | alessioigor: what kernel in meta-intel uses defconfig? | 14:36 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:d18d> has joined #yocto | 14:38 | |
| alessioigor | rburton: Seems none | 14:39 |
| *** elGamal <elGamal!~elg@5.253.206.78> has quit IRC | 14:39 | |
| *** elGamal <elGamal!~elg@5.253.206.78> has joined #yocto | 14:40 | |
| alessioigor | rburton: linux-ti-staging (meta-ti) uses defconfig whereas linux-intel (meta-intel) my cfg snippet collides with ERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/security/security.scc" | 14:42 |
| alessioigor | Infact I'm trying to turn off netfilter. | 14:43 |
| rburton | alessioigor: unset extra-features? | 14:45 |
| alessioigor | rburton: Yes but I don't know how do the same for linux-ti-staging... Do you have any hint? | 14:46 |
| rburton | alessioigor: for meta-ti, write your own defconfig | 14:47 |
| alessioigor | ouch | 14:48 |
| qschulz | alessioigor: it's fine. run a build without your changes. then run bitbake -c menuconfig linux-ti-staging | 14:49 |
| qschulz | disable what you need, bitbake -c savedefconfig linux-ti-staging, go to the workdir, get the defconfig in the root of ${S} (usually) | 14:50 |
| alessioigor | qschulz: Ok thanks | 14:50 |
| qschulz | put this defconfig where the recipe expects it (or in a bbappend which adds the required logic of loading a defconfig) | 14:50 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 14:52 | |
| d_thomas | Hello, I'm trying to upgrade the version of u-boot Yocto is building by using a recipe in my own custom layer. I have verified the recipe builds v2019.04 when placed in the meta-atmel layer. When I put the recipe in my own layer, the meta-atmel layer version of v2018.07 is built. I think the problem is the "require" statement. How do I proper | 14:53 |
| d_thomas | require/include a file from meta-atmel in my own layer? | 14:53 |
| letothe2nd | d_thomas: require and put the full path in. if it doesn't give you an error, it was successful | 14:53 |
| letothe2nd | d_thomas: include is the same, but will fail silently | 14:54 |
| letothe2nd | (which is usually not what you want) | 14:54 |
| qschulz | d_thomas: shouldn't this be part of a bbappend? | 14:54 |
| *** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has joined #yocto | 14:54 | |
| d_thomas | I'm seeing "Could not include required file meta-atmel/recipes-bsp/u-boot/u-boot-atmel.inc". If I remove the meta-atmel part it silently uses the old version. | 14:55 |
| d_thomas | I went with a bb file since it is a new version, based on a different git commit. Seemed cleaner that way. Otherwise the bbappend name wouldn't match the actual version | 14:56 |
| qschulz | yup, understood. That's what you should do indeed | 14:57 |
| qschulz | you cannot put the name of a layer in the path, Yocto looks from the root of every layer, not elsewhere | 14:57 |
| letothe2nd | yeah, and the version without the meta-atmel is correct. but, this means you have the file twice, under the exact same path? | 14:57 |
| qschulz | require recipes-bsp/u-boot/u-boot-atmel.inc is ok | 14:57 |
| letothe2nd | inside the layers, that is? | 14:57 |
| d_thomas | My intention is that u-boot-at91_2019.04.bb will only be in my layer (2018.07 is currently in the meta-atmel layer) | 14:58 |
| qschulz | letothe2nd: I suspect a PREFERRED_VERSION somewhere? | 14:59 |
| d_thomas | I put u-boot-at91_2019.04.bb in the meta-atmel layer only temporarily to verify that the recipe was correct and that nothing was forcing a preferred version | 14:59 |
| letothe2nd | qschulz: i did the same, but $ASKER claims there is none | 14:59 |
| d_thomas | Correct, so far I can't find anything forcing a version | 15:00 |
| *** copycat88 <copycat88!~copy@195.20.130.1> has quit IRC | 15:00 | |
| letothe2nd | like i said last time, i'm sure it is something rather stupid/weird, but i can't put my finger on it at the moment | 15:01 |
| letothe2nd | why do you need meta-atmel then anyways? | 15:01 |
| d_thomas | Same here :). As soon as I switch to "require recipes-bsp/u-boot/u-boot-atmel.inc", the build proceeds without complaint but ignores v2019.07 | 15:02 |
| d_thomas | I need meta-atmel for the development kit I'm building the image for | 15:02 |
| qschulz | d_thomas: that is normal, all recipes are parsed even if they are not to be compiled or used in any way. | 15:02 |
| qschulz | d_thomas: debug with bitbake u-boot-at91 -DDDDDDDDDDDDDDDDDDDDDDDDDDDDD and maybe that'll help find out something? | 15:03 |
| qschulz | (I never remember how many D's are needed, so I just put as many as my patience let me | 15:04 |
| d_thomas | wow, that's verbose turned up to 11 | 15:05 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 15:10 | |
| d_thomas | That's disappointing. The log just shows the sorted providers for u-boot are just the latest one from meta-atmel | 15:12 |
| letothe2nd | d_thomas: can you just put your layer on github or such? | 15:13 |
| d_thomas | https://pastebin.com/CzuAKY7X | 15:15 |
| d_thomas | That's the recipe | 15:15 |
| letothe2nd | i don't think that the recipe in itself is the problem | 15:16 |
| d_thomas | in a meta-my-custom-layer/recipes-bsp/u-boot directory | 15:16 |
| letothe2nd | i have no better advice at the moment other to make a fresh layer, add just the u-boot and start out testing from there. remove your other custom layer for the build, see if it works or breals. | 15:17 |
| d_thomas | I know my custom layer is getting used, because I had to modify the AT91Bootstrap bootloader to build the way I wanted in Yocto. So that bbappend file is working | 15:17 |
| letothe2nd | and if it breaks, show the whole minimized layer | 15:17 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:d18d> has quit IRC | 15:17 | |
| d_thomas | there just isn't much else in the layer..... the bootloader bbappend, a hello world program, and u-boot | 15:18 |
| letothe2nd | then, put it on github. | 15:18 |
| letothe2nd | if there's nothing magic inside | 15:19 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:d18d> has joined #yocto | 15:19 | |
| *** tgoodwin <tgoodwin!~tgoodwin@static-108-40-78-74.bltmmd.fios.verizon.net> has quit IRC | 15:30 | |
| d_thomas | Is it possible I just need to rebuild the entire image and not just u-boot? | 15:32 |
| letothe2nd | no | 15:34 |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 15:38 | |
| d_thomas | Before posting the repo to github, I'd need to scrub out my ssh configuration. But it's just a basic layer I'm building that I don't see how that would be breaking anything. Seemed like I just needed to get the directory and filename convention correct and this should have worked. | 15:38 |
| denix | rburton: meta-ti uses config fragments | 15:39 |
| denix | but not linux-yocto specific "scc" | 15:39 |
| letothe2nd | d_thomas: if you keep ssh configuretion inside the layer its a bad idea anyways :P | 15:40 |
| d_thomas | Moving it is on the list of things to do. This was just to get an image going that was usable for others | 15:41 |
| d_thomas | Getting Yocto to build u-boot, kernel, etc is just for my own sanity. :] | 15:42 |
| letothe2nd | d_thomas: whatever. i already invested a substantial amount of time trying to help you, which is fine. but my patience is used up by now - either i can see the whole thing, or' i'm just out. | 15:42 |
| qschulz | letothe2nd: I'm new to this but... what's the impact of layer priorities in figuring out which recipe to pick? | 15:42 |
| qschulz | because that might explain why an older version gets picked up? | 15:43 |
| qschulz | just throwing ideas | 15:43 |
| letothe2nd | qschulz: AFAIK none, it should just kick in if things collide, but i might be wrong. yet, with a complete layer i can try and reproduce. which i am also willing to do, but no more poking. | 15:44 |
| qschulz | letothe2nd: https://www.yoctoproject.org/docs/2.6/bitbake-user-manual/bitbake-user-manual.html#var-BBFILE_PRIORITY ah found it! | 15:45 |
| qschulz | "The precedence established through this variable stands regardless of a recipe's version (PV variable)" | 15:45 |
| qschulz | d_thomas: ^ | 15:46 |
| d_thomas | Ah, so my layer needs to be on the same priority level as meta-atmel? Thanks, I'll give that a try | 15:46 |
| d_thomas | oh weird, meta-atmel is 10 and I'm at 6 | 15:47 |
| letothe2nd | (we could easily have looked at it if the layer was up) | 15:48 |
| d_thomas | It was the priority | 15:51 |
| letothe2nd | *sighs* | 15:52 |
| d_thomas | Sorry letothe2nd. I think long term I could put my changes into a meta-atmel into a public layer and the secret sauce into a private layer | 15:52 |
| *** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC | 15:53 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC | 15:53 | |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 15:53 | |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 15:55 | |
| qschulz | d_thomas: maybe worth noting that, IIRC, this does not apply to bbclasses, where the first occurence of the bbclass in BBLAYERS to be found is the one taken | 15:57 |
| qschulz | to be taken with a grain of salt and experimentation :) | 15:57 |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC | 15:57 | |
| *** varjag <varjag!~user@122.62-97-226.bkkb.no> has quit IRC | 15:58 | |
| d_thomas | qschulz: interesting, good to know | 16:00 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:d18d> has quit IRC | 16:02 | |
| RP | qschulz: pretty sure classes are searched for using BBPATH | 16:03 |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 16:10 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 16:10 | |
| litb | qschulz, at least if metadata that comes before yours in BBLAYERS inherits a class that you want to override in yours, then the "wrong" bbclass is taken | 16:11 |
| litb | that happened for me | 16:11 |
| litb | RP, ah, for classes the priority it completely ignored? | 16:11 |
| RP | litb: not sure priority makes sense for classes | 16:13 |
| kergoth | ah the old 'bblayers order' vs bbfile priority thing pops up again :) | 16:13 |
| litb | lulz | 16:14 |
| RP | kergoth: part of me wants to delete a load of these variables | 16:14 |
| letothe2nd | RP: gogogo! | 16:14 |
| kergoth | it's tempting for sure. we have so much legacy stuff in all of this. i can't imagine many folks use bbpath+bbfiles to set up anymore | 16:14 |
| *** vmeson <vmeson!~rmacleod@S0106ac202ece3eb3.vc.shawcable.net> has joined #yocto | 16:15 | |
| litb | BTW sometimes I write bb.build.inherits_class('foo'): and i have seen others that do that | 16:15 |
| letothe2nd | RP: here something to get you started: https://www.youtube.com/watch?v=ZpUYjpKg9KY | 16:15 |
| kergoth | only the metadata knows what's been inherited, not the global bb.build python module :) | 16:15 |
| kergoth | globals aren't nice | 16:15 |
| litb | maybe it would be cool if there is a _bbclass-<name> override for each class inherited. then some of those checks could go | 16:15 |
| RP | litb: each override slows down parsing. Are you sure you'd want to do that? | 16:19 |
| RP | better would be d.inherits() | 16:19 |
| litb | in fact, it would be natural if the override was _class-<name> because it would be compatible with the BBCLASSEXTEND names, afaics | 16:19 |
| litb | RP, hm, I see | 16:20 |
| *** gaulishcoin <gaulishcoin!~gaulishco@anice-652-1-22-156.w83-201.abo.wanadoo.fr> has joined #yocto | 16:20 | |
| rburton | inherits() is fairly common | 16:24 |
| *** cp <cp!~cp@b157153.ppp.asahi-net.or.jp> has quit IRC | 16:29 | |
| *** cp <cp!~cp@b157153.ppp.asahi-net.or.jp> has joined #yocto | 16:29 | |
| RP | I mused at the OE meeting about a) fixing bitbake memres b) making it default c) making some kind of layer setup support in bitbake d) requiring it for eSDK e) replacing eSDK with that simpler mechanism (and simplifying selftests to use it ) | 16:31 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 16:33 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto | 16:34 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 16:38 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC | 16:40 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 16:47 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 16:47 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 16:48 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 16:48 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:49 | |
| *** vineela <vineela!~vtummala@134.134.139.72> has joined #yocto | 16:50 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 16:50 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:52 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 16:53 | |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 17:00 | |
| kanavin | rburton, RP - a colleague wrote a tool that would print 'critical paths' of Yocto builds: https://github.com/oesse/find-critical-path | 17:02 |
| kanavin | I am now convincing them to rewrite it in python, so it can be merged into buildstats directly | 17:02 |
| rburton | nice | 17:03 |
| rburton | i've something here somewhere that probably isn't as good :) | 17:03 |
| rburton | c++! | 17:03 |
| rburton | cik | 17:03 |
| kanavin | rburton, they didn't ask me about the unfortunate choice of implementation language :( | 17:03 |
| kanavin | boost as well! | 17:03 |
| kanavin | but their approch is based on computer science: they implement a well proven algorithm | 17:04 |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 17:05 | |
| RP | kanavin: nice, I've always just looked at the graph :) | 17:06 |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 17:11 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 17:17 | |
| lpapp | hi, modutils.sh is supposed to run on boot from meta? | 17:17 |
| lpapp | it seems that it fails at this condition in our case: [ -f /etc/modules ] || [ -d /etc/modules-load.d ] || exit 0 | 17:17 |
| lpapp | so it skips the rest, like important depmod, etc. | 17:17 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 17:18 | |
| lpapp | is it reasonable my board has neither /etc/modules, nor /etc/modules-load.d | 17:18 |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 17:24 | |
| *** mckoan is now known as mckoan|away | 17:24 | |
| *** mabnhdev <mabnhdev!0c260e0a@12.38.14.10> has joined #yocto | 17:25 | |
| *** tgoodwin <tgoodwin!~tgoodwin@static-108-40-78-74.bltmmd.fios.verizon.net> has joined #yocto | 17:32 | |
| mabnhdev | I'm upgrading my work to Zeus. I have a custom kernel which has to remain at 4.14 for the time being. I've defined my own Linux recipe modeled after linux-yocto. This has been working fine for me since Sumo. However, I'm now seeing failures in my perf build. My failure log is here - | 17:34 |
| mabnhdev | https://gist.github.com/mabnhdev/50ee5408ce9c291e036321395f470492. Any guidance on addressing this issue would be appreciated. | 17:34 |
| litb | mabnhdev, not sure, but it appears that it doesn't like your python version? | 17:42 |
| *** JaMa is now known as Guest58471 | 17:45 | |
| *** JaMa <JaMa!~martin@109.238.218.228> has joined #yocto | 17:45 | |
| mabnhdev | litb Yes, I added NO_LIBPERL=1 NO_LIBPYTHON=1 to EXTRA_OEMAKE and it complains less. But those warnings are still there and it now fails in do_install. I'm not sure that's the right way to go, though. | 17:45 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 17:47 | |
| *** yann <yann!~yann@85.118.38.73> has quit IRC | 17:48 | |
| mabnhdev | Here's the failure with NO_LIBPERL=1 NO_LIBPYTHON=1: https://gist.github.com/mabnhdev/54fa39a756fcebadce1c49f888493b03 | 17:51 |
| litb | mabnhdev, another parameter says PYTHON=python3 . dunno whether or not that contradicts NO_LIBPYTHON=1 | 17:57 |
| litb | mabnhdev, maybe the shebang line in that setup.py script is too long for your kernel to interpret. I once read some code in yocto that tried to minimize this path length | 18:02 |
| litb | ideally it would rely on PATH, instead of having an absolute pathname. maybe do_devshell could help | 18:02 |
| zeddii | mabnhdev: it would be interesting to hear if some of the mismatched header file warnings go away if you cherry-pick a commit on master to your branch. might not help, but you never know. | 18:13 |
| zeddii | see: perf: drop 'include' copy | 18:14 |
| zeddii | also, it might be possible that 4.14 is just to old to support the python3 only build, I’d have to double check when that transition was made. | 18:14 |
| zeddii | in that case, you might have to revert the python3 changes in zeus and take your chances with the python 2.7 EOL | 18:14 |
| mabnhdev | @zeddii - I should have both python 2.7 and python3 defined. I'll have to check that. I actually only need python 2.7, but including python3 was always the path of least resistence. | 18:16 |
| *** falstaff <falstaff!~quassel@37.17.234.113> has quit IRC | 18:16 | |
| *** thannoy <thannoy!~anthony@134-48-190-109.dsl.ovh.fr> has joined #yocto | 18:26 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 18:35 | |
| zeddii | the point is that we integrated patches in zeus to go to python3 only for the kernel bits, towards the goal of not having python3 in the release. | 18:37 |
| zeddii | but if the kernel is too old to fully support python3 perf, you’d have to revert those, or come up with your own patches, etc. | 18:38 |
| *** litb <litb!~jschaub@pd907fca9.dip0.t-ipconnect.de> has quit IRC | 18:47 | |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 18:48 | |
| mabnhdev | zeddii Ah. Understood. Is perf a "required" package? Can I just get rid of it to move forward? | 18:50 |
| zeddii | yep. you definitely can. | 18:51 |
| JaMa | mabnhdev: do you have https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg127705.html in your build? | 18:51 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto | 18:52 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-bjvnvqvazmfeowhb> has quit IRC | 18:53 | |
| mabnhdev | JaMa: Yes, I do have that patch in my build. | 18:54 |
| *** gaulishcoin <gaulishcoin!~gaulishco@anice-652-1-22-156.w83-201.abo.wanadoo.fr> has quit IRC | 19:21 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 19:52 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 20:03 | |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 20:12 | |
| *** thannoy_ <thannoy_!~anthony@134-48-190-109.dsl.ovh.fr> has joined #yocto | 20:12 | |
| *** thannoy <thannoy!~anthony@134-48-190-109.dsl.ovh.fr> has quit IRC | 20:12 | |
| letothe2nd | qschulz: you around? did you get to talk to khem? | 20:19 |
| *** florian_kc is now known as florian | 20:21 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto | 20:55 | |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 21:15 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 21:26 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC | 21:37 | |
| *** MiskaX <MiskaX!ewbbfp8hzj@rankki.sonarnerd.net> has joined #yocto | 21:57 | |
| *** JaMa <JaMa!~martin@109.238.218.228> has quit IRC | 22:04 | |
| *** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto | 22:21 | |
| *** marler8997 <marler8997!0f41fc0e@ztxe01hpics304.austin.hp.com> has joined #yocto | 22:23 | |
| marler8997 | I'm not sure what I'm missing here | 22:23 |
| marler8997 | I'm creating a recipe meant to be used as a tool during the build | 22:23 |
| marler8997 | it depends on openssl, so I add it as an RDEPENDS | 22:24 |
| marler8997 | but openssl doesn't get installed to the sysroot when I build mytool-native | 22:24 |
| marler8997 | I've minimized what I'm trying to do into these to small recipes: https://gist.github.com/marler8997/f8ceeeff80a0e1cb03e9c223654d0fc2 | 22:36 |
| marler8997 | I would think that if you added RDEPENDS to a recipe, that it would install those dependencies into the sysroot? | 22:37 |
| marler8997 | if you are building the "*-native" version of the recipe | 22:37 |
| khem | rdeps are used when building images or doing package installs | 22:39 |
| khem | if something is needed during build then use depends = ... | 22:39 |
| marler8997 | right | 22:39 |
| marler8997 | but this is an indirect dependency | 22:39 |
| marler8997 | A DEPENDS on B | 22:40 |
| marler8997 | well, A DEPENDS on B-native | 22:40 |
| marler8997 | and B has RDEPENDS | 22:40 |
| marler8997 | so, I would think that if you want to use B-native, which gets installed to the sysroot, then you would need the RDPENDS of B | 22:41 |
| marler8997 | Otherwise, you would need to write a different recipe for both B and B-native right? | 22:41 |
| khem | not really you can use class-native override | 22:42 |
| marler8997 | so you're saying I should do this: | 22:42 |
| marler8997 | DEPENDS_class-native = "bash coreutils openssl" | 22:42 |
| marler8997 | RDEPENDS_${PN} = "bash coreutils openssl"? | 22:43 |
| khem | rdeps are encoded into packages ( rpms, ipk etx metadata) since there are no output packages for native packages rdeps might go unnotices | 22:45 |
| marler8997 | Actually, it would be: DEPENDS_class-native = "bash-native coreutils-native openssl-native" | 22:45 |
| marler8997 | right, I understand what's goin on, I just don't understand the right way to do this | 22:46 |
| marler8997 | I want to write a recipe that works both with "-native" and without "-native". I would think I could configure the same dependencies for both | 22:46 |
| khem | DEPENDS_class-native = "bash-native coreutils-native openssl-native" seems fine | 22:46 |
| marler8997 | but that doesn't seem right does it? | 22:46 |
| marler8997 | Now I have to code the same dependencies twice | 22:47 |
| marler8997 | DEPENDS_class-native = "bash-native coreutils-native openssl-native" and then RDEPENDS_${PN} = "bash coreutils openssl" | 22:47 |
| marler8997 | is that really the right way to do this? | 22:47 |
| khem | usually rdeps are built too so I am sure it should be building the rdeps but it might not be staging them for native package sysroots | 22:49 |
| marler8997 | the RDEPS are not availible in the sysroot so my recipe that depends on openssl-wrapper-native fails because openssl isn't installed to the sysroot | 22:49 |
| marler8997 | I know I can add DEPENDS += "openssl" | 22:50 |
| marler8997 | but that doesn't seem correct | 22:50 |
| marler8997 | I mean DEPENDS += "openssl-native" | 22:50 |
| marler8997 | am I really supposed to configure the same dependencies twice...once for when it is installed to the sysroot and one for when it is installed to the target rootfs? | 22:51 |
| *** diego_r <diego_r!~diego@81.29.205.101> has quit IRC | 22:54 | |
| khem | rdeps are target specific | 22:54 |
| marler8997 | right, I understand what RDEPENDS does | 22:55 |
| marler8997 | it causes the packages listed to be installed when you install the PN from RDEPENDS_PN | 22:55 |
| marler8997 | in the example I posted, what is the right way to configure openssl-wrapper.bb so it works both natively and on the target | 22:56 |
| marler8997 | openssl-wrapper is just creating a bash script that called openssl | 22:56 |
| marler8997 | so it requires both bash and openssl to be installed | 22:56 |
| marler8997 | the only way I know how to make that work both natively and on the target is to use DEPENDS += "bash-native openssl-native" and RDEPENDS_${PN} += "bash openssl" | 22:57 |
| khem | rdeps should get mapped to native as well | 22:57 |
| marler8997 | but that doesn't seem right | 22:57 |
| khem | hmm | 22:57 |
| marler8997 | right, it would get mapped to native | 22:58 |
| marler8997 | but sysroot doesn't use packages | 22:58 |
| marler8997 | it uses SYSROOT_DIRS for normal recipes and SYSROOT_DIRS_NATIVE for "*-native" recipes | 22:58 |
| marler8997 | SYSROOT_DIRS uses common library directories and SYSROOT_DIRS_NATIVE uses common bin/config directories | 22:59 |
| marler8997 | it took me a while to realize that the sysroot is populated completely differently from the packages | 22:59 |
| marler8997 | and that sysroot uses DEPENDS and the packages use RDEPENDS | 23:00 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 23:01 | |
| marler8997 | at least that's how I understand it, when I think about it more, it seems like "*-native" packages should actualy be using RDEPENDS to know which "*-native" packages it depends on...but that doesn't seem to be the case in my example | 23:01 |
| *** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC | 23:06 | |
| marler8997 | it seems very odd to me that there are 2 different systems for "native runtime dependencies" and "target runtime dependencies" | 23:12 |
| marler8997 | as I see it, this comes from the fact that the sysroot is populated differently from the target rootfs | 23:12 |
| marler8997 | if sysroot was populated from the packages, then this would work as expected | 23:13 |
| *** BobPungartnik <BobPungartnik!~BobPungar@179.177.241.29> has joined #yocto | 23:13 | |
| *** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has quit IRC | 23:14 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC | 23:20 | |
| khem | openssl seems to not have option -v so maybe you want to use something like 'help' | 23:20 |
| khem | and perhaps thats what the problem is | 23:20 |
| *** BobPungartnik <BobPungartnik!~BobPungar@179.177.241.29> has quit IRC | 23:20 | |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 23:29 | |
| marler8997 | the problem is it can't find openssl | 23:33 |
| marler8997 | because it's not being installed to the sysroot | 23:33 |
| marler8997 | but when I add DEPENDS_class-native += "openssl-native", then it does get installed to the sysroot | 23:33 |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 23:37 | |
| *** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto | 23:38 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 23:47 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 23:49 | |
| *** thannoy_ <thannoy_!~anthony@134-48-190-109.dsl.ovh.fr> has quit IRC | 23:52 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!