| 00:04.03 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 01:49.08 | *** join/#oe paulg_ (~paulg@198-84-239-75.cpe.teksavvy.com) |
| 02:13.21 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 02:24.27 | *** join/#oe Crofton|work (~balister@pool-71-171-15-136.ronkva.east.verizon.net) |
| 03:06.37 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 03:17.41 | *** join/#oe coolmouse (~coolmouse@123.138.171.49) |
| 03:18.19 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 04:35.00 | *** join/#oe coolmouse_ (~coolmouse@123.138.171.49) |
| 06:17.00 | *** join/#oe AndersD (~anders@213-64-219-84-no126.business.telia.com) |
| 06:22.32 | *** join/#oe AndersD (~anders@213-64-219-84-no126.business.telia.com) |
| 06:39.59 | *** join/#oe GeorgeHahn (~GeorgeHah@c-69-141-92-254.hsd1.nj.comcast.net) |
| 06:50.37 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 07:05.21 | *** join/#oe Igel_ (~Igel@cjdns.io) |
| 07:14.39 | *** join/#oe deception_ (~deception@unaffiliated/deception) |
| 07:15.41 | *** join/#oe DJW|Badger (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net) |
| 07:15.51 | *** join/#oe georgem (~georgem@216-21-169-52.slc.googlefiber.net) |
| 07:16.05 | *** join/#oe mwester (~mwester@nslu2-linux/mwester) |
| 07:16.06 | *** join/#oe captainigloo (~captainig@ks389014.kimsufi.com) |
| 07:16.06 | *** join/#oe funman (~fun@rockbox/developer/funman) |
| 07:16.06 | *** join/#oe paulbarker (~quassel@newmail.betafive.co.uk) |
| 07:16.06 | *** join/#oe ChrisD1_Away (~ChrisD@merak.alcor.co.uk) |
| 07:17.04 | *** join/#oe morphis (~morphis@p5480DC98.dip0.t-ipconnect.de) |
| 07:17.54 | *** join/#oe deception (~deception@unaffiliated/deception) |
| 07:38.10 | *** join/#oe morphis (~morphis@p5480DC98.dip0.t-ipconnect.de) |
| 07:59.14 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-uuqjtyflvrcgpgpe) |
| 08:29.18 | *** join/#oe yann|work (~yann@LFbn-1-1026-146.w86-247.abo.wanadoo.fr) |
| 08:40.23 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 08:44.12 | *** join/#oe joshuagl (joshuagl@nat/intel/x-wpqlxerknyfssvki) |
| 08:53.44 | *** join/#oe edbart (~ebartosh@192.198.151.45) |
| 08:57.31 | *** join/#oe stefan_schmidt (~stefan@p4FF82E4D.dip0.t-ipconnect.de) |
| 08:58.26 | *** join/#oe stefan_schmidt (~stefan@p4FF82E4D.dip0.t-ipconnect.de) |
| 08:58.50 | *** join/#oe phdeswer (~phdeswer@91-159-55-220.elisa-laajakaista.fi) |
| 09:00.36 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 09:04.28 | *** join/#oe maxin (~maxin@2001:998:22:0:448e:c743:de24:2153) |
| 09:10.20 | *** join/#oe Net147 (~Net147@unaffiliated/net147) |
| 09:11.14 | *** join/#oe pespin (~pespin@5.149.142.22) |
| 09:20.38 | *** join/#oe Net147 (~Net147@unaffiliated/net147) |
| 09:24.20 | *** join/#oe AndersD (~anders@213-64-219-84-no126.business.telia.com) |
| 09:36.42 | *** join/#oe edbart (~ebartosh@192.198.151.45) |
| 09:39.42 | mago_ | if i "addtask" a function A after another task B in my recipe, does it automatically imply that A should always run whenever B runs, or does it only setup the dependency? i'd like to only run A when specified through "bitbake -c A myrecipe", but for some reason it runs as part of "bitbake myrecipe" |
| 09:45.55 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 09:47.08 | mago_ | (i had a look at bitbake -g, and yes, it does seem like A is a dependency to do_build. anyway I can prevent that?) |
| 09:47.30 | mago_ | i basically want something like populate_sdk, a task that I can run manually but isn't part of the normal do_build-thing |
| 09:48.32 | *** join/#oe rburton (~Adium@home.burtonini.com) |
| 09:49.48 | *** join/#oe jonathanmaw (~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk) |
| 09:54.56 | *** join/#oe JaMa (~martin@ip-86-49-34-37.net.upcbroadband.cz) |
| 09:57.53 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 10:04.04 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 10:07.17 | *** join/#oe belen (Adium@nat/intel/x-kxrxbnzhyuabfuok) |
| 10:10.30 | *** join/#oe joseppc (~Josep@sestofw01.enea.se) |
| 10:11.17 | *** join/#oe ant_work (~ant__@host213-59-dynamic.50-79-r.retail.telecomitalia.it) |
| 10:55.45 | *** join/#oe phdeswer_ (~phdeswer@auth.nomovok.info) |
| 11:06.07 | bluelightning | mago_: if you don't say "before do_build" (or indeed any other task) then it won't be part of the "normal" task flow |
| 11:13.40 | *** join/#oe ftonello (~felipe@82-71-26-47.dsl.in-addr.zen.co.uk) |
| 11:24.03 | *** join/#oe kristoffer (~kristoffe@ua-83-227-162-207.cust.bredbandsbolaget.se) |
| 11:36.03 | eengie | Anyone familiar with having multiple partitions for the generated filesystem image (beyond just boot, rootfs, and swap)? |
| 11:37.21 | *** join/#oe ldnunes (~ldnunes_@177.127.4.103) |
| 11:54.49 | *** join/#oe berton (~fabio@177.127.4.103) |
| 12:02.30 | eengie | I'm just looking for options. I've tried using wic by adding extra "part" directives to my wks file with different paths, but somehow the size always seems to go beyond the size of my SD card. |
| 12:03.28 | *** join/#oe ecloud (quassel@nat/digia/x-ljmlgwpqyncncfsu) |
| 12:12.40 | *** join/#oe caiortp (~inatel@131.221.240.204) |
| 12:20.58 | *** join/#oe Cubi1 (~sst@b2b-94-79-174-114.unitymedia.biz) |
| 12:24.37 | *** join/#oe ant_work (~ant__@host213-59-dynamic.50-79-r.retail.telecomitalia.it) |
| 12:38.34 | *** join/#oe LinuxMice (~LinuxMice@193.140.134.110) |
| 12:42.36 | *** join/#oe joshuagl (~joshuagl@192.198.151.44) |
| 12:48.58 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 13:06.34 | *** join/#oe blitz00 (stefans@unaffiliated/blitz00) |
| 13:26.27 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 13:39.24 | *** join/#oe vmeson (~rmacleod@128.224.252.2) |
| 13:44.08 | *** join/#oe kscherer (~kscherer@128.224.252.2) |
| 13:58.30 | *** join/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 14:44.19 | *** join/#oe rburton (~Adium@home.burtonini.com) |
| 15:12.20 | *** join/#oe CipherWizard (~cipherwiz@216-21-169-52.slc.googlefiber.net) |
| 15:25.31 | *** join/#oe ftonello (~felipe@82-71-26-47.dsl.in-addr.zen.co.uk) |
| 15:28.55 | *** join/#oe gabrbedd (~beddingfi@li680-65.members.linode.com) |
| 15:34.47 | *** join/#oe fischerm (~mfischer@207-114-172-147.static.twtelecom.net) |
| 15:40.26 | *** join/#oe mattsm (uid128834@gateway/web/irccloud.com/x-opktqddqwsnwgdkw) |
| 15:44.11 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 16:03.27 | kergoth | eengie: two things come to mind, one, the rootfs size is controlled by separate variables, and there's one to add 'extra' space to the rootfs, which would bloat it up if it's more than you need/want, and two, partition alignment could be a factor |
| 16:06.06 | eengie | kergoth: I ended up removing the --size option in my two rootfs parts only to realize that the rootfs plugin is going to grab everything at / and mount it at the path... not get everything at /path and mount it at /path which wasn't really intuitive to me. |
| 16:06.47 | eengie | By removing the size option, the partitions shrank to a minimal size and things fit, but I found that /whatever partition would end up being the root file system, again. |
| 16:06.48 | kergoth | ah, yes, i can see how that would be confusing. perhaps we need a 'source path' vs 'target path' to distinguish |
| 16:06.56 | kergoth | or just change the behavior altogether |
| 16:07.11 | kergoth | we do need to make it easy to break up the rootfs into multiple partitions by path, if that doesn't work, that's a problem |
| 16:07.16 | eengie | The format of the file made me immediately think of an fstab entry. |
| 16:07.27 | eengie | So I had that experience working against me I think... |
| 16:07.45 | kergoth | i think that's fair, i expect that will be the case for a lot of folks |
| 16:08.05 | eengie | Right, I don't think that works. From what I've read on forums, people want that feature and have proposed various patches, but I don't have access to any of that on daisy. |
| 16:08.12 | kergoth | i could see an argument for changing te default behavior, then adding a new argument to force the source path to be separate from the dest path |
| 16:08.15 | kergoth | i.e. --source-path / |
| 16:08.24 | kergoth | ah |
| 16:08.32 | *** join/#oe evanmeagher (~evanmeagh@73.71.33.109) |
| 16:08.36 | eengie | Right, that was one suggestion. Another was having it sourced from bitbake variables, which makes more sense. |
| 16:08.45 | kergoth | i'm not a wic expert by any means, just use it from time to time, haven't had time to try out the partitioning to break up the rootfs yet |
| 16:08.49 | eengie | My route was to have a script that copied my WKS and used sed to inject path names for partitions. |
| 16:08.59 | kergoth | i want to play with it to experiment with read-only-rootfs handling without using volatile storage |
| 16:10.25 | Crofton|work | the wic guys tend not to hang out here :( |
| 16:10.36 | kergoth | that's unfortunate |
| 16:12.13 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 16:15.32 | Crofton|work | or we need to get more people using it :) |
| 16:17.14 | kergoth | at mentor we're using it (wic via the image type) for all our supported bsps now, with success, though we're hitting a hiccup now since live/bootdisk setups run after do_image in a separate task, they don't integrate well, have to run wic manually for that one for now, or add another task |
| 16:20.35 | LinuxMice | hi everyone, i installed mariadb but i cannot acces remotely, How can i fix this |
| 16:31.22 | *** join/#oe edbart (~ebartosh@192.198.151.43) |
| 16:32.18 | eengie | LinuxMice: I'm not all that familiar with mariadb, but I know that for MySQL I had to establish external users in the database and give them access to the table(s) of interest. |
| 16:50.55 | *** part/#oe maxin (~maxin@2001:998:22:0:448e:c743:de24:2153) |
| 16:56.11 | eengie | kergoth: Is there a way to determine the family of processor being built by a given machine spec? (armv7l vs. x86, etc.)? |
| 16:57.52 | kergoth | look at DEFAULTTUNE, TUNE_FEATURES, and TARGET_ARCH in bitbake -e |
| 17:02.07 | eengie | thanks |
| 17:07.23 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 17:08.13 | *** join/#oe moto-timo (ttorling@fsf/member/moto-timo) |
| 17:09.07 | *** join/#oe evanmeagher (~evanmeagh@50.1.57.30) |
| 17:10.54 | *** join/#oe lerela (~lerela___@50-200-149-212-static.hfc.comcastbusiness.net) |
| 17:37.15 | *** join/#oe GeorgeHahn (~GeorgeHah@c-69-141-92-254.hsd1.nj.comcast.net) |
| 18:01.32 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 18:02.30 | eengie | Does anyone use FILESEXTRAPATHS_prepend to merge patch directories? |
| 18:03.27 | kergoth | "merge patch directories"? |
| 18:04.42 | eengie | I have 5 recipes that all have the same patch, but then each has their own individual patches too |
| 18:05.12 | kergoth | filespath could certainly be used to deal with that, yes |
| 18:06.17 | eengie | So that was a generic example; with another recipe it uses one of the common files but implements its own version of the other. |
| 18:06.45 | eengie | When the prepend or append happens, it seems to ignore the one in the recipe's files folder. |
| 18:07.35 | eengie | I would have thought that the combination of FILESEXETRAPATHS would have basically created a union of the two folders. |
| 18:08.11 | eengie | with the last one defined taking precedence... |
| 18:09.28 | kergoth | prepend/append is cumulative, and doesnt'r emove anything |
| 18:10.16 | eengie | I guess I was expecting a "cp -rf" kind of behavior where if the file exists, the next attempt to copy that file replaces the previously copied one. |
| 18:10.18 | eengie | and so on |
| 18:14.32 | *** join/#oe wto (~wto@h-140-99.a336.priv.bahnhof.se) |
| 18:15.44 | kergoth | it's like PATH. the first file found is used |
| 18:16.17 | kergoth | when a relative file:// file is specified in SRC_URI, FILESPATH is searched like PATH to find it |
| 18:16.19 | eengie | I see... but probably the reason why append didn't work is because I was using :=. |
| 18:16.23 | kergoth | FILESEXTRAPATHS is just injected into FILESPATH |
| 18:17.35 | kergoth | := will force immediate expansion, which can be good or bad depending on what you're doing. if you're using FILE_DIRNAME or THISDIR in a bbappend, you have to use := to make sure it's relative to the append (file currently being parsed) rather than when it's expanded at the end, at which point it'd be the path to the recipe, not the append |
| 18:17.45 | kergoth | if you're using it in a recipe, there's no need for the immediate expansion |
| 18:24.50 | eengie | Thanks for the explanation. My situation was from a recipe, but perhaps this has to do with where FILESEXTRAPATHS gets injected into FILESPATH, because if it's always before the local /files folder, then that explains why _append didn't affect the ordering of which file was ultimately applied. |
| 18:26.21 | kergoth | it sounds like you might want to append directly to filespath rather than filesextrapath |
| 18:26.30 | kergoth | but just use bitbake -e yourrecipe to examine the values of FILESPATH and FILESEXTRAPATHS |
| 18:26.41 | kergoth | bitbake -e is always the best way to make sure things are set the way you think they are |
| 18:26.54 | eengie | Good point... Should have gone there first. |
| 18:27.12 | eengie | Nice that it's granular enough to inspect a specific recipe (I've been using it for the whole image) |
| 18:27.36 | kergoth | no, you've been using it to examine configuration metadata, which is global |
| 18:27.40 | kergoth | the image is just another recipe :) |
| 18:36.02 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 18:48.05 | *** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net) |
| 18:55.38 | *** join/#oe phdeswer (~phdeswer@91-159-55-220.elisa-laajakaista.fi) |
| 19:17.46 | *** join/#oe edbart (~ebartosh@192.198.151.43) |
| 19:21.22 | *** join/#oe evanmeagher (~evanmeagh@50.1.57.30) |
| 19:25.56 | *** join/#oe edbart (~ebartosh@192.198.151.43) |
| 19:32.49 | *** join/#oe morphis (~morphis@p5480DC98.dip0.t-ipconnect.de) |
| 19:36.43 | *** join/#oe evanmeagher (~evanmeagh@50.1.57.30) |
| 19:44.31 | *** join/#oe bluelightning (~paul@2406:e007:5383:1:2ad2:44ff:fe40:9209) |
| 19:44.31 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 19:55.56 | *** join/#oe t0mmy_ (~tprrt@ram31-2-82-228-88-46.fbx.proxad.net) |
| 20:02.12 | *** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net) |
| 20:26.09 | *** join/#oe phdeswer (~phdeswer@91-159-55-220.elisa-laajakaista.fi) |
| 20:35.52 | *** join/#oe Crofton (~balister@12.31.71.58) |
| 20:42.49 | *** join/#oe evanmeag_ (~evanmeagh@50.1.57.30) |
| 20:57.02 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-mtixxbfvkezorwha) |
| 21:46.41 | *** join/#oe evanmeagher (~MongooseW@50.1.57.30) |
| 22:01.06 | *** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net) |
| 23:08.04 | fischerm | http://pastebin.com/vBrXi92t did anyone see this already when dealing with extensible sdks? |
| 23:12.34 | *** join/#oe GeorgeHahn (~GeorgeHah@c-69-141-92-254.hsd1.nj.comcast.net) |