| *** aehs29 <aehs29!aehernan@nat/intel/x-umfpqmovaofwcruf> has left #yocto | 00:00 | |
| *** billr <billr!~wcrandle@134.134.137.73> has quit IRC | 00:59 | |
| *** sameo <sameo!~samuel@192.55.54.43> has quit IRC | 01:03 | |
| *** sujith_h <sujith_h!~toaster@122.167.86.104> has quit IRC | 01:03 | |
| *** zeddii_home_ <zeddii_home_!~zeddii_ho@CPEe8de27b71faa-CMbcc810032faf.cpe.net.cable.rogers.com> has joined #yocto | 01:06 | |
| *** sujith_h_ <sujith_h_!~toaster@122.167.206.236> has joined #yocto | 01:08 | |
| *** sujith_h_ is now known as sujith_h | 01:08 | |
| *** zeddii_home <zeddii_home!~zeddii_ho@CPEe8de27b71faa-CMbcc810032faf.cpe.net.cable.rogers.com> has quit IRC | 01:09 | |
| *** zeddii_home_ is now known as zeddii_home | 01:09 | |
| *** vmesons is now known as vmeson | 01:10 | |
| *** sameo <sameo!~samuel@192.55.54.43> has joined #yocto | 01:24 | |
| *** nighty <nighty!~nighty@p001.gate.atson.jp> has joined #yocto | 02:17 | |
| *** Nilesh_ <Nilesh_!uid116340@gateway/web/irccloud.com/x-zefobuqcvbvjeyps> has joined #yocto | 02:23 | |
| *** nighty <nighty!~nighty@p001.gate.atson.jp> has quit IRC | 02:26 | |
| *** nighty <nighty!~nighty@p001.gate.atson.jp> has joined #yocto | 02:26 | |
| *** nighty <nighty!~nighty@p001.gate.atson.jp> has joined #yocto | 02:28 | |
| *** sameo <sameo!~samuel@192.55.54.43> has quit IRC | 02:37 | |
| *** bananadev <bananadev!~onlyester@118.70.128.150> has joined #yocto | 02:48 | |
| *** bluelightning <bluelightning!~paul@189.199.125.10> has joined #yocto | 02:52 | |
| *** bluelightning <bluelightning!~paul@189.199.125.10> has quit IRC | 02:52 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 02:52 | |
| *** AgentElrond <AgentElrond!~ELROND@97-102-189-66.res.bhn.net> has joined #yocto | 02:57 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 03:06 | |
| *** AgentElrond <AgentElrond!~ELROND@97-102-189-66.res.bhn.net> has quit IRC | 03:08 | |
| *** ntl <ntl!~nathanl@99-127-51-4.lightspeed.austtx.sbcglobal.net> has joined #yocto | 03:16 | |
| *** sujith_h <sujith_h!~toaster@122.167.206.236> has quit IRC | 03:31 | |
| *** AndersD <AndersD!~anders@h83-209-191-235.cust.se.alltele.net> has joined #yocto | 03:49 | |
| khem | I am struggling chasing errors like do_image_tar: Taskhash mismatch e46ba58e3a9cdc353a94548fd66fb109 verses 88d394eba0f2c542200ed8b0ad4b867a | 03:49 |
|---|---|---|
| khem | this started to happen with krogoth | 03:49 |
| khem | I see it with rpi images and also some internal images | 03:50 |
| khem | when I run bitbake-diffsigs it says basehash changed from 9bbc36cad4c9ade1a346c4b6bb6c6f75 to 138f22157ec470f60a2071db0f68a4e4 | 03:50 |
| *** ntl <ntl!~nathanl@99-127-51-4.lightspeed.austtx.sbcglobal.net> has quit IRC | 04:17 | |
| *** AndersD <AndersD!~anders@h83-209-191-235.cust.se.alltele.net> has quit IRC | 04:28 | |
| *** maxin <maxin!~maxin@37-219-27-165.nat.bb.dnainternet.fi> has joined #yocto | 05:01 | |
| *** sujith_h <sujith_h!~toaster@kde/developers/sujithh> has joined #yocto | 05:19 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC | 05:27 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 05:28 | |
| *** hamis_lt_u <hamis_lt_u!~irfan@110.93.212.98> has joined #yocto | 05:31 | |
| *** visaev <visaev!~visaev@81.171.81.144> has joined #yocto | 05:33 | |
| *** hamis_lt_u <hamis_lt_u!~irfan@110.93.212.98> has quit IRC | 05:36 | |
| *** qt-x <qt-x!~Thunderbi@217.10.196.2> has joined #yocto | 05:39 | |
| *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has quit IRC | 06:11 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:18 | |
| *** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has joined #yocto | 06:21 | |
| *** qt-x <qt-x!~Thunderbi@217.10.196.2> has quit IRC | 06:24 | |
| *** qt-x <qt-x!~Thunderbi@217.10.196.2> has joined #yocto | 06:32 | |
| *** vin <vin!~vincent@fsf/member/vin> has quit IRC | 06:34 | |
| *** vin <vin!~vincent@fsf/member/vin> has joined #yocto | 06:35 | |
| *** gtristan <gtristan!~tristanva@114.207.54.40> has joined #yocto | 06:38 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 06:41 | |
| *** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-exdhkdbrwzfnrdby> has joined #yocto | 06:48 | |
| *** jbrianceau_away is now known as jbrianceau | 06:48 | |
| *** fl0v0 <fl0v0!~fvo@pD9F6B7EE.dip0.t-ipconnect.de> has joined #yocto | 06:55 | |
| *** t0mmy <t0mmy!~tprrt@217.114.201.133> has joined #yocto | 06:56 | |
| *** maxin <maxin!~maxin@37-219-27-165.nat.bb.dnainternet.fi> has quit IRC | 07:09 | |
| *** rajm <rajm!~robertmar@82-70-136-246.dsl.in-addr.zen.co.uk> has joined #yocto | 07:09 | |
| *** yann <yann!~yann@nan92-1-81-57-214-146.fbx.proxad.net> has quit IRC | 07:13 | |
| *** agust <agust!~agust@p4FCB4322.dip0.t-ipconnect.de> has joined #yocto | 07:13 | |
| *** sno <sno!~sno@b2b-78-94-80-58.unitymedia.biz> has quit IRC | 07:19 | |
| *** obsrwr_ <obsrwr_!~otp-amois@188.24.204.43> has joined #yocto | 07:20 | |
| *** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto | 07:21 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 07:24 | |
| *** joshuagl <joshuagl!~joshuagl@192.198.151.45> has joined #yocto | 07:26 | |
| CTtpollard | khem: common problem for me as well in various do_$tasks | 07:32 |
| CTtpollard | khem: meta-raspberrypi have pushed a *fix* for it, but I'm still seeing it occur for other tasks, such as populate sdk | 07:32 |
| CTtpollard | I'm not sure what the solution is other than forcefully removing the check routine | 07:33 |
| *** Anticom <Anticom!~timo.m@217.6.33.234> has joined #yocto | 07:43 | |
| *** melonipoika <melonipoika!~jose@194.9.252.237> has joined #yocto | 07:49 | |
| *** mwalle <mwalle!~mwalle@194.25.174.126> has joined #yocto | 07:52 | |
| *** jku <jku!jku@nat/intel/x-ewijegcombirpzkz> has joined #yocto | 07:52 | |
| *** jku is now known as Guest73867 | 07:53 | |
| *** jku <jku!jku@nat/intel/x-fvicqpmsfwesjfyn> has joined #yocto | 07:53 | |
| *** jku is now known as Guest73867 | 07:53 | |
| *** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto | 07:55 | |
| rburton | khem, CTtpollard: stop using variables that change in between the cooker doing the calculations and the worker starting - often DATETIME and so on. if those are being used, whitelist them. | 08:03 |
| *** yann <yann!~yann@85-171-21-92.rev.numericable.fr> has joined #yocto | 08:04 | |
| CTtpollard | yeh it seems to be rogue DATETIMES in various classes | 08:04 |
| *** jku <jku!~jku@2001:998:22:0:4e8d:79ff:fef2:49ba> has joined #yocto | 08:09 | |
| *** jku is now known as Guest96062 | 08:09 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 08:14 | |
| *** sno <sno!~sno@62.157.143.22> has joined #yocto | 08:17 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 08:18 | |
| *** T_UNIX <T_UNIX!d4d3bd3c@gateway/web/freenode/ip.212.211.189.60> has joined #yocto | 08:24 | |
| eduardas_m | Hello. I am using the DART-6UL board from Variscite. I have problems related to using Qt5 with linuxfb plugin on a Yocto build. Are there people here working with a similar setup here? I have tried writing on the qt channel, but as far as I understand few people there have anything to do with embedded development. What would be the most appropriate place to get answers on Qt5 + Yocto related questions? | 08:25 |
| *** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC | 08:33 | |
| Anticom | Hi all. Wasn't there an option you could set in your local.conf to only keep the last image that was built? | 08:33 |
| *** seezer <seezer!seezer@quassel/developer/seezer> has quit IRC | 08:33 | |
| Anticom | I do remember something like that but i can't find it in the docs anymore | 08:33 |
| LetoThe2nd | Anticom: there is rm_work, but thats a little bit dofferent | 08:34 |
| *** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto | 08:34 | |
| redengin | eduardas_m, instead of asking why doesn't A work with B, do you know how A and B don't work together? | 08:34 |
| Anticom | LetoThe2nd: But there was no option to delete old images? | 08:35 |
| LetoThe2nd | Anticom: none that i knew of. but thats not an authoritative statement. | 08:35 |
| Anticom | Is rburton here? | 08:36 |
| *** seezer <seezer!quassel@quassel/developer/seezer> has joined #yocto | 08:36 | |
| joshuagl | RM_OLD_IMAGE | 08:37 |
| joshuagl | http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-RM_OLD_IMAGE | 08:37 |
| *** maxin <maxin!~maxin@37-219-27-165.nat.bb.dnainternet.fi> has joined #yocto | 08:37 | |
| * LetoThe2nd hands rburton the FLS hat. | 08:37 | |
| Anticom | joshuagl: thanks! | 08:38 |
| joshuagl | np Anticom | 08:40 |
| *** Guest96062 <Guest96062!~jku@2001:998:22:0:4e8d:79ff:fef2:49ba> has quit IRC | 08:40 | |
| eduardas_m | redengin: The point is I do not know what the proper way to rotate a Qt5 linuxfb application by 90 degrees on screen is and run into problems. My problem is elaborated here: http://forum.qt.io/topic/70184/weird-qcombobox-behaviour-under-qt-5-5-1-linuxfb-platform-yocto-build-for-imx6ul/2 | 08:44 |
| eduardas_m | I am not even sure whether this should be approached from the Qt framework side or from the framebuffer driver side. | 08:45 |
| eduardas_m | I am actually new to embedded linux so I wouldn't be surprised I am doing this completely wrong. | 08:47 |
| LetoThe2nd | isn't framebuffer kind of deprecated anyways? | 08:47 |
| LetoThe2nd | imx should have a decent usable drm, maybe even opengl implementation. | 08:48 |
| redengin | it sounds like a Qt bug based on expectations of Ubuntu builds | 08:48 |
| eduardas_m | imx6ul does not have a graphics accelerator, OpenGL is not usable | 08:48 |
| redengin | eduardas_m, have you tried other distros? | 08:48 |
| eduardas_m | only Yocto and Ubuntu 14.04 (works properly with the latter) | 08:49 |
| eduardas_m | am investigating further | 08:49 |
| redengin | eduardas_m, I'd try it out on other distros to determine if its just Ubuntu niceness that makes it work | 08:50 |
| sveinse | redengin: OOI, What has Ubuntu (or distros for that matter) to do with Variscites Qt5 yocto build? | 08:51 |
| sveinse | We use Qt5 on imx, but we do use full fsl opengl thou | 08:52 |
| redengin | sveinse, all the plumbing back to decide where/how to place things within the display | 08:53 |
| *** bananadev <bananadev!~onlyester@118.70.128.150> has quit IRC | 08:54 | |
| *** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto | 08:55 | |
| eduardas_m | sveinse: what is the method that you would use to rotate a Qt5 widget application by 90 degrees then? perhaps using QGraphicsScene is actually the problem? | 08:57 |
| eduardas_m | sveinse: do you use X window system? | 09:00 |
| *** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC | 09:01 | |
| *** belen <belen!~Adium@134.134.139.76> has joined #yocto | 09:04 | |
| sveinse | eduardas_m: No, we have a full-screen linuxfb app | 09:05 |
| eduardas_m | sveinse: thank you for sharing information, but could you tell anything about rotation? how would you go about implementing a portrait app in Qt5 under linuxfb? | 09:07 |
| *** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto | 09:11 | |
| *** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC | 09:11 | |
| *** grma <grma!~gruberm@80.93.38.128> has joined #yocto | 09:15 | |
| *** grma <grma!~gruberm@80.93.38.128> has quit IRC | 09:16 | |
| *** grma <grma!~gruberm@80.93.38.128> has joined #yocto | 09:16 | |
| *** AndersD <AndersD!~anders@213-64-218-130-no126.business.telia.com> has joined #yocto | 09:16 | |
| CTtpollard | is it still the process for patches for /classes to be sent to the oe-core ml? | 09:19 |
| *** pauloalvarez <pauloalvarez!~pauloalva@200.101.117.50> has joined #yocto | 09:20 | |
| sveinse | eduardas_m: Not sure, unfortunately. But Qt honors some environment variables, such as QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS=rotate=90 and QT_QPA_PLATFORM=eglfs | 09:22 |
| CTtpollard | and do all patches require a relevant bug-id? | 09:22 |
| redengin | CTtpollard, my experience is that you need to both suggest and offer to maintain | 09:24 |
| *** nighty <nighty!~nighty@p001.gate.atson.jp> has quit IRC | 09:25 | |
| *** maxin <maxin!~maxin@37-219-27-165.nat.bb.dnainternet.fi> has quit IRC | 09:28 | |
| *** Crofton <Crofton!~Crofton@217.155.200.106> has joined #yocto | 09:37 | |
| jubr | eduardas_m: I believe newer Qt5 releases will have a soft-opengl renderer, released under GPL3 | 09:40 |
| *** florian_kc is now known as florian | 09:42 | |
| jubr | https://blog.qt.io/blog/2015/01/22/introducing-the-qt-quick-2d-renderer/ | 09:43 |
| *** Crofton <Crofton!~Crofton@217.155.200.106> has quit IRC | 09:45 | |
| sveinse | If I set FOO="1" in a.bb and inherit a, then it can be accessed with ${FOO} from b.bb, right. How do I override FOO from local.conf then? | 09:46 |
| Ulfalizer | sveinse: you mean inheriting a class a.bbclass from a recipe b.bb, where a.bbclass sets FOO = "1"? | 09:49 |
| *** maxin <maxin!~maxin@2001:998:22:0:657c:8573:13c2:de73> has joined #yocto | 09:49 | |
| Ulfalizer | if you're meant to be able to set the variable in a configuration file, it will usually be set with ?= or ??= | 09:49 |
| Ulfalizer | in the bbclass that is | 09:50 |
| sveinse | Ulfalizer: Yes, my bad. a.bbclass in my example above, yes | 09:50 |
| Ulfalizer | that will leave the variable alone if it already has a value | 09:50 |
| sveinse | local.conf is read first when parsing? | 09:52 |
| Ulfalizer | sveinse: yep... the note i added to http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#usingpoky-debugging-viewing-variable-values might clarify things | 09:53 |
| Ulfalizer | first the configuration (.conf) files are parsed, and then your particular recipe (along with any bbclasses it inherits) | 09:53 |
| Ulfalizer | any variables set in the configuration files will be visible by the time recipes are parsed | 09:54 |
| sveinse | Ulfalizer: Ah, great. The NOTE block in section 2.3.2 which you just referred to answered another of my questions | 09:55 |
| Ulfalizer | neat :) | 09:56 |
| sveinse | The docs is great, but as a n00b you tend to get lost in all the information -- even if you have read it once. :D | 09:56 |
| Ulfalizer | that note was added within the last week i think :) | 09:57 |
| Ulfalizer | i've added quite a lot of stuff to the 2.2. manuals | 09:58 |
| sveinse | how do you determine ?= vs ??=. Am I right to assume: Use ?= and you'll know it when you need ??= ? | 09:58 |
| sveinse | I see PACKAGECONFIG is usually defined with ??= | 10:00 |
| Ulfalizer | sveinse: ??= is when you don't care whether another assignment comes before or after the ??=. that other assignment will win either way. | 10:00 |
| Ulfalizer | FOO ??= "foo" means "at the end of parsing, check if FOO was assigned a value. if not, assign 'foo' to FOO." | 10:01 |
| Ulfalizer | it's a "last resort" default in a way | 10:02 |
| sveinse | To summarize: I put FOO ??= "defaults" into a.bbclass. From b.bb I "inherit a" and can set FOO ?= "something else". I can then also do FOO_pn-b="mylocal", right? Not FOO_pn-a? | 10:05 |
| Ulfalizer | a ?= will always "win" over a ??=. if you have a FOO ?= "foo", then either that will assign "foo" to FOO, or FOO already had a value. either way, FOO will have a value at the end of parsing, and so the ??= value will never get assigned. | 10:07 |
| Ulfalizer | and yeah, FOO_pn-b would be the override that applies for b.bb. it's set based on the name of the recipe, not based on the name of the bbclass. | 10:08 |
| sveinse | Ulfalizer: Great. Understood! | 10:08 |
| Ulfalizer | you could look up the OVERRIDES variable to see the underlying mechanism behind overrides btw. i think it helps to understand how it works. | 10:08 |
| Ulfalizer | the rest becomes mostly "guessable" then :) | 10:09 |
| Ulfalizer | np | 10:09 |
| Ulfalizer | food time | 10:09 |
| sveinse | Actually I did read the OVERRIDES section, and I found the docs to very confusing | 10:09 |
| sveinse | Let me see if I can find it and explain | 10:09 |
| sveinse | section 3.2.1 in BB manual under "selecting a variable". The example lists OVERRIDES = "architecture:os:machine". I don't understand the significance of that list. At first I might think that these are the TEST_* variable to chose from, but then the next example with KBRANCH= does not show OVERRIDES being set. | 10:14 |
| sveinse | I've read this many times, and I just can't get my head around this | 10:14 |
| sveinse | So either I'm slow, or perhaps this section needs some better examples | 10:15 |
| jubr | sveinse: Ulfalizer: datastore-copies: cool note, I inferred this myself after some painstakingly long debug sessions | 10:20 |
| ionte | hi. is it possible to run a task with bitbake, without running the tasks it depends on? | 10:21 |
| ionte | i want to run deploy task, but i don't want to run the compile task, even if code has changed in the recipe | 10:22 |
| ionte | this is to build a device tree without recompiling the entire kernel. so i change the dts in my recipe, run "bitbake -c unpack <kernel-recipe>" and then "bitbake -c deploy <kernel-recipe>". but the last command also triggers a complete rebuild which is not necessary and takes a lot of time. | 10:23 |
| *** joshuagl <joshuagl!~joshuagl@192.198.151.45> has quit IRC | 10:25 | |
| jubr | ionte: bitbake -c task -f | 10:31 |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC | 10:31 | |
| Ulfalizer | sveinse: the way it works is that FOO_someoverride will only be applied of "someoverride" appears in OVERRIDES | 10:31 |
| Ulfalizer | so the current "configuration" (which recipe? which machine? etc.) is written to OVERRIDES, and that'll make those overrides apply | 10:33 |
| Ulfalizer | and yeah, the manual sometimes isn't as explicit as it could be | 10:33 |
| *** psadro <psadro!~Thunderbi@216.234.148.134> has quit IRC | 10:35 | |
| Ulfalizer | sometimes it makes things seem fancier than they really are :P | 10:35 |
| *** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has joined #yocto | 10:35 | |
| sveinse | Ulfalizer: So there is something like OVERRIDES="${MACHINE}" behind the scenes and then the example of KBRANCH_qemux86 will be selected? | 10:36 |
| *** joshuagl <joshuagl!~joshuagl@192.198.151.45> has joined #yocto | 10:37 | |
| Ulfalizer | sveinse: yep | 10:37 |
| rburton | bitbake -e will show you the value of OVERRIDES etc | 10:38 |
| Ulfalizer | it adds some indirection with a variable called MACHINEOVERRIDES though, that's added ot OVERRIDES | 10:38 |
| Ulfalizer | but that's just to confuse you ;) | 10:38 |
| Ulfalizer | also, makes it easier to customize | 10:39 |
| jubr | poky/meta/conf/bitbake.conf:OVERRIDES = "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable" | 10:39 |
| *** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has quit IRC | 10:40 | |
| sveinse | Ulfalizer: brilliant. :D (and it took four sentences to understand what I could not read from the text). IM-very-HO you should add that to the KBRANCH example. That OVERRIDES is set with ${MACHINES} and that is what makes it select the alternative overrides. | 10:40 |
| *** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has joined #yocto | 10:40 | |
| Ulfalizer | sveinse: i'm working on some other documentation atm. the documentation maintainer is very open to contributions though: https://bugzilla.yoctoproject.org/enter_bug.cgi?classification=Documentation :) | 10:41 |
| sveinse | Ulfalizer: all right, thanks | 10:41 |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has quit IRC | 10:42 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has joined #yocto | 10:42 | |
| sveinse | rburton, I've been running a day or so with sstate cache on NTFS (via the fuse driver). It seems to be working perfectly. Perhaps thought you wanted to know | 10:43 |
| LetoThe2nd | sveinse: Neanderthal Technology Fireplace System? | 10:43 |
| sveinse | LetoThe2nd: Yes | 10:43 |
| LetoThe2nd | sveinse: i hear mammoth steak work nicely along that, too! | 10:44 |
| rburton | sveinse: presumably because its a local disk and as you said, the file system is fine with the names, its windows that isn't. sstate over SMB on a NTFS file system is likely not going to work. | 10:44 |
| LetoThe2nd | (SCNR) | 10:44 |
| sveinse | No actually, NTFS in itself isn't so bad. It's windows front end which is | 10:44 |
| sveinse | The reason I have NTFS btw, is because I share this drive with Win machines. And unfortunately (and it's plain stupid) there are no other modern FS which share well with windows :( | 10:45 |
| LetoThe2nd | sveinse: i know, have ntfs extensively too. usually little hassles. but this is just stuck in my mind: http://www.onefunsite.com/images/nt.gif | 10:45 |
| sveinse | :D LOL. Well, I'm representing a very little Linux bubble in our company. The rest is Windows-centric, so I'm very alone at times. | 10:46 |
| sveinse | I'm looking forward to my presentation to the SW director that you need at least 50GB and native Linux machine to do anything useful in Yocto | 10:47 |
| sveinse | I wonder how i can sugar that pill :P | 10:47 |
| LetoThe2nd | sveinse: tell him you need a 32way build box with 128G ram | 10:48 |
| LetoThe2nd | sveinse: then let him negotiate you down to your actual needs. | 10:49 |
| LetoThe2nd | and if he just says 'yes', you're set anyways. | 10:49 |
| ionte | jubr: nope, that forces the task to be run, which in turn may run other tasks. in my case, forcing "deploy" after an "unpack" also runs "compile" etc | 10:49 |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC | 10:50 | |
| sveinse | What I'm planning on is having a large build server running linux, and let it populate the sstate cache. Most devs will do app development, so they'll work on one recipe only. If they then can utilize the sstate cache, they can probably get away with running the yocto build virtually. | 10:51 |
| rburton | sveinse: to be fair the disk requirements of yocto basically mean spending £50 on a hard disk | 10:52 |
| LetoThe2nd | sveinse: hm, sounds very much like you actually want to handle them the extensible sdk | 10:52 |
| rburton | sveinse: spinning rust is far more economical and the performance gain of ssd isn't as impressive as you'd like, given sufficient ram | 10:52 |
| LetoThe2nd | sveinse: which basically is a shrinkwrapped sstate for app developers to work on one recipe :) | 10:52 |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 10:52 | |
| LetoThe2nd | rburton: ++ | 10:52 |
| LetoThe2nd | given enough ram, all ssds for OE stuff are moot. | 10:52 |
| rburton | speaking of which i really need to raid my 2tb disks | 10:53 |
| sveinse | LetoThe2nd: We do SDK today. We have a product on the marked running Yocto, developed by a subcontractor. They provides us with a SDK and a core-image. We then build our app and integrate that into the core-image. | 10:53 |
| LetoThe2nd | sveinse: mind, i explicitly said "extensible sdk", not just "sdk" | 10:54 |
| LetoThe2nd | sveinse: its a rather new facility that targets the app developer case amongst some others. | 10:55 |
| Ulfalizer | rburton: all yocto does in the non-sstate case to check whether a task needs to be rerun is to look for a stamp file for the task with a matching input checksum, right? | 10:55 |
| sveinse | LetoThe2nd: The problem is that the glue to build our apps and integrate into the core-image now is a proprietary build system built by me. I'm now moving towards making recipes of everything so that we can use bb for what its good at | 10:55 |
| LetoThe2nd | sveinse: see: extensible sdk, really. | 10:55 |
| sveinse | LetoThe2nd: I will, thanks | 10:55 |
| Ulfalizer | i think one thing that makes the sstate cache harder to understand at the moment is that the non-sstate case isn't explained | 10:56 |
| *** hamis_lt_u <hamis_lt_u!~irfan@110.93.212.98> has joined #yocto | 10:56 | |
| rburton | Ulfalizer: effectively yeah. "has this been done" | 10:56 |
| Ulfalizer | ok, thanks. i'm thinking of adding a section on stamps. | 10:56 |
| *** pauloalvarez <pauloalvarez!~pauloalva@200.101.117.50> has quit IRC | 10:56 | |
| LetoThe2nd | rburton: i've conducted a few trivial tests with building on spinning rust vs. ssd vs. tmpfs. difference: neglectible, if you have enough ram that caches can take care of everything. | 10:56 |
| sveinse | OOI, why is the sstate cache sorting on hash-id, rather than filename? | 10:57 |
| Ulfalizer | sveinse: you mean for the two-character subdirectories? | 10:57 |
| sveinse | How much RAM are we talking about for decent spin-drive performance with a yocto build? | 10:57 |
| Ulfalizer | probably because it gives an even spread in that case | 10:57 |
| rburton | sveinse: 16gb to start with. my current machine has 64gb... | 10:58 |
| sveinse | Ulfalizer: Yes. Ah yes, make sense. Otherwise its like the debian repo syndrome. "lib/" is overfull :P | 10:58 |
| rburton | (old machine had 16gb, and after a build meminfo said that ~12gb was disk cache) | 10:58 |
| LetoThe2nd | sveinse: do a clean build with empty sstate, du -hs after finish, add 20% :-) | 10:58 |
| Ulfalizer | sveinse: some characters are more common than others too :) | 10:58 |
| rburton | sveinse, Ulfalizer: also performance: file systems don't like having a single folder with 50k files in | 10:59 |
| Ulfalizer | yeah, that's the original reason for having those two-character subdirectories at all i guess | 11:00 |
| Ulfalizer | otherwise everything could have been in a single directory | 11:00 |
| rburton | $ find /data/poky-master/sstate/ -type f|wc -l | 11:00 |
| rburton | 518759 | 11:00 |
| rburton | i was out by an order of magnitude :) | 11:00 |
| sveinse | LetoThe2nd: du + 20% = RAM size, that what you meant? | 11:00 |
| LetoThe2nd | sveinse: yeah. | 11:00 |
| rburton | that might be *a bit* over kill :) | 11:00 |
| LetoThe2nd | rburton: that 128g suggestion above was not a joke | 11:01 |
| sveinse | LetoThe2nd: That assumes extfs, doesn't it? | 11:01 |
| rburton | yeah start with 128 and negotiate down to just 64 | 11:01 |
| sveinse | Different fs have different caching schemes | 11:02 |
| LetoThe2nd | the point is, building a core-image-minimal or such is usually not a problem with less ressources. but once you pull in qt or even chromium, stuff gets nasty when you're low on ram | 11:02 |
| rburton | if you're not building qt/webkit/etc then you'll be "fine" with 16gb, but get as much as you can justify | 11:03 |
| sveinse | my sstate cache is at 43Gb... But I'm working on two flavors of arm, intel and qemu against the same sstate cache | 11:03 |
| rburton | pah | 11:03 |
| LetoThe2nd | rburton: thats a good bottom line. | 11:03 |
| rburton | 568G/data/poky-master/sstate/ | 11:03 |
| * rburton waits for kergoth to join in | 11:04 | |
| sveinse | whoah! ok. I'm standing in line all the way back :P | 11:04 |
| LetoThe2nd | much more important than 16gb ram vs. 32gb or so is, having a native environment. | 11:04 |
| LetoThe2nd | or at least some kind of docker/etc. container. | 11:04 |
| sveinse | (On request from my manager) I have actually on my list to benchmark the actual penalty from doing this virtual (against a phy disk) | 11:05 |
| rburton | IT HURTS SO BAD | 11:05 |
| * LetoThe2nd would guess a 4x-10x penalty. | 11:05 | |
| sveinse | Let's hope so, because it's tied to funding... | 11:05 |
| rburton | sveinse: obviously you need to throw more ram to the host to give the vm enough ram to play with | 11:06 |
| LetoThe2nd | sveinse: show him the following equation with the numbers appropriately filled in: if (time_for_tests * your_pay_per_hour) > your_wanted_invest -> just buy. | 11:06 |
| sveinse | LetoThe2nd: No, I don't think anybody will be unreasonable. I just have to quantify it to justify it. | 11:07 |
| sveinse | Is virtual build server just as bad? Our IT department runs a datacenter, so there is a requirement that every server is virtual. | 11:08 |
| LetoThe2nd | sveinse: thats only natural. and for investment of size, absolutely reasonable. but if we're talking about stuff thats in the sub-1k range, or maybe even sub-300, evalutaion quickly becomes pointless if its a one-off invest | 11:09 |
| LetoThe2nd | sveinse: depends on the kind of 'virtual' | 11:09 |
| LetoThe2nd | of course, i'm always speaking from my perspective | 11:10 |
| rburton | if its a xeon beast tricked out with all the ram and you can get dedicates slices then the overhead won't be too much | 11:12 |
| rburton | obviously thats a different experience to running oe builds inside virtualbox on a macbook air | 11:12 |
| rburton | (which i've seen) | 11:12 |
| sveinse | LetoThe2nd: Our current build server run under Hyper-V with a dedicated phy (SSD) drive. 16 CPUS (E5-2637), but only 8GB ram (which can be extended or course). It's performance for Yocto SDK based Qt app building is decent. | 11:13 |
| sveinse | I think I will propose adding a spin-drive and much more RAM | 11:14 |
| LetoThe2nd | yeah. still that same xeon certainly makes a difference between natively being linux and running xen or even lxc/docker with direct memory access, and some hyper-v thing that maybe even has to rely on file-based container images. | 11:14 |
| sveinse | To my experience, the biggest improvement in a VM is getting direct access to storage | 11:14 |
| LetoThe2nd | that and enough ram, yes. | 11:16 |
| rburton | all this talk of xeon is good for my stock, keep at it | 11:20 |
| sveinse | rburton: yes, your at Intel, right? | 11:20 |
| rburton | yeah | 11:20 |
| LetoThe2nd | rburton: other noble gases relevant for you too? | 11:21 |
| -YoctoAutoBuilder- build #908 of nightly-multilib is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-multilib/builds/908 | 11:21 | |
| sveinse | LetoThe2nd: I don't think Xeon is a gas. Xenon is :P | 11:22 |
| LetoThe2nd | sveinse: pun intended :) | 11:22 |
| sveinse | :D | 11:22 |
| rburton | success \o/ | 11:22 |
| sveinse | Intel Raon :P | 11:22 |
| sveinse | no wait, brand used | 11:22 |
| LetoThe2nd | Heium. gives you more vowels. | 11:23 |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC | 11:24 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 11:25 | |
| sveinse | I have to say I really like the sstate scheme. rm -rf tmp; bitbake core-image, and you're set in minutes | 11:29 |
| rburton | indeedy | 11:30 |
| sveinse | My recipe, which use EXTERNALSRC rebuilds quite a bit thou. I suppose it's because of the external-thing, right? | 11:31 |
| *** BlitzBlizz <BlitzBlizz!~blitz@2001:638:102:36:e3aa:c03b:c3ec:41c6> has joined #yocto | 11:33 | |
| *** arkver <arkver!~arkver@host81-135-58-159.range81-135.btcentralplus.com> has joined #yocto | 11:34 | |
| *** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC | 11:38 | |
| *** berton <berton!~fabio@177.127.4.56> has joined #yocto | 11:39 | |
| *** gleikeo <gleikeo!b2143441@gateway/web/freenode/ip.178.20.52.65> has joined #yocto | 11:39 | |
| gleikeo | i try to compile postgresql on krogoth branch but i have got an error checking Python.h usability... no | checking Python.h presence... no | checking for Python.h... no | configure: error: header file <Python.h> is required for Python | NOTE: The following config.log files may provide further information. | NOTE: /md0/gletourneur/projects/openembedded/oe-core/build/tmp-glibc/work/i586-oe-linux/postgresql/9.4.8-r0.0/build/config.log | E | 11:39 |
| gleikeo | any idea | 11:39 |
| *** Crofton <Crofton!~Crofton@217.155.200.106> has joined #yocto | 11:41 | |
| *** Crofton <Crofton!~Crofton@217.155.200.106> has quit IRC | 11:46 | |
| *** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto | 11:57 | |
| simonl | I'm trying to figure out why the meta-oe glog recipe no longer builds on my machine. It seems it tries to link to libgcc_s.so.1 from my host distro, because -L/usr/lib is passed to the linker when linking the tests | 11:58 |
| *** istarilucky <istarilucky!~rlucca@177.159.144.73> has joined #yocto | 11:58 | |
| simonl | Could someone give some hint as to how it is supposed to work? libglog.la has libdir = /usr/lib so I guess that's where the -L/usr/lib comes from? | 11:59 |
| rburton | yeah | 12:00 |
| rburton | well, maybe. | 12:01 |
| rburton | pastebin the actual logs? | 12:01 |
| neverpanic | How do I find out why a setscene task failed? I just get a warning but no reference to a log file or any other output that would indicate what the problem actually was. | 12:02 |
| neverpanic | warning is WARNING: Setscene task /home/clemens/dev/poky/meta/recipes-support/db/db_6.0.30.bb:do_packagedata (/home/clemens/dev/poky/meta/recipes-support/db/db_6.0.30.bb:do_packagedata_setscene) failed with exit code '1' - real task will be run instead | 12:02 |
| neverpanic | I'm pretty sure I broke this, but I need to be able to debug this to fix it. | 12:02 |
| T_UNIX | I'm trying to build qt 5.5.1 using dylan infrastructure. For some reason the qmake binary of the qtbase package is build for the build target, instead of the target arch. | 12:03 |
| T_UNIX | is that a bug that was overcome somewhen? | 12:03 |
| rburton | building target qtcore will build a target qmake, you want to build the native form first | 12:04 |
| sveinse | T_UNIX: Do you have DEPENDS += "qttools-native" in your recipe? | 12:04 |
| T_UNIX | sveinse: I have "grep qtbase-native * qtbase_5.5.1.bb:DEPENDS += "qtbase-native"" | 12:05 |
| T_UNIX | I think qttools[-native] is not available in dylan release. | 12:06 |
| simonl | https://www.irccloud.com/pastebin/plEEbQfD/compile%20log | 12:07 |
| sveinse | T_UNIX: ok, sorry, then I don't know | 12:07 |
| *** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has quit IRC | 12:07 | |
| simonl | rburton: ^ | 12:07 |
| T_UNIX | rburton: there is no qtcore target :-/ neither grep nor find could reveal one | 12:08 |
| T_UNIX | rburton: I'm not quite sure what's going on.. Either the -native qmake is packaged in the package stage of the qtbase recipe, or the qmake in qtbase is compiled with the wrong compiler :-/ | 12:09 |
| *** psadro <psadro!~Thunderbi@2620:0:ed0:800a:72f3:95ff:fe1d:9866> has joined #yocto | 12:09 | |
| T_UNIX | I'll have a closer look at the compile and install stages of the corresponding recipes.. | 12:13 |
| *** bluelightning <bluelightning!~paul@fixed-203-32-189-203-32-226.iusacell.net> has joined #yocto | 12:16 | |
| *** bluelightning <bluelightning!~paul@fixed-203-32-189-203-32-226.iusacell.net> has quit IRC | 12:16 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 12:16 | |
| *** jkridner|pd <jkridner|pd!~jkridner@c-68-61-101-211.hsd1.mi.comcast.net> has joined #yocto | 12:29 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 12:30 | |
| *** rZr <rZr!~RzR@unaffiliated/rzr> has left #yocto | 12:30 | |
| *** joshuagl <joshuagl!~joshuagl@192.198.151.45> has quit IRC | 12:31 | |
| *** dv_ <dv_!~quassel@62.178.118.86> has quit IRC | 12:37 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 12:37 | |
| *** dv <dv!~quassel@62.178.118.86> has joined #yocto | 12:38 | |
| neverpanic | where would I find logfiles for a setscene task? | 12:38 |
| *** joshuagl <joshuagl!~joshuagl@192.198.151.44> has joined #yocto | 12:44 | |
| *** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC | 12:47 | |
| *** zeddii <zeddii!~bruce@128.224.252.2> has joined #yocto | 12:49 | |
| *** paulg <paulg!~paulg@OTWAON23-3096772825.sdsl.bell.ca> has joined #yocto | 12:54 | |
| *** anselmolsm <anselmolsm!~anselmols@192.55.55.39> has joined #yocto | 12:54 | |
| *** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto | 12:55 | |
| *** dmoseley <dmoseley!~dmoseley@6532158hfc157.tampabay.res.rr.com> has joined #yocto | 12:57 | |
| *** BlitzBlizz <BlitzBlizz!~blitz@2001:638:102:36:e3aa:c03b:c3ec:41c6> has quit IRC | 12:58 | |
| HyP3r | Can someone tell me the difference of DEPENDS and RDEPENDS? I don't get it out of the refreence | 13:06 |
| HyP3r | http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#var-RDEPENDS | 13:07 |
| rburton | depends is build time, rdepends is runtime | 13:08 |
| HyP3r | ok, so if I do a only depends, Yocto will not include this package into the rootfs? | 13:08 |
| rburton | yes, but if the depends results in eg your application linking to a library, that library's package is automatically added to RDEPENDS | 13:09 |
| rburton | which is why you never see recipes rdepending on libc and so on | 13:09 |
| HyP3r | So is it better to define everything twice, DEPENDS and RDEPENDS or only RDEPENDS? | 13:10 |
| rburton | if the runtime depend is a library then it will be automatically added | 13:11 |
| rburton | anything else depends on context | 13:11 |
| rburton | a package will build-depend on make but won't need it at runtime | 13:11 |
| rburton | a package may dlopen() a library so it won't get detected automatically, so you need to add it to RDEPENDS | 13:11 |
| rburton | an app may call other apps, so you'll need them in RDEPENDS but not DEPENDS | 13:11 |
| rburton | there's no One True Answer, you just have to reflect reality in the packaging | 13:12 |
| HyP3r | ok | 13:12 |
| HyP3r | So I will look through my bunch of recpies, I guess I did it wrong | 13:12 |
| *** gleikeo <gleikeo!b2143441@gateway/web/freenode/ip.178.20.52.65> has quit IRC | 13:16 | |
| Ulfalizer | HyP3r: the latest version of the reference manual has more information by the way: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-DEPENDS | 13:25 |
| Ulfalizer | i added the note because i've seen a lot of people being confused by DEPENDS vs. RDEPENDS | 13:26 |
| Ulfalizer | the newer versions of the manual have a lot more stuff in general | 13:26 |
| Ulfalizer | HyP3r: a good rule of thumb is to only use RDEPENDS if you're really sure what you're doing, and always use DEPENDS otherwise | 13:29 |
| Ulfalizer | RDEPENDS is only needed if you have dependencies between packages that yocto can't infer by itself, e.g. if some program assumes that another program is installed because it runs it directly | 13:30 |
| Ulfalizer | for library dependencies, yocto can figure it out by itself | 13:31 |
| *** rcw <rcw!~rwoolley@128.224.252.2> has joined #yocto | 13:35 | |
| Ulfalizer | ...except e.g. in the dlopen() case i just noticed rburton mentioned :P | 13:42 |
| *** hamis_lt_u <hamis_lt_u!~irfan@110.93.212.98> has quit IRC | 13:44 | |
| *** gtristan <gtristan!~tristanva@114.207.54.40> has quit IRC | 13:45 | |
| *** Anticom <Anticom!~timo.m@217.6.33.234> has quit IRC | 13:47 | |
| HyP3r | Ulfalizer: in my case the image generation recpie points with IMAGE_INSTALl to some of my packages. E.g. foo-www. This package does not use autotools or something, it has only a mkdir -p ${D}/www and cp -Rd ${S}... ${D}... | 13:48 |
| HyP3r | So I'm pretty sure that can't see that this foo-www package needs python, apache, mod-wsgi, django, ... | 13:48 |
| HyP3r | So I decied to add some RDEPENDS, if I understood it correct | 13:49 |
| *** benjamirc <benjamirc!besquive@nat/intel/x-iutgdxdnnxjqbrmr> has joined #yocto | 13:50 | |
| HyP3r | But I gues I have to to a cleanall and recompile everything to make sure I have enough build dependencys | 13:50 |
| Ulfalizer | yeah, unless there's some relevant bbclass that adds the RDEPENDS for you, and they're not straightforward library dependencies, you'll have to declare them yourself in RDEPENDS | 13:50 |
| Ulfalizer | HyP3r: see http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#checking-for-missing-build-time-dependencies re. missing build dependencies | 13:51 |
| *** jkridner|pd <jkridner|pd!~jkridner@c-68-61-101-211.hsd1.mi.comcast.net> has quit IRC | 13:52 | |
| Ulfalizer | tldr; $ wipe-sysroot + rebuild should be a safe bet | 13:52 |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 13:52 | |
| HyP3r | yeah this tmp dir deleting sounds good, | 13:52 |
| Ulfalizer | or just run wipe-sysroot | 13:53 |
| *** AndersD <AndersD!~anders@213-64-218-130-no126.business.telia.com> has quit IRC | 13:53 | |
| HyP3r | yeah I like your too long didn't read :P | 13:54 |
| HyP3r | Another thing I'm currently handling but I'm not sure if this way is good: deamons and programs like samba, ntp, apache2, avahi do have configuration files, and I want to insert my own configuration files. I solved that by createing bbappend recpies for all those recpies (samba, apache, ...) and appened the install phase: do_install_append(). While this routine I added (copy over) my own configuration | 13:56 |
| HyP3r | I this a good way? | 13:56 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 13:56 | |
| *** maxin <maxin!~maxin@2001:998:22:0:657c:8573:13c2:de73> has quit IRC | 13:57 | |
| Ulfalizer | probably not a horrible approach at least | 13:58 |
| *** ntl <ntl!~nathanl@99-127-51-4.lightspeed.austtx.sbcglobal.net> has joined #yocto | 13:58 | |
| Ulfalizer | check out the CONFFILES variable too | 13:58 |
| HyP3r | ... not a horrible approach ... ooookay. Is there a better way? | 13:59 |
| Ulfalizer | not sure | 13:59 |
| HyP3r | well then I think its ok, for me, third week with yocto \o/ | 13:59 |
| Ulfalizer | can't think of anything for "global" configuration files | 13:59 |
| *** lamego <lamego!~jose@134.134.139.82> has joined #yocto | 14:00 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 14:02 | |
| *** qt-x <qt-x!~Thunderbi@217.10.196.2> has quit IRC | 14:04 | |
| *** madisox <madisox!~madison@12.30.244.5> has joined #yocto | 14:08 | |
| *** igor2 <igor2!~igor@189.112.127.225> has joined #yocto | 14:08 | |
| *** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC | 14:09 | |
| *** igor3 <igor3!~igor@189.112.127.225> has joined #yocto | 14:12 | |
| *** igor2 <igor2!~igor@189.112.127.225> has quit IRC | 14:14 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 14:17 | |
| *** jkridner|pd <jkridner|pd!~jkridner@c-68-61-101-211.hsd1.mi.comcast.net> has joined #yocto | 14:18 | |
| *** nighty <nighty!~nighty@s229123.ppp.asahi-net.or.jp> has joined #yocto | 14:20 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 14:22 | |
| *** jkridner|pd <jkridner|pd!~jkridner@c-68-61-101-211.hsd1.mi.comcast.net> has quit IRC | 14:26 | |
| *** AgentElrond <AgentElrond!~ELROND@97-102-189-66.res.bhn.net> has joined #yocto | 14:26 | |
| *** jkridner <jkridner!~jkridner@2601:409:8500:9430:2941:9702:841e:44> has joined #yocto | 14:29 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 14:29 | |
| AgentElrond | For anyone familiar with qemu, is it normal that the last line I see is "main-loop: WARNING: I/O thread spun for 1000 iterations" when I try to run my yocto-built image on qemuarm? | 14:30 |
| AgentElrond | Google suggests some people had freezing problems for this but with other operating systems. | 14:30 |
| *** maxin <maxin!~maxin@37-219-27-165.nat.bb.dnainternet.fi> has joined #yocto | 14:33 | |
| *** aehs29 <aehs29!aehernan@nat/intel/x-tythmdyrzoxsafcu> has joined #yocto | 14:34 | |
| *** visaev <visaev!~visaev@81.171.81.144> has quit IRC | 14:47 | |
| *** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC | 14:47 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 14:48 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 14:49 | |
| *** caiortp <caiortp!~inatel@131.221.240.204> has joined #yocto | 14:49 | |
| *** JaMa <JaMa!~martin@ip-89-176-104-169.net.upcbroadband.cz> has joined #yocto | 14:52 | |
| *** gtristan <gtristan!~tristanva@110.11.179.37> has joined #yocto | 14:53 | |
| *** paulg <paulg!~paulg@OTWAON23-3096772825.sdsl.bell.ca> has quit IRC | 15:15 | |
| *** maxin <maxin!~maxin@37-219-27-165.nat.bb.dnainternet.fi> has quit IRC | 15:21 | |
| *** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC | 15:22 | |
| *** Crofton <Crofton!~Crofton@217.155.200.106> has joined #yocto | 15:23 | |
| *** eduardas_m <eduardas_m!~eduardas_@213.197.143.19> has quit IRC | 15:34 | |
| *** fledermaus <fledermaus!~vivek@2a00:1098:5:0:d937:3976:9319:8236> has joined #yocto | 15:37 | |
| *** armpit <armpit!~akuster@2601:202:4001:9ea0:94d9:eae7:71b3:4646> has quit IRC | 15:44 | |
| *** jbrianceau is now known as jbrianceau_away | 15:47 | |
| *** billr <billr!~wcrandle@134.134.139.82> has joined #yocto | 15:52 | |
| *** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto | 15:58 | |
| HyP3r | Is there a way to configure a recpie that way, so every build time its completely _rebuilt_? | 15:59 |
| *** t0mmy <t0mmy!~tprrt@217.114.201.133> has quit IRC | 15:59 | |
| *** rajm <rajm!~robertmar@82-70-136-246.dsl.in-addr.zen.co.uk> has quit IRC | 15:59 | |
| *** Crofton <Crofton!~Crofton@217.155.200.106> has quit IRC | 16:01 | |
| *** stephano <stephano!stephano@nat/intel/x-auffyyhiabmxszhk> has joined #yocto | 16:01 | |
| jubr | HyP3r: http://www.crashcourse.ca/wiki/index.php/BitBake_task_flags | 16:01 |
| jubr | esp [nostamp] | 16:01 |
| HyP3r | https://github.com/01org/luv-yocto/blob/master/meta/classes/kernel.bbclass#L365 | 16:03 |
| HyP3r | ok, but what should I write do_install[nostamp] or do_compile[nostamp], or...? | 16:03 |
| *** vmeson <vmeson!~rmacleod@24-212-184-107.cable.teksavvy.com> has quit IRC | 16:04 | |
| *** vmeson <vmeson!~rmacleod@24-212-184-107.cable.teksavvy.com> has joined #yocto | 16:04 | |
| jubr | Depends on how early you want it to start? At do_compile? do_configure? do_unpack? | 16:04 |
| HyP3r | so I can also do do_fetch[nostamp] so the package will be allways fetched, configured, compiled... | 16:05 |
| CTtpollard | do_unpack is quite common | 16:05 |
| * jubr made a mental note of the [dirs] flag, a bit nicer than all those `mkdir -p` in do_install | 16:05 | |
| HyP3r | Because I also need that this packages I always fetched | 16:06 |
| CTtpollard | I've used nostamp there on a few problematic recipes that don't play nice with ssate | 16:06 |
| jubr | CTtpollard: yep, do_unpack also ensures teh do_patch is run | 16:06 |
| *** fl0v0 <fl0v0!~fvo@pD9F6B7EE.dip0.t-ipconnect.de> has quit IRC | 16:06 | |
| HyP3r | Is this correct? | 16:06 |
| CTtpollard | HyP3r: yes, if you need it to fetch every time | 16:07 |
| HyP3r | yes :( | 16:07 |
| CTtpollard | so it will refetch, unpack configure etc etc | 16:08 |
| HyP3r | Its nice that yocto has for everythiing a solution | 16:08 |
| * jubr agrees | 16:09 | |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 16:12 | |
| *** Crofton <Crofton!~Crofton@217.155.200.106> has joined #yocto | 16:15 | |
| kergoth | only downside is there's often more than one solution, and it's not always clear which is best :) | 16:16 |
| kergoth | HyP3r: re: overriding config files via bbappend, recipetool's appendfile command automates that process, can save some time over doing so manually, in case you didn't know | 16:16 |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 16:17 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 16:17 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 16:18 | |
| *** billr <billr!~wcrandle@134.134.139.82> has quit IRC | 16:22 | |
| HyP3r | kergoth: I don't even know recpietool | 16:23 |
| kergoth | recipetool and devtool are extremely valuable tools, really helpful and time saving | 16:23 |
| *** vmesons <vmesons!~rmacleod@24-212-184-107.cable.teksavvy.com> has joined #yocto | 16:23 | |
| *** vmeson <vmeson!~rmacleod@24-212-184-107.cable.teksavvy.com> has quit IRC | 16:23 | |
| AgentElrond | kergoth: I tried doing a directory rename like I mentioned yesterday | 16:23 |
| AgentElrond | I delete tmp but made no other changes. Running bitbake again fails trying to find the absolute path of my layer.conf file -- any ideas? | 16:24 |
| khem | CTtpollard: that rpi change was from me :) but its not fixing all cases. One of these days I will nail it | 16:24 |
| khem | rburton: the problem is that vardepexclude does not help when DATE and TIME are used inside anonymous python snippets | 16:24 |
| kergoth | HyP3r: recipetool appendfile meta-mylayer /etc/some-file /path/to/my/replacement/file -> writes a .bbappend tinto the meta-mylayer layer for whatever recipe provides /etc/some-file (assumign it's been built already, or you can specify the recipe with -r) | 16:25 |
| khem | rburton: or even names python functions | 16:25 |
| khem | or say I could not beat bitbake to accept it | 16:25 |
| kergoth | khem: anonymous python won't affect the checksums, and named functions you can use vardepsexclude on | 16:25 |
| khem | thats the nub of the issue I am seeing | 16:25 |
| * kergoth yawns | 16:25 | |
| HyP3r | kergoth: sound good, I'll try to find some documentation about that | 16:25 |
| khem | kergoth: thats what I thought but it seems base hash does account for anon python | 16:26 |
| kergoth | nope | 16:26 |
| khem | I have an example :0 | 16:26 |
| kergoth | anonymous python code was always explicitly *not* included. the results of what the functions do can affect che ksums, but not their code | 16:26 |
| jubr | kergoth: Tnx! recipetool looks nice, will look into that one! | 16:27 |
| AgentElrond | kergoth: Would removing build/tmp and manually updating paths in build/conf be sufficient for an overall absolute path change? | 16:27 |
| kergoth | including the code would be a clear bug IMO. the whole point of anonymous python is to alter metadata, and the effects of that will affect other checksums regardless, so there'd be no point including it | 16:27 |
| kergoth | AgentElrond: yes, altering bblayers.conf would fix yourl ayer.conf error. that + wiping tmp would do | 16:28 |
| khem | kergoth: see https://gist.github.com/kraj/63a3f0ac6cd6af31e8e57d4fd35a3059 | 16:28 |
| kergoth | khem: that won't work, you're putting it on the indirect thing, which doesn't work given the current implementation | 16:29 |
| khem | kergoth: thats a abridged snippet with intesting bits, now if I comment out stamp = assignment to be an empty string all works ok | 16:29 |
| kergoth | khem: tweak_image_name[vardepsexclude] += "DATE TIME" | 16:29 |
| AgentElrond | kergoth: Thanks! | 16:31 |
| *** phoo1234567 <phoo1234567!~phoo12345@c-75-69-172-183.hsd1.nh.comcast.net> has joined #yocto | 16:31 | |
| khem | kergoth: see https://gist.github.com/kraj/010ac278ecb7b69b35403136935ad571 | 16:32 |
| *** joshuagl <joshuagl!~joshuagl@192.198.151.44> has quit IRC | 16:32 | |
| khem | thats with above | 16:32 |
| khem | included | 16:32 |
| kergoth | hmm, sounds like a bug in the checksumming code somewhere | 16:33 |
| kergoth | basehash mismatches are such a pain to diagnose | 16:33 |
| kergoth | taskhash too, but still | 16:33 |
| jubr | kergoth: crap, we're stuck with Freescale's bsp based on fido, my `recipetool --help` only lists `create` :( | 16:33 |
| kergoth | ah | 16:34 |
| rburton | kergoth: can whatdepends -r show the package that i was looking for? in the connman in core-image-sato example, it doesn't list connman. | 16:34 |
| *** billr <billr!~wcrandle@134.134.139.76> has joined #yocto | 16:39 | |
| khem | jubr: always a good thing to move forward and upgrade | 16:41 |
| jubr | khem: preaching to the choir, baby. New device needs to be up & running & into field trials first... | 16:43 |
| AgentElrond | kergoth: You were of course correct. After updating bblayers.conf and blowing away tmp, the build looks like it may finish in 20 minutes which is better than 3 hours. :P | 16:47 |
| kergoth | nice | 16:47 |
| AgentElrond | kergoth: The only notable exception is that the Linux kernel got recompiled for some reason. | 16:47 |
| khem | kergoth: any workarounds you can think of ? | 16:58 |
| khem | ignoring date/time in hashes in python functions | 16:58 |
| *** T_UNIX <T_UNIX!d4d3bd3c@gateway/web/freenode/ip.212.211.189.60> has quit IRC | 16:58 | |
| *** grma <grma!~gruberm@80.93.38.128> has quit IRC | 16:59 | |
| kergoth | absolute worst case you could add both to the basehash whitelist, that should exclude it across the board, i expect | 16:59 |
| *** Crofton <Crofton!~Crofton@217.155.200.106> has quit IRC | 17:00 | |
| *** AgentElrond <AgentElrond!~ELROND@97-102-189-66.res.bhn.net> has quit IRC | 17:01 | |
| RP | kergoth: thanks for the review btw, I tweaked the commit message you mentioned. I've posted the main multi-config patch now, about to put it into -next and give it wider testing on the AB | 17:02 |
| sveinse | We talk alot about sharing sstate cache. But is it possible to share download dirs as well? | 17:02 |
| RP | kergoth: biggest worry now is whether I've missed some API changes somewhere :/ | 17:02 |
| RP | Its a pain but could have been a lot worse | 17:02 |
| ntl | sveinse: yes, the conf variable is DL_DIR | 17:07 |
| *** benjamirc <benjamirc!besquive@nat/intel/x-iutgdxdnnxjqbrmr> has quit IRC | 17:08 | |
| sveinse | Will a yocto build always max out memory (and swap) regardless of how much memory you throw at it? It an impressive amount of ps which is started. | 17:10 |
| neverpanic | sveinse: depends on what you do with it and many threads you start | 17:11 |
| neverpanic | template-heavy C++ usually needs more memory than compiling C | 17:11 |
| sveinse | The default, which is N jobs and N parallel make, IIRC | 17:11 |
| neverpanic | yeah, and N depends on $num_cpus, so whether your memory is maxed out depends on the relation between the number of CPUs you have and the amount of memory | 17:12 |
| khem | sveinse: ntl: its not safe to have same DL_DIR shared in different workspaces due to the fact that they can race against each other if building in parallel | 17:12 |
| *** Crofton <Crofton!~Crofton@217.155.200.106> has joined #yocto | 17:13 | |
| khem | better is to setup a source mirror in vicinity | 17:13 |
| sveinse | I just upped our build server from 8G to 16G, and it seems it is CPU bound, with the occasional page miss | 17:14 |
| khem | if you point DL_DIR to same location, it actually means you are allowing read and write operations from different workspaces | 17:14 |
| sveinse | I have a suspicion that if I threw 64G RAM at it, the sheer number of processes would still max out memory at some point | 17:14 |
| khem | sveinse: unless you build something like webkit/chromium, more memory is only going to be used as file cache, which in itself is an improvement | 17:15 |
| khem | sveinse: more memory is going to give you a better performance no matter what | 17:15 |
| khem | unless you have fast SSDs | 17:15 |
| khem | in which case it may be less of improvement | 17:15 |
| khem | like its useless to use distcc now a days, there once was a time when we were cpu bound and distcc would be helpful, now a days the distcc distributor node becomes a bottleneck quickly | 17:17 |
| sveinse | Well, I have 16 core Xeon build server, running guest on a Hyper-V VM, with direct access to a SSD. Upping the memory from 8G to 16G helped (I think). If I need more, I need to have a clear rationale for it. Not just because I want it. Server RAM is expensive | 17:17 |
| halfhalo | webkit/chromium is plenty happy to use 72+ cores and massive amounts of memory | 17:18 |
| sveinse | khem: I do share DL_DIR amongst workspaces. Luckily, the build thread is singleton, so only one bitbake is running at one given time :D | 17:19 |
| *** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto | 17:20 | |
| *** adelcast <adelcast!~adelcast@130.164.62.126> has joined #yocto | 17:20 | |
| khem | jubr: yes thats modus operandi unfortunately for many in industry, I am a big believer in rolling releases, and moving all testing and QA to left of commit, which means if thats successful, then your master is always releasable | 17:21 |
| khem | distros like archlinux are good examples | 17:21 |
| khem | time bases releases are things of past CI/CD is more optimal | 17:22 |
| khem | sveinse: as long as you enforce that restriction you are safe | 17:22 |
| *** belen <belen!~Adium@134.134.139.76> has quit IRC | 17:22 | |
| khem | kergoth: let me try to add it to basehash whitelist | 17:23 |
| *** adelcast <adelcast!~adelcast@130.164.62.126> has quit IRC | 17:25 | |
| *** MWelchUK <MWelchUK!~martyn@host81-147-3-127.range81-147.btcentralplus.com> has quit IRC | 17:26 | |
| sveinse | Has any of you experienced problem massively parallel building uim? meta-openembedded/meta-oe/recipes-support/uim/uim_1.8.6.bb in jethro. I just had a stop on uim do_install: "/srv/builds/core-image/build/tmp/work/x86_64-linux/uim-native/1.8.6-r0/build/uim/.libs/libuim.so: file not recognized: File format not recognized". Re-run bitbake, and everyone is happy. Smells awfully like race, doesn't it? | 17:26 |
| *** benjamirc <benjamirc!~besquive@134.134.137.75> has joined #yocto | 17:27 | |
| *** yann <yann!~yann@85-171-21-92.rev.numericable.fr> has quit IRC | 17:32 | |
| *** nisha <nisha!~nisha@38.104.105.146> has quit IRC | 17:33 | |
| khem | sveinse: yes its a race | 17:35 |
| khem | sveinse: try PARALLEL_MAKEINST = "" for validating the issue | 17:36 |
| khem | if this works then the package has issues with parallel build | 17:36 |
| khem | especially with make install target | 17:37 |
| khem | kergoth: whats the incantation to whitelist something from basehash something with BB_BASEHASH | 17:38 |
| *** boucman_work <boucman_work!~boucman@2a02-8428-034f-f800-9e32-0c7c-b391-6223.rev.sfr.net> has joined #yocto | 17:38 | |
| *** nisha <nisha!~nisha@38.104.105.146> has joined #yocto | 17:43 | |
| neverpanic | sveinse: yeah, a gig per core is what you should have at minimum. We're running 40 core + 64GiB on our workstations and still regularly hit top RAM | 17:43 |
| *** JaMa <JaMa!~martin@ip-89-176-104-169.net.upcbroadband.cz> has quit IRC | 17:44 | |
| *** armpit <armpit!~akuster@50.233.148.156> has joined #yocto | 17:45 | |
| *** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-exdhkdbrwzfnrdby> has quit IRC | 17:49 | |
| *** davis <davis!~davis@50-76-27-165-static.hfc.comcastbusiness.net> has joined #yocto | 17:50 | |
| davis | hello | 17:50 |
| davis | i'm having trouble pulling from a private repot with git. I can git clone the url from a bash prompt and I'm authenticated using keys, so I dont need to login or anything. | 17:51 |
| *** zeddii_home_ <zeddii_home_!~zeddii_ho@CPEe8de27b71faa-CMbcc810032faf.cpe.net.cable.rogers.com> has joined #yocto | 17:51 | |
| davis | however, when I try to do it with bitbake it fails. Here is my setup and error. | 17:52 |
| davis | https://gist.github.com/netskink/3d090630ccb44d9e58bbc5754538c3f2 | 17:52 |
| *** sujith_h <sujith_h!~toaster@kde/developers/sujithh> has quit IRC | 17:53 | |
| *** zeddii_home <zeddii_home!~zeddii_ho@CPEe8de27b71faa-CMbcc810032faf.cpe.net.cable.rogers.com> has quit IRC | 17:53 | |
| khem | davis: you may use ssh protocol | 17:53 |
| *** zeddii_home_ is now known as zeddii_home | 17:53 | |
| davis | i have protocl=ssh in the SRC_URI string | 17:54 |
| davis | fwiw, here is what it looks like | 17:55 |
| davis | SRC_URI = "git://devsupport/tfs/Linux%20PCM%20Project%20\(Reboot%20Edition\)/_git/PCMX;protocol=ssh;branch=master" | 17:55 |
| khem | something like SRC_URI = "git://git@github.com/xxxxx/arepo.git;protocol=ssh;branch=master" | 17:55 |
| khem | those %20 worries me | 17:55 |
| davis | yeah me too | 17:56 |
| davis | also the escaped ()'s | 17:56 |
| khem | anyway try git://git@github.com | 17:56 |
| khem | and this should help | 17:56 |
| davis | i've done things like this and it worked, | 17:56 |
| davis | #SRC_URI = "git://gitlab.com/netskink/cmake-tutor.git;protocol=https;branch=bitbake" | 17:56 |
| davis | gitlab does not have git protocol, so you need http or ssh | 17:57 |
| *** radzy <radzy!~radzy@unknown-216-194.windriver.com> has quit IRC | 17:57 | |
| *** sujith_h <sujith_h!~toaster@139.181.35.34> has joined #yocto | 17:57 | |
| davis | adding a git@ to my url does not work. same error. | 17:59 |
| *** radzy <radzy!~radzy@unknown-216-194.windriver.com> has joined #yocto | 18:01 | |
| *** willeponken <willeponken!~willeponk@diderot.campus.ltu.se> has quit IRC | 18:02 | |
| sveinse | khem: The way we come around that race is usually just to rerun the build. When it completes, it populates itself into the sstate cache, so usually we don't need that build any more. But it is really annoying when that happens (esp. when working on something else) | 18:07 |
| *** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has joined #yocto | 18:10 | |
| *** Biliogadafr <Biliogadafr!~pin@nat3-minsk-pool-46-53-182-183.telecom.by> has joined #yocto | 18:10 | |
| sveinse | BTW, rerunning the uim recipe with all cores enables also resolves the race. It just happens from time to time | 18:11 |
| *** simonl <simonl!uid6729@gateway/web/irccloud.com/x-hjggxemhqsnqyigk> has quit IRC | 18:16 | |
| *** Crofton <Crofton!~Crofton@217.155.200.106> has quit IRC | 18:17 | |
| *** RagBal <RagBal!~RagBal@82-168-15-181.ip.open.net> has quit IRC | 18:23 | |
| *** Rootert <Rootert!~Rootert@82-168-15-181.ip.open.net> has quit IRC | 18:23 | |
| davis | so here is a simpler situation. I have my own personal ssh repot here | 18:25 |
| davis | git@gitlab.com:netskink/awesome-breakout.git | 18:26 |
| davis | i did the SRC_URI like this | 18:26 |
| davis | SRC_URI = "git://git@gitlab.com:netskink/awesome-breakout.git" | 18:26 |
| kergoth | if you're copying and pasting that as is, it will not work. the url based syntax uses different separators | 18:26 |
| kergoth | yeah, that's wrong | 18:26 |
| davis | that does not worki either | 18:26 |
| kergoth | : isn't a valid separator between host and path in a url | 18:26 |
| kergoth | it's the separator between user and password | 18:26 |
| khem | davis is it gitlab ? | 18:26 |
| davis | yes its gitlab in that case | 18:26 |
| khem | then you might need to use :22/x/y/z | 18:26 |
| khem | after url | 18:27 |
| kergoth | git://git@gitlab.com/netskink/awesome-breakout.git;protocol=ssh | 18:27 |
| kergoth | :22? interesting, that should be default for the ssh protocol, no? | 18:27 |
| sveinse | Is there a way to run bb up until runing a recipe (going to test parallel builds in uim)? Is do_fetch a good place to stop and then rerun using a single CPU? | 18:27 |
| khem | or git://git@gitlab.com:22/netskink/awesome-breakout.git;protocol=ssh | 18:27 |
| khem | sveinse: as suggested try to nail it at root | 18:28 |
| davis | SRC_URI = "git://git@gitlab.com:/netskink/awesome-breakout.git;protocol=ssh" that works | 18:28 |
| *** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has quit IRC | 18:28 | |
| khem | workaround is to disable parallel install | 18:28 |
| sveinse | khem: Yeah, and with 5300 recipes in build, you'd want to not run those with PARALLEL_MAKEINST="", right? | 18:29 |
| *** sameo <sameo!~samuel@192.55.54.43> has joined #yocto | 18:29 | |
| khem | kergoth: looking for your help on disabling something from basehash | 18:29 |
| khem | sveinse: its a per recipe change | 18:29 |
| khem | sveinse: you just want to do it for uim | 18:29 |
| khem | which is a reasonable workaround | 18:29 |
| sveinse | khem: Ah, then. thanks | 18:29 |
| khem | unless you want to help fixing it | 18:30 |
| davis | hmm. so the one works with gitlab. I use that as a model for this internal Team Foundation Server and it fails. so frustrating working with a m$ server. | 18:30 |
| khem | davis: so you missed protocol setting from what was suggested earlier | 18:30 |
| davis | i added ;protocol=ssh at the end | 18:31 |
| khem | davis: yeah thats right | 18:31 |
| sveinse | khem, dunno if I'm that experienced enough in yocto and am builds yet. But I am taking a look at it now | 18:31 |
| davis | timestmap 14:28 works | 18:31 |
| khem | sveinse: thats the spirit :) | 18:31 |
| davis | sveinse: I am the biggest noob here and sometimes I even get lucky. | 18:31 |
| kergoth | khem: see bitabke.conf for the default bb basehash whitelist. iirc you might need to append to it with a ConfigParsed event handler, in the past it didn't like _append very much | 18:31 |
| sveinse | davis: Encouraging words... I',m what, three week into yocto. A lot of things to process. (yet I've done embedded build systems for many years, so some is familiar. Its the semantics which is different.) | 18:33 |
| fischerm | zeddii: trying to get salt-minion running on an oe target, since I pulled in meta-cloud-services root password is not empty (unknown). Ideas? | 18:33 |
| *** sno <sno!~sno@62.157.143.22> has quit IRC | 18:33 | |
| davis | so in gitlab url, it was git@gitlab.com:/my_user_name/project-name.git;protocl=ssh | 18:33 |
| davis | i wonder if that my_user_name is part of the url, or is an identifier for a login? I thought the public key was all that was necessary to authenticate with the repot. | 18:34 |
| davis | sveinse: i'm glad I can be encouraging. sometimes its all i feel i can do. lol | 18:34 |
| sveinse | davis: heh, I can help you with that if you need it to. the blind leading the blind and so on... :P | 18:36 |
| davis | fwiw, in my case ive asked the admin to change the "cell?" name and the repot name so there aren't any spaces or parens involved. | 18:36 |
| davis | also to check logs to see if its an authentication problem | 18:37 |
| sveinse | How do you force rebuilding a recipe which is in the sstate cache? | 18:37 |
| davis | sveinse: ive been working off and on with yocto a while now. "Embedded Linux Systems with the Yocto Project" is a good book. | 18:37 |
| davis | for rebuild, try cleanstate | 18:38 |
| khem | fischerm: you might need to add EXTRA_IMAGE_FEATURES ?= "debug-tweaks" to local.conf | 18:38 |
| davis | give me a second, i find the syntax | 18:38 |
| khem | davis: if you are in good terms with your IT lords the life can be easier | 18:39 |
| khem | davis: you can replace git://git@xx.com with git://cell@xx.com | 18:39 |
| khem | for user to be cell | 18:39 |
| khem | sveinse: bitbake -ccleansstate <recipe>;bitbake recipe | 18:40 |
| khem | recipe here is recipe name without .bb | 18:40 |
| *** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has joined #yocto | 18:40 | |
| sveinse | davis, I didn't get the start of you URI problems, but you know you can setup username, certs and stuff in ~/.ssh/config, right? | 18:41 |
| sveinse | We do that for some private repos which require login. This way we don't have to bother in SRC_URI | 18:41 |
| davis | sveinse: no i did not know that. | 18:41 |
| davis | i used this as a guide | 18:43 |
| davis | http://nerderati.com/2011/03/17/simplify-your-life-with-an-ssh-config-file/ | 18:43 |
| sveinse | davis, heres one "live" example: http://paste.ubuntu.com/23062464/ | 18:43 |
| davis | my clone still works. | 18:44 |
| davis | from cmd line | 18:44 |
| davis | ahh you add an id file | 18:44 |
| davis | is the entry for IdentifyFile your private key or public? | 18:45 |
| sveinse | This is the private, because it needs it to set up the encrypted link | 18:46 |
| khem | RP: kergoth https://bugzilla.yoctoproject.org/show_bug.cgi?id=10152 | 18:46 |
| yocti | Bug 10152: normal, Undecided, ---, richard.purdie, NEW , Bitbake always gets taskhash mismatches when using DATE and TIME in python functions | 18:46 |
| khem | its a regression compared to 2.0 and older releases | 18:47 |
| davis | sveinse: ok cool, still does not work though. I'll add that to my notes though. | 18:47 |
| sveinse | (I had to introduce the .ssh/keys/ directory, because ssh automatically tries the identities in .ssh/ and some servers kicks you out if you try too many keys) | 18:47 |
| davis | it would prevent me from having to pass an ident as command line when dealing with aws, i bet | 18:47 |
| sveinse | yes. And its convenient to setup username and stuff. "ssh buildserver" is all I write to log in to it | 18:48 |
| khem | sveinse: davis if you can convince your IT overlords to expose https protocol then you can just tool the use of username/pw in ~/.netrc and it will scale into automation | 18:48 |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 18:49 | |
| * sveinse will cry when his IT overlords starts closing down port 22 | 18:49 | |
| sveinse | windows admins barely know what it is | 18:50 |
| fischerm | khem: will give a shop | 18:50 |
| fischerm | khem: thx | 18:50 |
| davis | khem: team foundation server gives an opton to use https | 18:51 |
| davis | i'll look into netrc | 18:51 |
| *** pohly <pohly!~pohly@dyndsl-031-150-142-006.ewe-ip-backbone.de> has joined #yocto | 18:54 | |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto | 18:55 | |
| khem | davis: you need something like | 18:56 |
| khem | machine <machine-name> login <username> password <password> | 18:57 |
| khem | entry in ~/.netrc | 18:57 |
| *** RagBal <RagBal!~RagBal@82-168-15-181.ip.open.net> has joined #yocto | 18:58 | |
| khem | and then you can use "git://machine-name/dir/to/repo;protocol=https" | 18:58 |
| *** Rootert <Rootert!~Rootert@82-168-15-181.ip.open.net> has joined #yocto | 18:58 | |
| davis | heh, i was just doing my netrc | 18:58 |
| sveinse | Hmm. Been running -ccleansstate and rebuilding uim on with all available CPU without failing any single time. Perhaps a missing DEPENDS, which now is present in sysroot? | 18:58 |
| davis | yes, it works with http on bash level | 18:58 |
| sveinse | 5 times I've runned it | 18:58 |
| khem | sveinse: thats possible | 18:59 |
| sveinse | wipe-sysroot and then try rebuilding uim? | 18:59 |
| khem | sveinse: rm -rf tmp/;bitbake uim | 18:59 |
| khem | will expose DEPENDS issues | 18:59 |
| sveinse | ok, will try | 18:59 |
| khem | wipe the whole tmp | 18:59 |
| khem | it will reuse everything from sstate on rebuild so it will be matter of few minutes to rebuild | 19:00 |
| davis | whoa! that is working | 19:00 |
| davis | no | 19:00 |
| khem | and you will also get to experience the power OE at same time :) | 19:00 |
| davis | it went further but failed. perhaps, PV="1.0.0+git${SRCPV} | 19:00 |
| khem | davis: ofcourse it works, I use it every day | 19:00 |
| davis | " is a problem. | 19:01 |
| khem | whats the error ? | 19:01 |
| sveinse | While I'm waiting: Our server is running Ubuntu server, so lvm is installed by default. A bad idea for yocto? | 19:01 |
| davis | let me gist it | 19:01 |
| khem | sveinse: lvm is ok. nfs has gripes | 19:02 |
| *** fledermaus <fledermaus!~vivek@2a00:1098:5:0:d937:3976:9319:8236> has quit IRC | 19:02 | |
| davis | https://gist.github.com/netskink/3d090630ccb44d9e58bbc5754538c3f2 | 19:03 |
| sveinse | still waiting for my rm -rf tmp... | 19:03 |
| davis | the top one was where i tried http | 19:04 |
| davis | i should have renamed it | 19:04 |
| davis | its renamed now to http_attempt | 19:04 |
| khem | davis: you have a multiline string which is commented out, usually that has some issues with bitbake, add a new empty commented line at the end for it to notice end of commented mutliline | 19:06 |
| khem | line 10 | 19:06 |
| khem | add a # there | 19:07 |
| khem | and SRC_URI = "http://http://devsupport:8080 seems not ok | 19:07 |
| khem | SRC_URI = "http://devsupport:8080 | 19:07 |
| khem | might be ok | 19:08 |
| sveinse | Nope, 3 times of rm -rf tmp and rebuilding uim. No failures | 19:09 |
| khem | sveinse: so it might be rare then | 19:14 |
| khem | may be change parallelism | 19:14 |
| *** Tenhi_ <Tenhi_!~tenhi@static.177.80.201.138.clients.your-server.de> has joined #yocto | 19:14 | |
| khem | kergoth: I added DATE and TIME to BB_HASHBASE_WHITELIST in bitbake.conf, did not help either | 19:15 |
| sveinse | I need more time on this, but let me observe failing a few more times, and then I can test with PARALLEL_MAKEINST="" to see if it goes away | 19:15 |
| sveinse | Can I configure (in local.conf) that a recipe shall never be read from sstate cache? | 19:16 |
| *** sno <sno!~sno@b2b-78-94-80-58.unitymedia.biz> has joined #yocto | 19:18 | |
| sveinse | For CI build server, do you change the bitbake UI, or just leave it at knotty? | 19:19 |
| *** Tenhi_ <Tenhi_!~tenhi@static.177.80.201.138.clients.your-server.de> has quit IRC | 19:19 | |
| *** paulg <paulg!~paulg@198-84-239-75.cpe.teksavvy.com> has quit IRC | 19:19 | |
| *** slidercrank <slidercrank!~slidercra@unaffiliated/slidercrank> has joined #yocto | 19:21 | |
| khem | sveinse: yes but thats discouraged but you can add something like do_compile[nostamp] = "1" to the recipe | 19:27 |
| khem | as a gross hack | 19:27 |
| fischerm | khem: thx | 19:31 |
| fischerm | worked | 19:31 |
| RP | khem: its not a regression, we just added better debugging of when there are problems | 19:38 |
| *** igor3 <igor3!~igor@189.112.127.225> has quit IRC | 19:56 | |
| *** yann <yann!~yann@nan92-1-81-57-214-146.fbx.proxad.net> has joined #yocto | 19:58 | |
| *** obsrwr_ <obsrwr_!~otp-amois@188.24.204.43> has quit IRC | 20:09 | |
| *** igor3 <igor3!~igor@177.159.144.73> has joined #yocto | 20:10 | |
| *** rcw <rcw!~rwoolley@128.224.252.2> has quit IRC | 20:10 | |
| *** berton <berton!~fabio@177.127.4.56> has quit IRC | 20:28 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 20:35 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 20:36 | |
| *** pohly <pohly!~pohly@dyndsl-031-150-142-006.ewe-ip-backbone.de> has quit IRC | 20:37 | |
| khem | RP: OK, so its catching more errors I guess, which is fine, however, I have no way to shut this | 20:37 |
| khem | RP: none of vardepexclude work | 20:37 |
| *** Crofton <Crofton!~Crofton@217.155.202.22> has joined #yocto | 20:38 | |
| khem | RP: from an ignorant user's pov its a regression | 20:39 |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC | 20:39 | |
| *** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-jexcjzmxzffyflwf> has joined #yocto | 20:40 | |
| *** jbrianceau_away is now known as jbrianceau_home | 20:40 | |
| *** MWelchUK <MWelchUK!~martyn@host81-147-3-127.range81-147.btcentralplus.com> has joined #yocto | 20:43 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC | 20:45 | |
| *** Crofton <Crofton!~Crofton@217.155.202.22> has quit IRC | 20:46 | |
| *** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 20:47 | |
| *** caiortp <caiortp!~inatel@131.221.240.204> has quit IRC | 21:02 | |
| RP | khem: vardepexclude should work | 21:03 |
| khem | RP: I tried to add tweak_image_name[vardepsexclude] += "DATE TIME" | 21:04 |
| khem | has no effect | 21:04 |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC | 21:05 | |
| *** arkver <arkver!~arkver@host81-135-58-159.range81-135.btcentralplus.com> has quit IRC | 21:20 | |
| *** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC | 21:22 | |
| khem | RP: there seems to no way to disable this error thats my gripe | 21:24 |
| *** josep <josep!~josep@c-cbe670d5.010-118-73746f7.cust.bredbandsbolaget.se> has joined #yocto | 21:32 | |
| *** sveinse <sveinse!~chatzilla@156.92-221-160.customer.lyse.net> has quit IRC | 21:33 | |
| *** hbruce <hbruce!~hbruce@134.134.139.74> has joined #yocto | 21:33 | |
| *** hbruce <hbruce!~hbruce@134.134.139.74> has left #yocto | 21:34 | |
| *** caiortp <caiortp!~caiortp@138.94.55.199> has joined #yocto | 21:37 | |
| *** caiortp <caiortp!~caiortp@138.94.55.199> has quit IRC | 21:46 | |
| *** jbrianceau_home is now known as jbrianceau_away | 21:55 | |
| *** caiortp <caiortp!~caiortp@131.221.243.1> has joined #yocto | 22:00 | |
| *** fmeerkoetter <fmeerkoetter!~quassel@service.basyskom.com> has quit IRC | 22:01 | |
| *** bfederau <bfederau!~quassel@service.basyskom.com> has quit IRC | 22:01 | |
| *** fmeerkoetter <fmeerkoetter!~quassel@service.basyskom.com> has joined #yocto | 22:01 | |
| *** bfederau <bfederau!~quassel@service.basyskom.com> has joined #yocto | 22:01 | |
| *** dmoseley <dmoseley!~dmoseley@6532158hfc157.tampabay.res.rr.com> has quit IRC | 22:05 | |
| RP | khem: well, the above should work, the question is why it doesn't | 22:11 |
| *** stephano <stephano!stephano@nat/intel/x-auffyyhiabmxszhk> has quit IRC | 22:12 | |
| *** aehs29 <aehs29!aehernan@nat/intel/x-tythmdyrzoxsafcu> has left #yocto | 22:16 | |
| *** boucman_work <boucman_work!~boucman@2a02-8428-034f-f800-9e32-0c7c-b391-6223.rev.sfr.net> has quit IRC | 22:16 | |
| *** josep <josep!~josep@c-cbe670d5.010-118-73746f7.cust.bredbandsbolaget.se> has quit IRC | 22:19 | |
| *** agust <agust!~agust@p4FCB4322.dip0.t-ipconnect.de> has quit IRC | 22:23 | |
| *** anselmolsm <anselmolsm!~anselmols@192.55.55.39> has quit IRC | 22:43 | |
| -YoctoAutoBuilder- build #216 of nightly-musl is complete: Failure [failed BuildImages] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-musl/builds/216 | 22:47 | |
| *** aehs29 <aehs29!aehernan@nat/intel/x-nakmqqozsshyefdu> has joined #yocto | 22:48 | |
| *** jynik <jynik!~bragg@cpe-67-253-219-41.rochester.res.rr.com> has quit IRC | 22:58 | |
| *** jynik <jynik!~bragg@cpe-67-253-219-41.rochester.res.rr.com> has joined #yocto | 23:00 | |
| *** lamego <lamego!~jose@134.134.139.82> has quit IRC | 23:01 | |
| *** benjamirc <benjamirc!~besquive@134.134.137.75> has quit IRC | 23:02 | |
| *** igor3 <igor3!~igor@177.159.144.73> has quit IRC | 23:03 | |
| *** istarilucky <istarilucky!~rlucca@177.159.144.73> has quit IRC | 23:06 | |
| *** aehs29 <aehs29!aehernan@nat/intel/x-nakmqqozsshyefdu> has left #yocto | 23:10 | |
| *** mborzecki <mborzecki!~Maciej_Bo@staticline-31-182-60-238.toya.net.pl> has quit IRC | 23:17 | |
| -YoctoAutoBuilder- build #620 of nightly-world-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-world-lsb/builds/620 | 23:25 | |
| *** jpeters <jpeters!c66941c5@gateway/web/freenode/ip.198.105.65.197> has joined #yocto | 23:30 | |
| *** mborzecki <mborzecki!~Maciej_Bo@staticline-31-182-60-238.toya.net.pl> has joined #yocto | 23:31 | |
| *** Biliogadafr <Biliogadafr!~pin@nat3-minsk-pool-46-53-182-183.telecom.by> has quit IRC | 23:31 | |
| jpeters | I am having trouble adding a recipe to Yocto. I have added a recipe to install the azure libraries. It creates 3 shared libraries. In the azure..rpm I see the libumqtt.so.1.1 libumqtt.so.1 libamqp.so.1.1 libamqp.so.1 libumock.so.1.1 libumock.so.1 files. In the the azure-dev...rpm file I set libmqtt.so libamqp.so and libumock.so along with header files etc. | 23:34 |
| jpeters | A second recipe to test the installation links correctly against the libraries but when do_rootfs runs I get the message "Computing transaction...error: Can't install azure-test-1.0-r0@armv5e: no package provides libumqtt.so". | 23:36 |
| jpeters | Any idea what I could be doing wrong? | 23:36 |
| *** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-jexcjzmxzffyflwf> has quit IRC | 23:59 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!
