00:00.29 | *** join/#oe igeiser (~igeiser@pool-71-162-255-190.phlapa.fios.verizon.net) |
00:34.19 | *** join/#oe msm (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net) |
00:42.03 | *** join/#oe nitink (~nitink@134.134.139.76) |
01:01.43 | *** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net) |
01:36.43 | *** join/#oe risca (~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net) |
02:06.18 | *** join/#oe devzero_ (devzero@xdsl-78-35-53-231.netcologne.de) |
02:08.19 | *** join/#oe rsalveti (~rsalveti@177.99.132.224) |
02:08.20 | *** join/#oe rsalveti (~rsalveti@linaro/rsalveti) |
02:18.54 | *** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
02:57.18 | *** join/#oe JaMa (~martin@94.230.152.246) |
02:58.33 | *** join/#oe silviof1 (~silviof@ppp-93-104-165-130.dynamic.mnet-online.de) |
03:05.30 | *** join/#oe blupp (~blupp@dslb-188-099-251-231.pools.arcor-ip.net) |
03:10.03 | *** join/#oe pwgen_8 (~ew@daimi-pat.daimi.au.dk) |
03:34.46 | *** join/#oe notespace3 (~notespace@barracuda.ventureresearch.com) |
04:14.19 | *** join/#oe ensc_ (~irc-ensc@p54ADDAD5.dip.t-dialin.net) |
04:23.49 | *** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net) |
04:44.28 | *** join/#oe cheng (~cheng@115.133.208.164) |
04:58.32 | cheng | can i use opnembedded to build a cross native compiler on my dm8168 arm board? |
05:20.08 | *** join/#oe snkt (~snkt@122.170.104.85) |
05:22.42 | *** join/#oe erwt (~erwt@122.170.104.85) |
05:23.09 | *** join/#oe cheng (~cheng@115.133.208.164) |
05:23.41 | *** join/#oe garble (~thomas@2001:420:4:eb65:e291:f5ff:fe94:3e86) |
05:35.57 | *** join/#oe _tasslehoff_ (~Tasslehof@84.49.231.147) |
05:38.32 | *** join/#oe jkridner (~jason@pdpc/supporter/active/jkridner) |
05:43.46 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
05:53.06 | *** join/#oe rsalveti (~rsalveti@177.99.132.224) |
05:53.10 | *** join/#oe rsalveti (~rsalveti@linaro/rsalveti) |
06:07.45 | *** join/#oe mertsas (~martin@nat/cisco/x-hjdwvfuzjbezwtat) |
06:10.16 | *** join/#oe silviof1 (~silviof@host-188-174-185-49.customer.m-online.net) |
06:10.17 | _tasslehoff_ | Function failed: Fetcher failure for URL: 'file://var-run.conf'. Unable to fetch URL from any source <- this from base-files_3.0.14.bb, that hasn't changed since january and doesn't mention a var-run.conf. |
06:10.32 | _tasslehoff_ | is confused |
06:12.48 | JaMa | maybe some .bbappend does |
06:13.20 | *** join/#oe rob_w (~bob@93.104.205.194) |
06:13.20 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
06:17.11 | *** join/#oe Zagor (~bjst@46.35.227.87.static.tab.siw.siwnet.net) |
06:17.12 | *** join/#oe Zagor (~bjst@rockbox/developer/Zagor) |
06:20.35 | mckoan | good morning |
06:21.33 | _tasslehoff_ | is unconfused, but a bit ashamed :) |
06:22.33 | *** join/#oe erwt (~erwt@122.170.104.85) |
06:22.50 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
06:23.25 | *** join/#oe clio (~andrej@85.159.109.222) |
06:26.22 | *** join/#oe vitus (~vitus@145.253.169.210) |
06:31.22 | eFfeM_work | hm, meta-oe head does not work with yocto 1.2 :-( |
06:31.46 | JaMa | use meta-oe/denzil |
06:33.02 | *** join/#oe snkt (~snkt@122.170.104.85) |
06:33.07 | _tasslehoff_ | a case of two .bbappends setting FILESEXTRAPATHS := |
06:35.06 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
06:39.35 | eFfeM_work | JaMa: ah, thanks |
06:40.38 | eFfeM_work | btw anyone knows if there is a (non-classic) recipe for fastcgi ? does not seem to be in yocto 1.2 or meta-oe |
07:07.58 | *** join/#oe lamikr (lamikr@nat/nokia/x-yhptrvbomtlihsyj) |
07:08.11 | *** join/#oe garble (~thomas@2001:420:4:eb65:b93c:7d29:9b2e:c807) |
07:14.23 | *** join/#oe clio (~andrej@85.159.109.222) |
07:21.29 | *** join/#oe florian (~fuchs@port-217-146-132-69.static.qsc.de) |
07:21.31 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
07:30.22 | *** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it) |
07:36.41 | *** join/#oe rschus (~rschus@fb-n15-11.unbelievable-machine.net) |
07:37.14 | *** join/#oe lamikr (lamikr@nat/nokia/x-hidqilukkjuutbhz) |
07:40.04 | *** join/#oe morphis (~morphis@dslb-088-070-132-153.pools.arcor-ip.net) |
07:59.50 | _tasslehoff_ | if more than one .bbappend supply a file, how do I control which one is chosen? |
08:00.22 | _tasslehoff_ | does the order of paths in FILESEXTRAPATHS matter? |
08:00.48 | JaMa | yes it does |
08:22.51 | *** join/#oe rschus1 (~rschus@fb-n15-11.unbelievable-machine.net) |
08:26.08 | *** join/#oe ensc|w (~ensc@www.sigma-chemnitz.de) |
08:26.37 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
08:31.50 | *** join/#oe bluelightning (~paul@83.217.123.106) |
08:31.50 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
08:32.40 | *** join/#oe ericbutters (~kuhne@business-213-023-195-122.static.arcor-ip.net) |
08:33.32 | ericbutters | hi.. i did "bitbake -f firefox" and then i want to rebuild my images, so i call "bitbake" but i get: ERROR: Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information. |
08:37.42 | ericbutters | ah i need to run "bitbake myimage" .. |
08:38.12 | ericbutters | tz.. holidays ;) |
08:38.55 | *** join/#oe clio (~andrej@85.159.109.222) |
08:39.45 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
08:44.13 | bluelightning | morning all |
08:44.39 | kenws | good morning |
08:45.50 | ericbutters | anyone used fullscreen extension for firefox? |
08:46.27 | *** join/#oe morphis (~morphis@dslb-088-070-132-153.pools.arcor-ip.net) |
09:01.26 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
09:50.43 | *** join/#oe _tasslehoff_ (~Tasslehof@84.49.231.147) |
09:56.08 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
10:00.38 | *** join/#oe pepermint (~pepermint@host64-201-dynamic.10-188-r.retail.telecomitalia.it) |
10:12.06 | pb_ | hi all |
10:26.12 | florian | hi pb_ |
10:27.25 | mckoan | hi pb_, florian, all |
10:27.59 | florian | hi mckoan |
10:55.41 | *** join/#oe mickey_office (~mickey@e182221015.adsl.alicedsl.de) |
10:57.40 | *** join/#oe lamikr (lamikr@nat/nokia/x-pvuqryobashvtjac) |
11:20.12 | *** join/#oe pretec (~Matthias@port-92-195-19-28.dynamic.qsc.de) |
11:22.10 | pb_ | so, koen rejoins the tsc. that's a bit of a shame. |
11:23.32 | JaMa | why? |
11:25.35 | *** join/#oe dijenerate (~dijenerat@173.225.251.175) |
11:42.21 | florian | hum well... |
11:42.40 | florian | JaMa: he is not good for PR |
11:43.10 | XorA | PR is the boards job :-D |
11:43.41 | florian | well true, but the tsc acts in the public as well, controls resources etc. |
11:44.17 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
11:45.10 | *** join/#oe SlashV (~SlashV@ip176-146-172-82.adsl2.static.versatel.nl) |
11:50.47 | ynezz | hm, some of us didn't even noticed, that he has quit the tsc :p |
11:58.45 | JaMa | florian: but he is very good for patches right? so from my POV it's better to have good devs then good PR |
11:58.56 | *** join/#oe dv_ (~quassel@chello080108009040.14.11.vie.surfer.at) |
12:04.51 | pb_ | well, one can send patches without being on the TSC. |
13:11.54 | *** join/#oe ibot (~ibot@rikers.org) |
13:11.54 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel |
13:12.26 | *** join/#oe challinan (~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
13:17.19 | broonie | finds himself re-adding stuff that was already present in oe-classic to try to boostrap mea-oe. |
13:17.22 | broonie | meta-oe |
13:17.35 | broonie | On the bright side, there's a little bit more documentation than there is for angstrom |
13:26.35 | *** part/#oe tasslehoff (~Tasslehof@147.84-49-231.nextgentel.com) |
13:39.26 | *** join/#oe cheng (~cheng@175.140.179.93) |
13:40.22 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
13:59.47 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
14:03.12 | *** join/#oe bitkiller (~bitkiller@189.58.123.195.dynamic.adsl.gvt.net.br) |
14:04.36 | *** join/#oe devzero_ (devzero@xdsl-89-0-77-40.netcologne.de) |
14:08.52 | *** join/#oe hollisb (~hollisb@c-67-169-221-181.hsd1.or.comcast.net) |
14:10.23 | *** join/#oe hollisb_ (~hollisb@c-67-169-221-181.hsd1.or.comcast.net) |
14:44.33 | *** join/#oe eFfeM (~frans@a2038.upc-a.chello.nl) |
14:57.13 | *** join/#oe fray (U2FsdGVkX1@gate.crashing.org) |
15:01.18 | *** part/#oe Zagor (~bjst@rockbox/developer/Zagor) |
15:07.02 | *** join/#oe nitink (nitink@nat/intel/x-hjxrimdxohsxswdq) |
15:19.34 | *** join/#oe jmpdelos (~polk@delos.delos.com) |
15:20.41 | *** join/#oe kristoffer (~kristoffe@c-c3dde555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
15:24.47 | *** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
15:28.48 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
15:31.16 | ensc|w | is there a clean way (except going manually into the source cache dir and pruning files there) how the downloaded files from SRC_URI can be removed? E.g. I have trouble with tcf-agent whose license text has been changed recently and the old file is lingering around at a lot of installations. |
15:32.32 | JaMa | something like -c cleanall? |
15:33.29 | JaMa | or you need to do it automatically with each "upgrade" build? |
15:34.50 | ensc|w | JaMa: thx, cleanall seems to be enough |
15:35.40 | kergoth | that reminds me, we really need to get file:// files from SRC_URI added to the appropriate checksums. otherwise you're forced to manually cleansstate when changing them. worse yet, if using SSTATE_MIRRORS, there's no way to tell it not to re-fetch the shared state archive |
15:38.28 | JaMa | kergoth: are checksums of e.g. http:// files now part of sstate hash? |
15:38.47 | kergoth | no idea |
15:39.01 | kergoth | i doubt it, though, but that would be good too |
15:39.22 | kergoth | we've talked about this before, its just i happened to get bitten by it while hacking on external-csl-toolchain the other day (modified SUPPORTED) |
15:39.26 | kergoth | heh |
15:39.51 | JaMa | yup especially with PRSERV stuff (if it will end manuall PR bumps) |
15:40.18 | kergoth | good point |
15:40.28 | kergoth | hmm, would think it wouldn't be hard to do, actually.. |
15:40.43 | *** join/#oe zenlinux_ (~sgarman@12.70.159.234) |
15:41.12 | kergoth | add a ConfigParsed handler to checksum file:// files and store those in a variable or variables, add that to SRC_URI vardeps, and similarly suck in the various SRC_URI md5sum/shasum flags |
15:41.22 | kergoth | hm |
15:41.38 | JaMa | probably good to add it soon in release cycle as it will invalidate whole sstate cache :) |
15:41.56 | kergoth | 'll try doing a quick prototype and see how it behaves |
15:59.12 | *** join/#oe W1N9Zr0 (~W1N9Zr0@24-212-193-98.cable.teksavvy.com) |
16:04.04 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
16:28.13 | *** join/#oe pespin (~pespin@172.pool85-50-83.dynamic.orange.es) |
16:36.14 | kenws | is looking at the 64bithack.patch that gets applied to the GCC and wonders why --disable-multilib isn't used instead |
16:38.11 | *** join/#oe Ironnads (~Ironnads@host109-152-218-189.range109-152.btcentralplus.com) |
16:38.34 | kenws | The patch seems strange. In case someone would enable multilib the locations for the m32 and m64 libs would be the same |
16:38.47 | kenws | khem: RP: Any hints? : ) |
16:40.01 | fray | I've had a request from a customer of mine.. they would like -more- verbose bitbake information from the build.. basically when a task finishes, they'd like the contents of log file printed to the screen.. |
16:40.05 | fray | (even better if it was live) |
16:40.21 | fray | is there any way to do this, or would this be a custom UI? If it's a custom UI, any pointers to how to do this work? |
16:40.55 | kenws | fray: what about the -v switch to bitbake? |
16:41.25 | bluelightning | fray: I'm having a hard time imagining that being usable with multiple threads running, but I'm sure it would be possible... |
16:41.26 | denisATeukrea | indeed or -DDD |
16:41.42 | fray | -DDD isn't it.. |
16:41.46 | denisATeukrea | ok |
16:41.53 | fray | they don't want more spew from bitbake.. they want the logs of the build in context |
16:42.00 | denisATeukrea | ah ok |
16:42.41 | fray | bluelightning I don't disagree.. the use-case specifically is "I want to do bitbake -c compile rpm" and I want the logs printed to the screen so I can immediate see what worked or didn't and inspect them.. they don't want to have to go digging through the tmp.../work/... directory structure to find the right files.. |
16:42.53 | fray | this also allows them to see an overall build captured in a single log file for grepping.. |
16:42.59 | fray | I'd certainly not advocate it be a default UI |
16:43.26 | fray | (I also suspect using this, you'd likely turn off parallel bitbake tasks.. but it could still be useful w/o it) |
16:44.01 | bluelightning | OK... it kind of sounds like something that could be implemented as a command line option to the default ui |
16:44.46 | fray | that is what I was thinking.. but I don't have any experience with the UI to be able to do that.. |
16:45.04 | fray | I'm really not sure fi they prefer "live" listing, or when the task is complete (successfull or not) it just dump the results |
16:45.09 | fray | I'm not even sure if live is a possibility |
16:47.11 | *** join/#oe hbeck (~hbeck@38.114.125.89) |
16:47.29 | fray | BTW what is the default UI? |
16:49.15 | *** join/#oe flo_lap (~fuchs@sign-4db6aa73.pool.mediaWays.net) |
16:49.15 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
16:49.47 | bluelightning | fray: knotty |
16:50.03 | fray | ok.. I think I see where the error logs are printed |
16:50.12 | *** join/#oe mr_science (~sarnold@net-cf9a4e91.cst.impulse.net) |
16:50.12 | *** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy) |
16:50.32 | fray | I see it checking bb.build.TaskFailed.. is there a TaskSucceeded? |
16:51.37 | fray | apparently there is, it's listed in the uihelper.py... |
16:53.21 | mario-goulart | Hi. Is anybody having problem with log4j1.2-native? I'm getting this error: http://paste.debian.net/167021/ |
16:54.13 | RP | fray: look at knotty.py, its straight forward to add something in there which would cat the log at task completetion |
16:54.34 | RP | fray: since its the UI that writes to the screen, the multiple process problem shouldn't be an issue in that case |
16:55.17 | RP | kenws: We build a toolchain per multilib and this was the simplest way to avoid some nasty logic figuring things out |
16:55.34 | kenws | RP: I think the reason for the 64bithack.patch is the libstdc++. With --disable-multiarch the libstdc++ would still be placed in lib64 which is not what you want. |
16:55.37 | RP | kenws: we are working on something better but its not been ready for master yet |
16:56.02 | RP | kenws: there are a variety of bad things that code can do |
16:57.01 | kenws | RP: I think deleting the MULTILIB_OSDIRNAMES MULTILIB_DIRNAMES variables from the i386/t-linux64 should also achive this |
16:57.53 | kenws | This causes the GCC to support just one flavour (m32 or m64) even if you enable multilib |
16:57.55 | RP | kenws: ultimately we're going to write out the multilib configuration into there |
16:58.57 | kenws | RP: Hm, I'm afraid I don't get it. Are you saying that you want oe to support multilib in the future? |
17:00.25 | RP | kenws: we support multilib now with a toolchain per multilib. This doesn't let us build a toolchain for use on target that will support multilib though |
17:01.07 | kenws | RP: alright, so far I'm with you |
17:01.59 | RP | kenws: if we fix the gcc configuration to match the full set of multilibs, it will work on target which is a good idea IMO |
17:02.07 | RP | kenws: sorry, I need to go :( |
17:02.40 | kenws | RP: ok, thanks so far. Maybe you could check the irc log later again |
17:04.49 | fray | bluelightning how does hob watch the task log directly in the UI? |
17:05.36 | bluelightning | fray: AFAIK it works in the same way as knotty, by listening for events |
17:06.03 | fray | yes.. but what actually watches the logs.. |
17:06.13 | fray | since they appear to be displayed live, and not on the succeeded or failed event |
17:06.31 | fray | my assumption is that something captures the event.logfile on task start.. adds it to the tree.. |
17:06.39 | fray | but I'm curious how it's being run... |
17:07.11 | bluelightning | I wasn't aware that it actually looked at the log for a task unless it failed |
17:07.35 | fray | in the UI on hob, I swear you get a tree view of all of the tasks and you can expand and watch them... live even |
17:08.07 | bluelightning | yeah, but that's just a list of what tasks have run and are running; that's solely based on the events |
17:08.22 | fray | yes.. it's the printing of hte logs part I'm wondering how it's implemented |
17:08.46 | bluelightning | if it is printing the actual logs of individual tasks that's functionality I haven't seen |
17:08.50 | fray | since I can do the same event processing in the knotty ui (or any other ui).. but I don't know how to watch a file "live" based on the events.. I do see how to do it after the task has finished though |
17:10.27 | fray | I can't run hob unfortunately, or I would run it and verify what I remember |
17:10.45 | fray | (hob complains it can't run remote due to TCP/IP netowrking for ORBit) |
17:15.13 | bluelightning | hmm, that's a bit sad |
17:18.08 | *** join/#oe zxdx (~zxdx@178.120.60.76) |
17:18.32 | fray | hey if I manually run dbus it starts to work! |
17:19.35 | bluelightning | fray: actually you're right, it does include the task output in the tree |
17:19.48 | bluelightning | fray: maybe the code is in runningbuild.py? |
17:20.28 | fray | I note that most of the ui/hob.py code seems to just be very basic... where is the majority of the implementation? |
17:21.43 | fray | Hmm the new hob doesn't see to let you see the log live, only once the task is done |
17:22.05 | fray | is hob1 still available? |
17:22.26 | bluelightning | fray: in the git history only |
17:22.28 | bluelightning | AFAIK |
17:22.40 | fray | ok.. I can back off to a prior release and double check this |
17:23.41 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
17:24.15 | fray | Hmm.. scrolling through the logs is -really- slow.. (I'm on a remote x-term.. so I don't know if that is an artifact of being remote or not) |
17:24.32 | fray | (remote over an 802.11g link) |
17:24.53 | fray | says 54Mbit/s rate.. ;) |
17:25.32 | bluelightning | ah, well latency could be the issue there |
17:25.50 | fray | I suspect gtk isn't optimizaing the scrolling.. but actually trying to display -everything- |
17:26.30 | bluelightning | X11-over-ssh performance on a local LAN with machines right next to eachother is pretty poor if you ask me, let alone wireless |
17:26.48 | fray | ya.. thats what I'm stuck with.. the amchines are in the server lab next door |
17:28.02 | bluelightning | ok I gotta run, may be back online later |
17:30.31 | *** join/#oe silviof1 (~silviof@host-188-174-181-140.customer.m-online.net) |
17:38.18 | *** join/#oe johncylee (~john@114-32-34-65.HINET-IP.hinet.net) |
17:38.39 | *** join/#oe jkridner_ (~jason@pdpc/supporter/active/jkridner) |
17:39.43 | *** join/#oe johncylee (~john@114-32-34-65.HINET-IP.hinet.net) |
17:56.24 | kenws | RP: khem: I think what the GCC folks are saying is that even if you disable multilib the libstdc++ will be placed in lib64 during the install step. Because that's where 64bit libs go for linux targets according to the FHS. If you don't like this but want to use linux as a target you have to patch the toolchain which is what 64bithack.patch attempts to do. One solution would be to have a distinctive OE target that doesn't support multilib and has 64bit libs under lib |
17:56.24 | kenws | . Another hack would be to just delete the MULTILIB_* variables from the gcc/config/i386/t-linux64. The advantage over the current 64bithack.patch would be that no one could ever build a broken multilib toolchain. Even easier, we could just this: http://paste.ubuntu.com/962860. |
17:56.31 | *** join/#oe mickeyl (~mickey@openmoko/coreteam/mickey) |
17:56.43 | mickeyl | florian: which channel? |
17:57.19 | kenws | I'm currently testing this patch against meta-linaro and it's looking good |
17:58.18 | *** join/#oe JaMa (~martin@94.230.152.246) |
18:00.07 | florian | mickeyl: #oe-board is the one we used the last time iirc |
18:01.56 | mickeyl | k |
18:21.13 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
18:21.18 | *** join/#oe jmpdelos (~polk@delos.delos.com) |
18:32.26 | *** join/#oe tasslehoff (~tasslehof@145.79-161-31.customer.lyse.net) |
18:46.35 | *** join/#oe fullstop (~quassel@64-121-54-104.c3-0.tlg-ubr1.atw-tlg.pa.cable.rcn.com) |
18:57.29 | *** join/#oe dijenerate (~dijenerat@72.51.108.124) |
19:36.13 | *** join/#oe e-ffi (~cybercom@HSI-KBW-134-3-115-142.hsi14.kabel-badenwuerttemberg.de) |
19:58.28 | *** join/#oe eFfeM1 (~frans@a2038.upc-a.chello.nl) |
19:59.00 | *** join/#oe fray (U2FsdGVkX1@gate.crashing.org) |
20:21.18 | *** join/#oe bluelightning (~paul@cpc2-lewi17-2-0-cust101.2-4.cable.virginmedia.com) |
20:21.18 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
20:28.28 | *** join/#oe dijenerate (~dijenerat@65.48.164.104) |
20:48.37 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
21:14.19 | JeremyClarkson | Hey all. I'm trying to include a custom kernel module in a custom image (based on omap3-console-image, and I'm getting an error resolving conffiles. Apparently an existing conffile (that is different from the new one) already exists. What does this mean, in general terms? (I've been googling, but I'm still confused.) Thanks in advance. |
21:21.24 | *** join/#oe risca (~risca@wi-secure-6897.cc.umanitoba.ca) |
21:26.47 | *** join/#oe ant__ (~andrea@host61-186-dynamic.60-82-r.retail.telecomitalia.it) |
21:35.44 | *** join/#oe CMoH (~cipi@95.76.68.223) |
21:35.45 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
21:46.06 | *** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net) |
22:08.45 | *** join/#oe bluelightning (~paul@cpc2-lewi17-2-0-cust101.2-4.cable.virginmedia.com) |
22:08.46 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
22:08.49 | khem | JeremyClarkson: which conffile ? |
22:09.19 | JeremyClarkson | khem: device_table |
22:15.28 | khem | hmmm are you using latest oe |
22:15.37 | khem | this issue was dealt with in angstrom |
22:15.41 | khem | iirc anyway |
22:16.04 | JeremyClarkson | I beleive i |
22:16.14 | JeremyClarkson | I believe I'm using the 2011.3 branch |
22:16.25 | khem | oh hmm |
22:19.59 | JeremyClarkson | I suspect my do_install task is bad. I tried removing it (to use the default module task, but it wouldn't build) |
22:27.35 | khem | check if there are other samples of external modules in tree |
22:27.38 | khem | and follow the steps |
22:28.16 | JeremyClarkson | ok |
22:30.21 | *** part/#oe cminyard (~cminyard@pool-173-57-151-210.dllstx.fios.verizon.net) |
22:33.37 | *** join/#oe cminyard (~cminyard@pool-173-57-151-210.dllstx.fios.verizon.net) |
22:34.41 | *** join/#oe metaxa (metaxa@members.bombshellz.net) |
22:39.00 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
23:04.45 | *** join/#oe ericben (~ebenard@pac33-2-82-240-38-71.fbx.proxad.net) |
23:22.04 | *** join/#oe bluelightning_ (~paul@cpc2-lewi17-2-0-cust101.2-4.cable.virginmedia.com) |
23:22.04 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
23:30.00 | *** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
23:51.45 | *** join/#oe Crofton (~balister@32.168.14.8) |
23:57.14 | *** join/#oe dijenerate (~dijenerat@173.225.251.175) |