| *** smartin_ <smartin_!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has quit IRC | 00:03 | |
| *** maxtothemax <maxtothemax!~maxtothem@134.134.139.74> has quit IRC | 00:04 | |
| *** sjolley <sjolley!sjolley@nat/intel/x-wknvrlujwhvnrtrt> has quit IRC | 00:05 | |
| *** pidge <pidge!pidge@nat/intel/x-stayggovgbwzmita> has quit IRC | 00:05 | |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC | 00:13 | |
| *** maxtothemax <maxtothemax!~maxtothem@134.134.139.74> has joined #yocto | 00:14 | |
| WarheadsSE | nerdboy: in hilarity, sure enough, same build root, right after that failure, turn around a build a more featured image? Wham, works. *facepalm* Go back to "problematic" one? Boom. Fail. *facedesk* | 00:15 |
|---|---|---|
| kergoth | better than it succeeding when you went back to the problematic one | 00:17 |
| *** fgretief <fgretief!~chatzilla@196-210-119-217.dynamic.isadsl.co.za> has quit IRC | 00:19 | |
| * nerdboy looks for a pillow... | 00:19 | |
| *** EddyLaiTW <EddyLaiTW!~eddylai@61-231-110-191.dynamic.hinet.net> has quit IRC | 00:23 | |
| *** sjolley <sjolley!sjolley@nat/intel/x-jpteksttpppgrjit> has joined #yocto | 00:47 | |
| *** Nitin <Nitin!nakamble@nat/intel/x-yfqvgclisydjvxww> has joined #yocto | 00:53 | |
| *** Nitin <Nitin!nakamble@nat/intel/x-yfqvgclisydjvxww> has quit IRC | 00:58 | |
| *** fgretief <fgretief!~chatzilla@196-210-119-217.dynamic.isadsl.co.za> has joined #yocto | 01:01 | |
| *** sunzun <sunzun!43357602@gateway/web/freenode/ip.67.53.118.2> has joined #yocto | 01:09 | |
| *** Squix <Squix!~Squix__@p052.net059084091.tokai.or.jp> has joined #yocto | 01:18 | |
| *** flihp <flihp!~flihp@c-76-24-20-220.hsd1.ma.comcast.net> has joined #yocto | 01:20 | |
| *** Squix <Squix!~Squix__@p052.net059084091.tokai.or.jp> has quit IRC | 01:45 | |
| *** fgretief <fgretief!~chatzilla@196-210-119-217.dynamic.isadsl.co.za> has quit IRC | 01:47 | |
| *** fray <fray!U2FsdGVkX1@gate.crashing.org> has quit IRC | 02:00 | |
| *** fray <fray!U2FsdGVkX1@gate.crashing.org> has joined #yocto | 02:01 | |
| *** rcw <rcw!~rwoolley@76-10-165-112.dsl.teksavvy.com> has joined #yocto | 02:06 | |
| *** rcw <rcw!~rwoolley@76-10-165-112.dsl.teksavvy.com> has quit IRC | 02:21 | |
| *** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:40c:29da:5f39:896d:200:7ed0> has joined #yocto | 02:42 | |
| *** LCyrin <LCyrin!~LCyrin@2607:fb90:270a:b754:14c4:900c:cfab:e402> has quit IRC | 02:44 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 02:45 | |
| *** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:40c:29da:5f39:896d:200:7ed0> has quit IRC | 02:55 | |
| *** LCyrin <LCyrin!~LCyrin@2607:fb90:2709:33d9:c94a:ba28:c411:c836> has joined #yocto | 02:56 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 02:58 | |
| *** hsychla_ <hsychla_!~hsychla@pd95c9392.dip0.t-ipconnect.de> has quit IRC | 03:04 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 03:09 | |
| *** armpit <armpit!~akuster@2601:c:9380:601:f465:994a:7e40:209f> has quit IRC | 03:17 | |
| *** armpit <armpit!~akuster@2601:c:9380:601:f465:994a:7e40:209f> has joined #yocto | 03:18 | |
| *** slips <slips!~quassel@mail.tomra.no> has quit IRC | 03:34 | |
| *** fitzsim` <fitzsim`!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has joined #yocto | 03:48 | |
| *** alphago`` <alphago``!~user@chippewa-nat.cray.com> has joined #yocto | 03:48 | |
| *** phragment_ <phragment_!~blubb@vpn.htu.tu-graz.ac.at> has joined #yocto | 03:49 | |
| *** awafaa_ <awafaa_!sid716@gateway/web/irccloud.com/x-kgcnwmjasfindvvm> has joined #yocto | 03:49 | |
| *** tobiash_ <tobiash_!~quassel@mail.bmw-carit.de> has joined #yocto | 03:49 | |
| *** evanp_ <evanp_!evan@nat/intel/x-zuxnwkeenqwwlvde> has joined #yocto | 03:49 | |
| *** ndec_ <ndec_!~ndec@linaro/ndec> has joined #yocto | 03:49 | |
| *** diego_ <diego_!~diego@host65-246-static.10-188-b.business.telecomitalia.it> has joined #yocto | 03:50 | |
| *** diego_r <diego_r!~diego@host65-246-static.10-188-b.business.telecomitalia.it> has quit IRC | 03:50 | |
| *** diego_ is now known as diego_r | 03:50 | |
| *** zbr <zbr!zibri@rfc1459.se> has joined #yocto | 03:51 | |
| *** tf_ <tf_!~tomas@r-finger.com> has joined #yocto | 03:51 | |
| *** Daemon405 <Daemon405!~who_knows@cpc21-newt31-2-0-cust123.newt.cable.virginm.net> has joined #yocto | 03:52 | |
| *** abelloni_ <abelloni_!~abelloni@128-79-216-6.hfc.dyn.abo.bbox.fr> has joined #yocto | 03:52 | |
| *** ionte_ <ionte_!~jonatan@c-3345e055.164-1-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 03:52 | |
| *** mckoan_ <mckoan_!~marco@unaffiliated/mckoan> has joined #yocto | 03:52 | |
| *** Anarky <Anarky!~Anarky@136.217.123.78.rev.sfr.net> has quit IRC | 03:52 | |
| *** madisox <madisox!~madisox@nat/cisco/x-xrcwfrlypytivhfr> has quit IRC | 03:52 | |
| *** halfhalo <halfhalo!halfhalo@nasadmin/webteam/halfhalo> has quit IRC | 03:52 | |
| *** zibri <zibri!zibri@rfc1459.se> has quit IRC | 03:52 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has quit IRC | 03:52 | |
| *** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC | 03:52 | |
| *** awafaa <awafaa!sid716@gateway/web/irccloud.com/x-fkodamfcxykxqpue> has quit IRC | 03:52 | |
| *** tf <tf!~tomas@r-finger.com> has quit IRC | 03:52 | |
| *** joeythesaint <joeythesaint!~joe@209.141.56.162> has quit IRC | 03:52 | |
| *** fitzsim <fitzsim!~user@2001:420:284a:1300:21c:c4ff:fe73:2d74> has quit IRC | 03:52 | |
| *** tobiash <tobiash!~quassel@mail.bmw-carit.de> has quit IRC | 03:52 | |
| *** mckoan|away <mckoan|away!~marco@unaffiliated/mckoan> has quit IRC | 03:52 | |
| *** ionte <ionte!~jonatan@c-3345e055.164-1-64736c10.cust.bredbandsbolaget.se> has quit IRC | 03:52 | |
| *** abelloni <abelloni!~abelloni@128-79-216-6.hfc.dyn.abo.bbox.fr> has quit IRC | 03:52 | |
| *** alphago` <alphago`!~user@chippewa-nat.cray.com> has quit IRC | 03:52 | |
| *** phragment <phragment!~blubb@vpn.htu.tu-graz.ac.at> has quit IRC | 03:52 | |
| *** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has quit IRC | 03:52 | |
| *** ftonello <ftonello!~felipe@wsip-70-183-20-162.oc.oc.cox.net> has quit IRC | 03:52 | |
| *** ndec <ndec!~ndec@linaro/ndec> has quit IRC | 03:52 | |
| *** evanp <evanp!evan@nat/intel/x-gkzyswoiocfitzro> has quit IRC | 03:52 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@yocto-www.yoctoproject.org> has joined #yocto | 03:52 | |
| *** madisox <madisox!~madisox@nat/cisco/x-cjdlyxoikogpjqrh> has joined #yocto | 03:52 | |
| *** Anarky <Anarky!~Anarky@136.217.123.78.rev.sfr.net> has joined #yocto | 03:53 | |
| *** awafaa_ is now known as awafaa | 03:53 | |
| *** halfhalo <halfhalo!halfhalo@nasadmin/webteam/halfhalo> has joined #yocto | 03:54 | |
| *** joeythesaint <joeythesaint!~joe@209.141.56.162> has joined #yocto | 03:54 | |
| *** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has joined #yocto | 03:56 | |
| *** hsychla <hsychla!~hsychla@pd95c9392.dip0.t-ipconnect.de> has joined #yocto | 04:05 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 04:08 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 04:18 | |
| *** Nitin <Nitin!nakamble@nat/intel/x-fkvrnvuhvbptlqhj> has joined #yocto | 04:30 | |
| *** Nitin <Nitin!nakamble@nat/intel/x-fkvrnvuhvbptlqhj> has quit IRC | 04:35 | |
| *** [Sno] <[Sno]!~Sno]@p578b540c.dip0.t-ipconnect.de> has quit IRC | 04:37 | |
| *** ka6sox is now known as ka6sox-away | 04:54 | |
| *** ka6sox-away is now known as ka6sox | 04:59 | |
| *** phantomD <phantomD!destroy@a89-154-119-158.cpe.netcabo.pt> has quit IRC | 05:04 | |
| *** phantom <phantom!destroy@a89-154-119-158.cpe.netcabo.pt> has joined #yocto | 05:04 | |
| *** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:40c:7208:5689:dabd:bc93:b8e7> has joined #yocto | 05:08 | |
| *** LCyrin <LCyrin!~LCyrin@2607:fb90:2709:33d9:c94a:ba28:c411:c836> has quit IRC | 05:11 | |
| *** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has joined #yocto | 05:14 | |
| *** phantom is now known as phantoxeD | 05:26 | |
| *** stiandre <stiandre!~stiandre@109.247.13.242> has joined #yocto | 05:30 | |
| *** agust <agust!~agust@pD9E2F8F1.dip0.t-ipconnect.de> has joined #yocto | 05:30 | |
| *** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has quit IRC | 05:33 | |
| *** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has joined #yocto | 05:35 | |
| khem | sgw_: what is /usr/bin/perl version ? | 05:40 |
| *** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC | 05:46 | |
| *** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has quit IRC | 05:56 | |
| *** florin_ <florin_!~florin@89.121.200.106> has joined #yocto | 06:01 | |
| *** florin_ <florin_!~florin@89.121.200.106> has left #yocto | 06:01 | |
| *** [Sno] <[Sno]!~Sno]@pd956d8ef.dip0.t-ipconnect.de> has joined #yocto | 06:02 | |
| *** gebreselaisi <gebreselaisi!~florin@89.121.200.106> has joined #yocto | 06:03 | |
| gebreselaisi | hi everybody | 06:03 |
| gebreselaisi | does anyone have an idea on how to enable the build of the qttestbrowser using the qtwebkit recipe in meta-qt? | 06:04 |
| gebreselaisi | seems to me the build is a production build which skips compilation of qttestbrowser | 06:04 |
| *** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has quit IRC | 06:05 | |
| gebreselaisi | Tools/qmake/mkspecs/features/configure.prf already has build_testbrowser and build_qttestsupport in WEBKIT_TOOLS_CONFIG variable but that does not help | 06:05 |
| *** gebreselaisi <gebreselaisi!~florin@89.121.200.106> has quit IRC | 06:08 | |
| *** LCyrin <LCyrin!~LCyrin@2607:fb90:270e:fa2d:dc75:4e94:488f:3224> has joined #yocto | 06:08 | |
| *** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has joined #yocto | 06:09 | |
| *** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has joined #yocto | 06:10 | |
| *** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:40c:7208:5689:dabd:bc93:b8e7> has quit IRC | 06:12 | |
| *** roric <roric!~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se> has quit IRC | 06:15 | |
| *** fray <fray!U2FsdGVkX1@gate.crashing.org> has quit IRC | 06:20 | |
| *** fray <fray!U2FsdGVkX1@gate.crashing.org> has joined #yocto | 06:22 | |
| *** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has quit IRC | 06:31 | |
| *** TobSnyder <TobSnyder!~schneider@ip92343918.dynamic.kabel-deutschland.de> has joined #yocto | 06:36 | |
| *** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has joined #yocto | 06:37 | |
| *** TobSnyder <TobSnyder!~schneider@ip92343918.dynamic.kabel-deutschland.de> has quit IRC | 06:39 | |
| *** kroon <kroon!~kroon@fw.mikrodidakt.se> has joined #yocto | 06:39 | |
| *** ddom <ddom!~ddom@ip-37-201-80-63.hsi13.unitymediagroup.de> has quit IRC | 06:40 | |
| *** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has quit IRC | 06:49 | |
| *** soderstrom <soderstrom!~soderstro@81.216.59.226> has joined #yocto | 06:50 | |
| *** ivanstojanovic <ivanstojanovic!~evo@vpn.anton-paar.com> has quit IRC | 06:52 | |
| *** TobSnyder <TobSnyder!~schneider@ip92343918.dynamic.kabel-deutschland.de> has joined #yocto | 06:53 | |
| *** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has joined #yocto | 06:53 | |
| *** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has quit IRC | 07:02 | |
| *** silviof <silviof!~silviof@unaffiliated/silviof> has joined #yocto | 07:04 | |
| *** TobSnyder <TobSnyder!~schneider@ip92343918.dynamic.kabel-deutschland.de> has quit IRC | 07:07 | |
| *** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has joined #yocto | 07:07 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 07:11 | |
| *** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-nbzrpmhmxxmgeeym> has joined #yocto | 07:12 | |
| *** jbrianceau_away is now known as jbrianceau | 07:13 | |
| *** roric <roric!~roric@83.140.117.51> has joined #yocto | 07:16 | |
| *** EddyLaiTW <EddyLaiTW!~eddylai@61-231-110-191.dynamic.hinet.net> has joined #yocto | 07:18 | |
| *** elinuxer <elinuxer!~elinux1@122.165.223.135> has joined #yocto | 07:21 | |
| *** roric <roric!~roric@83.140.117.51> has quit IRC | 07:22 | |
| *** ant_work <ant_work!~ant__@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto | 07:24 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 07:25 | |
| elinuxer | hai yocto, After boot the kernel its hang up over "at91sam9x5ek login:" i couldn't login or enter the user name . How can i resolve this? | 07:25 |
| *** TobSnyder <TobSnyder!~schneider@ip92343918.dynamic.kabel-deutschland.de> has joined #yocto | 07:27 | |
| *** zerus <zerus!~epetmab@81-229-90-163-no67.tbcn.telia.com> has joined #yocto | 07:31 | |
| *** TobSnyder <TobSnyder!~schneider@ip92343918.dynamic.kabel-deutschland.de> has quit IRC | 07:31 | |
| *** TobSnyder <TobSnyder!~schneider@ip92343918.dynamic.kabel-deutschland.de> has joined #yocto | 07:36 | |
| *** ddom <ddom!~ddom@p4FFAB15F.dip0.t-ipconnect.de> has joined #yocto | 07:37 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 07:39 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto | 07:47 | |
| *** belen <belen!~Adium@190.227.187.81.in-addr.arpa> has joined #yocto | 07:50 | |
| *** roric <roric!~roric@83.140.117.51> has joined #yocto | 07:50 | |
| *** roric <roric!~roric@83.140.117.51> has quit IRC | 07:59 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 08:00 | |
| lpapp | good morning | 08:00 |
| EddyLaiTW | good afternoon | 08:00 |
| *** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has quit IRC | 08:00 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC | 08:04 | |
| *** ecdhe <ecdhe!~ecdhe@173-22-126-166.client.mchsi.com> has joined #yocto | 08:06 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto | 08:16 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 08:16 | |
| *** tasslehoff <tasslehoff!~Tasslehof@77.40.182.98> has joined #yocto | 08:19 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 08:22 | |
| *** LocutusOfBorg1 <LocutusOfBorg1!~Gianfranc@host246-168-dynamic.14-87-r.retail.telecomitalia.it> has quit IRC | 08:25 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC | 08:29 | |
| *** sameo <sameo!~samuel@192.55.54.40> has joined #yocto | 08:32 | |
| *** LocutusOfBorg1 <LocutusOfBorg1!~Gianfranc@host246-168-dynamic.14-87-r.retail.telecomitalia.it> has joined #yocto | 08:33 | |
| *** ddom_ <ddom_!~ddom@p4FFDAE12.dip0.t-ipconnect.de> has joined #yocto | 08:39 | |
| *** lyang0 <lyang0!~lyang001@1.202.252.122> has quit IRC | 08:43 | |
| *** ddom <ddom!~ddom@p4FFAB15F.dip0.t-ipconnect.de> has quit IRC | 08:43 | |
| *** lyang0 <lyang0!~lyang001@1.202.252.122> has joined #yocto | 08:43 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 08:48 | |
| *** roric <roric!~roric@83.140.117.51> has joined #yocto | 08:48 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 08:49 | |
| *** Ramos <Ramos!c058a901@gateway/web/freenode/ip.192.88.169.1> has joined #yocto | 08:55 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto | 08:55 | |
| Ramos | How qemu dtb file is compiled from Yocto source? | 08:55 |
| *** roric <roric!~roric@83.140.117.51> has quit IRC | 08:56 | |
| *** seezer <seezer!quassel335@quassel/developer/seezer> has quit IRC | 08:57 | |
| *** seezer <seezer!test@quassel/developer/seezer> has joined #yocto | 08:59 | |
| [Sno] | how can I change the deployed web-server from lighttpd to nginx (lighttpd comes with packagegroup-core-full-cmdline which is required by core-image-lsb) | 09:00 |
| lpapp | [Sno]: do you still need busybox ? | 09:00 |
| *** qt-x <qt-x!~ionel@217.10.196.2> has joined #yocto | 09:03 | |
| Ramos | How dtb file is compiled from qemu recipe file? | 09:06 |
| *** jimBaxter_uk <jimBaxter_uk!~jbaxter@jimbax.plus.com> has joined #yocto | 09:09 | |
| *** stuartw_ <stuartw_!~stuartw@77.107.122.34> has joined #yocto | 09:09 | |
| [Sno] | lpapp: I'd like to keep it, yes | 09:09 |
| *** belen <belen!Adium@nat/intel/x-bywzgdsoroykvshh> has joined #yocto | 09:10 | |
| *** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC | 09:10 | |
| [Sno] | lpapp: the image is there: https://github.com/rehsack/meta-jens/tree/master/recipes-graphics/images | 09:13 |
| [Sno] | likely I can do it better ;) | 09:13 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 09:22 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 09:23 | |
| *** roric <roric!~roric@83.140.117.51> has joined #yocto | 09:44 | |
| *** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto | 09:48 | |
| *** Ramos <Ramos!c058a901@gateway/web/freenode/ip.192.88.169.1> has quit IRC | 09:52 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:54 | |
| *** zbr is now known as zibri | 10:07 | |
| *** elinuxer <elinuxer!~elinux1@122.165.223.135> has quit IRC | 10:08 | |
| *** blitz00 <blitz00!stefans@nat/intel/x-ofxaxzdzwkudnapk> has joined #yocto | 10:42 | |
| *** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto | 10:42 | |
| silviof | (cross from #oe) I have the problem that with a yocto/oe toolchain (created with meta-toolchain-sdk) I can not start the menuconfig for kernel configuration (after source .../environment-setup-...). I have found the problem and a solution (please read this short thread http://www.spinics.net/lists/linux-kbuild/msg09959.html). Can someone test this patch that "-c menuconfig" is still functional. | 10:52 |
| *** EddyLaiTW <EddyLaiTW!~eddylai@61-231-110-191.dynamic.hinet.net> has quit IRC | 10:55 | |
| *** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:2701:8459:586a:a4e3:1eea:7ee9> has joined #yocto | 11:00 | |
| *** LCyrin <LCyrin!~LCyrin@2607:fb90:270e:fa2d:dc75:4e94:488f:3224> has quit IRC | 11:03 | |
| *** zerus <zerus!~epetmab@81-229-90-163-no67.tbcn.telia.com> has quit IRC | 11:04 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC | 11:06 | |
| *** manuel___ <manuel___!~manuel_@p4FDAC1E3.dip0.t-ipconnect.de> has joined #yocto | 11:10 | |
| *** tmpsantos <tmpsantos!~tmpsantos@134.191.220.73> has joined #yocto | 11:15 | |
| *** zerus <zerus!~epetmab@81-229-90-163-no67.tbcn.telia.com> has joined #yocto | 11:40 | |
| [Sno] | lpapp: do you have a recommendation without busybox? | 11:54 |
| *** LCyrin <LCyrin!~LCyrin@2607:fb90:40a:9692:2564:bd63:f148:2645> has joined #yocto | 12:00 | |
| *** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:2701:8459:586a:a4e3:1eea:7ee9> has quit IRC | 12:04 | |
| lpapp | [Sno]: cannot you exclude it (_remove or something)? | 12:15 |
| lpapp | it seems that my foo-git package is not rebuilt even though the git repository got new commits. Shouldn't it automatically rebuild stuff after fetching the new commits? | 12:15 |
| lpapp | I have SRCREV = "${AUTOREV}" there. | 12:17 |
| *** roric <roric!~roric@83.140.117.51> has quit IRC | 12:17 | |
| JaMa | gdo you have SRCPV in PV? | 12:20 |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto | 12:27 | |
| lpapp | JaMa: nope | 12:27 |
| lpapp | JaMa: is that mandatory for getting the new commits automatically? | 12:33 |
| [Sno] | lpapp: we recognized that it updates automatically when you include the rev in SRC_URI="git://...;rev=deadbeef" | 12:42 |
| [Sno] | lpapp: how should such a _remove line look like? | 12:42 |
| *** roric <roric!~roric@83.140.117.51> has joined #yocto | 12:42 | |
| lpapp | [Sno]: but then you hard code the revision. | 12:43 |
| lpapp | [Sno]: I do not know the syntax, but it was added pro-dylan iirc based on _append, it is something like _exclude/remove or something. | 12:45 |
| lpapp | post-dylan* | 12:46 |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC | 12:46 | |
| JaMa | lpapp: afaik yes | 12:52 |
| *** tomz_ <tomz_!tomz@nat/intel/x-jwpgpypraovyayal> has quit IRC | 12:58 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto | 13:00 | |
| *** LocutusOfBorg1 <LocutusOfBorg1!~Gianfranc@host246-168-dynamic.14-87-r.retail.telecomitalia.it> has quit IRC | 13:02 | |
| blloyd | With Fedora 20, I am seeing a lot of screen pauses. (Typed all before this aside before seeing any on screen) They are frequent and annoying and I don't see any CPU spikes or any logging to explain them. Where else can I look for a culprit? | 13:11 |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC | 13:16 | |
| *** alimon <alimon!~alimon@189.154.7.33> has joined #yocto | 13:20 | |
| *** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC | 13:28 | |
| *** fitzsim` is now known as fitzsim | 13:32 | |
| *** oneQubit <oneQubit!~oneQubit@73.191.59.249> has joined #yocto | 13:51 | |
| *** sjolley <sjolley!sjolley@nat/intel/x-jpteksttpppgrjit> has quit IRC | 13:57 | |
| ndec_ | lpapp: yes, you need to have SRCPV in PV, otherwise PV doesn't change, so you recipe is not rebuilt | 14:00 |
| *** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:408:c30c:78ad:49da:d4b3:7187> has joined #yocto | 14:00 | |
| *** Nitin <Nitin!nakamble@nat/intel/x-rycntuvfcllcvxcv> has joined #yocto | 14:03 | |
| fray_ | ndec_ that's not -strictly- true.. the change of the SRCPV will trigger a rebuild, and with the PR service enable will cause the PR number to increment... however without the SRCPV, it's unclear to other developers it's a SCM based recipe.. | 14:03 |
| fray_ | this PV is modified to include SRCPV so the developers know it's an SCM based recipe, and the change of the SRCPV will make it to clear to the system and developers the version has changed (without making them manage anything themselves) | 14:04 |
| lpapp | JaMa: ndec_ ok, thanks, but I think there could be a sane default in Yocto, namely: PV = "${SRCPV}" when AUTOREV is specified. | 14:04 |
| ndec_ | hmm. PR.. that's something i don't use ;-) | 14:04 |
| *** kroon <kroon!~kroon@fw.mikrodidakt.se> has quit IRC | 14:04 | |
| *** LCyrin <LCyrin!~LCyrin@2607:fb90:40a:9692:2564:bd63:f148:2645> has quit IRC | 14:04 | |
| *** ant_work <ant_work!~ant__@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC | 14:04 | |
| fray_ | Ya, when you use an autorev scheme.. it may be required.. I'm not sure | 14:04 |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto | 14:05 | |
| fray_ | I do have some recipes that use SCM backends, but don't list SRCPV.. but that is because I'm pointing to specific commit that represents a release point | 14:05 |
| ndec_ | lpapp: well, not sure what a sane default would be.. PV is rarely just SRCPV | 14:05 |
| ndec_ | but something like 1.0+gitSRCPV | 14:05 |
| fray_ | correct.. it's usually "basever+scmSRCPV" | 14:05 |
| *** ndec_ is now known as ndec | 14:06 | |
| fray_ | and only the recipe developer knows hwat basever is.. | 14:06 |
| lpapp | ndec_: then you override, done. | 14:06 |
| lpapp | ndec: but for people like me, I would not need to do anything special. | 14:06 |
| JaMa | fray_: I think that without SRCPV in PV the do_fetch task doesn't have the AUTOREV value in signature -> isn't reexecuted when there is new change | 14:06 |
| ndec | PV=SRCPV would be quite bad for git where commits aren't in 'increasing' order. not sure it would be a good default | 14:06 |
| fray_ | the default PV comes from the recipe filename.. | 14:06 |
| fray_ | so you shouldn't globally set PV=SRCPV or you'll brake that assumption.. | 14:07 |
| fray_ | JaMa, ya the AUTOREV may be unique.. I haven't explored that enought to know the edge conditions | 14:07 |
| JaMa | ndec: SRCPV should be increasing, thanks to the prefix added by PR service | 14:07 |
| lpapp | ndec: it is a good default since it does not break your picky case, yet it will work for me who could not care less about a simple name. | 14:07 |
| JaMa | I'm sure it was behaving like this in dylan, I think it wasn't changed since then | 14:07 |
| lpapp | ndec: 1.0+gitSRCPV is a very bad idea for _me_ because the whole point is not to maintain the version... it will break at 1.1 and 2.0... | 14:09 |
| lpapp | or even 1.0.1 to be fair. | 14:09 |
| ndec | well, i was not proposing to make my suggestion a default.. | 14:09 |
| JaMa | lpapp: then you can set it to just SRCPV if you _want_, but it shouldn't be default | 14:09 |
| lpapp | JaMa: why not? | 14:10 |
| lpapp | what does it break? | 14:10 |
| JaMa | versioning between builders not sharing the same PR service for example | 14:10 |
| lpapp | cause clearly, it makes some people happy, so what breakage would it cause for others as a disadvantage? | 14:10 |
| fray_ | if it's broken for -you- it does not mean it's broken for everyone else.. | 14:10 |
| fray_ | changing build versions causes havoc for people trying to do on-target package upgrades.. even between a 1.6 to 1.7 release time.. | 14:11 |
| lpapp | that is irrelevant, we are talking about autorev. | 14:11 |
| fray_ | some of the decisions made in the past don't make sense anymore -- but we're stuck with them, and they cause little issue | 14:11 |
| lpapp | not all the case. | 14:11 |
| lpapp | not to mention I have never mentioned it is broken for everyone, so I must decline that assumption. | 14:11 |
| lpapp | JaMa: is this PR service some new thing? | 14:12 |
| fray_ | PR service was introduced in 1.3 or 1.4 | 14:13 |
| lpapp | 1.4 | 14:13 |
| lpapp | yeah, relatively new, OK, well, I was not aware of it. | 14:14 |
| lpapp | when I started reading the manuals, it was not there yet. | 14:14 |
| lpapp | I must read upon that before I can reply. | 14:14 |
| lpapp | when I was making the recipes, I was told just to remove the PR field, and everything will be alright. | 14:15 |
| fray_ | yes, the PR server is what automatically increments them | 14:16 |
| fray_ | uses the base PV, and PR numbers... as well as the checksum of parts of the recipe to determine if an existing PR number has been issued or if a new one is to be generated.. | 14:16 |
| fray_ | it generates them in increasing order to facilitiate on-target package upgrades | 14:16 |
| *** tasslehoff <tasslehoff!~Tasslehof@77.40.182.98> has quit IRC | 14:18 | |
| *** stiandre <stiandre!~stiandre@109.247.13.242> has quit IRC | 14:18 | |
| *** sjolley <sjolley!~sjolley@134.134.139.72> has joined #yocto | 14:19 | |
| *** [Sno] <[Sno]!~Sno]@pd956d8ef.dip0.t-ipconnect.de> has quit IRC | 14:21 | |
| lpapp | so what is wrong about having localhost always the PR service? | 14:21 |
| *** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto | 14:24 | |
| manuel___ | so i have an out-of-tree kernel module, and i can bitbake it just fine. however, for iterative development, i would like to just “make” it with the toolchain, what’s the best way to do that? | 14:28 |
| manuel___ | the kernel development manual mentions how to do it on the target, i want to do it on the host | 14:28 |
| fray_ | one way is setup a recipe.. then use bitbake -c devshell recipe | 14:31 |
| lpapp | (and why is localhost:0 not the default PR service?) | 14:33 |
| manuel___ | that will have the toolchain setup (trying out right now, taking a while) | 14:34 |
| JaMa | lpapp: because PR service is disabled by default | 14:35 |
| manuel___ | fray: that gives me an error about M= file not found, that doesn’t seem good (after running make) | 14:36 |
| fray_ | I'm not sure.. if you can find Zeddii, he'd be the one to ask | 14:37 |
| manuel___ | ah it’s missing KERNEL_SRC i guess | 14:37 |
| sgw_ | khem: good morning, noticed you ping'ed me late last night: Perl version: v5.16.3 | 14:39 |
| lpapp | JaMa: why is that? | 14:41 |
| fray_ | for people who are NOT doing on target package upgrades, the PR service is extra overhead | 14:41 |
| lpapp | it is only overhead for building. | 14:42 |
| lpapp | is it non-negligible? | 14:42 |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 14:43 | |
| JaMa | and for people who cares about on target upgrades, they usually want to use PR service provided by their distro -> so there cannot be good default | 14:43 |
| lpapp | I am not convinced about the constant "there is no default for the majority, so there should be none approach", but ok. | 14:44 |
| lpapp | I will put it into our local.conf sample, thanks. (localhost:0) | 14:45 |
| JaMa | there is reasonable default "disabled" | 14:45 |
| lpapp | well, we will agree to disagree whether that is reasonable :) | 14:45 |
| lpapp | IMHO, setting the default to localhost:0 is ok for many people, and the one who would like to have custom, they will need to provide their way either way. | 14:46 |
| lpapp | regardless of the default, but it would help the people who are happy with localhost. | 14:46 |
| lpapp | the current default does not help even those people. | 14:46 |
| JaMa | it won't help people who are happy without PR service | 14:47 |
| lpapp | disabling does not seem to help there either, so it is the same, no? | 14:47 |
| bluelightning | no | 14:48 |
| lpapp | it is a bit like if we cannot help 60% (I am not convinced that a correct measure for custom anyway), we do not help 30% either. | 14:49 |
| lpapp | anyway, for fact, this is a regression since it did use to work without enabling it explicitly. Now, we got all of this broken all of a sudden, apparently. | 14:51 |
| lpapp | this is regression* | 14:51 |
| JaMa | nothing is broken when PR service is disabled | 14:51 |
| JaMa | and it's probably more like 30% custom, 30% disabled, 30% localhost, 10% doesn't care | 14:52 |
| lpapp | ok, I think it would be better to clarify what "PR service disabled" means. What happens if I do not use PR in the recipe? Will it automatically incremented? | 14:52 |
| ndec | the main issue is that this reasoning can be applied to pretty much *any* configuration. oe/yocto is a toolset to help you build/make your own distro/builds. you cannot make defaults for every config that will satisfy everyone.. better let people do their own config.. | 14:52 |
| lpapp | be* | 14:52 |
| JaMa | no it wont be automatically increamented (and it wasn't before) so it's no regression | 14:53 |
| lpapp | I sure was told it was. | 14:53 |
| lpapp | one of my patches was even rejected for that nitpicky reason that it had the PR in. | 14:53 |
| lpapp | the suggestion was "Remove it because it will be incremented automatically". | 14:53 |
| lpapp | (I can look up the email if you want) | 14:54 |
| JaMa | for poeple you're using PR service | 14:54 |
| JaMa | no need to look it up.. I've wrote many replies like that myself | 14:54 |
| lpapp | so the suggestion was to break the recipe for people not using PR service? | 14:55 |
| lpapp | (i.e. when the PR service is disabled - default) | 14:55 |
| bluelightning | if you're not using the PR service, you aren't the kind of person who cares if PR is incremented | 14:56 |
| manuel___ | fray: does Zeddii hang around here? | 14:56 |
| lpapp | but what I am saying is the opposite: I would like to use it since it is error-prone to manually increment blabla, but I do not agree with the overhead of a custom service. I prefer KISS which means auto-increment by one here, not to force me to manually keep track of it by default. | 14:57 |
| manuel___ | i’ve figure my thing out, i wonder if there’s a way to have the toolchain set KERNEL_SRC, i can always add it to the environment source by hand | 14:57 |
| *** dv_ <dv_!~quassel@chello062178118086.5.14.vie.surfer.at> has joined #yocto | 14:59 | |
| *** dv__ <dv__!~quassel@chello062178118086.5.14.vie.surfer.at> has quit IRC | 14:59 | |
| *** LynnCyrin <LynnCyrin!~LCyrin@2607:fb90:408:c30c:78ad:49da:d4b3:7187> has quit IRC | 14:59 | |
| lpapp | so with the current system in place: I can only do this, right? echo 'PRSERV_HOST = "localhost:0"' >> ../meta-foo/conf/local.conf.sample? | 14:59 |
| lpapp | (based on my need above) | 14:59 |
| rburton | yes | 15:01 |
| rburton | personally i have that it my site.conf | 15:01 |
| JaMa | webos-ports and SHR have it in setup scripts (using remove PR service) | 15:01 |
| lpapp | rburton: thanks, fair enough, I will move it there. | 15:02 |
| ndec | rburton: you say this, as you have 1 'site.conf' for all workspace.. is that correct? if so, how do you globablly set your site.conf? | 15:03 |
| *** rcw <rcw!~rwoolley@128.224.252.2> has joined #yocto | 15:03 | |
| lpapp | so the PR service only steps in if there is no PR specified in the recipe? | 15:04 |
| lpapp | or it is always overriding that? | 15:04 |
| rburton | lpapp: if the recipe doesn't set a PR then the default is r0 | 15:05 |
| lpapp | and then r1, r2, etc? | 15:05 |
| lpapp | (with localhost:0, that is) | 15:05 |
| rburton | (see bitbake.conf) | 15:05 |
| rburton | the PR service adds a .x | 15:06 |
| rburton | so you get r0.1, r0.2 | 15:06 |
| lpapp | never reaches r1? | 15:06 |
| rburton | correct | 15:06 |
| lpapp | wow | 15:06 |
| rburton | this lets you use the PR service and explicit PRs at the same time | 15:06 |
| lpapp | well, it is just packaging version, isn't it? | 15:07 |
| lpapp | PV remains the same anyway, right? | 15:07 |
| lpapp | (if that is correct, I could not care less what PR is) | 15:07 |
| lpapp | (as long as it is not the same and somehow incremented) | 15:07 |
| rburton | the PR is embedded in the package name and versioning | 15:07 |
| lpapp | yes, but not in the software version itself. | 15:08 |
| rburton | right | 15:08 |
| lpapp | good, so yeah, thanks. | 15:08 |
| rburton | thats PV and isn't touched | 15:08 |
| rburton | eg i have sato-icon-theme_0.4.1-r6.1_all.ipk in my deploy/ipk | 15:08 |
| lpapp | so you have a custom PR service? | 15:08 |
| lpapp | or your localhost is customized? | 15:09 |
| rburton | not at all | 15:09 |
| rburton | as i said, i takes the PR and adds .x | 15:09 |
| lpapp | but r6.1 > r0.X | 15:09 |
| rburton | and sato-icon-theme has an explicit PR=r6 | 15:09 |
| lpapp | ah | 15:09 |
| lpapp | I see what you mean. | 15:09 |
| rburton | (that was a carefully chosen example) | 15:10 |
| lpapp | so what happens if you do not specify PR, 1,2,3,4? | 15:10 |
| lpapp | ah, no, r0 | 15:10 |
| lpapp | you said that above. | 15:10 |
| *** TobSnyder <TobSnyder!~schneider@ip92343918.dynamic.kabel-deutschland.de> has quit IRC | 15:20 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 15:26 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 15:28 | |
| *** dv__ <dv__!~quassel@chello062178118086.5.14.vie.surfer.at> has joined #yocto | 15:34 | |
| *** forcev <forcev!~quassel@w-28.cust-19171.ip.static.uno.uk.net> has joined #yocto | 15:36 | |
| *** stuartw_ <stuartw_!~stuartw@77.107.122.34> has quit IRC | 15:38 | |
| *** dv_ <dv_!~quassel@chello062178118086.5.14.vie.surfer.at> has quit IRC | 15:40 | |
| *** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC | 15:40 | |
| lpapp | is it a general practice that people use an ipkg folder in projects similarly to the good old "debian" for in-project packaging? | 15:42 |
| lpapp | that would spare us going to Yocto for every single local change. | 15:43 |
| lpapp | I could just say make ipkg and the package is generated that I can install on the rootfs. | 15:43 |
| lpapp | I have only done this many times with debian/ subfolder, but I wonder if some bitbake/ subfolder with the recipe and bitbake in there could also do it somehow? | 15:43 |
| lpapp | the alternative is to set up a local directory URL which cannot be committed to our Yocto repository for obvious reasons, etc. | 15:44 |
| lpapp | whereas a "bitbake/" directory could be easily committed to the project repository. | 15:44 |
| *** vagrant4ever <vagrant4ever!a6821a3a@gateway/web/freenode/ip.166.130.26.58> has joined #yocto | 15:46 | |
| rburton | if you wanted to drive opkg directly you'd need to write opkg-native packaging | 15:47 |
| lpapp | cannot we get yocto generate that for us and sync? | 15:47 |
| rburton | you could | 15:48 |
| rburton | package_ipk obviously generates it | 15:48 |
| *** jbrianceau is now known as jbrianceau_away | 15:48 | |
| vagrant4ever | I am new to the yocto project. I am trying to build an image for a beaglebone with bluez5 (for low power bluetooth). I have added this to my local.conf file but the build complains that bluez4 is still included. Anything I can try to fix this? | 15:49 |
| lpapp | rburton: ok, well, that sounds like a plan, based on my experience with debian/, it is probably not something that some other people will not follow. | 15:49 |
| lpapp | I mean, probably some people already are doing it. | 15:49 |
| rburton | lpapp: maybe, not aware of any myself | 15:49 |
| *** starship <starship!~duracrisi@unaffiliated/duracrisis> has joined #yocto | 15:49 | |
| lpapp | rburton: well, it makes sense for CI, too. | 15:50 |
| rburton | surely CI should be done in yocto | 15:50 |
| lpapp | for interim builds, I am not sure. | 15:50 |
| lpapp | for release builds, sure. | 15:50 |
| rburton | people i know that do tight hack-compile-install-test cycles tend to use the devshell or adt and copies binaries directly to the target, avoiding packages | 15:50 |
| *** kkh <kkh!~duracrisi@unaffiliated/duracrisis> has quit IRC | 15:50 | |
| lpapp | that is a very bad approach | 15:51 |
| lpapp | it disrespects security, let alone the error prone process when you have many files to put to many places. | 15:51 |
| *** ddom_ <ddom_!~ddom@p4FFDAE12.dip0.t-ipconnect.de> has quit IRC | 15:51 | |
| lpapp | but for some it might work for simple things. | 15:51 |
| lpapp | I would not allow my embedded system accept unsigned random files :) | 15:52 |
| sunzun | hey guys. I have a question about compiling opencv with yocto. when I do bitbake opencv, it gets hung up on trying to compile the eigen library, with the following error code. http://pastie.org/private/w9gr8cuenrvrkgrxeh3ejw I'm wondering if there is a known fix for this. Let me know if you need more info | 15:52 |
| lpapp | also, doing manually the packaging might be just reinventing the package, when you need more than just a binary in /usr/bin, e.g. man pages, configuration into /etc/, libraries, tools, etc. | 15:52 |
| rburton | lpapp: exactly | 15:53 |
| lpapp | sunzun: eigen is a header-only template, it is not compiled on its own | 15:53 |
| lpapp | you mean when it is compiled against opencv? | 15:53 |
| lpapp | rburton: exactly which part? | 15:53 |
| rburton | lpapp: reinventing all the packaging | 15:54 |
| rburton | sunzun: looks like the eigen recipe hasn't been tested for ages and is broken with the "recent' (several months ago) cmake changes | 15:54 |
| lpapp | rburton: yes, but isn't it simpler to sync the result of package_ipk to avoid the reinventing? | 15:54 |
| lpapp | sunzun: the error report seems to be clear to me. | 15:54 |
| *** sjolley <sjolley!~sjolley@134.134.139.72> has quit IRC | 15:55 | |
| lpapp | sunzun: in-source builds are bad, so you will need to figure out why it is doing it. | 15:55 |
| rburton | lpapp: its simpler to use bitbake to build the package in the first place surely. | 15:55 |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 15:55 | |
| lpapp | rburton: why? That requires Yocto knowledge for every developer, not just the system builder. | 15:56 |
| sunzun | lpapp: yeah, it says that you can't build in source, but I'm not quite sure where i would go to fix this. I've taken a look at the eigen recipe, and I'm not sure how to patch it to fix it, nor can I find a patch that's available | 15:56 |
| lpapp | like I said, eigen is a template-header, it is not built on its own | 15:56 |
| lpapp | (at least it was last time I checked in its core mission) | 15:56 |
| lpapp | you need to fix whatever is trying to use it, assuming opencv here. | 15:57 |
| *** qt-x <qt-x!~ionel@217.10.196.2> has quit IRC | 15:57 | |
| lpapp | rburton: also, how would you arrange local hack trials with Yocto? It cannot be checked into the mainline repository of our Yocto stuff | 15:58 |
| *** sjolley <sjolley!~sjolley@134.134.139.72> has joined #yocto | 15:58 | |
| lpapp | rburton: and every developer might have different local path, and I would rather leave it that way with their preference. I am not a unity purist. | 15:58 |
| rburton | lpapp: not sure i understand what you mean by local hack trials | 15:58 |
| lpapp | rburton: but if there is an ipkg folder, they just run make ipkg | 15:58 |
| lpapp | rburton: modifying the source code locally to attempt to add a feature or fix a bug, and then would like to ship it onto the target for testing. | 15:58 |
| lpapp | how would you do that with Yocto that is better than make ipkg? | 15:59 |
| rburton | sunzun: you should probably check that you're using the latest libeigen recipe, the commit log shows a commit in june that fixing build problems | 15:59 |
| *** madisox <madisox!~madisox@nat/cisco/x-cjdlyxoikogpjqrh> has quit IRC | 16:00 | |
| rburton | lpapp: not even bother with a package and rsync to the target | 16:00 |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC | 16:00 | |
| lpapp | rburton: why not? | 16:01 |
| sunzun | lpapp: yeah I figure the issue is more with cmake and opencv than with eigen itself.all of the stuff I find on google regarding cmake and yocto is somewhat old, and as you mentioned, this may be a recent change that broke it | 16:01 |
| *** belen <belen!Adium@nat/intel/x-bywzgdsoroykvshh> has quit IRC | 16:01 | |
| sunzun | rburton: yeah, double checked that I am. the patch that fixed this bug perviously no longer works | 16:01 |
| lpapp | libeigen? :) | 16:01 |
| lpapp | what is that? | 16:01 |
| *** madisox <madisox!~madisox@nat/cisco/x-jqrdpspujvosskaq> has joined #yocto | 16:02 | |
| lpapp | AFAIK it does not generate any library. | 16:02 |
| rburton | lpapp: that's the name of the recipe though | 16:02 |
| lpapp | rburton: what is wrong about make ipkg (which also does the scp)? | 16:02 |
| rburton | lpapp: nothing | 16:03 |
| lpapp | good, and how would it be better with Yocto? | 16:03 |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto | 16:03 | |
| lpapp | I cannot reasonably imagine testing local stuff with yocto. | 16:03 |
| sunzun | lpapp: https://github.com/openembedded/meta-oe/tree/master/meta-oe/recipes-support/libeigen | 16:03 |
| *** belen <belen!Adium@nat/intel/x-secembqbncfozday> has joined #yocto | 16:03 | |
| sunzun | that's the recipe I'm using | 16:03 |
| sunzun | afaik, that's the latest version? | 16:03 |
| lpapp | yes and no | 16:04 |
| lpapp | the recipe might be latest, eigen nope. | 16:04 |
| rburton | sunzun: right, should have worked :/ | 16:05 |
| *** belen1 <belen1!Adium@nat/intel/x-eaymkcdbwqiifapj> has joined #yocto | 16:05 | |
| sunzun | rburton: yeah, I know. it's weird that it's showing a bug that a previous patch should have fixed | 16:05 |
| lpapp | rburton: currently, I made a foo-git package and CI (Jenkins) does not clean the workspace between runs, but it feels hackish. | 16:06 |
| lpapp | obviously, rebuilding the whole system is too long to be an option. | 16:07 |
| lpapp | that is why I think life would be better with ipk/ | 16:07 |
| *** belen <belen!Adium@nat/intel/x-secembqbncfozday> has quit IRC | 16:08 | |
| sunzun | lpapp: yeah, I can see that eigen is header only. but it uses cmake to install. I guess I need to change the way yocto uses cmake (basically just need to figure out how to make it "build" outside the source directory as per the error message lol). any suggestions on where to start? I'm pretty new to yocto itself | 16:08 |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 16:09 | |
| lpapp | sunzun: your problem is build, not install. | 16:09 |
| lpapp | sunzun: meta/classes/cmake.bbclass, maybe. | 16:09 |
| sunzun | hmm okay. I'll start looking into it. thanks. | 16:09 |
| *** belen1 <belen1!Adium@nat/intel/x-eaymkcdbwqiifapj> has quit IRC | 16:09 | |
| lpapp | sunzun: well, first I would check the logs in temp/ | 16:10 |
| rburton | sunzun: the class does builds in a build/ dir by default, unless you've got a non-current cmake.bbclass | 16:11 |
| rburton | sunzun: actually, do you have meta-oe master but an old oe-core? | 16:11 |
| lpapp | so is it possible to install our SDK (core-image-minimal pretty much) and run bitbake through a recipe in the application repository? | 16:11 |
| *** roric <roric!~roric@83.140.117.51> has quit IRC | 16:11 | |
| sunzun | lpapp: the logs are basically what I pasted. no other information. | 16:11 |
| lpapp | and bitbake picking up the deps from the SDK? | 16:11 |
| sunzun | rburton: I cloned both yocto and everything else in the last two days. unless things have changed since then, it should be up to date. I'll double check though; I've already had to change a bunch of other things that were broken (and shouldn't have been), so this might be another one | 16:13 |
| *** belen <belen!~Adium@192.198.151.44> has joined #yocto | 16:13 | |
| lpapp | sunzun: heh, you are having fun, I hear you :-) | 16:14 |
| rburton | sunzun: probably best to mail oe-devel, it's probably a simple fix for someone with the time to look at it (not me, in meetings right now) | 16:15 |
| sunzun | hey, what do you know, when I meld the current cmake.bbclass and the one i have, there are several differences. makes sense. complete sense. | 16:17 |
| sunzun | lpapp: you know it. :D | 16:17 |
| rburton | sunzun: sounds like you've got a messed up clone? | 16:18 |
| sunzun | rburton: we're required to use a certain branch; sounds like the branch we're supposed to use clearly doesn't work with some stuff, but since it's the only version that works with our software, I'm just going to have to go through everything manually and fix things myself as they come up | 16:20 |
| rburton | sunzun: if you want to use eg daisy of oe-core, then ensure you also use the daisy meta-oe branch | 16:21 |
| rburton | sunzun: as meta-oe master depends on oe-core master | 16:21 |
| sunzun | rburton: hmm... you're right. I forgot to switch over the meta-oe branch since I cloned that separately | 16:22 |
| sunzun | doesn't fix my issue though, although it probably saved a lot of future headache | 16:23 |
| kergoth | vagrant4ever: re: bluez4 vs bluez5, it's not very easy to switch at the moment. at mentor we switched to bluez5 by default and added bits to make it a little easier to switch, but it's not merged. a new virtual provide has to be added, and software that can support both need its deps adjusted to the virtual. it has to be done carefully, as not all software supports both. software that uses libbluetooth will work with both, as will software | 16:31 |
| kergoth | adjusted to work with both dbus apis, but then there's the question of how to handle the runtime dependency, so really need both a new virtual provide and a new virtual-runtime. see meta-mel in meta-mentor to see how we're handling it. I intend to submit to oe-core, but haven't gotten to it yet | 16:31 |
| *** belen <belen!~Adium@192.198.151.44> has quit IRC | 16:32 | |
| *** belen <belen!Adium@nat/intel/x-ykhyhlxswvgwhfvq> has joined #yocto | 16:33 | |
| kergoth | i also have a prototype private layer which replaces the internal bluetooth implementation with a no-op third party implementation, to make it easier to drop in a commercial bluetooth implementation (additional runtime virtuals coupled with carefully disabling packagegroups and excluding packages that unconditionally pull in bluez to remove the internal default implementation) | 16:34 |
| kergoth | that said, i'm not 100% happy with it, hence not pushing much of that stuff yet | 16:34 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto | 16:34 | |
| vagrant4ever | kergoth: thanks for the information. Being new to this build environment seems like it will be tough to switch. At this time I really only care about interacting with BLE devices. Would it be possible/smart to go with a minimalist build, add bluez5 and only packages I will need? | 16:43 |
| *** staylor <staylor!~staylor@mail.au-zone.com> has joined #yocto | 16:43 | |
| kergoth | the only concern there is that bluez4 might still be pulled in via dependencies. you can certainly give that a shot, though, it'd be a reasonable starting point | 16:43 |
| fray_ | I usually "whack" the dependency issue by blacklisting bluez4 ... that way if something requires it, I get a nice list and can try to deal with it | 16:44 |
| kergoth | yeah, that's exactly what i did too :) | 16:44 |
| fray_ | PNBLACKLIST[bluez4] = "We support bluez5 now." | 16:44 |
| kergoth | blacklist is handy for that | 16:44 |
| fray_ | :) | 16:44 |
| vagrant4ever | fray, kergoth: thanks I will give that a try. | 16:48 |
| kergoth | we should think about moving to bluez5 by default and making 4 an optional switch, but it might be too late to consider such a thing for this release. i really need to do a better job of working within the yocto process, but it's tough to find time, i tend to have to focus on getting crap working for mentor, and then play catch up after the release | 16:49 |
| *** blloyd <blloyd!~blloyd@COX-66-210-177-72-static.coxinet.net> has quit IRC | 16:49 | |
| *** manuel___ <manuel___!~manuel_@p4FDAC1E3.dip0.t-ipconnect.de> has quit IRC | 16:50 | |
| *** sjolley <sjolley!~sjolley@134.134.139.72> has quit IRC | 16:53 | |
| *** armpit <armpit!~akuster@2601:c:9380:601:f465:994a:7e40:209f> has quit IRC | 16:54 | |
| *** belen1 <belen1!Adium@nat/intel/x-jawvnnfncabdohlx> has joined #yocto | 16:55 | |
| *** sjolley <sjolley!sjolley@nat/intel/x-fohtbmgfokkcryck> has joined #yocto | 16:55 | |
| *** belen <belen!Adium@nat/intel/x-ykhyhlxswvgwhfvq> has quit IRC | 16:56 | |
| *** belen <belen!Adium@nat/intel/x-adogbjuqzxbhtkfj> has joined #yocto | 16:58 | |
| *** belen1 <belen1!Adium@nat/intel/x-jawvnnfncabdohlx> has quit IRC | 16:59 | |
| *** khem___ <khem___!cc0ff166@gateway/web/freenode/ip.204.15.241.102> has joined #yocto | 17:03 | |
| khem | kergoth: I share same pain | 17:07 |
| *** belen <belen!Adium@nat/intel/x-adogbjuqzxbhtkfj> has quit IRC | 17:09 | |
| *** belen <belen!Adium@nat/intel/x-zxcnmmkregqkdmox> has joined #yocto | 17:10 | |
| *** cristianiorga <cristianiorga!~cristiani@134.134.139.74> has quit IRC | 17:13 | |
| *** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC | 17:15 | |
| *** Nitin <Nitin!nakamble@nat/intel/x-rycntuvfcllcvxcv> has quit IRC | 17:18 | |
| *** ddom_ <ddom_!~ddom@ip-37-201-80-63.hsi13.unitymediagroup.de> has joined #yocto | 17:22 | |
| *** Daemon405 is now known as Daemon404 | 17:24 | |
| *** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has joined #yocto | 17:25 | |
| *** stiandre <stiandre!~stiandre@250.97.45.31.customer.cdi.no> has joined #yocto | 17:25 | |
| kergoth | man, the unexpected rebuild of everything from scratch is SO PAINFUL | 17:33 |
| kergoth | expect a quick build to test something, and suddenly blocked for an hour | 17:33 |
| kergoth | whats worse is when -S printdiff says nothing changed | 17:34 |
| kergoth | yet everything is rebuilding from scratch anyway | 17:34 |
| khem___ | hmm | 17:38 |
| khem___ | printdiff is like a balm | 17:38 |
| nerdboy | kergoth: pretty sure the outside world is still there... maybe this is your chance... | 17:39 |
| nerdboy | make a run for the door, quick! | 17:39 |
| * kergoth looks longingly toward the front window of the coffee shop | 17:40 | |
| kergoth | printidff is great, when it actually works | 17:40 |
| darknighte | nerdboy: no encouraging slacking! | 17:40 |
| kergoth | which admittedly is usually the case, but not always | 17:40 |
| darknighte | unless I get to slack off too! :) | 17:40 |
| kergoth | i've seen builds where everything rebuilt from scratch, and the resulting sstate archives *have the exact same signatures and filenames as the ones i already had* | 17:40 |
| kergoth | haven't nailed that behavior down yet, though | 17:40 |
| * nerdboy "blocked" by webkit | 17:40 | |
| nerdboy | time to talk to the wife... | 17:41 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 17:43 | |
| lpapp | has anyone successfully managed to use gdbserver here with Yocto for debugging, like ever? | 17:43 |
| *** belen <belen!Adium@nat/intel/x-zxcnmmkregqkdmox> has quit IRC | 17:45 | |
| lpapp | it is such a painful territory even without Yocto, so I wonder if someone had already written a good tutorial about it. | 17:45 |
| fray_ | I have, but not within the last few months.. | 17:46 |
| lpapp | I cannot get it work properly with Yocto, I do not know why. | 17:46 |
| fray_ | I usually have to look up the steps when I do it | 17:47 |
| lpapp | http://paste.kde.org/praueca7s | 17:48 |
| lpapp | I wrote a debug.sh script so that I can use debug.sh myprogram | 17:48 |
| lpapp | but the script is not the point, I am just showing what I am trying | 17:48 |
| lpapp | so basically getting the stripped binary from the image rootfs and getting the symbol file from the -dbg package's packages-split sub-directory | 17:48 |
| fray_ | target remote is just one of many.. before that you normally configure where the -dbg symbols are.. etc.. | 17:49 |
| lpapp | on the target, I am just running gdbserver 192.168.0.32:2345 foo | 17:49 |
| fray_ | ya, that sounds correct | 17:49 |
| lpapp | and I have this in my ~/.gdbinit file: | 17:49 |
| lpapp | set sysroot ./tmp/work/foo-foo-linux-gnueabi/foo-core-image/1.0-r0/rootfs/ | 17:49 |
| lpapp | I will add that sysroot step to my script later. | 17:49 |
| lpapp | but that is about what I am trying to do; I observe random behavior :) | 17:50 |
| fray_ | I usually construct a special rootfs that has the debug and set it there.. | 17:50 |
| fray_ | I don't generally use the tmp/work version | 17:50 |
| lpapp | sometimes a breakpoint is not hit even the code path is hit; sometimes it jumps forth and back in the code even though I use -O0 and -g, etc. | 17:50 |
| *** pidge <pidge!pidge@nat/intel/x-wqeugevbovufkdpx> has joined #yocto | 17:52 | |
| lpapp | well, hand-crafting a custom rootfs... I am not sure that is good... you better use the SDK then if you do not like the Yocto environment's internal rootfs. | 17:53 |
| kergoth | Hmm, do we have a bitbake argument to exit after the sstates are fetched / after the runqueue is prepared, but before the build starts? | 17:53 |
| kergoth | i'm guessing probably not | 17:53 |
| kergoth | wonder if that'd be worth adding, to pre-fetch your sstates without doing so manually | 17:53 |
| sgw_ | khem___: any ideas on the eglibc issue? | 17:54 |
| khem___ | sgw_: I tried to reproduce it on my end but did not happen | 17:55 |
| khem___ | I was using ubuntu 12.04 for this | 17:55 |
| sgw_ | khem___: I am on my F19 machine, let me check my 13.10 machine | 17:56 |
| fray_ | I create a parallel 'rootfs' that only incudes the -dbg packages.. it's simple enough to do and doesn't require any special work | 17:57 |
| *** Nitin <Nitin!nakamble@nat/intel/x-skjdpoycobcilfgx> has joined #yocto | 17:57 | |
| fray_ | alternatively you run the image generation twice, the second time with the pkg-dbgs enabled | 17:57 |
| lpapp | that is not an option | 17:58 |
| seebs | I sent a patch for that PREFERRED_PROVIDER problem I was having. | 17:58 |
| *** jbrianceau_away <jbrianceau_away!uid10952@gateway/web/irccloud.com/x-nbzrpmhmxxmgeeym> has quit IRC | 17:58 | |
| lpapp | that would be quite cumbersome to switch forth and back IMO | 17:58 |
| *** diego_r <diego_r!~diego@host65-246-static.10-188-b.business.telecomitalia.it> has quit IRC | 17:58 | |
| lpapp | for every single developer | 17:58 |
| fray_ | it's simple.. | 17:58 |
| lpapp | some people do not even know Yocto, and they should not. | 17:58 |
| fray_ | image-dbg.bb: | 17:58 |
| lpapp | they get a ready-made rootfs | 17:58 |
| fray_ | require image.bb | 17:58 |
| lpapp | which is non-debug | 17:58 |
| fray_ | IMAGE_FEATURES += "pkg-dbgs" | 17:58 |
| fray_ | .... | 17:58 |
| fray_ | bitbake image image-dbg | 17:59 |
| fray_ | you get two images.. one for the system and one for the debugger | 17:59 |
| kergoth | for the rootfs with only -dbg packages, we have pending patches to do that automatically when a var is set, in meta-mentor, https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mentor-staging/lib/oe/rootfs.py#L26 | 17:59 |
| fray_ | otherise I just look at what I'm dbeugging and extract the -dbg packages myself | 17:59 |
| lpapp | fray_: the process is straight-forward, but not simple | 17:59 |
| * kergoth grumbles | 17:59 | |
| lpapp | it involves lots of steps, including image reflash | 17:59 |
| lpapp | that is very complex an environment for debugging. | 18:00 |
| lpapp | a little program | 18:00 |
| fray_ | you do NOT flash the target with the dbeug image, ever.. | 18:00 |
| fray_ | it's not requried | 18:00 |
| fray_ | gdbserver and gdb (cross) will connect the dots.. | 18:00 |
| seebs | I was assuming the debugger would run elsewhere, not on the target. | 18:00 |
| lpapp | oh, sometimes it is required, like now | 18:00 |
| lpapp | when I got fedup with gdbserver, and putting gdb onto the target. | 18:00 |
| lpapp | (using NFS) | 18:00 |
| sgw_ | khem___: yup it happens on my 13.10 machine also, which has perl 5.14.2 | 18:01 |
| lpapp | anyway, I will call it a bad day | 18:01 |
| lpapp | cya | 18:01 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 18:01 | |
| fray_ | kergoth, I'm all for that patch.. we've got a similar hack in our stuff to generate a -dbg only FS.. it's a pain | 18:01 |
| kergoth | its handy either to hand to the local gdb with a remote gdbserver, or to write onto a usb stick for on-target | 18:02 |
| fray_ | yup | 18:02 |
| fray_ | the one we wrote (1.5 time frame-ish) simply iterated over the install set and installed the dbg into a separate directory.. but it was too much of a hack to submit.. | 18:03 |
| fray_ | a python based approach for that is significantly better | 18:03 |
| *** Nitin1 <Nitin1!~nakamble@134.134.139.76> has joined #yocto | 18:03 | |
| *** Nitin <Nitin!nakamble@nat/intel/x-skjdpoycobcilfgx> has quit IRC | 18:03 | |
| * nerdboy thought the wall was chipping away, but has apparently been quickly shored up | 18:07 | |
| kergoth | does anyone know offhand if PATH only contains the pattern, or the entire path? | 18:07 |
| kergoth | e.g. file://foo/.* https://foo.com/bar/PATH | 18:07 |
| kergoth | does that fetch bar/foo/blah, or bar/blah? | 18:07 |
| * kergoth constructs a test mirrors var and cranks up fetch debugging | 18:08 | |
| *** Nitin1 <Nitin1!~nakamble@134.134.139.76> has quit IRC | 18:10 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 18:12 | |
| *** Nitin <Nitin!~nakamble@134.134.139.76> has joined #yocto | 18:13 | |
| *** khem___ <khem___!cc0ff166@gateway/web/freenode/ip.204.15.241.102> has quit IRC | 18:14 | |
| *** jimBaxter_uk <jimBaxter_uk!~jbaxter@jimbax.plus.com> has quit IRC | 18:22 | |
| *** [Sno] <[Sno]!~Sno]@p578b540c.dip0.t-ipconnect.de> has joined #yocto | 18:24 | |
| *** jimBaxter_uk <jimBaxter_uk!~jbaxter@jimbax.plus.com> has joined #yocto | 18:25 | |
| *** alimon <alimon!~alimon@189.154.7.33> has quit IRC | 18:26 | |
| sgw_ | khem: I can easily reproduce it with the conf command that gets run during the config process KCONFIG=<config> <sysroot path>/usr/bin/conf --oldaskconfig option-groups.def | 18:30 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 18:32 | |
| kergoth | hah. create a build dir called `build-PATH`, then add a file://${TOPDIR}/ path to MIRRORS. prepare to be amused | 18:42 |
| kergoth | we should have had some sort of token marker for those replacements, ${} or %{} or something :) | 18:42 |
| kergoth | gah, the verbosity of a -DDD build is still absolutely insane. forgot how bad that was :) | 18:45 |
| *** belen <belen!~Adium@190.227.187.81.in-addr.arpa> has joined #yocto | 18:45 | |
| *** flihp <flihp!~flihp@c-76-24-20-220.hsd1.ma.comcast.net> has quit IRC | 18:46 | |
| mranostay | hi kergoth | 18:49 |
| kergoth | hey mranostay | 18:50 |
| mranostay | kergoth: how are the bits baking? | 18:51 |
| nerdboy | spilling on the floor, sounds like... | 18:53 |
| *** kkh <kkh!~duracrisi@unaffiliated/duracrisis> has joined #yocto | 18:54 | |
| kergoth | arguing with bitbake again :) | 18:55 |
| kergoth | mostly losing | 18:55 |
| *** starship <starship!~duracrisi@unaffiliated/duracrisis> has quit IRC | 18:58 | |
| *** JYDawg <JYDawg!~jydawg@jydawg.xs4all.nl> has quit IRC | 18:58 | |
| *** JYDawg <JYDawg!~jydawg@jydawg.xs4all.nl> has joined #yocto | 18:59 | |
| darknighte | hmm, anyone know what the status of Qt5 on i.MX6 is on Daisy? | 19:12 |
| *** smartin_ <smartin_!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has joined #yocto | 19:22 | |
| nerdboy | okay, what exactly is the relationship between poky/meta and oe-core/meta ? | 19:24 |
| nerdboy | they're almost identical (but not quite) | 19:24 |
| nerdboy | are they manually synced at some interval? | 19:24 |
| nerdboy | other than the *.conf.sample files in oe-core the only differences i see are mine | 19:28 |
| nerdboy | yet the other day there was difference (upstream) in a bbclass file... | 19:28 |
| JaMa | nerdboy: poky/meta is created with combo-layer tool | 19:28 |
| nerdboy | from oe-core and other stuff? | 19:28 |
| JaMa | yes | 19:29 |
| nerdboy | that last difference is still confusing me... just a commit timing thing? | 19:29 |
| nerdboy | JaMa: how often does that happen and get committed to the poky repo? | 19:30 |
| JaMa | don't know | 19:31 |
| kergoth | at least in the past, there were local changes that hadn't yet gone into bitbake/oe-core, despite the use of combo-layer, but hopefully that's not the case anymore :) | 19:31 |
| nerdboy | i guess i'll know when bleeding-edge gstreamer shows up in poky? | 19:31 |
| nerdboy | that sounds like the other direction... | 19:32 |
| nerdboy | it goes both ways? | 19:32 |
| JaMa | combo-layer allows to split patches, but I think that it's used only one-way | 19:33 |
| nerdboy | i'm assuming this isn't documented anywhere yet? | 19:33 |
| darknighte | JaMa: you know what the status of Qt5(via directFB) support on i.MX6 on the daisy release is? | 19:34 |
| JaMa | OE @ ~/extras/poky $ diff -rq meta ~/openembedded-core/meta | 19:35 |
| JaMa | Only in /OE/openembedded-core/meta/conf: bblayers.conf.sample | 19:35 |
| JaMa | Only in /OE/openembedded-core/meta/conf: local.conf.sample | 19:35 |
| JaMa | Only in /OE/openembedded-core/meta/conf: local.conf.sample.extended | 19:35 |
| JaMa | Only in /OE/openembedded-core/meta/conf: site.conf.sample | 19:35 |
| JaMa | I don't see any other difference | 19:36 |
| JaMa | darknighte: no idea | 19:36 |
| nerdboy | yup, pulled on master again and got the new gstreamer stuff | 19:36 |
| nerdboy | wasn't there when it broke latest (upstream) rpi updates | 19:36 |
| nerdboy | timing is everything, apparently... | 19:37 |
| darknighte | JaMa: rats. thx anyway | 19:37 |
| JaMa | RP: is there some reason why conf.sample files are in poky only in ./meta-yocto/conf/? | 19:37 |
| JaMa | local.conf.sample.extended site.conf.sample are identical, bblayers.conf.sample local.conf.sample are a bit different | 19:39 |
| *** forcev <forcev!~quassel@w-28.cust-19171.ip.static.uno.uk.net> has quit IRC | 19:41 | |
| *** kkh <kkh!~duracrisi@unaffiliated/duracrisis> has quit IRC | 19:43 | |
| *** kkh <kkh!~duracrisi@unaffiliated/duracrisis> has joined #yocto | 19:43 | |
| Daemon404 | 2 | 19:44 |
| JaMa | 42 | 19:45 |
| *** blloyd <blloyd!~blloyd@COX-66-210-177-72-static.coxinet.net> has joined #yocto | 19:45 | |
| *** rcw <rcw!~rwoolley@128.224.252.2> has quit IRC | 19:46 | |
| *** rcw <rcw!~rwoolley@128.224.252.2> has joined #yocto | 19:47 | |
| *** smartin <smartin!~smartin@195.190.86.18> has quit IRC | 19:48 | |
| *** smartin <smartin!~smartin@195.190.86.18> has joined #yocto | 19:52 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 19:52 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 19:53 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has left #yocto | 19:59 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 19:59 | |
| blloyd | anyone know why gdb would be compiled with --with-ncurses and --disable-tui? Seems funny because I thought it only used ncurses for tui mode. | 20:00 |
| *** stiandre <stiandre!~stiandre@250.97.45.31.customer.cdi.no> has quit IRC | 20:00 | |
| khem | sgw_: Does it happen with poky-tiny config or normal poky config for you | 20:01 |
| khem | JaMa: meta-yocto actually is the poky distro layer | 20:03 |
| Crofton|work | mv meta-yocto meta-poky to increase clarity | 20:04 |
| khem | I asked for it during ELC 2011 | 20:04 |
| kergoth | thatd be nice, would definitely reduce confusion | 20:05 |
| khem | I agree, but the fact that poky uses combo-layer makes it a bit different setup then others do e.g. others use layers as they are and add a setup layer and a distro layer to form the complete set | 20:07 |
| khem | so meta-yocto kind of looses the significance of being a distro layer there | 20:07 |
| khem | this is a different approach but some folks want it this way | 20:08 |
| khem | where all metadata is under single git repo | 20:08 |
| *** belen <belen!~Adium@190.227.187.81.in-addr.arpa> has quit IRC | 20:09 | |
| kergoth | meh, I'd like to leverage the internal setup scripts more, rather than rolling our own so much, but the core ones are still rather limited | 20:11 |
| kergoth | hmm | 20:11 |
| *** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto | 20:14 | |
| JaMa | khem: yes, but that doesn't explain why their were removed from meta subdirectory (unless something requires them to be uniq) | 20:26 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 20:28 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 20:29 | |
| *** flihp <flihp!~flihp@50.153.134.134> has joined #yocto | 20:35 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 20:40 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 20:41 | |
| nerdboy | maybe a "repo" repo/manifest instead | 20:42 |
| nerdboy | ie, one for poky (sans hand-made layer tool), one for oe-core, etc | 20:43 |
| nerdboy | plus document using them | 20:43 |
| *** ant__ <ant__!~andrea@host169-1-dynamic.51-79-r.retail.telecomitalia.it> has joined #yocto | 20:44 | |
| nerdboy | some (non-core) setups already do that... | 20:44 |
| nerdboy | but yeah, i thought the main difference/intent of poky repo was to provide yocto-bsp, poky/meta, demo images, etc, all in one repo | 20:46 |
| sgw_ | khem: normal configuration multiple build machines and different MACHINE settings (arm/x86) | 20:47 |
| nerdboy | oh, and yocto reference kernel and default machine support for a handful of machines | 20:47 |
| lpapp | good morning | 20:55 |
| *** rcw <rcw!~rwoolley@128.224.252.2> has quit IRC | 21:06 | |
| *** ant_home <ant_home!~andrea@host209-253-dynamic.25-79-r.retail.telecomitalia.it> has joined #yocto | 21:11 | |
| *** ant__ <ant__!~andrea@host169-1-dynamic.51-79-r.retail.telecomitalia.it> has quit IRC | 21:14 | |
| *** jkridner|work is now known as jkridner | 21:14 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 21:14 | |
| *** ddom_ <ddom_!~ddom@ip-37-201-80-63.hsi13.unitymediagroup.de> has quit IRC | 21:14 | |
| *** ddom_ <ddom_!~ddom@ip-37-201-80-63.hsi13.unitymediagroup.de> has joined #yocto | 21:15 | |
| *** theguy <theguy!~theguy@S0106602ad07d0544.gv.shawcable.net> has joined #yocto | 21:16 | |
| theguy | Hey everybody | 21:16 |
| lpapp | hi | 21:17 |
| theguy | Can anyone help me with a udev issue? | 21:17 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 21:17 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 21:18 | |
| sgw_ | theguy: depends on what it is | 21:18 |
| lpapp | theguy: what issue | 21:19 |
| khem | sgw_: hmm ok. I will try to reproduce it with OE-Core tonight | 21:19 |
| *** sjolley <sjolley!sjolley@nat/intel/x-fohtbmgfokkcryck> has quit IRC | 21:19 | |
| nerdboy | udev problem as in installing your own custom rule perhaps? | 21:21 |
| *** ddom_ <ddom_!~ddom@ip-37-201-80-63.hsi13.unitymediagroup.de> has quit IRC | 21:21 | |
| *** ddom_ <ddom_!~ddom@ip-37-201-80-63.hsi13.unitymediagroup.de> has joined #yocto | 21:21 | |
| sgw_ | khem: Ok, I will be back around after 8 - 9ish or so tonight. | 21:22 |
| RP | JaMa: they got filtered out mainly to reduce confusion | 21:22 |
| RP | and yes, that layer should have been called meta-poky | 21:22 |
| RP | I still sometimes wonder about changing the name | 21:22 |
| *** sjolley <sjolley!sjolley@nat/intel/x-jyuolqdihloucavb> has joined #yocto | 21:23 | |
| *** ddom_ <ddom_!~ddom@ip-37-201-80-63.hsi13.unitymediagroup.de> has quit IRC | 21:24 | |
| khem | RP: master-next is missing 1 gcc patch | 21:24 |
| khem | from me | 21:24 |
| *** sameo <sameo!~samuel@192.55.54.40> has quit IRC | 21:25 | |
| khem | http://patchwork.openembedded.org/patch/78131/ and http://patchwork.openembedded.org/patch/78135/ | 21:26 |
| *** LocutusOfBorg1 <LocutusOfBorg1!~Gianfranc@host158-225-dynamic.9-87-r.retail.telecomitalia.it> has joined #yocto | 21:29 | |
| *** vagrant4ever <vagrant4ever!a6821a3a@gateway/web/freenode/ip.166.130.26.58> has quit IRC | 21:29 | |
| RP | khem: I was waiting for Peter to rebase them | 21:30 |
| *** smartin_ <smartin_!~smartin@ivr94-4-82-229-165-48.fbx.proxad.net> has quit IRC | 21:30 | |
| *** LocutusOfBorg1 <LocutusOfBorg1!~Gianfranc@host158-225-dynamic.9-87-r.retail.telecomitalia.it> has quit IRC | 21:33 | |
| hbruce | New to Yocto. Using daisy release, but meta-java doesn't have daisy branch. Should i take dora or master? | 21:34 |
| khem | he did I think | 21:35 |
| khem | hbruce: master | 21:35 |
| RP | khem: right, but not when I last built -next ;-) | 21:36 |
| RP | khem: I'm updating | 21:36 |
| *** jmpdelos__ <jmpdelos__!~polk@71-34-144-108.clsp.qwest.net> has joined #yocto | 21:37 | |
| *** jmdelos_ <jmdelos_!~polk@75-173-225-178.clsp.qwest.net> has quit IRC | 21:37 | |
| *** ftonello <ftonello!~felipe@wsip-70-183-20-162.oc.oc.cox.net> has joined #yocto | 21:39 | |
| khem | RP: ok here is the rebased versions on top of master-next http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/musl | 21:39 |
| *** flihp <flihp!~flihp@50.153.134.134> has quit IRC | 21:40 | |
| theguy | Actually no, udev problem where my drive does not disappear from /dev when I remove it | 21:40 |
| nerdboy | is there something in fstab? | 21:41 |
| nerdboy | related to whatever the device is... | 21:41 |
| nerdboy | so you get something like a stale /dev/sdb,/dev/sdb1 ? | 21:43 |
| theguy | Nothing in fstab | 21:43 |
| nerdboy | i have seen that lately, but on my desktop after a usb bus hiccup | 21:43 |
| theguy | And exactly. It's /dev/sda and /dev/sda1 | 21:43 |
| nerdboy | 3.13.6 gentoo-sources and <urp> udev-212-r1 | 21:45 |
| theguy | It works fine for a while, then suddenly after a reboot /dev/sda is there when it shouldn't be | 21:45 |
| nerdboy | reboot with device still inserted? | 21:45 |
| theguy | I'm running 3.0.35 | 21:45 |
| theguy | with the freescale 4.0.0 bsp | 21:45 |
| theguy | If I insert and remove the drive, udev still detects it and mounts/unmounts it automatically | 21:46 |
| theguy | But it just doesn't remove /dev/sda anymore | 21:47 |
| nerdboy | been using 3.15/patched mainline and bleeding-edge u-boot on wand/udoo | 21:47 |
| nerdboy | theguy: you mean with the stale /dev file there? | 21:47 |
| theguy | Yeah. The file /dev/sda stays whether the drive is inserted or not, but udev seems happy and it mounts/unmounts correctly | 21:48 |
| nerdboy | then it detects/mounts as sdb if sda is stale... at least it should... | 21:48 |
| theguy | It still gets used as /dev/sda | 21:48 |
| nerdboy | ? | 21:48 |
| nerdboy | not with (systend) udev... | 21:49 |
| theguy | Yeah it's weird. I've seen it on my desktop before where it will increment the letter if one goes stale, but in this case it keeps using /dev/sda. It's just that the file doesn't go away when the drive is removed. | 21:49 |
| nerdboy | oe uses 18x-something i belivee | 21:49 |
| theguy | 18x? | 21:49 |
| theguy | udev version? | 21:50 |
| nerdboy | as opposed to 20x | 21:50 |
| nerdboy | yeah | 21:50 |
| nerdboy | well, 212 on my desktop and it's behind... | 21:50 |
| theguy | Oh yeah - 182-r7 | 21:50 |
| nerdboy | pretty sure that's still udev source before it "merged" with systemd | 21:51 |
| nerdboy | not to say the behavior doesn't change like my underwear... | 21:51 |
| theguy | My system doesn't use systemd, so I assume it would have to be before that? | 21:51 |
| theguy | Is there a forum or chat room that might have a lot of knowledge on udev? If I could figure out exactly where udev creates/deletes that file I could try and debug it | 21:52 |
| nerdboy | my gentoo builds leave out systemd as well (just openrc stuff is fine) but udev has been assimilated afaik | 21:54 |
| nerdboy | the rules are on your system | 21:54 |
| hbruce | khem: Thx. Using meta-java master but getting build errors in xerces-j-native. Anyone seen this? | 21:54 |
| khem | RP: I have consolidated Peter's and mine patches on top of master here http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/musl | 21:55 |
| *** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC | 21:55 | |
| theguy | I don't think it's an issue with the rules. It works fine for a while and then stops working randomly until I recreate my rootfs | 21:56 |
| theguy | As far as I can tell the creation of /dev/sdx is built into udev as well | 21:56 |
| nerdboy | it should be in the default rules | 21:57 |
| nerdboy | use opkg/rpm/apt to list the rule files | 21:57 |
| *** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto | 21:57 | |
| khem | hbruce: what errors ? | 21:58 |
| nerdboy | so you're plugging in a device, unmounting, change partitions, mkfs and remount? | 21:58 |
| theguy | Oh, how do I do that? I've looked through the rule files in /etc/udev/rules.d but I don't see anything about creating /dev/sdx files | 21:58 |
| theguy | When it breaks? All I do is reboot a few times with the drive inserted. | 21:59 |
| *** Nitin1 <Nitin1!~nakamble@134.134.137.71> has joined #yocto | 21:59 | |
| nerdboy | opkg list-installed | grep udev (for package names) | 21:59 |
| theguy | Although it seems to happen after I do a "system update" by copying a duplicate root filesystem from a USB drive onto my device | 22:00 |
| nerdboy | opkg files udev (to list files in a package) | 22:00 |
| nerdboy | there's another place for rules | 22:00 |
| nerdboy | look in /lib/udev/rules.d/ | 22:00 |
| *** bfederau <bfederau!~quassel@service.basyskom.com> has quit IRC | 22:01 | |
| khem | RP: current master-next which you rebased few min ago is still missing one patch http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/musl&id=0e299ee5155c94f09a15430c091766cfb55bce68 | 22:01 |
| *** bfederau <bfederau!~quassel@service.basyskom.com> has joined #yocto | 22:01 | |
| nerdboy | that's for opkg packages anyway... | 22:01 |
| theguy | I have dpkg, I'll look up the command | 22:01 |
| nerdboy | 60-persistent-storage.rules | 22:01 |
| theguy | I'll take a look through there thanks | 22:02 |
| *** Nitin <Nitin!~nakamble@134.134.139.76> has quit IRC | 22:03 | |
| theguy | As far as I can tell, the rules files don't change between when it works and when it doesn't | 22:03 |
| *** Nitin1 <Nitin1!~nakamble@134.134.137.71> has quit IRC | 22:04 | |
| theguy | Although I should verify that | 22:05 |
| nerdboy | to be safe, if you change the partition table you should remove/reinsert the device or run partprobe | 22:05 |
| nerdboy | the rules files don't change on their own... | 22:05 |
| nerdboy | the stale device file is an artifact of udev not handling something very well | 22:05 |
| nerdboy | something you're doing/not doing is my guess, or the device/reader is flakey | 22:06 |
| theguy | The partition table is never changed. I do mount/unmount the drive and read data from it. At some point, I copy a duplicate root filesystem from the USB drive over top of my root filesystem and then reboot. It seems to work until another one or two reboots after that. | 22:07 |
| theguy | I have an application running that monitors /dev/sda... I wonder if that is somehow preventing it from being deleted. | 22:07 |
| nerdboy | maybe sync after untar and see if that helps | 22:07 |
| theguy | I'll give that try thanks | 22:08 |
| nerdboy | or might be flakey hardware/driver getting saturated during heavy i/o and taking a dump | 22:08 |
| theguy | It could be. Once it | 22:08 |
| theguy | Once it's broken though, the file /dev/sda is created on boot whether the drive is inserted or not. And the continues until I re-flash the root filesystem. Even if I delete the file manually and reboot it returns. | 22:09 |
| nerdboy | it's stale so it's a real file there when udev starts (which it sees and won't create the device) | 22:10 |
| theguy | I delete it and reboot, without ever inserting the drive, it gets created on boot again | 22:11 |
| nerdboy | you could wipe /dev on boot/reboot but you'd need to provide/create /dev/{console,null,zero} at a minimum | 22:11 |
| RP | khem: thanks, added | 22:11 |
| nerdboy | but it guarantee clean /dev startup | 22:11 |
| theguy | Oh would I have to wipe all of /dev instead of just the one file? | 22:11 |
| theguy | Ok I'll give that a try | 22:12 |
| khem | RP: cool. so once this goes into master, I will be able to announce availability of meta-musl https://github.com/kraj/meta-musl | 22:12 |
| nerdboy | just the stale ones, although the problem might just make new stale ones... | 22:12 |
| theguy | That's what happens. If I delete the stale file /dev/sda and then reboot, it gets created again. Even if I never inserted the drive. | 22:13 |
| nerdboy | now *that* sounds really weird... | 22:13 |
| nerdboy | does your build have a default device tarball? | 22:14 |
| RP | khem: there is quite a queue in master-next so its going to need an autobuilder run and so on | 22:14 |
| nerdboy | rpi boots off /dev/mmcblk0 so i have no sda unless i plug something else in | 22:14 |
| theguy | Same with me. Boot is from /dev/mmcblk0 and /dev/sda is only created when I plug in a USB drive | 22:15 |
| nerdboy | if you have a /dev/sda with no physical device then something else is going on | 22:15 |
| nerdboy | assuming this is accurate/correct: <theguy> That's what happens. If I delete the stale file /dev/sda and then reboot, it gets created again. Even if I never inserted the drive. | 22:16 |
| hbruce | kmem: Java build error src/org/apache/html/dom/HTMLIFrameElementImpl.java (at line 28) | 22:16 |
| khem | RP: yes, true | 22:16 |
| nerdboy | that should not happen with a default udev setup | 22:16 |
| theguy | Yep that's what happens. USB drive is /dev/sda, but after a few reboots that file starts to appear even when the drive isn't inserted. | 22:17 |
| hbruce | khem: sorry got your handle wrong | 22:17 |
| khem | RP: I am going to work on glibc 2.20 now as a part of that I am planning on renaming eglibc recipes to be called glibc | 22:17 |
| theguy | So my application thinks a USB drive is inserted when it actually isn't. | 22:17 |
| nerdboy | minimal static devices are the three above, whether they get plopped there by initramfs or they're just static | 22:17 |
| khem | hbruce: thats ok you can use ashmem too :) I do android too | 22:18 |
| khem | hbruce: pastebin the full build log somewhere | 22:18 |
| theguy | I never make /dev/sda static. At some point it starts getting created on boot. If I delete it and reboot it comes back again. | 22:18 |
| theguy | So I'd like to figure out what's placing it there on boot. | 22:18 |
| khem | RP: that reminds me of glibc -> eglibc transition now in reverse order | 22:18 |
| nerdboy | "after a few reboots" meaning the device was plugged in at least once and later you get a stale (normal) device/partition file in dev | 22:19 |
| khem | since we did not remove glibc provides I am hoping this to be simpler | 22:19 |
| RP | khem: yes, lets hope so. Did we get anywhere with configuration of glibc? | 22:19 |
| theguy | Yep. After the device has been plugged in a few times, and the board is rebooted a few times, that file starts showing up even when it shouldn't. | 22:19 |
| khem | upstreaming ? | 22:19 |
| RP | khem: yes | 22:19 |
| nerdboy | can you make it happen while you watch dmesg? | 22:20 |
| khem | nowhere yet I am thinking bring the port to 2.20 will help in that | 22:20 |
| RP | khem: ok | 22:20 |
| nerdboy | seem like there should be a udev log entry that at least smells funny... | 22:20 |
| khem | so end of this month if all is ok I will propose it for 2.21 | 22:20 |
| theguy | I've looked through the logs when it's working properly and when it isn't, but I can't seem to find any differences | 22:21 |
| khem | RP: after I have had good results with 2.20 on master that is | 22:21 |
| theguy | It's a weird issue. I've been working on it for a few days now | 22:21 |
| theguy | I'll look a bit more closely at my application - maybe it's creating the file somehow by accident. | 22:22 |
| nerdboy | what usb hardware/drivers? using usb-gadget? otg? other? | 22:22 |
| RP | khem: sounds good | 22:23 |
| nerdboy | theguy: strace your app | 22:23 |
| nerdboy | should be clear whether it does or not | 22:23 |
| theguy | It's an i.MX6, the freescale bsp supplied the drivers. I believe it's a USB host but I'd have to double check. | 22:24 |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC | 22:24 | |
| nerdboy | sounds normal enough, notwithstanding you could've found an actual bug | 22:25 |
| theguy | Actually once the problem starts, even if I never run the app, the file still appears on boot. Although the app could be starting the problem in the first place | 22:25 |
| hbruce | khem: Build output at http://pastebin.com/fr7ZDTYs | 22:26 |
| theguy | I wonder! It feels like a bug, but there are many times where I think it's a bug and it turns out to be my code :/ | 22:26 |
| nerdboy | if it's a stale file it will always be there unless /dev is mounted volatile | 22:26 |
| theguy | Would udev give an error if it couldn't remove the file when the drive was removed? | 22:26 |
| nerdboy | bug in your code/upstream bug, bug is abug... | 22:26 |
| nerdboy | it should in theory | 22:27 |
| nerdboy | not sure how quiet you can make it | 22:28 |
| theguy | Do you know where I could look for that error? I've looked in /var/log/messages after setting the log priority to info but I see no mention of /dev/sda at all | 22:28 |
| theguy | Oh sorry that's not true. I see mention of it but nothing to say when it is created/deleted | 22:28 |
| nerdboy | can you determine for sure if it's just a stale file created once and subsequently ignored bu udev? | 22:28 |
| theguy | If I do a "rm /dev/sda", it goes away. udev then works properly until I reboot, at which point /dev/sda magically appears again | 22:29 |
| nerdboy | you should see the usual udev/usb device messages in dmesg and the kernel log | 22:30 |
| nerdboy | it should not magically reappear on its own | 22:30 |
| nerdboy | someone is putting it there, and that's not "typical" udev behavior | 22:30 |
| theguy | I'll try and break it again and then look at the kernel logs after a reboot | 22:31 |
| theguy | Yeah. I just can't figure out what's putting it there | 22:31 |
| theguy | Just doing an update now, which should break it. And then I'll see if the logs mention it on reboot. | 22:32 |
| nerdboy | okay, not that i've had a reason to look before, but the default is empty /dev dir is empty when not in a running system | 22:35 |
| *** Nitin <Nitin!~nakamble@134.134.137.73> has joined #yocto | 22:35 | |
| nerdboy | everybody's different... | 22:35 |
| *** zerus <zerus!~epetmab@81-229-90-163-no67.tbcn.telia.com> has quit IRC | 22:36 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 22:36 | |
| theguy | Ok I broke it again. I'll take a look at the log files. | 22:37 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 22:38 | |
| theguy | So dmesg | grep sda shows nothing, but the file is there | 22:39 |
| theguy | I'll rm /dev/sda and reboot | 22:39 |
| theguy | After reboot, /dev/sda is back. The drive is not inserted. | 22:40 |
| theguy | I can't find anything that would be creating that file | 22:42 |
| nerdboy | what gets it back to normal? cold boot? | 22:45 |
| theguy | Cold boot doesn't work. I end up reflashing the SD card from scratch with a fresh root filesystem | 22:46 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 22:47 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 22:48 | |
| *** PMC-Sierra <PMC-Sierra!d144a0f1@gateway/web/freenode/ip.209.68.160.241> has joined #yocto | 22:48 | |
| nerdboy | sync didn't help? | 22:48 |
| nerdboy | are you preserving the proper permissions on what comes out of the tarball? | 22:49 |
| theguy | Should I do a sync after removing /dev/sda? | 22:49 |
| nerdboy | before | 22:49 |
| theguy | Ok | 22:49 |
| nerdboy | when sync returns everything is flushed | 22:50 |
| theguy | Ok, so I'll do sync, then rm /dev/sda, then reboot | 22:50 |
| nerdboy | so if it still pukes that would eliminate incomplete writes to the card | 22:50 |
| theguy | Alright one sec | 22:51 |
| theguy | Looks like the file still gets created on boot | 22:51 |
| theguy | nerdboy thanks a lot for the help. I've got to head off now. | 22:53 |
| theguy | But you've given me a bunch of things to look at so I'll investigate them further. | 22:53 |
| nerdboy | don't forget to report back... | 22:54 |
| theguy | Will do! I'm back tomorrow so I'll sign in here and give you an update | 22:54 |
| nerdboy | ok | 22:55 |
| theguy | Really appreciate it! Cheers | 22:55 |
| *** theguy <theguy!~theguy@S0106602ad07d0544.gv.shawcable.net> has quit IRC | 22:55 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 22:56 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 22:57 | |
| * nerdboy kinda feels like the sales guy who sends people across the street for a better deal | 22:58 | |
| *** PMC-Sierra <PMC-Sierra!d144a0f1@gateway/web/freenode/ip.209.68.160.241> has quit IRC | 23:00 | |
| *** agust <agust!~agust@pD9E2F8F1.dip0.t-ipconnect.de> has quit IRC | 23:02 | |
| *** ant_home <ant_home!~andrea@host209-253-dynamic.25-79-r.retail.telecomitalia.it> has quit IRC | 23:03 | |
| *** staylor <staylor!~staylor@mail.au-zone.com> has quit IRC | 23:04 | |
| nerdboy | probably why i'm not a sales guy... | 23:05 |
| -YoctoAutoBuilder- build #206 of nightly-intel-gpl is complete: Failure [failed BuildImages BuildImages_1] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-intel-gpl/builds/206 | 23:17 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 23:30 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 23:32 | |
| *** jkridner <jkridner!~jkridner@c-98-250-189-79.hsd1.mi.comcast.net> has joined #yocto | 23:33 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 23:33 | |
| -YoctoAutoBuilder- build #204 of nightly-non-gpl3 is complete: Failure [failed BuildImages] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-non-gpl3/builds/204 | 23:38 | |
| -YoctoAutoBuilder- build #199 of poky-tiny is complete: Failure [failed BuildImages] Build details are at http://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/199 | 23:42 | |
| -YoctoAutoBuilder- build #203 of nightly-fsl-ppc-lsb is complete: Failure [failed BuildImages] Build details are at http://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc-lsb/builds/203 | 23:52 | |
| *** seebs <seebs!~seebs@184-223-223-108.pools.spcsdns.net> has joined #yocto | 23:52 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!