| 01:23.09 | *** join/#oe multiplex (~Laurent@37.1.173.206) |
| 01:30.28 | *** join/#oe multiplex (~Laurent@37.1.173.206) |
| 01:42.07 | *** join/#oe dijenerate (~dijenerat@173.225.251.175) |
| 03:50.53 | *** join/#oe risca (~risca@wi-secure-8039.cc.umanitoba.ca) |
| 04:44.45 | *** join/#oe War2 (~war2@unaffiliated/war2) |
| 04:46.19 | *** join/#oe hrw (~hrw@linaro/hrw) |
| 04:47.10 | *** join/#oe kgilmer (~kgilmer@p3179-ipad13yosemiya.okinawa.ocn.ne.jp) |
| 05:01.36 | *** join/#oe risca (~risca@wnpgmb0903w-ds01-177-34.dynamic.mtsallstream.net) |
| 05:09.57 | *** join/#oe erwt (~erwt@122.170.104.85) |
| 05:26.00 | *** join/#oe War2 (~war2@unaffiliated/war2) |
| 05:26.11 | *** join/#oe hrw (~hrw@linaro/hrw) |
| 05:44.07 | *** join/#oe snkt (~snkt@122.170.104.85) |
| 05:45.11 | *** join/#oe clio (~andrej@85.159.109.222) |
| 05:51.05 | *** join/#oe Ofpo (~Openfreer@116.228.88.131) |
| 05:51.10 | *** join/#oe Openfree` (~Openfreer@116.228.88.131) |
| 05:55.17 | *** join/#oe openfree (~dennis@116.228.88.131) |
| 06:05.37 | *** join/#oe devzero_ (devzero@xdsl-78-35-59-213.netcologne.de) |
| 06:21.21 | *** join/#oe mayday_jay (~mayday_ja@2001:470:b0ba:0:200:1aff:fe19:b8c5) |
| 06:45.22 | *** join/#oe tscheck (~t@83.151.21.119) |
| 06:45.28 | *** join/#oe tasslehoffwrk (~Tasslehof@147.84-49-231.nextgentel.com) |
| 06:51.21 | tasslehoffwrk | morning. can I add users to my image compile-time? |
| 07:06.59 | Noor | tasslehoffwrk: u r working on which OE classic or core? |
| 07:13.38 | tasslehoffwrk | Noor: classic |
| 07:14.15 | tasslehoffwrk | my core image is almost ready, but not early enough to be used for our first release |
| 07:14.37 | Noor | tasslehoffwrk: then I am afraid you cant do it .... thats my thinking .... I have beginners exp in OE more experience ppl can comment on it as well |
| 07:20.50 | *** join/#oe vitus (~vitus@145.253.169.210) |
| 07:23.00 | tasslehoffwrk | Noor: ok. thanks :) |
| 07:24.32 | Noor | tasslehoffwrk: in oe-core there is a class useradd ... u can loo into that if u want |
| 07:24.38 | Noor | look |
| 07:25.02 | tasslehoffwrk | Noor: that's the one I've seen discussed here, and the reason I asked |
| 07:25.07 | tasslehoffwrk | :) |
| 07:29.44 | *** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net) |
| 07:31.42 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 07:39.45 | *** join/#oe rschus (~rschus@vsr56-1-89-84-156-196.dsl.sta.abo.bbox.fr) |
| 07:41.53 | *** join/#oe bluelightning (~paul@cpc2-lewi17-2-0-cust101.2-4.cable.virginmedia.com) |
| 07:41.53 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 07:58.39 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 08:13.28 | *** join/#oe esbenh (~esben@hugin.dotsrc.org) |
| 08:17.59 | *** join/#oe sH|Mnemonic (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 08:21.40 | *** join/#oe Spider-Pork (~Spider-Po@host39-232-static.225-95-b.business.telecomitalia.it) |
| 08:26.42 | mckoan | good morning |
| 08:37.41 | *** join/#oe jkridner_ (~jason@pdpc/supporter/active/jkridner) |
| 08:53.51 | *** join/#oe kgilmer (~kgilmer@p3179-ipad13yosemiya.okinawa.ocn.ne.jp) |
| 09:02.12 | *** join/#oe Zagor (~bjst@rockbox/developer/Zagor) |
| 09:09.22 | *** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it) |
| 09:16.29 | *** join/#oe pespin (~pespin@90.163.51.170) |
| 09:18.02 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 09:22.37 | *** join/#oe amarsman (~marsman@90-145-17-249.wxdsl.nl) |
| 09:29.33 | *** join/#oe tws (~Miranda@178.120.244.19) |
| 09:45.28 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 09:54.04 | *** join/#oe rob_w (~bob@host-188-174-219-117.customer.m-online.net) |
| 09:54.04 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 09:59.45 | *** join/#oe ericben (~ebenard@pac33-2-82-240-38-71.fbx.proxad.net) |
| 10:08.42 | *** join/#oe ensc|w (~ensc@www.sigma-chemnitz.de) |
| 10:11.20 | rob_w | i am having issue compiling ti dsplink and lpm and all those friends as it always does errors regarding wrong vfp settings between the modules |
| 10:16.12 | *** join/#oe War2 (~war2@unaffiliated/war2) |
| 10:27.57 | *** join/#oe rschus (~rschus@89.1.20.66) |
| 10:38.59 | *** join/#oe rschus1 (~rschus@vsr56-1-89-84-156-196.dsl.sta.abo.bbox.fr) |
| 10:44.29 | *** join/#oe icanicant (~klawson@213.218.221.154) |
| 10:48.25 | otavio | morning |
| 10:50.15 | otavio | tasslehoffwrk: useradd shouldn't be too hard to port to oe classic |
| 10:50.28 | otavio | tasslehoffwrk: ahh, forget ... |
| 10:50.44 | otavio | tasslehoffwrk: it uses sstage methods ... |
| 10:50.55 | otavio | tasslehoffwrk: i do believe it won't be trivial |
| 11:11.00 | *** join/#oe sterNiX (~LessIsMor@unaffiliated/nu253r/x-0655220) |
| 11:14.01 | *** join/#oe tasslehoffwrk (~Tasslehof@84.49.231.147) |
| 11:24.32 | *** join/#oe rob_w (~bob@93.104.205.194) |
| 11:24.32 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 11:37.35 | Noor | I ma orking on oe-core and bit confused on do deply function |
| 11:38.31 | Noor | I can see u-boot is being deployed in DEPLOYDIR but I am not able to understand how it does to DEPLPY_DIR_IMAGE folder |
| 11:38.39 | Noor | can somebosy give me a pointer |
| 11:39.14 | Noor | somebody |
| 11:40.59 | Noor | typing is getting worse day by day |
| 11:46.45 | *** join/#oe likewise (~likewise@116-66-ftth.onsneteindhoven.nl) |
| 11:48.34 | bluelightning | Noor: does bitbake -e u-boot | grep DEPLOY_DIR_IMAGE help? |
| 11:48.56 | bluelightning | -> office, back in 1hr |
| 11:49.49 | *** join/#oe hexor (~hexor@unaffiliated/hexor) |
| 11:50.22 | *** part/#oe hexor (~hexor@unaffiliated/hexor) |
| 11:55.10 | *** join/#oe woglinde (~henning@fb-n15-11.unbelievable-machine.net) |
| 12:04.34 | *** join/#oe jackmitch (~jack@195.171.99.130) |
| 12:09.10 | jackmitch | Trying to build cpufrequtils with openembedded I recieve this error: http://pastebin.com/1NSdi5Ym |
| 12:09.34 | jackmitch | could anyone shed any light on what the issue is, it seems to be missing 'install' but other pakges seem to use it without issue... |
| 12:11.43 | woglinde | jackmitch do you use oe-classic or oe-core? |
| 12:11.52 | jackmitch | oe-core |
| 12:13.32 | woglinde | are you sure? |
| 12:13.34 | woglinde | tmp-angstrom_2010_x-eglibc |
| 12:14.14 | woglinde | besides that check of /usr/bin/install is there |
| 12:14.23 | jackmitch | I think so, I am trying to build for the beaglebone and have followed the instructions here: http://www.angstrom-distribution.org/building-angstrom |
| 12:14.26 | woglinde | and check if the tools /usr/bin/install uses are there |
| 12:14.51 | woglinde | what branch of setup-srcipts did you check out? |
| 12:15.00 | jackmitch | master I would imagine |
| 12:15.19 | jackmitch | yes, master |
| 12:17.22 | jackmitch | To be honest all I want to do is re-compile my beaglebones kernel to enable SPI, but the meta-ti layer can't be used with anything other than angstrom and you have to rebuild the whole distribution. Bit of a nightmare to be honest. |
| 12:18.27 | jackmitch | I tried doing it through the way I know by using the layers and sourcing the oe script, but it failed so I thought it would be easy to use the 'pre-configured' script that it told me to use but alas... not very easy. |
| 12:19.04 | jackmitch | https://github.com/Angstrom-distribution/meta-ti |
| 12:19.52 | woglinde | no |
| 12:20.13 | woglinde | bitbake -c menuconfig virtual/kernel |
| 12:20.25 | woglinde | or bitbake -c menuconfig linux |
| 12:20.38 | woglinde | bitbake -c devshell foo and copy your config out |
| 12:20.51 | jackmitch | but I would have to do that after I had used the angstrom script yes? |
| 12:21.20 | woglinde | than dont use the script |
| 12:21.29 | woglinde | its in the docs how to do it |
| 12:22.15 | jackmitch | I must be beign daft, which documents are you refering to, I feel like i've been going in circles all morning! |
| 12:23.13 | woglinde | http://www.angstrom-distribution.org/building-angstrom |
| 12:23.21 | woglinde | MACHINE=beagleboard ./oebb.sh bitbake virtual/kernel |
| 12:23.42 | woglinde | to hard to find? |
| 12:24.11 | jackmitch | ah right ok, yes but I thought if I was bulding master then the if I built the kernel alone it wouldn't be compatible with my current 'demo image' userland? |
| 12:24.27 | woglinde | its the same source |
| 12:24.39 | woglinde | maybee some newer patches |
| 12:24.39 | jackmitch | so I would build the latest 'generic' angstrom and then rebuild the kernel to my spec afterwards |
| 12:24.43 | woglinde | look the recipe |
| 12:24.59 | woglinde | you mean you are building toolchain |
| 12:25.33 | woglinde | angstroem are the ipk's for the target which falls out in the end |
| 12:25.53 | jackmitch | In my head I would build the latest angstrom distro, then load my beaglebone, then I would add a to the kernel recipe to give me the functionallity I required, then rebuild |
| 12:26.07 | jackmitch | add a patch* |
| 12:26.30 | woglinde | again for kernel you only need gcc-cross in the end |
| 12:26.41 | woglinde | nothig more |
| 12:27.02 | jackmitch | ok, right i'll try just building the kernel but then what happens |
| 12:28.05 | woglinde | OR |
| 12:28.16 | woglinde | you download sdk from narcissus and following this |
| 12:28.24 | woglinde | http://bec-systems.com/site/521/best-practices-for-kernel-development-with-openembedded |
| 12:31.23 | jackmitch | ok, i'll have a read thanks - I have been using Yocto recently and the development cycle seems a lot less convoluted but I don't know if that is due to Texas Instruments or the Angstrom disto, but I suppose with them depending on each other it makes no difference.. |
| 12:32.17 | woglinde | o,O |
| 12:32.42 | woglinde | angstroem and yocto editing recipes and running bitbake is all the same |
| 12:32.57 | woglinde | both using oe |
| 12:33.35 | jackmitch | indeed, but Yocto seems to be more barebones without the need for a complicated wrapper script |
| 12:34.23 | woglinde | *sigh* |
| 12:34.31 | jackmitch | I tried pulling the layers down seperatly with bitbake, set the machine to beaglebone as in the meta-ti layers conf and ti bottled out within the first 5 minutes |
| 12:35.02 | woglinde | you cannt pull the layers with bitbake |
| 12:35.14 | jackmitch | ok my mis-wording, I pulled them in with git |
| 12:35.50 | jackmitch | so I cloned openembedded-core, then in that i cloned bitbake, meta-ti and the other layers it required |
| 12:35.59 | jackmitch | sourced the oe-script so setup the buld environment |
| 12:36.04 | woglinde | did you read the readme? |
| 12:36.05 | woglinde | https://github.com/Angstrom-distribution/meta-ti |
| 12:36.13 | woglinde | This layer depends on: |
| 12:36.58 | jackmitch | yes, I pulled in all the required layers and it still failed, which I why I turned to the script |
| 12:39.32 | woglinde | yes |
| 12:41.28 | woglinde | and you run MACHINE=beaglebone ./oebb.sh bitbake virtual/kernel |
| 12:41.34 | woglinde | nor? |
| 12:43.00 | jackmitch | when I cloned the layers manually I changed the MACHINE variable to beaglebone and tried to build the systemd-image which failed, just now I used the script and it sucessfully built the kernel |
| 12:43.35 | jackmitch | so now I'll add a new SRC_URI to to the kernel .bb file which my patch and it should build |
| 12:52.04 | woglinde | exactly |
| 12:52.13 | woglinde | dont forgot to update the defconfig |
| 12:52.25 | woglinde | if you change something on the config |
| 12:52.33 | woglinde | and maybee alter the revision |
| 12:52.48 | woglinde | so you are sure you not interfere with official packages |
| 13:06.29 | *** join/#oe pespin (~pespin@cisne-cn09.upc.es) |
| 13:06.33 | *** join/#oe sterNiX (~LessIsMor@2.176.243.237) |
| 13:06.33 | *** join/#oe sterNiX (~LessIsMor@unaffiliated/nu253r/x-0655220) |
| 13:07.03 | *** join/#oe bluelightning (~paul@83.217.123.106) |
| 13:07.03 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 13:08.54 | bluelightning | Noor: did you figure it out? |
| 13:09.08 | Noor | bluelightning: yeah |
| 13:09.21 | Noor | sstate is doign the trick |
| 13:10.08 | Noor | bluelightning: it happend by seeting SSTATETASKS += "do_deploy" do_deploy[sstate-name] = "deploy" do_deploy[sstate-inputdirs] = "${DEPLOYDIR}" do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}" in deply.bbclass |
| 13:10.42 | bluelightning | I thought that was just telling sstate to monitor that directory for files... |
| 13:11.16 | Noor | if we remove these lines files are not outputed to deploy/images folder |
| 13:12.19 | Noor | bluelightning: i set do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}" with do_deploy[sstate-outputdirs] = ~/ttteee and images where created in ~/tttee when do_deploy function was executed |
| 13:12.29 | Noor | sstate is still mistry for me :D |
| 13:12.30 | bluelightning | ah ok, interesting |
| 13:12.36 | Noor | need to get hold of it |
| 13:13.12 | Noor | and it pick the images from do_deploy[sstate-inputdirs] = "${DEPLOYDIR}" |
| 13:19.50 | mertsas | I'm trying to make a rootfs image, right now only with twt, and I'm trying to get glxgears to run as a demo. I have task-xserver, xf86-video-omapfb, mesa-demos, xterm, twt and xinit added to IMAGE_INSTALL, but when I try to do glxinfo I get: Error: couldn't find RGB GLX visual or fbconfig. Any idea why this is? |
| 13:21.49 | *** join/#oe pespin (~pespin@cisne-cn08.upc.es) |
| 13:30.51 | mertsas | yeah, seems like I just had to add mesa-xlib instead of mesa-dri |
| 13:39.16 | *** join/#oe sterNiX (~LessIsMor@2.176.243.237) |
| 13:39.16 | *** join/#oe sterNiX (~LessIsMor@unaffiliated/nu253r/x-0655220) |
| 13:50.46 | *** join/#oe kgilmer (~kgilmer@p3179-ipad13yosemiya.okinawa.ocn.ne.jp) |
| 14:21.28 | *** join/#oe Marex (vasum7am@u-pl13.ms.mff.cuni.cz) |
| 14:28.29 | *** join/#oe kgilmer (~kgilmer@p3179-ipad13yosemiya.okinawa.ocn.ne.jp) |
| 14:33.29 | *** join/#oe galak (~galak@nat/ti/x-ypmpqyeaeajaxond) |
| 14:35.10 | *** join/#oe Tartarus (trini@pixelshelf.com) |
| 14:47.35 | *** join/#oe dijenerate (~dijenerat@173.225.251.175) |
| 14:51.27 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
| 14:57.04 | *** join/#oe War2 (~war2@unaffiliated/war2) |
| 15:09.37 | *** join/#oe pepermint (~pepermint@host239-84-dynamic.4-87-r.retail.telecomitalia.it) |
| 15:12.31 | *** join/#oe pespin (~pespin@cisne-cn07.upc.es) |
| 15:17.56 | kergoth | Noor, bluelightning: the deploy tasks outputs to DEPLOYDIR. without those flags, it won't take the DEPLOYDIR files and send them to DEPLOY_DIR_IMAGE |
| 15:18.30 | Noor | kergoth: yeah thats what I figure it out |
| 15:18.45 | kergoth | nods |
| 15:19.02 | Noor | in classic it was much simpler :) |
| 15:19.36 | kergoth | in classic the cached binaries implementation was recipe wide, not task level |
| 15:19.39 | kergoth | which is part of it |
| 15:22.06 | Noor | really needs to understand the sstate code and how sstate is being saved |
| 15:22.10 | Noor | yeah |
| 15:23.25 | Noor | kergoth that means if you add your own task then you need to tell sstate to add it |
| 15:24.17 | kergoth | if you want to use sstate with it, yes. that's not always the case. for example, for the source archival stuff, we'll likely want to exclude it from sstate entirely if we can, as it doesn't make sense to re-archive DL_DIR files into more archives :) |
| 15:26.35 | Noor | hhhhmmmm |
| 15:27.09 | Noor | but if we have to add it in sstate we need to do some more work or it will be automatically added ... that was my question |
| 15:28.33 | kergoth | I'm not sure what you mean by automatically added. To a certain extent it depends on where the task fits into the task graph, since afaik sstate assumes that tasks that an sstate task depends upon have been satisfied once that sstate is used |
| 15:28.37 | *** join/#oe dijenerate (~dijenerat@173.225.251.175) |
| 15:29.44 | Noor | hhhmmm |
| 15:34.59 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
| 16:02.04 | *** part/#oe Zagor (~bjst@rockbox/developer/Zagor) |
| 16:05.22 | *** join/#oe hollisb (~hollisb@c-67-169-221-181.hsd1.or.comcast.net) |
| 16:23.24 | *** join/#oe darknighte (~darknight@pdpc/supporter/professional/darknighte) |
| 16:26.49 | *** join/#oe msm (~msm@gate-tx3.freescale.com) |
| 16:27.09 | msm | khem: ping |
| 16:40.40 | *** join/#oe Mazingaro (~Tetsuja@78.7.236.30) |
| 16:40.43 | Mazingaro | hi |
| 16:41.04 | Mazingaro | please I need suggestions for a simple https server for cortex-m3 + gcc :) tx |
| 16:45.05 | woglinde | Mazingaro you could try http://www.fefe.de/gatling/ |
| 16:45.30 | Mazingaro | thanks |
| 16:45.49 | woglinde | or http://www.cherokee-project.com/doc/cookbook_https_accelerator.html |
| 16:45.56 | woglinde | and update the cherokee recpie |
| 16:45.58 | woglinde | ;) |
| 16:46.19 | Mazingaro | I'm running on a baremetal system, no os on it |
| 16:52.47 | *** join/#oe rob_w (~bob@host-188-174-219-117.customer.m-online.net) |
| 16:52.47 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 16:59.11 | khem | msm: pong |
| 17:00.47 | *** join/#oe pvanhoof (~pvanhoof@d54C148A9.access.telenet.be) |
| 17:03.37 | msm | khem: can you give me a few bits of detail on the gcc version strategy |
| 17:03.45 | msm | my gcc appears to report as 4.6.3 |
| 17:04.00 | msm | then, the subversion revision we are using does not align with upstream 4.6.2 release |
| 17:04.07 | msm | and 4.6.3 is unreleased at this point? |
| 17:04.48 | khem | msm: yes dont be encumbered with release numbers |
| 17:05.10 | khem | FWIW gcc only major releases matter |
| 17:05.19 | msm | khem: OK |
| 17:05.22 | khem | .x.x.x releases are bug fix releases |
| 17:05.32 | khem | so basically no new features nothing |
| 17:05.33 | msm | im just trying to get internal patches posted upstream |
| 17:05.41 | msm | and i want to make sure they should apply or if things are appropriate |
| 17:05.42 | khem | 4.6.2 is 4.6.1+bug fixes |
| 17:06.05 | msm | i just noticed powerpc-gcc -v reports 4.6.3 as well? |
| 17:06.20 | khem | yes once 4.6.2 is released that version bumps |
| 17:06.49 | khem | so we are not top of 4.6 branch but we are some patches behing |
| 17:06.54 | msm | khem: OK - that's sort of confusing for end users sometimes (esp. ones that want to know exactly which gcc version) |
| 17:06.56 | khem | we track the branch not the releases |
| 17:07.08 | msm | khem: makes sense from the oe-core side |
| 17:07.20 | msm | ill have to explain this properly... |
| 17:07.36 | khem | I think the nature of packages matter |
| 17:07.49 | khem | some packages change features between minor releases |
| 17:07.52 | khem | but gcc does not |
| 17:08.09 | msm | khem: ok - so i want to submit internal toolchain patches (ones that might never be really accepted upstream) |
| 17:08.14 | msm | khem: just for powerpc32/64 though |
| 17:08.15 | khem | Its easy to maintain if we track the branch |
| 17:08.29 | msm | and these are tested internally to some degree |
| 17:08.37 | khem | ok |
| 17:08.40 | msm | so - is there any caveat with doing something like that? |
| 17:08.43 | khem | here is testing reference |
| 17:09.02 | khem | http://sakrah.dontexist.org/files/gcc-tests/ |
| 17:09.24 | khem | so if your tests dont regress they should be fine |
| 17:09.28 | khem | err patches |
| 17:09.56 | khem | from lame user pov you should mention we are at 4.6.2+patches state |
| 17:10.03 | khem | who care about numbers |
| 17:10.10 | *** join/#oe rickfoosusa (~chatzilla@cpe-72-177-7-236.austin.res.rr.com) |
| 17:10.15 | khem | since its really like that |
| 17:10.47 | khem | where we get the cumulative patches from svn instead of adding them individually to SRC_URI |
| 17:10.50 | khem | makes sense ? |
| 17:11.02 | msm | khem: yep - you answered everything |
| 17:11.20 | msm | khem: getting gcc to say 4.6.2+ instead of 4.6.3 might be nice - but not something im doing to try to change =) |
| 17:13.17 | khem | yes I thought about that. |
| 17:13.31 | khem | since it needed a living patch I slacked |
| 17:13.53 | khem | but if it makes air cleaner I can think of it |
| 17:14.25 | khem | but only after 4.6.3 is released since I dont want to go back in order |
| 17:14.59 | khem | gcc names some dirs with that number in installation dir |
| 17:19.33 | *** join/#oe rickfoosusa (~chatzilla@cpe-72-177-7-236.austin.res.rr.com) |
| 17:24.35 | msm | khem: right, i saw that… it would'nt be fun - and little benefit |
| 17:27.52 | *** join/#oe morphis (~morphis@dslb-088-071-253-071.pools.arcor-ip.net) |
| 17:40.19 | *** join/#oe pespin (~pespin@90.163.51.170) |
| 17:52.49 | *** join/#oe playya_ (~playya@unaffiliated/playya) |
| 17:58.35 | icanicant | Has anyone experienced problems with 'reboot' command and systemd? I can only reboot using 'reboot -f' at the moment. |
| 18:00.28 | *** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy) |
| 18:00.40 | mr_science | ahoy |
| 18:03.09 | mr_science | ERROR: QA Issue with gkrellm: Architecture did not match |
| 18:03.30 | mr_science | is there a work-around for this? |
| 18:04.22 | mr_science | it builds fine, but then errors out in do_package |
| 18:05.02 | bluelightning | mr_science: sounds like executables being compiled for the host instead of the target maybe? |
| 18:06.08 | *** join/#oe devzero_ (devzero@xdsl-89-0-82-169.netcologne.de) |
| 18:08.13 | mr_science | yeah, but why? |
| 18:08.52 | mr_science | pretty much everything else built fine |
| 18:09.00 | mr_science | more or less... |
| 18:11.23 | mr_science | i'll try it from a clean tmp and see what happens, but other than that I got nothin' |
| 18:13.17 | bluelightning | why? hard to say without looking at the way gkrellm builds itself |
| 18:14.03 | *** join/#oe florian (~fuchs@sign-4db6aade.pool.mediaWays.net) |
| 18:14.04 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 18:30.53 | mr_science | bluelightning, mostly because the ordering of build images/provides seems to trigger different dependency resolution |
| 18:31.53 | mr_science | for example, if i go straight for our TI image build from a clean tmp, python-native will fail |
| 18:32.20 | mr_science | and then it builds fine if i run the same command again |
| 18:32.53 | mr_science | wheras if i build the rescue-image first (a very minimal image) then python-native doesn't fail |
| 18:36.08 | bluelightning | mr_science: so there's a missing dependency somewhere |
| 18:36.13 | bluelightning | mr_science: what's the failure? |
| 18:37.31 | *** join/#oe eFfeM (~frans@a2038.upc-a.chello.nl) |
| 18:47.00 | *** join/#oe tasslehoff (~tasslehof@145.79-161-31.customer.lyse.net) |
| 19:07.11 | *** join/#oe likewise (~likewise@095-097-098-131.static.chello.nl) |
| 19:09.16 | *** join/#oe GNUtoo|laptop (~gnutoo@host29-81-dynamic.48-82-r.retail.telecomitalia.it) |
| 19:10.14 | *** join/#oe Heinervdm (~thomas@p5B0F4BE0.dip.t-dialin.net) |
| 19:15.28 | *** join/#oe risca (~risca@wi-secure-8039.cc.umanitoba.ca) |
| 19:27.43 | *** join/#oe rah (rah@myrtle.6gnip.net) |
| 19:28.39 | *** join/#oe likewise (~likewise@116-66-ftth.onsneteindhoven.nl) |
| 19:37.34 | *** join/#oe rcf (~rcf@215.229-243-81.adsl-dyn.isp.belgacom.be) |
| 19:38.05 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 19:38.31 | *** join/#oe CMoH (~cipi@95.76.68.223) |
| 19:38.32 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 19:45.09 | mr_science | bluelightning, i'll have to run that one again, but i just built gkrellm with our previous TI build version and it built fine |
| 19:45.36 | mr_science | also on a different build host tho... |
| 19:47.58 | *** join/#oe icanicant (~icanicant@dsl-217-155-248-78.zen.co.uk) |
| 19:51.13 | *** join/#oe drw (~dwilliams@cpe-24-242-197-126.tx.res.rr.com) |
| 19:59.49 | *** join/#oe risca (~risca@wi-secure-8039.cc.umanitoba.ca) |
| 20:00.52 | *** join/#oe mrmoku` (~mrmoku@ppp-188-174-118-164.dynamic.mnet-online.de) |
| 20:10.45 | *** join/#oe anarsoul (~anarsoul@80.249.90.230) |
| 20:23.29 | *** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net) |
| 20:28.42 | *** join/#oe woglinde (~heinold@g225164118.adsl.alicedsl.de) |
| 20:34.47 | *** join/#oe awozniak (~awozniak@74.82.132.35) |
| 20:35.48 | *** join/#oe pepermint (~pepermint@host239-84-dynamic.4-87-r.retail.telecomitalia.it) |
| 20:37.44 | *** join/#oe jkridner (~jason@pdpc/supporter/active/jkridner) |
| 20:42.24 | tzanger | hm |
| 20:44.10 | tzanger | in recipes, are DEPS build time or run time dependencies? I'm trying to get package P to enable support for feature F, and dependency D enables that. I have D listed as a dependency, but when package P goes to configure itself it says it can't find D and therefore won't include feature F. |
| 20:44.27 | *** join/#oe cminyard (~cminyard@pool-173-57-157-96.dllstx.fios.verizon.net) |
| 20:56.52 | *** join/#oe bluelightning (~paul@cpc2-lewi17-2-0-cust101.2-4.cable.virginmedia.com) |
| 20:56.53 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 20:59.19 | *** join/#oe anarsoul_ (~anarsoul@212.98.178.206) |
| 21:08.49 | *** join/#oe sakoman (~sakoman@static-74-41-60-154.dsl1.pco.ca.frontiernet.net) |
| 21:24.48 | *** join/#oe maccarro (~maccarro@71-212-64-14.tukw.qwest.net) |
| 21:27.53 | *** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net) |
| 21:29.29 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
| 21:32.18 | mr_science | tzanger, the only thing i can think of is the STAGING_LIBS thing, but it also seems like you shouldn't have to do that... |
| 21:32.57 | woglinde | you RDEPENDS |
| 21:33.10 | woglinde | DEPENDS are for building RDEPENDS are for runtimes |
| 21:35.10 | tzanger | woglinde: hm, that is what I thought... ok. DEPENDS = "D" is there. does rm_work screw things up if it is in D's recipe? |
| 21:35.48 | woglinde | ? |
| 21:36.02 | woglinde | rm_works deletes the unpackaged source dir |
| 21:36.13 | woglinde | and the tmp packages building dirs |
| 21:53.27 | *** join/#oe ant__ (~andrea@host74-51-dynamic.5-87-r.retail.telecomitalia.it) |
| 21:53.58 | tzanger | strange. the only thing I can think of is that the dependency doesn't have the .h file in FILES_${PN} and it's not sticking around for the package that needs to see it |
| 21:54.19 | tzanger | this is for asterisk and libpri, don't mean to act mysterious, just trying ot state the problem plainly |
| 21:54.38 | khem | tzanger: most probably the files are not packaged correctly |
| 21:54.52 | khem | what do you have in packages-split/ |
| 21:55.55 | khem | asterisk DEPENDS on libpri right ? |
| 21:56.17 | tzanger | khem: yes, asterisk DEPENDS contains libpri (and openssl and a bunch of other things that are getting found correctly) |
| 21:56.29 | tzanger | forgive me... what is packages-split/? |
| 21:56.32 | khem | so which one is missing ? |
| 21:56.43 | woglinde | tzanger you working on meta-telephony? |
| 21:56.57 | tzanger | woglinde: no, that's not me |
| 21:57.05 | tzanger | khem: libpri doesn't get found |
| 21:57.11 | khem | ok. |
| 21:57.36 | woglinde | tzanger than not double the work |
| 22:00.05 | woglinde | hm I asked zecke where he put meta-telephony |
| 22:00.35 | *** join/#oe galak (~galak@nat/ti/x-ptrdinyqqssbtsbe) |
| 22:04.35 | *** join/#oe hillct (~hillct@cpe-174-109-206-062.nc.res.rr.com) |
| 22:05.12 | woglinde | tzanger -> https://gitorious.org/sysmocom-openembedded/meta-telephony/commits/master |
| 22:11.38 | tzanger | woglinde: checking it out, thank you |
| 22:11.59 | khem | woglinde: gitorious does not work well with bitbake in non interactive mode |
| 22:12.01 | tzanger | although I think I may have found the issue... depending on libpri-dev instead of libpri, since the .h is there |
| 22:12.13 | khem | It was a pain to get efikamx kernel |
| 22:12.36 | woglinde | khem I wonder why you need bitbake |
| 22:12.39 | woglinde | just use git |
| 22:12.48 | khem | tzanger: well if you have libpri in DEPENDS then libpri-dev will get staged automatically |
| 22:12.55 | khem | in which case it should have found the header |
| 22:13.13 | khem | woglinde: since I dont have buttbake :) |
| 22:15.56 | *** join/#oe hillct (~hillct@cpe-174-109-206-062.nc.res.rr.com) |
| 22:19.11 | tzanger | khem: hmm ok |
| 22:23.52 | *** join/#oe hillct_ (~hillct@cpe-174-109-206-062.nc.res.rr.com) |
| 22:24.43 | bluelightning | kenws: http://video.linux.com/categories/2012-embedded-linux-conference |
| 22:25.59 | Crofton|work | bluelightning, ping |
| 22:26.05 | bluelightning | hi Crofton|work |
| 22:26.18 | Crofton|work | hey, I am getting my oe-core build up again |
| 22:26.26 | bluelightning | ah, great :) |
| 22:26.29 | Crofton|work | are your qt patches somewhere I can pull them? |
| 22:26.30 | tzanger | I should be able to see the header files in the staging dir shouldn't I? |
| 22:26.56 | bluelightning | Crofton|work: sure, one sec |
| 22:27.34 | bluelightning | Crofton|work: http://cgit.openembedded.org/openembedded-core-contrib/log/?h=paule/qmake-target |
| 22:27.47 | bluelightning | Crofton|work: you'll probably want to rebase on top of current master though |
| 22:27.58 | *** join/#oe hillct_ (~hillct@cpe-174-109-206-062.nc.res.rr.com) |
| 22:28.09 | Crofton|work | yeah |
| 22:31.55 | bluelightning | khem: watching your talk now btw :) |
| 22:32.58 | khem | bluelightning: it was second last talk and immediately after lunch. not best time to grab attention |
| 22:33.26 | bluelightning | khem: seems pretty good so far :) you mentioned a few small things about OE-classic I left out |
| 22:33.45 | bluelightning | actually I don't think I spent a lot of time talking about classic |
| 22:34.05 | khem | bluelightning: yeah we have to get people past the hump :) |
| 22:34.21 | khem | bluelightning: one thing that people did point out is documentation |
| 22:34.28 | khem | which is not helping so much in migration |
| 22:34.34 | bluelightning | yeah :/ |
| 22:34.49 | bluelightning | maybe I will get time to do another piece this week |
| 22:36.39 | khem | yes. I plan to go through wiki myself as well. |
| 22:37.01 | khem | only once I go past through these horrendous reviews at work |
| 22:43.08 | tzanger | ahh, for some reason libpri is being built for x86-64 (the host) instead of teh target |
| 22:43.28 | woglinde | good nite |
| 22:48.28 | *** join/#oe CcSsNET (~user@c-24-147-194-80.hsd1.ma.comcast.net) |
| 22:52.52 | khem | tzanger: are you using oe.classic ? |
| 22:53.03 | *** join/#oe pespin (~pespin@90.163.51.170) |
| 22:53.26 | khem | tzanger: I think the host one should be libpri-native which should be coming from another dependency |
| 22:53.42 | tzanger | I have no idea if it's classic or new coke. it's just a standard angstrom build that we've been slwoly adding to |
| 22:57.49 | tzanger | I think we had a problem like this in another library |
| 22:58.35 | tzanger | had to add TARGET_CC_ARCH += " ${LDFLAGS} " |
| 22:59.34 | khem | why is that a problem |
| 23:00.08 | tzanger | it's not, I just dont' understand why I had to add it |
| 23:00.15 | tzanger | is it something configure automatically does? |
| 23:00.20 | khem | no |
| 23:00.49 | khem | it just adds the hash related flags that this packages build system does not respect otherwise through normal LDFLAGS settings |
| 23:01.22 | ant__ | otavio: any progress wrt udev unification? |
| 23:07.59 | *** join/#oe hollisb (~hollisb@c-67-169-221-181.hsd1.or.comcast.net) |
| 23:16.07 | *** join/#oe risca (~risca@wi-secure-8039.cc.umanitoba.ca) |
| 23:17.36 | *** join/#oe kgilmer (~kgilmer@p3158-ipad06yosemiya.okinawa.ocn.ne.jp) |
| 23:17.57 | *** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
| 23:45.11 | *** join/#oe OsmanB (~kadir@46.2.3.30) |
| 23:45.12 | otavio | ant__: partially |
| 23:45.19 | otavio | ant__: want to try it? |
| 23:45.51 | ant__ | to be honest is because I'd like to get rid of one .bbappend to udev in meta-oe |
| 23:49.50 | *** join/#oe RushPL_ (~quassel@89-69-171-30.dynamic.chello.pl) |
| 23:51.13 | *** join/#oe valhalla_ (~valhalla@81-174-23-102.dynamic.ngi.it) |
| 23:52.10 | *** join/#oe kgilmer (~kgilmer@p3158-ipad06yosemiya.okinawa.ocn.ne.jp) |
| 23:53.28 | *** join/#oe msm2 (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net) |
| 23:53.36 | *** join/#oe jevin (~jevin@napalm.jevinskie.com) |
| 23:53.46 | *** join/#oe CIA-134 (~CIA@cia.atheme.org) |
| 23:54.34 | *** join/#oe toobluesc (~nitro@cpe-76-183-52-98.tx.res.rr.com) |
| 23:56.17 | *** join/#oe mr_science (~sarnold@net-cf9a4e91.cst.impulse.net) |
| 23:56.17 | *** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy) |
| 23:59.12 | *** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net) |