| 00:02.46 | msw | kergoth: I have a python rpm2cpio if that's more desirable |
| 00:04.33 | msw | kergoth: http://cvs.specifix.com/viewcvs/viewcvs.cgi/conary/rpmhelper.py?rev=1.17&content-type=text/vnd.viewcvs-markup and http://cvs.specifix.com/viewcvs/viewcvs.cgi/conary/scripts/rpm2cpio?rev=1.5&content-type=text/vnd.viewcvs-markup |
| 00:05.03 | CosmicPenguin | That would be even better |
| 00:05.06 | kergoth | ah, cool |
| 00:05.27 | CosmicPenguin | Put it in the unpacker as a handler for .rpm files... :) |
| 00:07.00 | msw | the license on the files is CPL |
| 00:07.03 | msw | btw |
| 00:07.21 | msw | dunno what bitbake is these days |
| 00:07.33 | kergoth | the bitbake core is GPL |
| 00:07.51 | ljp | http://www.olympus-ost.com/products_R1000_sp.htm |
| 00:08.07 | kergoth | heh, there's a montavista guy in #rpm |
| 00:08.12 | kergoth | we're discussing crosscompilation approaches |
| 00:08.19 | kergoth | apparently they do something similar to our CONFIG_SITE method |
| 00:08.33 | msw | kergoth: if you wanna use it I can see about re-releasing rpmhelper.seekToData() and rpm2cpio under a different license |
| 00:08.43 | kergoth | k, i'll take a look |
| 00:08.59 | CosmicPenguin | I can see it now |
| 00:09.03 | koen | ljp: 256MB rom!?! |
| 00:09.15 | CosmicPenguin | "Montavista announces their new RPM build farm based on the Bitbake engine" |
| 00:09.29 | CosmicPenguin | And there was much rejoycing |
| 00:09.39 | CosmicPenguin | or whatever |
| 00:09.53 | Pigi | nite all |
| 00:09.55 | kergoth | hehe |
| 00:10.07 | kergoth | i'd love to use bitbake-ng to build all my packages in all my distros |
| 00:10.13 | kergoth | fuck the native package manager's build functions |
| 00:10.53 | kergoth | hehe |
| 00:11.17 | CosmicPenguin | Its been a while since I've visited spec file hell |
| 00:11.27 | CosmicPenguin | Thank God |
| 00:12.18 | *** join/#oe hufnus (~slonsiki@63.93.79.56) |
| 00:23.47 | keturn | EXTRA_OECONF_append_bash = " --disable-nls" # this did not result in --disable-nls showing up in temp/run.do_configure |
| 00:24.04 | keturn | when I added the EXTRA_OECONF_append_bash to my distro.conf |
| 00:24.31 | pb_ | it wouldn't do. "bash" is not an OVERRIDE. |
| 00:25.55 | keturn | So there's a difference between EXTRA_OECONF, and, say, PREFERRED_VERSION? |
| 00:27.59 | pb_ | yeah |
| 00:28.09 | pb_ | PREFERRED_VERSION is a magic variable that bitbake interprets directly. |
| 00:28.18 | pb_ | although its syntax looks like an override, it isn't actually. |
| 00:29.17 | pb_ | similarly with CVSDATE, which is special-cased in the fetch code. |
| 00:29.55 | pb_ | generally speaking, you can't override arbitary variables based on ${PN}. |
| 00:43.35 | *** join/#oe tomimo (~kurre@a84-231-39-238.elisa-laajakaista.fi) |
| 00:47.43 | koen | 'night all |
| 00:57.46 | *** join/#oe kurre2 (~tomimo@a84-231-39-238.elisa-laajakaista.fi) |
| 00:58.19 | *** join/#oe kurre2___ (~tomimo@a84-231-39-238.elisa-laajakaista.fi) |
| 01:00.30 | *** part/#oe kurre2___ (~tomimo@a84-231-39-238.elisa-laajakaista.fi) |
| 01:06.13 | keturn | So if I want a package compiled with different configure options, I make a seperate .bb for it? |
| 01:06.30 | kergoth | usually thats the way, yeah |
| 01:06.34 | kergoth | what package ? |
| 01:07.29 | keturn | well, bash so far. but maybe anything else I feel like stripping nls support out of if I start feeling paranoid about my weight. |
| 01:07.50 | *** join/#oe T` (~total@MY.RES.cmu.edu) |
| 01:08.17 | kergoth | keturn: eh |
| 01:08.20 | kergoth | keturn: we handle that already. |
| 01:08.30 | kergoth | any package using nls should be inheriting gettext |
| 01:08.32 | kergoth | gettext obeys USE_NLS |
| 01:08.48 | kergoth | you can set USE_NLS to "no" globally, or turn it on and off for specific packages with USE_NLS_packagename |
| 01:09.20 | kergoth | i.e. for uclibc builds, i tend to set USE_NLS = "no", and USE_NLS_glib-2.0 = "yes" (since it doesnt build without it) |
| 01:10.59 | kergoth | alright, tonight is "get that fucking bitbake-ng design spec done" night |
| 01:11.18 | kergoth | RP: you around? |
| 01:11.52 | keturn | bash_3.0.bb does not "inherit gettext" |
| 01:12.12 | kergoth | if it uses gettext (i.e. you see a libintl or 'po' directory), it should be |
| 01:12.25 | kergoth | we havent done a very good job of auditing packages to make sure they do so, to date |
| 01:15.00 | *** join/#oe scanline (~micah@dlc-stb1.colorado.edu) |
| 01:20.26 | aloph1 | clear |
| 01:24.12 | keturn | is bugs.openembedded.org coming back soon? |
| 01:27.12 | kergoth | treke-: where should i point bugs.openembedded.org at again? |
| 01:29.50 | RP | kergoth: yes |
| 01:32.21 | kergoth | RP: reread your bits in the wiki, all of it looks sane to me. Shouldn't be hard to implement. Just create a bitbake/resource.h for creating and manipulating a resource, add the ability to bind a baker or bakers (threads) to the resources, and probably some sort of inline scripting language like lua for specifying the exact thread policy |
| 01:32.26 | kergoth | opinion? |
| 01:32.59 | RP | kergoth: That's basically what I had in mind... |
| 01:33.09 | kergoth | scriptability would be -really- useful |
| 01:33.19 | kergoth | anyone creating a bitbake daemon could completely customize thread behavior |
| 01:34.02 | kergoth | want to help with the design doc? can add you to the bitbake berlios project with write access to svn |
| 01:34.07 | RP | agreed. customized thread behvaiour is very desireable |
| 01:34.14 | kergoth | (and function prototypes in the headers) |
| 01:34.31 | kergoth | once we've got the doc done and the prototypes in place, we can get to work on implementation |
| 01:34.33 | RP | formal software specification is not my strong point... |
| 01:34.39 | kergoth | me either |
| 01:34.44 | *** join/#oe treke|home (~ggilbert@69-175-32-221.ventca.adelphia.net) |
| 01:34.47 | RP | :) |
| 01:34.48 | kergoth | i just want to do this implementation correctly :) |
| 01:34.50 | kergoth | hey treke|home |
| 01:34.59 | kergoth | treke|home: where should i point bugs.openembedded.org at again? |
| 01:35.52 | keturn | how do you feel about test-driven development? |
| 01:36.02 | RP | kergoth: The one bit that needs some thought is deciding upon a task order and how to efficently plan the tasklist |
| 01:36.14 | kergoth | nod |
| 01:36.26 | kergoth | anyone know of a decent C implementation of some basic graph theory? |
| 01:36.26 | CIA-5 | 03kergoth * r117 10bitbake-ng/ (acinclude.m4 m4/internal/visibility.m4): Move BB_DEFAULT_FLAGS autoconf macro from m4/internal/visibility.m4 to acinclude.m4. |
| 01:36.32 | kergoth | might make use of something like that for our tasks |
| 01:36.48 | RP | I think applying some number of each of the tasks that aren;y blocked works but how to calculate that number remains to be seen... |
| 01:37.10 | RP | I have an implementation in my head. I need to try it on paper to see if it stacks up. |
| 01:37.23 | RP | We don't need anything comlicated - just something effective... |
| 01:37.24 | CIA-5 | 03kergoth * r118 10bitbake-ng/configure.ac: No need to run the AC_PROG_CXX and BB_CXX_HIDDEN_VISIBILITY_INLINES macros. |
| 01:38.05 | RP | It'd be nice if whatever implementation is replaceable anyway :) |
| 01:38.24 | CIA-5 | 03kergoth * r119 10bitbake-ng/doc/design_spec/design_spec.xml: Start adding notes to the design doc about the recipe implementation. Up next: description of the recipe backend, the recipe box, and the bakers. |
| 01:38.51 | CIA-5 | 03kergoth * r120 10bitbake-ng/include/ (bitbake/recipe-modules.h bitbake/recipe.h bitbake.h): Add preliminary recipe frontend and backend function prototypes. |
| 01:39.42 | kergoth | RP: heh, we need a whiteboard. draw lines of flow along the paths through the graph representing the recipes and recipe methods |
| 01:40.37 | RP | That's effectively the idea. Each line to a task increases it's count. Tasks with the highest count get done first |
| 01:40.41 | RP | as more depends on them |
| 01:40.59 | kergoth | right, blow away things thatll block large numbers of paths |
| 01:41.00 | kergoth | makes sense |
| 01:41.06 | kergoth | like, say, the c library for example |
| 01:41.12 | RP | Thereby giving threading the best chance of doing something useful |
| 01:41.20 | RP | yes |
| 01:41.41 | kergoth | should create another wiki page on ideas for the -default- scheduling policy |
| 01:41.43 | kergoth | heh |
| 01:41.48 | RP | :) |
| 01:41.55 | RP | I think we just covered it :) |
| 01:41.59 | kergoth | hehe |
| 01:42.35 | kergoth | its slightly more complex than that. should a thread take single pcakages, or entire sections of the graph |
| 01:42.47 | kergoth | personally i'd say they should grab an entire path, so the other threads know where that thread is heading |
| 01:42.57 | kergoth | and can work to remove blockers from that path ahead of time |
| 01:43.32 | treke|wow | not to be a stick in the mud, but hasn't shit already been written to do this? |
| 01:43.38 | RP | You should never hit that case if the algorithms are right... |
| 01:44.22 | *** join/#oe CuZnDragon (~rcook@66.140.245.97) |
| 01:44.32 | RP | treke|wow: There problably is... |
| 01:44.32 | kergoth | well, you cant just run around zapping individual nodes in the graph. you still have to obey dependencies, which means you have to walk down a path in the graph |
| 01:44.54 | treke|wow | oh wait |
| 01:45.08 | treke|wow | you're talking about something completely different from me |
| 01:45.22 | kergoth | treke|home: we're talking about scheduling policy for the bitbake-ng baker threads. |
| 01:45.37 | kergoth | using an optimal algorithm to get the most efficiency out of them |
| 01:45.58 | treke|wow | for some reason I thought you were writing some kind of project scheduler :p |
| 01:46.08 | keturn | how well does parallel make work, overall? If it works, I would suspect that would be a better use of parallel resources than running parallel bakers. |
| 01:46.22 | kergoth | keturn: cpu isnt the major bottleneck. |
| 01:46.22 | RP | I guess the problem is we have two sets of dependencies. Task dependenices (compile after configure) and Inter module dependencies (gcc needs libc or whatever) |
| 01:46.26 | kergoth | keturn: and cpu is all make -j gains you |
| 01:47.10 | RP | keturn: parallel make means bitbake spends no time in do_compile. It spends ages single threaded elsewhere :-/ |
| 01:47.18 | kergoth | right |
| 01:49.39 | kergoth | RP: here's one issue. i want the recipes modular, so that we could, say, for example, use a shell script as a recipe. in that situation, itd be the recipe's backend which would know how to "execute" the steps in that recipe. in other words, the bakers may or may not have access to information about what individual methods exist and how and when they're called, and method interdependencies |
| 01:50.21 | kergoth | if it has that info, it can do some more intelligent things, but we need to account for the situation where the only level of scheduling we can control at the baker level is recipes |
| 01:51.50 | RP | It say that oe should define some base receipe classes such as fetch, patch, configure, compile, stage and package |
| 01:52.11 | RP | In the case of a custom set of steps for a recepie, they' |
| 01:52.29 | RP | d be the compile class or whatever, as appropriate |
| 01:52.32 | kergoth | remember that oe is just one user of bitbake. we may have multiple file formats for recipes. |
| 01:52.52 | kergoth | picture libbitbake as the new workhorse for portage-ng for executing ebuilds, for example. |
| 01:52.59 | RP | That's why I'm suggesting oe defines those classes of receipes... |
| 01:53.04 | kergoth | which is why i want to handle both possibilities |
| 01:53.10 | RP | or those threads |
| 01:53.11 | kergoth | thats a given, the recipe defines tasks |
| 01:53.19 | kergoth | the question is who's responsible for executing the tasks in order |
| 01:53.24 | kergoth | the bakers, or the recipe itself |
| 01:53.35 | kergoth | in the ebuild case, itd be the latter. in the oe case, as today, itd be the former |
| 01:53.46 | RP | oe defines task interdependencies |
| 01:54.00 | kergoth | yes, it does. the question is _who_ obeys them |
| 01:54.06 | RP | it defines configure must run before compile, patch after fetch etc. |
| 01:54.38 | RP | bitbake runs things based on the rules oe provides it with |
| 01:54.42 | kergoth | right now, bitbake handles the task graph and executes tasks in order, and handles stamps. in the ebuild case, it wouldnt have that level of control |
| 01:54.55 | kergoth | yes, thats how oe would behave givne today's methodology |
| 01:55.08 | kergoth | in the ebuild case all you can do is read some variables out of it, and "execute" the recipe |
| 01:55.16 | kergoth | you dont have granular control over individual task execution |
| 01:55.22 | kergoth | because its just a shell script |
| 01:55.30 | RP | in that case you can only run one task |
| 01:55.43 | kergoth | in that case you dont even know what tasks exist. |
| 01:55.47 | kergoth | all you can do is run the recipe |
| 01:56.04 | RP | so ebuilds define one task and all is well... |
| 01:56.05 | *** join/#oe west (~west@12-217-163-182.client.mchsi.com) |
| 01:56.10 | west | anyone here? |
| 01:56.14 | kergoth | no, they dont |
| 01:56.18 | kergoth | an ebuild is a shell script. |
| 01:56.23 | kergoth | it can do anything it wants when it runs |
| 01:56.35 | kergoth | run 12 different internal shell functions with interdependency |
| 01:56.40 | kergoth | or whatever |
| 01:56.49 | RP | That's its problem, not bitbakes... |
| 01:57.00 | RP | bitbake sees it as a single task |
| 01:57.07 | kergoth | no, it isnt. if the bakers assume that they have information about tasks, then ebuild is no longer a viable recipe format |
| 01:57.22 | kergoth | ahhh i see what you mean |
| 01:57.41 | kergoth | okay, thatd work |
| 01:58.02 | RP | In oe's case we provide into to bitbake telling it what tasks depend on what. In ebuilds, one one task can run so we don't need to know anything |
| 01:58.12 | RP | s/into/sinfo/ |
| 01:58.21 | west | question, let's say that I've got the build environment for oe set up |
| 01:58.28 | kergoth | but in both cases, its the _recipe_ executing the tasks, not the core |
| 01:58.40 | kergoth | right now the core is what reads the tasks out of hte metadata and emits it in shell |
| 01:58.42 | RP | kergoth: yes |
| 01:58.58 | west | and I've got the code for a program, which is not a oe bb package, and I want to compile it |
| 01:59.07 | RP | oe defines a "do_compile" task and tells bitbake how to run it... |
| 01:59.14 | west | any best way of setting my PATH/INCLUDE optimally? |
| 01:59.26 | kergoth | RP: wait, "tells bitbake how to run it"? |
| 01:59.44 | kergoth | west: oe already sets your CFLAGS, LDFLAGS, etc appropriately |
| 01:59.52 | kergoth | west: you just need your .bb to pass them into your makefiles so they get obeyed |
| 02:00.01 | RP | west: you need to write a .bb for your package... |
| 02:00.16 | west | alright, so I've got the tar ball, but no CVS repository |
| 02:00.23 | kergoth | ? |
| 02:00.33 | kergoth | look at some of the existing .bb files |
| 02:00.40 | kergoth | there are over 2,000 of them |
| 02:00.45 | west | all of the packages that I looked at worked on CVS |
| 02:00.49 | kergoth | eh? |
| 02:00.52 | west | not a local file |
| 02:00.54 | kergoth | very few work from cvs |
| 02:00.58 | kergoth | most download tarballs from upstream |
| 02:01.03 | kergoth | if its a local file, use a file:// url |
| 02:01.08 | kergoth | file:///usr/src/blah.tar.gz |
| 02:01.12 | kergoth | in SRC_URI |
| 02:01.31 | RP | kergoth: oe is going to have to define tasks such as "fetch", "patch", "configure", "compile" etc. by defining the tasks, we tell bitbake of its existance and presumably then bitbake will somehow be able to run defined tasks... |
| 02:01.51 | west | what is the purpose of TAG? |
| 02:02.16 | west | and S? |
| 02:02.19 | kergoth | RP: i figure we just have a bb_recipe_gettasks or something, to find out whats available, and a bb_recipe_execute_task to run a given task. keep the actual execution in the hands of the recipe handler |
| 02:02.23 | kergoth | west: eh? TAG? |
| 02:02.26 | kergoth | TAG isnt a standard variable. |
| 02:02.36 | kergoth | S is the source tree. its the directory that the tar.gz unpacks |
| 02:02.42 | west | alright |
| 02:02.51 | RP | kergoth: Yes, that what I'm thinking |
| 02:03.03 | kergoth | alright, good, we're on the same page |
| 02:03.09 | west | so SRC_URI points to the tarball |
| 02:03.16 | west | and S points to the directory it unpacks |
| 02:03.18 | kergoth | right |
| 02:04.30 | kergoth | RP: okay, i like your method. i was thinking about a callback thatd "execute" the recipe, the default of which would exert control over the bakers to give it control over tasks. but your way (everything has tasks, ebuild has just one) is much cleaner. |
| 02:06.10 | RP | That way we can implement task control in bitbake whilst not requiring any knowledge about what tasks do... |
| 02:06.21 | kergoth | right |
| 02:06.35 | kergoth | hmm |
| 02:06.42 | keturn | urgh. do_patchcmd for less is trying to invoke perforce. |
| 02:06.47 | west | alright, before I go on my great porting quest |
| 02:07.02 | kergoth | okay, the task might be bitbake "metadata" or not, it could be binary, or whatever, depending on the recipe |
| 02:07.07 | west | does anyone know if there's just a plain and simple blanker applet for oz? |
| 02:07.09 | kergoth | however, lets say the format is oe |
| 02:07.13 | kergoth | so its tasks are metadata |
| 02:07.34 | kergoth | in that case, the code that emits the bitbake metadata as shell and runs the task, that might be useful for more than just the .oe recipe handler |
| 02:08.04 | kergoth | so might want a supplementary lib for that |
| 02:08.18 | RP | A support lib sounds reasonable |
| 02:08.20 | kergoth | "execution of bitbake metadata" |
| 02:08.29 | kergoth | which may or may not be used by more than one recipe handler |
| 02:08.36 | RP | yes |
| 02:08.44 | kergoth | i like that, thats clean |
| 02:09.41 | kergoth | hehe, we could patch rpm to replace its 'build' code with a libbitbake engine |
| 02:09.58 | RP | :)) |
| 02:10.12 | kergoth | aw |
| 02:10.15 | treke|wow | better do that before he hurts himself |
| 02:10.19 | kergoth | hehe |
| 02:10.44 | kergoth | i was thinking that .conf files are recipes, just with no tasks |
| 02:10.45 | treke|wow | You planning on moving dependency handling into the core? |
| 02:11.18 | kergoth | treke|wow: we're going to have a scheduler. "baker" threads following inter package dependencies executing tasks |
| 02:11.50 | RP | treke|home: the core needs to know something about dependencies to schedule... |
| 02:11.51 | treke|wow | that sounds vaguelly like a yes |
| 02:12.03 | kergoth | RP: you want to throw together the function prototypes for bitbake/bakers.h? |
| 02:12.07 | kergoth | yes, its a yes |
| 02:12.12 | treke|wow | ok |
| 02:12.40 | RP | kergoth: I'm really no good at that... |
| 02:12.47 | kergoth | hehe, np |
| 02:13.00 | treke|wow | RP: it's mostly a matter of whether or not I as joe user trying to use libbitbake was going to have to write my own like I do with the current version. Sounds like that's a no |
| 02:13.20 | kergoth | treke|wow: itll be a no. it should give you absolutely everything you need |
| 02:13.23 | RP | kergoth: I am working on something to show how to calculate task counts though... |
| 02:13.29 | kergoth | cool |
| 02:13.30 | treke|wow | cool. |
| 02:13.42 | kergoth | i was researching graph theory for a while, for grabbing paths and things |
| 02:13.45 | treke|wow | That's a big help, since I absolutly hate dependency handling. |
| 02:14.19 | RP | kergoth: What I have in mind is surprisingly simple :) |
| 02:14.31 | kergoth | treke|wow: you'll be able to say "hey.. bakers.. go build me ncurses, get back to me when you're done. use up to 2 threads for compilation, 1 for fetching, and 2 for unpack." |
| 02:15.32 | RP | kergoth: Spot on :) |
| 02:16.10 | treke|wow | kergoth: Well the question is whether or not I'll be able to get a list of what needs to be done in order |
| 02:16.23 | kergoth | treke|wow: the graph will be accessible. |
| 02:16.29 | treke|wow | since telling bitbake to do shit isn't always useful :) |
| 02:16.46 | kergoth | so you can ask for the section of the graph which outlines the path from here to ncurses |
| 02:16.51 | treke|wow | cool |
| 02:16.51 | kergoth | and you could walk it manually, or whatever |
| 02:17.04 | RP | treke|wow: The idea is it will provide a list of items for each task sorted in order of priority |
| 02:17.57 | west | so, no good blankers out there? |
| 02:18.30 | kergoth | you havent given any real information |
| 02:18.33 | kergoth | console? gpe? opie? |
| 02:18.37 | west | opie, soory |
| 02:18.38 | kergoth | regardless, this isnt an oz support channel |
| 02:18.41 | kergoth | #openzaurus is |
| 02:18.43 | west | ah |
| 02:18.44 | west | sorry |
| 02:18.57 | kergoth | this chan is for development and build work |
| 02:19.00 | west | it's just really active hre |
| 02:19.20 | kergoth | #openzaurus is primarily a support channel. when no one needs help, it tends to be empty |
| 02:19.23 | kergoth | s/empty/quiet/ |
| 02:19.42 | kergoth | here, half the time we're bullshitting about nothing, but that doesnt make the questions on topic here |
| 02:19.45 | treke|wow | RP: yeah, I'm thinking of stuff like the build daemon where I don't want to just tell bb to build and go on its way for a couple hours |
| 02:19.46 | kergoth | ask them there, and see if we notice |
| 02:20.22 | kergoth | i still want a screensaver that shows the bakers running along the paths :) |
| 02:20.25 | west | meh, i'll keep on with my "port", that way I can ask questions here |
| 02:20.26 | kergoth | in 3d, naturally |
| 02:20.49 | west | must say that I'm impressed by the build environment |
| 02:22.21 | RP | kergoth: It'd be impressive :) |
| 02:22.45 | treke|wow | hehe |
| 02:22.57 | west | why do you say that? |
| 02:23.19 | RP | kergoth: http://www.rpsys.net/openzaurus/bbtree.txt |
| 02:23.45 | RP | Simple but shows the idea |
| 02:24.11 | RP | Use a fixed width font. Ascii art was never a strong point... :) |
| 02:24.31 | west | yeah, so it may need work :) |
| 02:24.37 | treke|wow | aalib! |
| 02:24.48 | kergoth | RP: the individual step counts should probably feed into the package counts, shouldnt they? |
| 02:25.08 | RP | kergoth: You need to start with the end results |
| 02:25.19 | RP | Packaging doesn't depend on anything... |
| 02:25.40 | kergoth | ahh right, terminology problem, i interpreted package as in current oe terminology |
| 02:25.52 | kergoth | where a "package" is a .bb |
| 02:25.59 | kergoth | not as in package the step |
| 02:26.02 | kergoth | looks sane |
| 02:26.16 | RP | Yes, package as in create an ipk or whatever |
| 02:26.18 | west | two more questions, then I've got to disappear |
| 02:27.38 | RP | In that case recipe 3 depends on r2 which in turn depends on r1 |
| 02:27.51 | kergoth | nod |
| 02:28.09 | RP | You can then order the tasks in each task list by the count... |
| 02:28.10 | west | first, can you blank all zaurus devices by sending 0x4611 to /dev/fb0 by ioctl? |
| 02:28.18 | kergoth | what tasks exist is dependent on the recipe type, so i expect that the DEPENDS field will need to specify the task |
| 02:28.47 | kergoth | just wondering syntactically, how we specify dependency on another recipe in the new file format |
| 02:29.02 | RP | That's a good question |
| 02:29.09 | west | and, second, if I have a package I want to give to add into the archive, just tell you guys? |
| 02:29.09 | kergoth | task attribute perhaps? |
| 02:29.17 | RP | You could make DEPENDS a staging depend... |
| 02:29.29 | kergoth | do_configure.depends += "ncurses.stage" |
| 02:29.33 | kergoth | :) |
| 02:29.49 | kergoth | or DEPENDS = "ncurses.stage" |
| 02:29.57 | kergoth | i dont want to make the core automatically assume stage |
| 02:30.05 | kergoth | because the recipes may or may not _have_ a stage as we know it |
| 02:30.07 | RP | true |
| 02:30.11 | kergoth | at least, not that we can get to |
| 02:30.21 | kergoth | i'm planning on having scoped metadata lookup |
| 02:30.23 | kergoth | like that ncurses.stage |
| 02:30.40 | kergoth | bb_recipe_box_lookup("ncurses.SRC_URI", box) |
| 02:30.44 | RP | tasks could be empty remember... |
| 02:30.45 | kergoth | something like that |
| 02:31.04 | kergoth | what do you mean by empty? |
| 02:31.29 | RP | A task could do nothing but still be "executed" |
| 02:31.46 | RP | Saves having to factor skipping tasks into things... |
| 02:32.22 | kergoth | i want to make sure the core can determine if a task has anything to do. i'd like "nothing to do" to be independent from task completion |
| 02:32.28 | kergoth | for clarity |
| 02:32.32 | kergoth | so empty would be nothing to do |
| 02:32.52 | RP | why differentiate? |
| 02:33.27 | kergoth | let me try to remember why :) |
| 02:33.40 | kergoth | there was a circumstance where itd be beneficial, if i can remember what it was |
| 02:34.07 | RP | I'd say the core should execute it, the receipe handler does nothing and returns success and all is well with the world... :) |
| 02:34.07 | kergoth | i think it had to do with stamp handling |
| 02:34.33 | RP | the core then stamps it as done... |
| 02:34.43 | kergoth | right |
| 02:34.57 | kergoth | i'm trying to recall why that isnt optimal, but my memory isnt cooperating |
| 02:35.12 | RP | the core doesn't care whether the task does anything or not... |
| 02:35.29 | RP | It isn't optimal from the viewpoint that its not efficent... |
| 02:35.44 | RP | but I'd argue there are other things to worry about... |
| 02:35.47 | kergoth | well, the recipe handler can return immediately |
| 02:35.52 | kergoth | in _python_ function calls are expensive |
| 02:35.52 | RP | exactly |
| 02:35.56 | kergoth | not so much in c |
| 02:36.14 | RP | not enough to worry about... |
| 02:36.45 | *** join/#oe micropal_ (ident@139.80-202-82.nextgentel.com) |
| 02:37.14 | kergoth | i wonder how best to architect things like metadata storage. ram backed vs sqlite backed and the like |
| 02:37.19 | kergoth | that could probably just be a compile time thing |
| 02:37.45 | RP | sql seems more hassle than its worth to me... |
| 02:37.55 | kergoth | file backed is nice. |
| 02:38.00 | kergoth | we need it to keep resource consumption down |
| 02:38.13 | kergoth | and sqlite is fast and cleaner than something like berkeley db, imho |
| 02:38.21 | kergoth | its not like we're using mysql here :) |
| 02:38.22 | RP | sql is good at certain things and I use it a lot. bb metadata doesn't strike me as a good sql data candidate... |
| 02:38.44 | RP | Lets look at it logically - what does the core need to know about the metadata? |
| 02:38.53 | kergoth | key, value, and attributes |
| 02:38.57 | kergoth | attributes are more key/value pairs |
| 02:39.00 | RP | All it really needs to know about are dependencies |
| 02:39.13 | kergoth | well, anyone needs to be able to look at the data. |
| 02:39.16 | RP | the rest is the recipe handlers problem... |
| 02:39.27 | kergoth | as a libbitbake user, i might want to, say, show the user whats happening. |
| 02:40.18 | RP | so the recipe handler returns the info if asked. Pass the request on to the receie handler |
| 02:40.30 | kergoth | thats the intent. |
| 02:40.52 | kergoth | you'll never actually have to hook into the 'metadata' stuff, you'll ask a recipe or recipe box for lookup of an item of metadata |
| 02:41.15 | kergoth | but those recipes may want a clean backend for it. we dont want them all reinventing the wheel for how they store it, do we? |
| 02:41.16 | RP | sounds good |
| 02:41.24 | RP | no... |
| 02:41.43 | kergoth | thats the idea behind bitbake/metadata.h. just a common metadata store for the recipes to use to hold their data |
| 02:41.44 | RP | although do they need to store it? |
| 02:41.56 | RP | What gets me is bitbake's speed when you use -b somebbfile.bb |
| 02:42.16 | RP | It only needs the memory footprint to calculate the dependencies... |
| 02:42.17 | kergoth | ah, you were here for the recipe/metadata caching discussion i had with raster |
| 02:42.28 | RP | was I? |
| 02:42.34 | kergoth | er |
| 02:42.35 | kergoth | werent |
| 02:42.38 | kergoth | damn fingers |
| 02:42.38 | *** join/#oe dkey (~dkey@L0003P06.dipool.highway.telekom.at) |
| 02:43.45 | kergoth | i think its useful to have a common 'bitbake variable' format, to hold key, value, attributes, cached version of the expanded variable chunks (resolved var references to other variables) and stuff |
| 02:44.10 | kergoth | we track variable changes, automatically update the expanded versions of things for variable references |
| 02:44.42 | kergoth | i suppose this stuff could stay local to the oe recipe handler, but i think itd be useful for more than one recipe handler |
| 02:44.43 | RP | That all sounds good. One question |
| 02:44.52 | RP | How often in a run do you access the same data twice? |
| 02:45.47 | kergoth | tasks will access a variable numerous times in a single recipe execution |
| 02:45.47 | RP | Ok, you may access the same base classes but you have to recalc all the data anyway as you may have overridden something... |
| 02:46.14 | kergoth | you only have to recalc when a variable changes. we track references to other variables |
| 02:46.31 | RP | Tthere is a case given we're seperating the tasks out... |
| 02:46.56 | *** join/#oe bluelightning (~bluelight@203-173-244-34.akl.ihugultra.co.nz) |
| 02:46.59 | RP | I'd say not in memory though |
| 02:47.15 | *** join/#oe linuxwhore (~johnh@70-56-163-89.mpls.qwest.net) |
| 02:47.16 | kergoth | well, where do we draw the line between a common metadata store and wahts local to the recipe handler |
| 02:47.19 | RP | and maybe not in sql. Maybe a cache file it best... |
| 02:47.19 | kergoth | thats the question |
| 02:47.46 | kergoth | here, let me pull up the doc i did when raster and i discussed. this is mostly oe specific, but other formats could benefit |
| 02:48.05 | RP | With a single sql store you'd have to search through every piece of metadata when you're only likely to after metadata for a specific file... |
| 02:48.32 | RP | so I'd say each bb should have a cache file of some sort |
| 02:48.36 | kergoth | eh |
| 02:48.42 | kergoth | a "specific file" doesnt mean much |
| 02:48.47 | kergoth | it could be linked to any number of parent scopes |
| 02:48.51 | kergoth | whos metadata affects his |
| 02:49.55 | kergoth | okay here |
| 02:50.00 | kergoth | given the oe recipe format: |
| 02:50.09 | kergoth | A := "blah ${B}" |
| 02:50.12 | kergoth | thats in the recipe |
| 02:50.16 | kergoth | what do you do? |
| 02:50.30 | RP | I see the problem... |
| 02:50.32 | kergoth | if you resolve it immediately, you'll have to reparse the file if B changes. |
| 02:50.55 | kergoth | if you "compile" the .oe into a binary format, you can just "re execute" the .oe |
| 02:50.58 | kergoth | avoiding a parse |
| 02:51.20 | RP | so that binary format is your cache |
| 02:51.24 | kergoth | right |
| 02:51.34 | kergoth | a .oec |
| 02:51.37 | kergoth | or similar |
| 02:51.42 | RP | yes |
| 02:52.02 | kergoth | the question is what happens beyohnd that. once its attached to its parent scopes and all those are resolved, what happens to the data |
| 02:52.25 | kergoth | optimally thatd be cached too, in a database, with the cached variable expansions, so that you dont even have to re execute the .oec unless you have to |
| 02:52.38 | RP | an .oecc file? |
| 02:52.41 | kergoth | so vars dont all need to be reexpanded if things change |
| 02:53.17 | RP | I'd say another cache file... |
| 02:53.36 | kergoth | and that cache file holds the contents of all the vars in all the parent scopes? |
| 02:53.43 | RP | yes |
| 02:53.44 | kergoth | or do we pull all those in too? |
| 02:53.48 | kergoth | i dont like that idea |
| 02:53.57 | RP | why? |
| 02:54.18 | kergoth | i'd rather the lookup process jump from child to parent to find the data directly. |
| 02:54.45 | kergoth | its just more data to keep up to date, more tracking to do, and duplication of the same data in multiple places |
| 02:54.46 | RP | Ok, but once you have the final data why do you do? |
| 02:54.48 | kergoth | feels prone ot failure |
| 02:55.32 | RP | I can see the tracking working ok - just go by timestamps of files... |
| 02:56.19 | RP | create a list of parent files you had to read to generate the data, if any of them change, cache is invalid |
| 02:57.39 | RP | That data once resolved is only useful to the task at hand so no point in keeping it in memory and no point in mixing it with other data when it has no useful relationship with it |
| 02:58.49 | kergoth | the .bbc has to be read into ram to be executed. the fully resolved version will have metadata looked up directly in the file. what is it? sqlite3? bdb? |
| 03:04.13 | RP | Good question... |
| 03:05.26 | kergoth | okay, lets give an example circumstance. bitbake.conf's timestamp changes. bitbake.conf is linked to every recipe in existance. you naturally dont want to be updating the children unless the variables actually changed. |
| 03:05.49 | *** join/#oe mithro (~tim@dsl1-83.gw1.adl1.airnet.com.au) |
| 03:06.37 | kergoth | first step when a file changes, we parse it in, attach to scopes, re execute the .oec if anything is unresolved. now, we know which variables changed. what next? |
| 03:06.37 | kergoth | you need to find every child that has variables that reference the changed variables, and update their expanded forms, at a minimum |
| 03:06.51 | kergoth | if any children had := or += operations that were affected by those changes, those have to have their .oec's reexecuted as well |
| 03:07.33 | kergoth | and -then-, in your suggestion, we go through every last child and update its cache of the parent variables |
| 03:07.41 | kergoth | _that_ step isnt necessary if you lookup indirectly |
| 03:07.47 | kergoth | which is why i didnt like that method |
| 03:09.25 | kergoth | A := "${B}" <-unresolved, must exist in .oec form, can be resolved into a variable and expanded when attached to parent scopes. when a referenced variable changes, it needs to be both reexecuted, and reexpanded |
| 03:09.33 | RP | The amount of freedom available with bb's variables makes this very tricky to design for... |
| 03:09.52 | kergoth | A = "${B}" <-resolved, can exist as a normal variable form rather than .oec. can be expanded when attached to parent scopes, and when a referenced variable cahnges, it needs to be reexpanded |
| 03:09.57 | kergoth | er |
| 03:09.58 | kergoth | s/resolved/unresolved/ |
| 03:10.00 | RP | I don't disagree. I'm just trying to think around the problem... |
| 03:10.08 | kergoth | its a fairly complex system :) |
| 03:10.18 | kergoth | making it efficient is relatively challenging |
| 03:10.21 | kergoth | which makes it interesting :) |
| 03:10.26 | RP | :) |
| 03:10.48 | kergoth | the problem with indirect lookup is that we have to look up metadata from multiple locations, unless we have a single sqlite datastore |
| 03:10.55 | kergoth | but its more efficient when things change |
| 03:11.42 | RP | I need to give it some thought :) |
| 03:11.53 | RP | I should really also get some sleep... |
| 03:11.56 | mithro | ibot seen pb |
| 03:11.57 | ibot | pb <~pb@dsl-082-082-128-195.arcor-ip.net> was last seen on IRC in channel #debian, 340d 5h 32m 48s ago, saying: 'streuner__can you help me with my printer?'. |
| 03:12.00 | mithro | ibot seen pb_ |
| 03:12.01 | ibot | pb_ <~pb@2002:5168:d330:1:20b:6aff:fe40:e27f> was last seen on IRC in channel #handhelds.org, 2h 29m 55s ago, saying: 'night all'. |
| 03:12.26 | kergoth | now, i figured we could have a single sqlite datastore, if we have a field in the table with the filename |
| 03:12.26 | kergoth | or, have a table per file |
| 03:12.26 | kergoth | itd still be pretty quick |
| 03:12.48 | kergoth | this is why bitbake-ng isnt coded yet. lots of ways to screw it up |
| 03:12.57 | RP | :) |
| 03:13.14 | RP | I'll give it some thought and sleep on it |
| 03:13.21 | mithro | well code it and if you stuff up start again :) |
| 03:13.24 | kergoth | and where you draw the line between what metadat resides in the recipe, and what in our metadata store |
| 03:13.28 | kergoth | is pretty blurry |
| 03:13.33 | kergoth | heh |
| 03:13.37 | mithro | we all know how people love to reinvent the wheel multiple times |
| 03:13.56 | kergoth | heh |
| 03:14.00 | kergoth | we're on our first rewrite |
| 03:14.05 | kergoth | i'd like to avoid a second for a while, thanks |
| 03:14.08 | kergoth | :) |
| 03:14.09 | treke|wow | well |
| 03:14.15 | treke|wow | first rewrite of the rewrite |
| 03:14.36 | kergoth | we've never done a rewrite before |
| 03:14.40 | kergoth | just lots of evolving |
| 03:14.45 | treke|wow | which was a rewrite of a fourth or fifth edition :) |
| 03:15.01 | kergoth | which is why teh current core is a mess |
| 03:15.40 | kergoth | you can only evolve for so long |
| 03:15.40 | kergoth | heh |
| 03:15.40 | treke|wow | I meant buildroot :p |
| 03:15.40 | kergoth | ahh |
| 03:15.43 | kergoth | okay, so the third time's the charm |
| 03:15.43 | mithro | where did buildroot come from? |
| 03:15.47 | kergoth | or is it three strikes and you're out? |
| 03:15.57 | kergoth | mithro: tim riker and others, iirc. |
| 03:15.59 | kergoth | originally |
| 03:16.03 | RP | I'm going to sleep on it... 'night all |
| 03:16.08 | kergoth | his copyright was in our toplevel Makefile in the oz one |
| 03:16.11 | kergoth | RP: night |
| 03:16.17 | mithro | nah it's 1000th time's the charm |
| 03:17.02 | mithro | RP|zZz: coming to the miniconf? |
| 03:21.11 | [g2] | kergoth, mtd-utils is much better for NOR flash_eraseall now |
| 03:21.23 | kergoth | cool |
| 03:21.29 | [g2] | I just tested on the OpenSlug target |
| 03:21.42 | [g2] | that was the only thing that I tested |
| 03:21.49 | kergoth | let me know when you push the update to the more recent snap |
| 03:21.54 | [g2] | but the fixes are in the CVS repo |
| 03:22.50 | [g2] | I've got a copy of the 20050118.bb which is just named 20050128.bb to pull the latest with the fixes |
| 03:23.25 | [g2] | I didn't know whether the mtd-native should match, I'm guessing it probably should |
| 03:23.39 | kergoth | doubt itll matter, but its generally a good idea |
| 03:23.43 | [g2] | or they may be close enough |
| 03:25.06 | [g2] | do you want me to change both and I'll push, or do you just want to update the date because that's all it is |
| 03:25.25 | mithro | ljp: you about at all? |
| 03:25.32 | mithro | ibot seen ljp |
| 03:25.33 | ibot | ljp is currently on #zaurus (14h 47m 46s) #opie (14h 47m 46s) #oe (14h 47m 46s) #elinux (14h 47m 46s) #handhelds.org (14h 47m 46s) #openzaurus (14h 47m 46s). Has said a total of 3 messages. Is idling for 3h 9m 28s |
| 03:25.45 | mithro | [g2]: you comming to the miniconf? |
| 03:25.55 | [g2] | in AU ? |
| 03:26.00 | mithro | yeah |
| 03:26.09 | [g2] | Sounds real nice, I'd like to go |
| 03:26.21 | kergoth | i'll take care of it |
| 03:26.34 | [g2] | kergoth, thx |
| 03:27.11 | [g2] | mithro, unfortunately it's about 1/2 way around the globe |
| 03:27.49 | CIA-5 | 03kergoth 07 * r1.2999.2.1 10openembedded/packages/mtd/ (mtd-utils_20050128.bb mtd-utils-native_20050128.bb): Update mtd-utils to 20050128. |
| 03:28.15 | [g2] | going to AU ? |
| 03:28.41 | [g2] | or bb-ng ? |
| 03:29.09 | kergoth | cant afford to go to au |
| 03:29.17 | kergoth | bb-ng, trying to nail down this metadata/recipe stuff |
| 03:29.47 | [g2] | well I'm sure mithro would send you before me :) |
| 03:30.00 | kergoth | hmm |
| 03:30.01 | mithro | kergoth: stow away in a planes cargo hold :) |
| 03:30.08 | kergoth | how vars reference one another is recipe handler specific |
| 03:30.14 | kergoth | so that doesnt belong in the core |
| 03:30.16 | kergoth | no expansion in the core |
| 03:30.31 | kergoth | so no variable intermediate forms are touchable in the core in any way, shape, or form |
| 03:31.30 | kergoth | the question is whether or not the final form metadata is stored using something in the core. it really should, so that is consistent across different recipe types |
| 03:31.49 | kergoth | (note: i'm mostly talking to myself here, feel free to ignore me) |
| 03:32.48 | kergoth | hmm |
| 03:32.54 | ljp | mithro: pong |
| 03:34.00 | mithro | ljp: can you give me a quick title for your talk |
| 03:35.42 | ljp | my working title is a bit stupod |
| 03:36.16 | ljp | 'Qtopia: the past, the present, and the future' |
| 03:36.18 | ljp | heh |
| 03:36.53 | CIA-5 | 03kergoth * r121 10bitbake-ng/doc/ramblings/ (4 files): Add few text files of slightly coherent rambling about possible ways of doing things for bitbake-ng. Gives an idea of the brainstorming involved in the design. |
| 03:37.42 | mithro | do you know sarahs working title? |
| 03:40.30 | ljp | hangon |
| 03:42.20 | ljp | working title is "Phone security - Qtopia 4 and beyond" |
| 03:43.37 | mithro | i've got approx 8 talks if nobody cancels |
| 03:44.04 | ljp | cool |
| 03:45.12 | ljp | i'm all registered and have flights |
| 03:45.31 | mithro | cool |
| 03:45.49 | mithro | i need to get my talk for the main conference in order, the deadline is rapidly approching |
| 03:48.24 | kergoth | what are the talks so far? |
| 03:48.59 | kergoth | mm, guinness |
| 03:49.03 | ljp | just a bunch of geeks sitting around on their laptops chatting |
| 03:49.04 | *** join/#oe raster (~raster@YahooBB219198104088.bbtec.net) |
| 03:49.09 | kergoth | hey raster |
| 03:49.29 | ljp | frick its hot |
| 03:50.00 | raster | kergoth: hey k! |
| 03:50.03 | kergoth | how goes? |
| 03:50.10 | raster | busy |
| 03:50.20 | raster | peolpe send me too many mails, patches and shit |
| 03:50.31 | raster | i just woke up and spent 3 hrs going thru it all |
| 03:50.32 | raster | grrr |
| 03:50.40 | kergoth | jeeze |
| 03:50.55 | raster | well it also mean examining patches |
| 03:50.58 | raster | finding/fixing a bug |
| 03:50.59 | raster | etc. |
| 03:51.25 | mithro | hey raster you comming to the miniconf? |
| 03:51.37 | kergoth | nod. i'm glad my projects are pretty small. doesnt take 3 hours :) |
| 03:51.46 | raster | mithro: nup. as i'd have to fork out a few grand to get my arse to .au |
| 03:51.53 | raster | and i'm currently skint. |
| 03:51.59 | mithro | skint? |
| 03:52.11 | raster | spare cash nada |
| 03:52.24 | raster | no play mulah |
| 03:52.26 | mithro | kergoth: does the www.openembedded.org have php? |
| 03:53.14 | mithro | and who would i talk to about getting a link on the main website to the miniconf website? |
| 03:54.00 | kergoth | it does. i can do it |
| 03:54.04 | kergoth | its hosted on handhelds.org |
| 03:55.41 | mithro | kergoth: it would be cool if you could setup the link, i could do it myself but didn't want to step on anyone toes |
| 03:56.02 | kergoth | k |
| 03:57.38 | kergoth | hmm, i should finish this design doc before i drink too much beer, otherwise it wont be very readable |
| 03:57.42 | kergoth | heh |
| 04:02.02 | kergoth | anyone have the url to marc singer's C .bb parser? |
| 04:02.29 | [g2] | I do |
| 04:02.40 | kergoth | what is it? |
| 04:02.44 | kergoth | we should probably put it in the wiki somewhere |
| 04:02.50 | raster | a chicken |
| 04:02.51 | [g2] | one sec |
| 04:02.54 | kergoth | raster: thanks |
| 04:03.21 | raster | bgaaaaaaaawk |
| 04:04.16 | jcrouse | Its not the bb trunk? |
| 04:04.24 | [g2] | http://projects.buici.com/oe/ |
| 04:05.05 | [g2] | kergoth, from when I ran it, it seemed like a great start |
| 04:05.42 | [g2] | it parses the full OE tree in 6 seconds on my machine, NSLU2 in 1 second |
| 04:06.07 | [g2] | it's like 1:50 for the cached version |
| 04:06.29 | ljp | now we're talkin |
| 04:07.21 | kergoth | [g2]: cool, i'll take a look and think about whats necessary to get it rolling in bitbake-ng |
| 04:07.34 | [g2] | it was really sweet, but there were some python stuff it didn't fully parse |
| 04:07.40 | kergoth | nod |
| 04:07.53 | kergoth | hmm |
| 04:08.04 | kergoth | speaking of which, i need to give thought to how to handle inline scripting |
| 04:08.15 | [g2] | I was thinking hey Python's got a C intf right, |
| 04:08.25 | kergoth | it does, but its annoying |
| 04:08.30 | kergoth | lua will be available sooner than python |
| 04:09.00 | [g2] | well it's the conversion that's the issue right |
| 04:09.09 | [g2] | or maybe not |
| 04:09.31 | [g2] | maybe bb could just re-emit |
| 04:09.45 | kergoth | it can re-emit in a new format no problem, without expanding anything |
| 04:09.48 | [g2] | but I'm just totally talking out my a** |
| 04:09.59 | kergoth | but naturally it wont be useful for actual builds until we can inline python |
| 04:09.59 | kergoth | or |
| 04:10.04 | kergoth | rewrite the classes and things in lua |
| 04:10.05 | [g2] | right, so it'd be like a 1-time charge |
| 04:10.06 | kergoth | which is actually what i'd prefer |
| 04:10.24 | kergoth | we can keep around a parser for the old format, for compatibility |
| 04:10.32 | kergoth | once we have inline python, itll actually be useful |
| 04:10.39 | kergoth | for people not willing to transition yet |
| 04:10.39 | ljp | btry it in lisp, so I can run it from emacs ;) |
| 04:10.45 | kergoth | ~lart ljp |
| 04:10.50 | *** join/#oe beewoolie (~beewoolie@florence.buici.com) |
| 04:10.52 | kergoth | if you want to write lisp bindings, you go right ahead |
| 04:10.54 | kergoth | hey beewoolie |
| 04:10.59 | ljp | heh |
| 04:11.04 | ljp | lisp sux |
| 04:11.08 | beewoolie | kergoth: Hey. [g2] says you're looking for the parser url. |
| 04:11.19 | kergoth | yep, he just gave it to me |
| 04:11.28 | kergoth | looking into pulling it into bitbake-ng when i start implemetning |
| 04:11.31 | kergoth | implementing, even |
| 04:11.34 | beewoolie | well ok then. |
| 04:11.37 | kergoth | :) |
| 04:11.54 | beewoolie | cool. I'm glad for the effort to be useful. |
| 04:12.16 | kergoth | we'll have to rewrite the python parts in lua, or get the inline python going soon |
| 04:12.22 | kergoth | heh |
| 04:13.23 | [g2] | isn't lua based on the same parser generator lemon ? |
| 04:13.38 | kergoth | dont know what they use to parse |
| 04:15.27 | beewoolie | Lemon works OK. It doesn't seem to be a big improvement over yacc. |
| 04:15.51 | beewoolie | It would be handy to have something a little easier to work with, something with look-ahead. |
| 04:17.26 | mithro | hey beewoolie you comming to the miniconf? |
| 04:18.09 | kergoth | mithro: isnt shameless promotion fun? :) |
| 04:18.51 | kergoth | i wish i could go :\ |
| 04:24.32 | mithro | kergoth: well hopefully you can participate in some ways via the wonders of the net :) |
| 04:26.07 | mithro | hey chouimat you comming to the miniconf? |
| 04:26.24 | mithro | kergoth: well i don't want the miniconference to flop :) |
| 04:26.25 | chouimat | mithro: where is that? |
| 04:26.40 | mithro | australia, canberra in april |
| 04:27.10 | chouimat | mithro: do you know the cost of a plane ticket between Ottawa Canada and Australia? |
| 04:28.11 | chouimat | for a guy looking for a job? but If you have one for me in australia I won't say no :) |
| 04:28.22 | kergoth | hehe |
| 04:28.26 | kergoth | still no luck on the job front? |
| 04:28.44 | chouimat | kergoth: applied for one at CST (canadian nsa) |
| 04:29.29 | chouimat | kergoth: and november/december/january are the slow months in canada |
| 04:29.35 | kergoth | ah |
| 04:30.18 | chouimat | kergoth: and if I get the job I will have to get a level3 security clearance |
| 04:30.49 | kergoth | nod. sounds like a hassle. but a job is a job.. |
| 04:30.52 | mithro | chouimat: that hard? |
| 04:30.53 | kergoth | good luck |
| 04:31.09 | chouimat | mithro: level3? that Top secret level |
| 04:32.44 | chouimat | mithro: level 1 take 3 weeks, level 2 takes 4 to 8 weeks after the level 1 and level 3 takes 4 to 12 months after level 2 |
| 04:32.50 | mithro | well it's not to hard to get top secret here |
| 04:34.31 | chouimat | mithro: here it got a little more harder because we a paranoid country south of the border :) |
| 04:36.05 | ljp | mexico? ;) |
| 04:36.06 | chouimat | kergoth: sorry if I offended you :) |
| 04:36.21 | chouimat | ljp: jesusland |
| 04:37.07 | mithro | chouimat: that map of jesusland is so funny |
| 04:37.16 | chouimat | hehe |
| 04:38.08 | chouimat | ljp: I'm still thinking about applying but I don't know if I choose Oslo or Brisbane |
| 04:38.12 | kergoth | hehe |
| 04:39.56 | chouimat | and the idea of moving again after meeting this chick is kind of depressing: http://ulyx.ath.cx/friend.jpg |
| 04:39.57 | ljp | i prefer surf girls |
| 04:40.07 | chouimat | ljp: look at the link |
| 04:40.40 | kergoth | yum. |
| 04:41.00 | chouimat | kergoth: dating her for the last 2 weeks ... she's 28 |
| 04:41.14 | kergoth | this the married one? |
| 04:41.34 | chouimat | kergoth: no |
| 04:41.39 | kergoth | ah |
| 04:41.55 | chouimat | the married one is like that too |
| 04:42.28 | chouimat | kergoth: the married one is 34 |
| 04:42.28 | mithro | chouimat: now we need to see a picture of you |
| 04:42.54 | chouimat | mithro: http://ulyx.ath.cx/me.jpg |
| 04:42.56 | ljp | too bad she looks french ;) |
| 04:43.26 | *** join/#oe linuxwhore (~johnh@70-56-163-89.mpls.qwest.net) |
| 04:43.58 | chouimat | ljp: she doesn't speak french at all |
| 04:44.12 | mithro | chouimat: how old are you? |
| 04:44.23 | chouimat | will be 31 next month |
| 04:44.54 | mithro | chouimat: so you are playing both the younger and older sides of the field eh? |
| 04:44.57 | *** join/#oe joshua_ (joshua@joshuawise.com) |
| 04:46.01 | chouimat | mithro: nothing said I can't and being 30 is you sill find the 18 year old one hot and you start to find the 40 one too :) ask ljp |
| 04:46.30 | kergoth | hehe |
| 04:46.31 | chouimat | =) |
| 04:47.36 | ljp | my chickipoo is only 11 years younger |
| 04:47.37 | mithro | i'm 21 so I've still got a while till that happens :) |
| 04:48.08 | chouimat | mithro: ljp hehe |
| 04:48.37 | mithro | if my chickipoo was 11 years younger i would be dating a 10 year old |
| 04:48.46 | ljp | ha |
| 04:48.57 | mithro | which generally gets you thrown in jail i believe |
| 04:49.15 | kergoth | i'll be 25 in april. i can feel the big three-oh hunting me down |
| 04:49.26 | mithro | ljp: how long will your talk be approx? |
| 04:49.42 | ljp | not sure |
| 04:50.52 | treke|wow | kergoth: you're a quarter of a century old :p |
| 04:51.12 | mithro | well will it be about 50 minutes? |
| 04:51.24 | mithro | or more likely to be 20? |
| 04:51.41 | ljp | 20 or so.. maybe longer |
| 04:51.46 | mithro | i'm currently planning for 1 hour and half hour sessions |
| 04:51.58 | ljp | ok. i can expand |
| 04:52.14 | mithro | i'm currently planning for 1 hour or half hour sessions |
| 04:52.30 | mithro | not 1+1/2 hour :) |
| 04:52.39 | mithro | hence the 20 or 50 minute questions |
| 04:52.52 | mithro | need to leave time for people to change to other conferences etc |
| 04:53.32 | ljp | ya, I'd like to check out the audio one |
| 04:53.42 | kergoth | treke|wow: yep. depressing. half way through the decade to 30 |
| 04:53.54 | kergoth | treke|wow: i feel so office space. mid 20s, stuck in a damn cubicle, hate my job.. |
| 04:55.34 | mithro | i'm pretty sure we'll only make 1+1/2 days max anyway |
| 04:57.50 | chouimat | kergoth: btw the chick I meet tonight her little sister too ... and I bet the mother is fucking hot too (or was fucking hot) |
| 04:57.57 | kergoth | hehe |
| 04:58.55 | chouimat | kergoth: 2 years younger with readhair more or less the same look |
| 04:59.34 | mithro | i didn't know you could print on hair these days, it's amazing what technology can do |
| 05:00.00 | chouimat | mithro: hehe |
| 05:00.22 | chouimat | mithro: desole mais typo ... red not read |
| 05:01.40 | mithro | chouimat: i figured at much |
| 05:02.09 | mithro | why are we all strangely attracted towards red haired women? |
| 05:02.55 | kergoth | red's an inherently agressive, firey color. not surprising that thatd be attractive |
| 05:04.16 | mithro | but men with red hair generally arn't considered attractive |
| 05:04.55 | kergoth | fiestiness isnt really an attractive element in men |
| 05:05.00 | kergoth | strength, confidence, etc are |
| 05:05.14 | chouimat | kergoth: because they are HOT in bed ..... |
| 05:05.19 | kergoth | hehe |
| 05:05.30 | kergoth | true that |
| 05:05.54 | chouimat | kergoth: actualy we are attracted to nasty woman no matter the hair color ... |
| 05:07.08 | chouimat | probably because nice and good woman remind us of our (respective) mother ... I don't really know and I was sleeping in the psychology classes |
| 05:10.53 | *** join/#oe Q_Continuum (~Q_Continu@0-2pool145-246.nas8.minneapolis1.mn.us.da.qwest.net) |
| 05:20.53 | chouimat|Zzzz | night |
| 05:35.20 | *** join/#oe qip|Virus|here (~Thomas@p5091A906.dip.t-dialin.net) |
| 05:38.23 | mithro | kergoth: so about that link :) |
| 06:00.01 | *** join/#oe joshin (~joshg@VDSL-130-13-185-112.PHNX.QWEST.NET) |
| 06:02.29 | ljp | bp's gonna be there? |
| 06:02.33 | ljp | err pb |
| 06:03.29 | mithro | yeah should be |
| 06:05.12 | *** join/#oe kergoth (~kergoth@proxysb02.ext.ti.com) |
| 06:05.34 | mithro | wb kergoth |
| 06:09.16 | *** join/#oe kergoth_ (~kergoth@ip71.churchill-park.dfw.ygnition.net) |
| 06:11.03 | *** join/#oe kergoth (~kergoth@proxyle02.ext.ti.com) |
| 06:11.40 | *** join/#oe kergoth_ (~kergoth@ip71.churchill-park.dfw.ygnition.net) |
| 06:23.36 | *** join/#oe zedkatuf (~dfutak@82-32-58-45.cable.ubr08.azte.blueyonder.co.uk) |
| 06:57.23 | *** join/#oe offroadgeek (~offroadge@dsl027-191-249.sfo1.dsl.speakeasy.net) |
| 07:16.45 | *** join/#oe bronson (~bronson@node-40240852.sjc.onnet.us.uu.net) |
| 07:38.05 | *** join/#oe micropal (ident@139.80-202-82.nextgentel.com) |
| 07:55.06 | *** join/#oe sc (~sc@p509252E7.dip0.t-ipconnect.de) |
| 08:42.30 | uv1 | Good morning |
| 08:44.41 | uv1 | Just builded an opie-image for my CL860 and flashed that. After reboot, the initial calibration is not working. You get the first cross-hair and than, the display does not react on the pen any more. Tried, whether the kernel or initrd. It is the initrd. |
| 08:45.13 | *** join/#oe Q_Continuum_ (~Q_Continu@0-2pool145-246.nas8.minneapolis1.mn.us.da.qwest.net) |
| 08:58.14 | *** join/#oe Mardy (~mardy@adsl-24-108.38-151.net24.it) |
| 09:01.43 | koen | good morning all |
| 09:16.45 | *** join/#oe gints (~gints@195.2.115.160) |
| 09:32.41 | koen | 'morning mickeyl |
| 09:33.03 | mickeyl | morning koen |
| 09:37.51 | CIA-5 | 03mickeyl 07 * r1.3012 10openembedded/ (3 files in 2 dirs): opie-memoryapplet: catch up w/ upstream |
| 09:37.56 | CIA-5 | 03mickeyl 07 * r1.3010 10openembedded/packages/ (14 files in 3 dirs): repair opie-help-en packaging |
| 09:40.17 | CIA-5 | 03mickeyl 07 * r1.3013 10openembedded/ (22 files in 2 dirs): introduce qte4-snapshot (upstream is broken atm.) and remove 2.3.8-snapshot which wasn't ever used |
| 09:47.02 | *** part/#oe bluelightning (~bluelight@203-173-244-34.akl.ihugultra.co.nz) |
| 09:47.10 | *** join/#oe bluelightning (~bluelight@203-173-244-34.akl.ihugultra.co.nz) |
| 10:03.14 | CIA-5 | 03mickeyl 07 * r1.3014 10openembedded/ (10 files in 3 dirs): add rxvt-unicode 4.8 |
| 10:07.42 | *** join/#oe oe_newbie (~kvirc@195.234.128.72) |
| 10:08.16 | chris144|home | good morning everyone |
| 10:08.35 | mickeyl | dito to you |
| 10:09.00 | *** join/#oe pb_ (~pb@2002:5168:d330:1:20b:6aff:fe40:e27f) |
| 10:09.20 | mickeyl | morning pb_ |
| 10:09.24 | bluelightning | hi pb_ |
| 10:09.29 | pb_ | good morning mickey |
| 10:09.43 | pb_ | hi bluelightning |
| 10:14.29 | RP | morning all |
| 10:14.40 | bluelightning | hi RP |
| 10:16.32 | *** join/#oe moa_ (~moa@paris.bluebugs.org) |
| 10:16.54 | mickeyl | morning RP |
| 10:17.40 | mickeyl | building a new kernel to work more on the initscripts playing nice w/ elpp. current version in bk has sound? |
| 10:17.47 | mickeyl | s/bk/oe/ |
| 10:19.10 | RP | mickeyl: It has sound, yes. The power system is before though. hang on one second... |
| 10:19.40 | koen | bbl |
| 10:22.03 | *** join/#oe micropal_ (ident@139.80-202-82.nextgentel.com) |
| 10:22.07 | RP | mickeyl: done |
| 10:22.28 | mickeyl | great. bk pulling... |
| 10:22.39 | RP | The suspend key stopped working after my last round of changes. Everything should worl with that image now... |
| 10:23.51 | RP | mickeyl: I'm working on cleanups to the sound drivers but I'm not finished them yet... |
| 10:24.11 | RP | Everything should work though (just a few warnings when compiling ;-) |
| 10:24.35 | mickeyl | fine. |
| 10:24.52 | mickeyl | did you calm down the GPIO output a bit? |
| 10:25.02 | mickeyl | last version i had spit lots of messages out |
| 10:25.35 | RP | Which messages? |
| 10:25.44 | mickeyl | let me check |
| 10:26.10 | RP | Somehow, I think you have debug enabled in your image... (cat /proc/sys/kernel/printk) |
| 10:26.21 | mickeyl | IRQ28 (GPIO5): edges |
| 10:26.38 | RP | Just upon suspend/resume? |
| 10:26.42 | RP | or at other times? |
| 10:26.51 | mickeyl | on touching the screen iirc |
| 10:26.58 | mickeyl | printk reports 7 4 1 7 |
| 10:27.18 | RP | It only prints that for me when the first number is an 8 |
| 10:27.28 | RP | The IRQ messageat's a KERN_DEBUG message. Some how your |
| 10:27.43 | RP | I'll try again... |
| 10:27.49 | RP | The IRQ messageat's a KERN_DEBUG message. Some how |
| 10:27.49 | RP | your |
| 10:28.21 | RP | The IRQ message is a KERN_DEBUG level message and should only appear if that logging level is enabled... |
| 10:28.34 | RP | Sorry - keyboard interfacing error :) |
| 10:28.45 | RP | I need to wake up :) |
| 10:28.47 | mickeyl | hehe. you should go to breakfast before typing :)) |
| 10:29.20 | RP | I'm blaming kergoth`zzz - talking to me until the early hours of the morning... ;-) |
| 10:29.51 | RP | Is this with or without your elpp changes? |
| 10:30.06 | mickeyl | without, it's a kernel from you |
| 10:30.18 | mickeyl | the last one we built during the ts finding series |
| 10:30.23 | mickeyl | s/we/you/ |
| 10:30.37 | RP | Hmmm. It doesn't do that for me... |
| 10:31.51 | RP | I'm really at a loss to explain it. It does show those messages as it suspend/sresumes here but not at any other time... |
| 10:32.21 | mickeyl | nm. nothing too much disturbing, but let's have an eye on that. |
| 10:32.34 | RP | Try a new image. If it still does it, I'll probe further... |
| 10:32.40 | mickeyl | will do |
| 10:32.46 | mickeyl | i'll build one now |
| 10:32.55 | RP | ok |
| 10:33.02 | Bernardo | good morning |
| 10:33.04 | RP | I'll try some breakfast :) |
| 10:33.11 | mickeyl | hehe |
| 10:33.12 | mickeyl | bon appetit |
| 10:35.46 | Bernardo | mickeyl: I've been unable to build wellenreiter, with the following error: |
| 10:35.48 | Bernardo | configwindow.cpp:376: error: 'class QComboBox' has no member named 'setCurrentText' |
| 10:36.11 | Bernardo | I have distro=oz-3.5.3 |
| 10:36.42 | mickeyl | interesting. no one had problems to build wellenreiter since ages |
| 10:37.04 | mickeyl | ah |
| 10:37.10 | mickeyl | let me check somethign |
| 10:37.23 | *** join/#oe oe_newbie (~kvirc@195.234.128.72) |
| 10:37.40 | Bernardo | I just blasted my whole build dirs and started from 0 |
| 10:37.48 | mickeyl | uh oh |
| 10:37.49 | Bernardo | trying to fix kdepimpi 2.0.0 |
| 10:37.51 | mickeyl | ~lart ar_ |
| 10:38.05 | mickeyl | hmm |
| 10:38.23 | mickeyl | say which qte version are you using? |
| 10:39.27 | mickeyl | ar_ changed something in the #if QT_VERSION stuff to take qte 2.3.10 into account |
| 10:39.29 | Bernardo | I think it is 2.3.10 snapshot |
| 10:39.39 | mickeyl | it will probably break with everything smaller than 2.3.10 |
| 10:39.53 | mickeyl | let me try to reproduce |
| 10:39.54 | *** join/#oe dkey| (~dkey@L0011P30.dipool.highway.telekom.at) |
| 10:39.56 | Bernardo | yes, you must change QT_VERSION >= 300 to QT_VERSION >= 0x030000 |
| 10:40.05 | Bernardo | that is what I had to do to kdepimpi |
| 10:40.57 | mickeyl | will take a while |
| 10:41.01 | mickeyl | load is 6 on my build machine |
| 10:41.06 | mickeyl | heh |
| 10:42.36 | mickeyl | ~hug uml |
| 10:42.38 | ibot | ACTION hugs uml |
| 10:42.45 | mickeyl | uml is the best thing since sliced bread |
| 10:42.55 | mickeyl | i can't count the number of reboots i saved thanks to it |
| 10:43.13 | mickeyl | especially when you're working on init stuff |
| 10:43.48 | Bernardo | :) |
| 10:43.54 | Bernardo | I have to learn to work with it |
| 10:53.02 | mickeyl | any shell experts around? |
| 10:53.15 | mickeyl | how can i get the result code ? |
| 10:53.20 | mickeyl | i.e. i want to do |
| 10:53.24 | pb_ | $? |
| 10:53.27 | mickeyl | result= run a script |
| 10:53.35 | mickeyl | if result; do something |
| 10:53.38 | mickeyl | else; do something else |
| 10:53.40 | mickeyl | oh $? |
| 10:53.43 | pb_ | yeah |
| 10:53.46 | pb_ | or, you can just do |
| 10:53.58 | pb_ | if /some/script; then .... |
| 10:54.06 | mickeyl | ah great. exactly what i need. |
| 10:54.08 | mickeyl | thanks |
| 10:54.38 | mickeyl | hmm the more i know shell the more i like it :) |
| 10:56.20 | pb_ | fundamentally, "if <something>; then" just invokes <something> as a command and inspects its exit status. |
| 10:56.46 | pb_ | the "if [ foo == bar ];" syntax works because [ is a built-in function that sets its exit code based on whether the condition you specify is true or not. |
| 10:57.00 | mickeyl | ah, i see |
| 10:57.28 | mickeyl | so in general the exit code is an integer? |
| 10:57.35 | bluelightning | also, foo && bar |
| 10:57.42 | bluelightning | bar will only be executed if foo succeeds |
| 10:57.44 | mickeyl | shell just sets it based on return <whatever> in main() ? |
| 10:58.01 | bluelightning | mickeyl: yep |
| 10:58.08 | pb_ | yep, that's right |
| 10:58.27 | mickeyl | ok, so i should better be checking for zero and != zero |
| 10:58.33 | mickeyl | instead of 0 and 1 |
| 10:58.53 | pb_ | yes, probably a good idea |
| 10:59.15 | pb_ | 0 always indicates success, and most programs return 1 on any failure, but sometimes you can get other exit codes for particular failure types. |
| 11:03.35 | Mardy | I installed bootstrap-image (1-2 days ago) in my zaurus C860 |
| 11:03.46 | Mardy | when the console scrolls, |
| 11:04.01 | Mardy | the upper 4 lines are left untouched, i.e. they don't scroll |
| 11:04.29 | Mardy | if I manually call "reset", then everything works perfectly |
| 11:04.38 | Mardy | is this a known issue? |
| 11:05.58 | mickeyl | do you see a logo on the console? |
| 11:06.13 | mickeyl | if yes, then i wouldn't call this an "issue". it's like the kernel works when a logo is set |
| 11:11.20 | *** join/#oe Marsupilami25 (~Marsupila@152.139-60-66-nokia-static.surewest.net) |
| 11:12.01 | Mardy | mickeyl: I see the logo just when it's booting |
| 11:12.11 | Mardy | then it disappears |
| 11:12.33 | mickeyl | it should disappear as soon as the first clear or reset has been issued |
| 11:12.41 | Mardy | "vi" always uses the whole screen; it's just the console, which has this problem |
| 11:14.25 | Mardy | then probably neither "clear" or "reset" is called |
| 11:15.05 | mickeyl | automatically no |
| 11:15.11 | mickeyl | the user calls clear or reset |
| 11:15.18 | mickeyl | when he wants to have the complete screen |
| 11:15.42 | mickeyl | some gettys do it |
| 11:16.28 | Mardy | the problem is, that "vi" uses the complete screen, |
| 11:16.56 | Mardy | and when it exits, it doesn't clean the screen |
| 11:17.16 | Mardy | so the first lines would always be as vi left them |
| 11:17.48 | mickeyl | hmm then just do ctrl-l or call clean right after logging in |
| 11:20.31 | Mardy | they don't work, "reset" is necessary |
| 11:20.43 | Mardy | ctrl+l clears the whole screen, |
| 11:21.01 | Mardy | but then the scrolling doesn't change the first 4 lines anyway |
| 11:21.47 | Mardy | anyway, that's not a big problem |
| 11:24.19 | chris144|home | folks, I am a bit stuck with the package mc which depends on package ncurses |
| 11:24.45 | pb_ | what's the problem? |
| 11:25.24 | chris144|home | for some reason ncurses does not get installed, even that mc.bb includes DEPENDS = \"ncurses glib-2.0\". |
| 11:26.22 | pb_ | what does the Depends line in your mc.ipk look like? |
| 11:26.35 | chris144|home | in the package list mc does not include any dep on ncurses, it is really weird |
| 11:26.46 | chris144|home | mc.ipk, let me look |
| 11:27.43 | chris144|home | pb_: how do I list a dep line in ipk? |
| 11:27.57 | pb_ | dpkg-deb -I mc.ipk | grep Depends |
| 11:28.04 | *** join/#oe dalibor (~topic@p508AE45B.dip.t-dialin.net) |
| 11:28.09 | chris144|home | thanks! |
| 11:29.23 | chris144|home | ok, I need to look for the dpkg-dep on ym system, I never dealt with ipkg or dpkg. hold on... |
| 11:29.36 | chris144|home | its a Suse system... |
| 11:30.24 | pb_ | ah. you might need to install it by hand, then. |
| 11:30.52 | chris144|home | shouldnt it be in the staging somewhere? |
| 11:31.01 | pb_ | no, we don't build dpkg-deb in oe |
| 11:31.06 | chris144|home | ok |
| 11:31.36 | pb_ | you could use ipkg-unbuild, which is in oe, but it's a bit less convenient. |
| 11:32.33 | chris144|home | it is a debian package right? i will install it... |
| 11:32.37 | pb_ | yeah |
| 11:33.09 | chris144|home | btw: what is the difference between ipkg and dpkg? |
| 11:35.31 | pb_ | ipkg is smaller |
| 11:35.55 | chris144|home | but obviously dpkg is able to handle ipk packages right? |
| 11:36.57 | pb_ | yeah |
| 11:37.01 | pb_ | and vice versa |
| 11:37.07 | chris144|home | ok |
| 11:37.30 | chris144|home | I think it need to get debian some time... |
| 11:47.26 | chris144|home | pb_: r u still there? |
| 11:47.52 | Bernardo | QOutputDev.cpp in qpdf2 also needs a QT_VERSION test corrected from 300 to 0x030000 |
| 11:48.05 | pb_ | yes |
| 11:48.17 | chris144|home | pb_: the ncurses is missind in the Depends line from mc. |
| 11:48.31 | chris144|home | but it is in the bb file, have a look |
| 11:48.37 | pb_ | what does the Depends line actually say? |
| 11:48.43 | chris144|home | hold on.. |
| 11:49.03 | pb_ | the DEPENDS in the .bb file is irrelevant to this problem |
| 11:49.04 | chris144|home | Depends: mc-locale*, libglib-2.0-0 (>= 2.6.1), libgcc1 (>= 3.4.3), libc6 (>= 2.3.2+cvs20040726) |
| 11:49.49 | pb_ | ok |
| 11:50.03 | pb_ | and the mc binary is actually linked against libncurses, right? |
| 11:50.41 | chris144|home | let me check |
| 11:51.55 | chris144|home | actually no, however it was at my last full oe build? |
| 11:52.00 | chris144|home | ok |
| 11:52.11 | chris144|home | a new patch maybe? |
| 11:52.23 | pb_ | I guess. |
| 11:52.43 | chris144|home | lets have a look at the mc package.. |
| 12:06.01 | *** join/#oe oggers (~ogger@57.Red-213-96-148.pooles.rima-tde.net) |
| 12:06.03 | *** join/#oe dkey (~dkey@L0012P17.dipool.highway.telekom.at) |
| 12:07.21 | chris144|home | pb_: it looks as if somebody patched the mc.bb file. Do you know how I cab get a history of changes to the mc.bb file in bk? |
| 12:07.32 | pb_ | bk prs mc.bb |
| 12:07.53 | chris144|home | ok, it is prs, I am more used to cvs...thanks! |
| 12:08.31 | pb_ | or use the web interface: http://openembedded.bkbits.net:8080/openembedded/hist/packages/mc/mc_4.6.0.bb?nav=index.html|src/|src/packages|src/packages/mc |
| 12:09.05 | chris144|home | cool! |
| 12:09.33 | pb_ | doesn't look it's been changed recently |
| 12:09.44 | chris144|home | that is right! |
| 12:10.27 | chris144|home | what could have happened though is that I removed another package from ym build that included libncurses. |
| 12:10.46 | chris144|home | and possibly mc used ncurses if it found it. |
| 12:11.00 | chris144|home | no cince it is gone mc does not look for it anymore |
| 12:11.20 | chris144|home | but still, why is mc not linked aginst ncurses then? |
| 12:11.51 | *** join/#oe zecke (~ich@83.169.146.40) |
| 12:12.06 | *** part/#oe zecke (~ich@83.169.146.40) |
| 12:12.41 | *** join/#oe zecke (~ich@83.169.146.40) |
| 12:13.07 | *** join/#oe zecke (~ich@83.169.146.40) |
| 12:13.22 | pb_ | zecke: heh, some problem with your computer? |
| 12:12.56 | RP | Yay. Sounds works across suspend/resumes now I've fixed the code :) |
| 12:13.02 | pb_ | RP: very good! |
| 12:13.30 | RP | I do like platform devices :) |
| 12:13.32 | zecke | pb_: good 'morning' |
| 12:13.42 | zecke | pb_: yeah irssi refused to join the channel or it did and didn't tell me |
| 12:14.05 | pb_ | --> zecke (~ich@83.169.146.40) has joined #oe |
| 12:14.05 | pb_ | <-- zecke (~ich@83.169.146.40) has left #oe |
| 12:14.05 | pb_ | --> zecke (~ich@83.169.146.40) has joined #oe |
| 12:14.05 | pb_ | <-- zecke has quit (Client Quit) |
| 12:14.12 | pb_ | looks like the latter :-} |
| 12:14.33 | zecke | now all looks good and I'll stay |
| 12:14.37 | pb_ | heh |
| 12:14.37 | zecke | sorry for the noise |
| 12:15.23 | *** join/#oe dave-osk (~db@adsl-69-107-48-231.dsl.pltn13.pacbell.net) |
| 12:23.55 | gints | mickeyl: did you got my two last mails? |
| 12:24.15 | gints | like ipaq.patch change |
| 12:24.19 | gints | and prboom.sh change |
| 12:25.54 | mickeyl | yeah |
| 12:25.59 | mickeyl | no time to look into yet |
| 12:26.52 | gints | ok.. |
| 12:27.11 | chris144|home | mc |
| 12:27.52 | chris144|home | wrong window, sorry:-) |
| 12:40.30 | chris144|home | pb_: I found the mc/ncurses problem: I removed gdb from ym RDEPENDS list. that caused ncurses not to be installed anymore on my target. mc actually uses it automatically if it finds it. as i said before : as stupid as it gets...but thanks for your help! |
| 12:43.08 | pb_ | ah, right |
| 12:43.39 | pb_ | bbl, gotta go into work for a bit |
| 12:49.19 | *** join/#oe zap (~zap@217.170.93.9) |
| 12:50.57 | RP | <cia> openzaurus-2.6: Update sound drivers - fix suspend/resume problems</cia> |
| 12:57.19 | Bernardo | mickeyl: the problem with wellenreiter seems to be the tests for QT_VERSION. If I change the 300 to 0x030000 it builds |
| 12:58.16 | Bernardo | Ah, the only place that needed changing was in gui/configwindow.cpp |
| 13:00.49 | zecke | Bernardo: wasn't it already changed? |
| 13:01.39 | zecke | Bernardo: Skyhusker sent me two patches for konq/E |
| 13:05.25 | *** join/#oe McK (~mck@cable240a021.usuarios.retecal.es) |
| 13:05.54 | Bernardo | zecke: at least when using distro=oz-3.5.3 wellenreiter still has that problem |
| 13:06.20 | Bernardo | the patches for konq/e, it would be extra cool if it fixed the cache problem |
| 13:06.21 | zecke | ah wellenreiter 1.0.3 |
| 13:07.17 | zecke | nice |
| 13:07.30 | zecke | Bernardo: I'll talk to mickeyl and see if he tagged or branched 1.0.3 |
| 13:07.42 | CIA-5 | 03mickeyl 07 * r1.3008.1.1 10openembedded/packages/sysvinit/ (sysvinit_2.86.bb sysvinit/rcS): sysinit: indicate success/failure based on return code during rcS (w/ELPP) |
| 13:10.12 | *** join/#oe mithro (~tim@dsl1-83.gw1.adl1.airnet.com.au) |
| 13:10.48 | CIA-5 | 03mickeyl 07 * r1.3018 10openembedded/packages/linux/openzaurus_2.6.11-rc2.bb: |
| 13:10.48 | CIA-5 | Merge bk://oe-devel@oe-devel.bkbits.net/openembedded |
| 13:10.48 | CIA-5 | into r2d2.tm.informatik.uni-frankfurt.de:/local/pkg/oe/packages |
| 13:10.51 | CIA-5 | 03mickeyl 07 * r1.3015.1.1 10openembedded/packages/linux/ (2 files in 2 dirs): oz-2.6: slightly adjust the elp patch |
| 13:12.16 | zecke | RP: did you encounter any big problem with the kernel-keymap patch? |
| 13:35.45 | *** join/#oe sc (~sc@p509244FC.dip0.t-ipconnect.de) |
| 13:41.37 | mickeyl | hmm d'oh |
| 13:41.43 | mickeyl | no nfs in 2.6 |
| 13:43.04 | Mardy | is there some program like "xev" in oe? |
| 13:43.23 | Mardy | I need to use it to figure out the keycodes under gpe |
| 13:43.30 | uv1 | Hi all |
| 13:44.50 | uv1 | Found some bugs again. libopie2 build (examples/opiemm) complains "isStereo" not found. Wouldn't it be helpfull to make its own package for the examples ? This is really boaring ! |
| 13:45.58 | mickeyl | rebuild libopie2 |
| 13:46.09 | uv1 | hostap_0.3.5 cannot be loaded from hostap.epitest.fi. you get a connect, but nothing happens any more. Any idea, where to get the package elsewhere ? |
| 13:46.12 | mickeyl | an additional method is no bug |
| 13:46.36 | uv1 | mickeyl: but should be available ? ;-) |
| 13:46.41 | mickeyl | of course |
| 13:46.43 | mickeyl | and it is |
| 13:46.54 | uv1 | mickeyl: since when and where ? |
| 13:47.19 | mickeyl | where = where it belongs to, see opiemm.h |
| 13:47.30 | mickeyl | when = since the first usage was there |
| 13:47.58 | mickeyl | actually osoundsystem.h, not opiemm.h |
| 13:48.06 | zecke | uv1: remove libopiemm from staging |
| 13:48.43 | zecke | mickeyl: the problem is more fundamental. OE puts staging_lib and staging_incdir before any other include/library path |
| 13:49.10 | mickeyl | oh you mean once again someone using Opie standalone against OE staging tree without telling me that? |
| 13:49.28 | zecke | mickeyl: no. If I compile libopie and then compile libopie again |
| 13:49.42 | Bernardo | uv1: google for it, I got it from a gentoo mirror |
| 13:49.46 | zecke | mickeyl: with the second libopie compile it uses the libraries in staging and not the newly compiled ones |
| 13:50.02 | mickeyl | this is correct |
| 13:50.13 | mickeyl | ok, i see |
| 13:50.26 | mickeyl | i'll come up with a fix |
| 13:50.27 | zecke | mickeyl: and it is a problem if you change the library (new headers are installed in advance of compiling) |
| 13:50.30 | Bernardo | uv1: and don't forget that after downloading it to your downloads dir, you need to generate a md5sum |
| 13:50.55 | zecke | mickeyl: the problem -I${STAGING_INCDIR} and -L${STAGING_LIB} should be after the 'local' paths |
| 13:51.03 | zecke | and not be the very first |
| 13:51.16 | mickeyl | i don't think we want to change that |
| 13:51.21 | mickeyl | that would open up a can of worms |
| 13:51.31 | mickeyl | i rather split the package up |
| 13:51.44 | mickeyl | compiling binaries and libs in one package wasn't a good idea from the start |
| 13:51.59 | uv1 | Bernardo: A search for "hostap +source +0.3.5" did not really lead me to gentoo. Do you have a full path for me ? |
| 13:52.05 | uv1 | mickeyl: Thanks ;-) |
| 13:52.37 | zecke | mickeyl: and we would need do_stage_headers do_stage_libs. And stage the headers before compiling... |
| 13:53.58 | Bernardo | uv1: no, I just looked for the exact .tar.gz name that oe was trying to download |
| 13:54.10 | uv1 | zecke: Thanks, that worked ;-) |
| 13:54.25 | Bernardo | I don't recall the exact site, because I downloaded it on another machine |
| 13:57.06 | uv1 | Bernardo: Could we not use that site as an alternative for this package ? |
| 13:57.39 | bluelightning | is qte supposed to build right now? seems qt-embedded-2.3.10-snapshot-20050120 can't be found |
| 13:59.28 | mickeyl | ya that's the problem with snapshots |
| 13:59.34 | mickeyl | ~lart TT for being unable to release programs |
| 13:59.47 | bluelightning | what's the last usable version? |
| 13:59.48 | zecke | mickeyl: should I mirror a qt-e snapshot on my hh.org site? |
| 13:59.48 | mickeyl | go ahead and declare a snapshot a release |
| 13:59.52 | mickeyl | then put it up to handhelds.org |
| 13:59.57 | mickeyl | or openzaurus.org/mirror |
| 14:00.01 | mickeyl | and then lets take it from there |
| 14:00.03 | mickeyl | zecke: yeah, or that |
| 14:02.21 | uv1 | Bernardo: Thanks, sometimes the most obvious search pattern is better than even a regex ;-) |
| 14:03.22 | zecke | kergoth`zzz: do you know what K_PPARENR is? KeyPad Parenthis Right? I've never seen that... |
| 14:04.30 | bluelightning | zecke: I don't have a working cross-build of qt/opie atm, and OE uicmoc-native requires the new qt snapshot... so I guess I will have to wait |
| 14:04.39 | bluelightning | (to test the patch that is) |
| 14:05.30 | zecke | bluelightning: you could rename the qte-2.3.10 file |
| 14:05.52 | uv1 | And here is a line stopper. Using the freshly build image (from this morning) my CL860 is not able to calibrate. The first touch on the display shows the cross-hair and then the system is not willing to go on. Tried a differnet kernel, no change, tried the new kernel with the official OZ3.5.2 initrd worked. Anyone else having that problem ? |
| 14:05.53 | mithro | so what are people up to? |
| 14:06.18 | zecke | bluelightning: ftp://ftp.trolltech.com/qt/snapshots/qt-embedded-2.3.10-snapshot-20050129.tar.gz |
| 14:06.34 | bluelightning | zecke: thanks |
| 14:07.02 | zecke | uv1: Might be striking a problem with my new and untested rading of raw samples :} |
| 14:07.10 | mithro | dont you just love internet pyrimid schemes |
| 14:07.34 | zecke | uv1: look at the tslib.patch that is applied to QtE |
| 14:13.06 | uv1 | zecke: found the patch. What kind of info can I get out regarding that prob ? |
| 14:14.00 | zecke | uv1: If it crashes on calibration, I've luckily failed with the logic to read a raw sample |
| 14:14.55 | uv1 | zecke: And now ? |
| 14:15.17 | zecke | uv1: play with it |
| 14:15.27 | zecke | uv1: or do not apply the patch |
| 14:15.49 | uv1 | zecke: :-O |
| 14:16.04 | zecke | uv1: look at the commit message of that patc |
| 14:16.06 | zecke | h |
| 14:16.15 | zecke | it clearly says please test and that I didn't test it |
| 14:17.37 | zecke | I'm busy with the kernel-keymap patch, you could help me and find the problem in the readInterpolateSample |
| 14:17.48 | uv1 | So I will try ... |
| 14:18.04 | zecke | uv1: or use Qt2.3.7 if you need something working now |
| 14:18.22 | RP | zecke: I set a build away with the keymap patch yesterday. I'll test it now :) |
| 14:19.33 | *** join/#oe marcansoft (1337@80-29-50-207.adsl.nuria.telefonica-data.net) |
| 14:30.10 | RP | zecke: I've just tried the keyboard. Simple letter keys work. Keys such as tab, enter, arrow keys, shift etc. don't :-/ |
| 14:36.58 | *** join/#oe ycheng (~ycheng@tlug.sinica.edu.tw) |
| 14:38.41 | *** join/#oe robmv (~robert@200.109.22.73) |
| 14:49.42 | bluelightning | night all |
| 14:55.57 | *** join/#oe micropal (ident@139.80-202-82.nextgentel.com) |
| 15:01.11 | CIA-5 | 03mickeyl 07 * r1.3019 10openembedded/packages/opie-examples/opie-examples_cvs.bb: add opie-examples |
| 15:09.30 | *** join/#oe offroadgeek (~offroadge@dsl027-191-249.sfo1.dsl.speakeasy.net) |
| 15:10.56 | *** join/#oe rob_w (~roboo@p83.129.177.155.tisdip.tiscali.de) |
| 15:13.28 | *** join/#oe gremlin[it] (~gremlin@194-185-220-105.f4.ngi.it) |
| 15:14.20 | gremlin[it] | Hi to all ... |
| 15:15.29 | gremlin[it] | info : finally i was able to sucessfully end the compilation of meta-gpe ... and now where are packeges *.ipkg ??? |
| 15:27.41 | *** join/#oe treke|home (~ggilbert@69-175-32-221.ventca.adelphia.net) |
| 15:35.06 | gremlin[it] | hi treke |
| 15:37.32 | gremlin[it] | hi kergoth |
| 15:38.09 | *** join/#oe mithro (~tim@dsl1-83.gw1.adl1.airnet.com.au) |
| 15:39.55 | kergoth | hey |
| 15:40.35 | kergoth | heh, rpm is switching to sqlite3 instead of bdb |
| 15:40.37 | kergoth | nifty |
| 15:41.12 | jcrouse | rpm made a right decision? |
| 15:41.13 | jcrouse | No way |
| 15:42.02 | kergoth | hehe |
| 15:43.36 | gremlin[it] | kergoth ... where i read thet ? |
| 15:44.20 | jcrouse | Thats in 4.4? |
| 15:44.21 | gremlin[it] | ufff ... so tired .. my english is too bad .... |
| 15:44.35 | gremlin[it] | kergoth .. where u read abour 'new' rpm ? |
| 15:44.39 | kergoth | jcrouse: the upcoming 4.4.1 or 4.4.2 will use sqlite |
| 15:44.46 | kergoth | gremlin[it]: talking to rpm devs |
| 15:44.50 | gremlin[it] | nice ;) |
| 15:45.24 | jcrouse | kergoth: I'll be Montavista had a hand in that |
| 15:45.27 | kergoth | jcrouse: heh, the main cross issue i ran into yesterday is already opened in the bugzilla by one of the montavista guys :) |
| 15:45.35 | kergoth | just the fix hasnt been checked in yet |
| 15:48.02 | jcrouse | Still doesn't help the horrible dependency handling, and the lack of feed support |
| 15:48.05 | jcrouse | But its a start |
| 15:51.57 | chouimat | morning |
| 15:52.07 | kergoth | morning |
| 16:15.08 | treke|home | morning kergoth, cos, choiumat |
| 16:15.35 | *** join/#oe Camelot (~Anon@ppp685.adelaide.on.net.au) |
| 16:19.23 | *** part/#oe Camelot (~Anon@ppp685.adelaide.on.net.au) |
| 16:20.13 | *** join/#oe gremlin[it] (~gremlin@194-185-220-105.f4.ngi.it) |
| 16:20.18 | *** join/#oe qfh (~qfh@ppp-62-245-210-140.mnet-online.de) |
| 16:20.33 | gremlin[it] | hi again ... |
| 16:21.07 | gremlin[it] | question about oe : finally i was able to build with bitbake 'meta-gpe' ... but where are alal packeges ... .ipkg files ? |
| 16:21.26 | gremlin[it] | where is |
| 16:21.30 | *** join/#oe Camelot (~Anon@ppp685.adelaide.on.net.au) |
| 16:21.46 | *** part/#oe Camelot (~Anon@ppp685.adelaide.on.net.au) |
| 16:25.44 | kergoth | gremlin[it]: tmp/deploy/ipk |
| 16:26.47 | gremlin[it] | DOH !!! i try with find -name '*.ipkg' !!! :( :( :( |
| 16:26.54 | kergoth | heh |
| 16:27.39 | *** join/#oe _McK (~mck@cable240a021.usuarios.retecal.es) |
| 16:27.40 | *** join/#oe __McK__ (~mck@cable240a021.usuarios.retecal.es) |
| 16:27.41 | gremlin[it] | mhh builing gpe-image i'll obtain a jffs2 filesystem to flash directly on my device .. right ? |
| 16:28.00 | kergoth | yes |
| 16:28.06 | kergoth | itll be in tmp/deploy/images/ |
| 16:28.49 | gremlin[it] | last question ... if i want to build a gpe-image wth a reduced numeber of already installed packages ... what i can do ? |
| 16:29.16 | kergoth | cp gpe-image.bb gpe-image-gremlin.bb |
| 16:29.21 | kergoth | vi gpe-image-gremlin.bb |
| 16:29.25 | kergoth | -blah blah- |
| 16:29.26 | kergoth | :wq |
| 16:29.30 | kergoth | bitbake gpe-image-gremlin |
| 16:29.35 | kergoth | heh |
| 16:31.21 | uv1 | Can someone advise me, how to setup an bb file to get an ipk out of a uverdef library. Configure and compilation works already, but I only get an abc-dev_x.y.z.ipk always. |
| 16:31.34 | gremlin[it] | kergoth ok ... perfect :) |
| 16:32.25 | kergoth | uv1: do_install. |
| 16:32.38 | kergoth | uv1: install the files into ${D} |
| 16:32.47 | kergoth | uv1: i.e. put the binary in ${D}/${bindir}/ |
| 16:33.03 | kergoth | it'll automatically break things out into subpackages in a sane fashion based on hte contents of ${D} |
| 16:33.34 | uv1 | kergoth: Thanks, will try that. |
| 16:35.20 | gremlin[it] | kergoth on gpe-image.bb there is only macro block packages ... i suppose i have tou touch lot of .bb files ;) ... i would create a super small H3600 gpe ... with a good amount of gpe application but with only hardware support for H3600 internal devices ... |
| 16:35.49 | kergoth | gremlin[it]: nod, its likely installing some task packages emitted by meta-gpe, right? so you'd create a custom meta-gpe too. |
| 16:36.55 | gremlin[it] | yes ... maybe also i need to touch task-booststrap to cut off many kernel modules |
| 16:37.53 | kergoth | gremlin[it]: kernel modules are usually added to task-bootstrap by the machine or distro .conf |
| 16:38.14 | gremlin[it] | ok |
| 16:38.21 | kergoth | gremlin[it]: mkdir build/conf/machine; cp openembedded/conf/machine/whatever.conf build/conf/machine/ .. then itll use the build one instead, and you can make changes without modifying the oe versions |
| 16:38.27 | *** join/#oe zwi (~zwi@216.88.131.43) |
| 16:38.51 | gremlin[it] | tank so much ! |
| 16:38.58 | kergoth | np |
| 16:40.39 | gremlin[it] | files in build/conf have priority over openembedded/conf without any extra option to use in bitbake ? |
| 16:41.02 | kergoth | bitbake obeys BBPATH |
| 16:41.10 | kergoth | if build is before openembedded in BBPATH, those will be used |
| 16:41.30 | gremlin[it] | OK |
| 16:45.16 | *** join/#oe darkschneider (~gab@81-208-36-80.fastres.net) |
| 16:47.21 | uv1 | OK, have initrd and zImage of feed from today running (using qte 2.3.7 because of the calibration problem). Is it a known problem, that the "Fn" key does not work on CL860 ? |
| 16:55.46 | treke- | ugh |
| 16:56.04 | treke- | one of my office mates threw out food in our trashcan. We have no freaking air circulation in here |
| 16:58.04 | jcrouse | Not to mention, its Saturday |
| 16:58.41 | treke- | smells like rotten banana in here |
| 16:59.45 | uv1 | kergoth: Just builded opie-zsafe and called install task. An ipk is generated, but not listed in the Packages file in deploy/ipk. How to rebuild that ? |
| 17:00.22 | kergoth | Packages is only built when oe needs to build it to create an image. |
| 17:01.06 | uv1 | kergoth: Isn't it planned to use the ipk dir as a packages feed ? |
| 17:02.00 | Mardy | uv1: hi, I ran into the very same problem (Fn key not working) |
| 17:02.11 | Mardy | uv1: are you subscribed to the gpe mailing list? |
| 17:02.12 | *** join/#oe chewy (~dieu@r2351064.cidc.net) |
| 17:02.25 | uv1 | Mardy: No I am opie ;-) |
| 17:02.27 | treke- | you use ipkg-build-packages from ipkg-utils to recreate a Packages file |
| 17:02.49 | Mardy | uv1: oh, sorry, I just created a working keymap file for gpe :-) |
| 17:07.35 | gremlin[it] | mhhh error buildig gpe-image .... ERROR: Cannot satisfy the following dependencies for gpe-task-base: |
| 17:07.35 | gremlin[it] | | Installing libgpg-error0 (0.7-r3) to root... |
| 17:07.49 | RP | uv1: I think that could be the result of some work in progress by zecke on the qte keymap |
| 17:08.02 | kergoth | uv1: hm? |
| 17:08.17 | kergoth | uv1: there are feed .bb's, but under normal circumstances you'd maintain the feed yourself. |
| 17:08.29 | kergoth | OE is a build tool, not a feed maintainance tool |
| 17:22.43 | uv1 | kergoth: Ok, will care for that myself. Bye for now, will drink some good spanish red wine now ;-) |
| 17:23.41 | kergoth | good plan |
| 17:27.41 | RP | hi zecke |
| 17:28.01 | zecke | hehe uv1 suffers badly from my work :) |
| 17:28.11 | gremlin[it] | >>> NOTE: preferred version 4.1 of rxvt-unicode not available |
| 17:28.14 | RP | Is there anything I need to do to enable the new keyboard driver? |
| 17:30.18 | RP | zecke: Which keyboard type does the Zaurus use? |
| 17:30.54 | RP | TTY? |
| 17:33.47 | zecke | hmm, I run it without any QWS_KEYBOARD export |
| 17:34.56 | *** join/#oe robilad (~topic@mpiat2305.ag2.mpi-sb.mpg.de) |
| 17:40.46 | jcrouse | gremlin[it]: yeah, thats a problem |
| 17:41.04 | jcrouse | They pulled their legacy stuff from the website, its 4.8 or nothing now |
| 17:44.01 | *** join/#oe micropal_ (ident@139.80-202-82.nextgentel.com) |
| 17:44.36 | koen | jcrouse: the legacy stuff should be under Attic |
| 17:44.40 | jcrouse | is it? |
| 17:44.45 | treke- | yeah |
| 17:44.50 | jcrouse | I had this problem a few days ago, and tried to find it |
| 17:44.58 | treke- | there was a patch for that this morning |
| 17:45.02 | koen | someone posted a patch for it on the oe-ml |
| 17:45.20 | treke- | which was promptly disregarded :) |
| 17:45.25 | treke- | http://dist.schmorp.de/rxvt-unicode/Attic/rxvt-unicode-4.1.tar.bz2 |
| 17:45.36 | jcrouse | Well, looky there |
| 17:45.50 | gremlin[it] | in fact was buildrxvt-unicode-4.8 but seem gpe-image prefear 'old' 4.1 |
| 17:46.02 | jcrouse | Thats still slightly annoying, but less annoying then it just disappearing... :) |
| 17:46.06 | kergoth | jcrouse: http://people.redhat.com/laroche/pyrpm/. heh |
| 17:46.17 | treke- | The old bbs were deleted as well iirc |
| 17:46.46 | jcrouse | kergoth: heh |
| 17:47.19 | jcrouse | kergoth: do you need the RPM api libraries to use that? |
| 17:47.38 | *** part/#oe robilad (~topic@mpiat2305.ag2.mpi-sb.mpg.de) |
| 17:47.54 | kergoth | jcrouse: no |
| 17:48.09 | jcrouse | note to self: Read the import line before asking stupid questions |
| 17:48.13 | kergoth | hehe |
| 17:48.18 | jcrouse | sweet |
| 17:48.24 | jcrouse | you going to add that to the libbb? |
| 17:48.57 | kergoth | might be worth doing. the src_rpm parser could actually use this to get at the data rather than calling out rpm, and it could be used instead of rpm2cpio for the unpack |
| 17:49.13 | jcrouse | nod |
| 17:49.51 | jcrouse | brings up a whole new world of compatabilty - especially for binary packages that are distributed as .rpms |
| 17:50.53 | kergoth | <PROTECTED> |
| 17:50.54 | kergoth | twisted |
| 17:51.44 | jcrouse | didn't you do that with MV rpms early in the OE experience? |
| 17:51.45 | koen | kergoth: france told me he used some rsh foo to build arm rpm on x86 that executed make test on an arm system |
| 17:51.53 | koen | that is twisted |
| 17:51.57 | kergoth | heh |
| 17:52.06 | gremlin[it] | byeeeeeeeee |
| 17:52.10 | koen | bye gints |
| 17:52.11 | kergoth | just use the binfmt_misc stuff that scratchbox does to automatically execute arm binaries on a remote machine :) |
| 17:52.22 | koen | ~lart tabcompletion |
| 17:56.54 | zecke | kergoth: Can you confirm I need to handle NumLock and Keypad myslef |
| 18:06.06 | RP | zecke: I'm still uneasy about this keymap code. I still think we should be using XLATE with something added to fins out the status of the modifer keys... |
| 18:06.19 | RP | s/fins/find/ |
| 18:07.40 | mickeyl | zecke: no worries, FN never worked on c7x0 under Opie |
| 18:07.49 | mickeyl | your work didn't make it worse |
| 18:08.21 | RP | mickeyl: I thought it did work? |
| 18:08.45 | RP | mickeyl: How does zecke's patch work for you? Do you arrow keys work under opie? |
| 18:09.07 | mickeyl | RP: no, FN never worked. neither under the old hacked sharp keymap nor under the new yet |
| 18:09.11 | mickeyl | let me check arrows... |
| 18:10.40 | zecke | just write a proper keymap ;) |
| 18:10.53 | *** join/#oe rob_w (~roboo@p213.54.156.238.tisdip.tiscali.de) |
| 18:11.15 | RP | zecke: the keymap is fine. Even Shift to get a capital letter isn't working here :-/ |
| 18:11.36 | mickeyl | yes, arrows work here |
| 18:11.51 | mickeyl | everything works here except FN |
| 18:12.07 | RP | mickeyl: Is there something I need to enable to make things work? |
| 18:12.23 | mickeyl | no, this is a fresh openzaurus-pxa-2.6 build |
| 18:12.30 | mickeyl | w/ DISTRO=openzaurus-3.5.3 |
| 18:12.37 | mickeyl | no special tweaks |
| 18:13.04 | RP | Hmmm. My distro is set to "openzaurus" |
| 18:13.24 | mickeyl | shouldn't make much of a difference |
| 18:13.32 | mickeyl | root@openzaurus-pxa-2:/root# ipkg status libqte2 |
| 18:13.32 | mickeyl | Package: libqte2 |
| 18:13.32 | mickeyl | Version: 2.3.10-snapshot-20050120-r7 |
| 18:13.32 | mickeyl | Depends: libts-0.0-0 (>= 0.0cvs20050126), libc6 (>= 2.3.2+cvs20040726), libpng12-0 (>= 1.2.7), libz1 (>= 1.2.2), libjpeg62 (>= 6b), libgcc1 (>= 3.4.3) |
| 18:13.32 | mickeyl | Status: install ok installed |
| 18:13.33 | mickeyl | Architecture: zaurus-clamshell |
| 18:13.40 | mickeyl | which one do you have? |
| 18:14.54 | RP | 2.3.7-r21 :-/ |
| 18:15.10 | mickeyl | ups |
| 18:15.11 | mickeyl | hehe |
| 18:15.14 | mickeyl | no wonder then |
| 18:15.32 | mickeyl | i think we no longer care about 2.3.7 |
| 18:15.37 | RP | :) |
| 18:15.50 | RP | How I've managed that I don't know... |
| 18:16.12 | mickeyl | btw., can you remind me where the POWER constants live ? |
| 18:16.16 | mickeyl | (i.e. in which header file) |
| 18:16.26 | RP | include/linux/fb.h |
| 18:16.30 | mickeyl | thanks |
| 18:17.32 | mickeyl | the VESA ? |
| 18:17.42 | zecke | RP: what is the FN key (kergoth treated it as F22 and Alt Modifier) |
| 18:17.48 | zecke | we could treat it as AltGr for now? |
| 18:18.06 | RP | I use it as AltGr under the kernel map |
| 18:18.13 | mickeyl | very good |
| 18:18.16 | mickeyl | i would support that |
| 18:18.26 | zecke | mickeyl: and why doesn't it work for you? |
| 18:18.38 | mickeyl | hmm why oh why |
| 18:18.40 | mickeyl | no idea why |
| 18:18.57 | mickeyl | what was that key diagnose thing again? |
| 18:19.03 | mickeyl | opie-keyview or so |
| 18:19.07 | zecke | yes |
| 18:19.08 | mickeyl | let me check if that's in oe |
| 18:19.13 | zecke | probably not |
| 18:19.33 | mickeyl | while we are doing these 2.6 things i thought we really need one diagnosis app |
| 18:19.45 | mickeyl | featureing keyboard, ts, sounds, leds, etc. |
| 18:19.48 | mickeyl | wouldn't that be nice? |
| 18:20.07 | RP | Maybe add a bitbake file that adds ts_calibrate, ts_test etc to the image? |
| 18:20.25 | mickeyl | ah well i thought about a more integrated solution |
| 18:20.42 | RP | mickeyl: In the backlight drivers we use the codes FB_BLANK_NORMAL, FB_BLANK_UNBLANK etc. |
| 18:21.10 | mickeyl | those are not in fb.h |
| 18:21.21 | RP | mickeyl: They're in the enum |
| 18:21.41 | mickeyl | which kernel version? |
| 18:24.08 | mickeyl | aha, that's new |
| 18:24.23 | mickeyl | it's not in 2.6.8.1 |
| 18:24.28 | mickeyl | (which i appear to have on the desktop) |
| 18:24.32 | mickeyl | i see the enum now |
| 18:24.41 | mickeyl | heh and they just map to the vesa stuff |
| 18:24.45 | mickeyl | so i will stick to those |
| 18:25.32 | mickeyl | does the fb driver react to all of 'em? |
| 18:25.37 | mickeyl | or just unblack + normal ? |
| 18:29.43 | RP | It reacts to them all but just treats it as blank and unblank |
| 18:30.17 | pb_ | re |
| 18:30.25 | koen | pb_: wb |
| 18:30.38 | RP | pb_: hello |
| 18:31.04 | RP | mickeyl: It won't neccessarily always follow the vesa stuff... |
| 18:31.31 | mickeyl | ok |
| 18:31.38 | mickeyl | buf[0] = on ? FB_BLANK_UNBLANK : FB_BLANK_BLANK; |
| 18:31.44 | mickeyl | ok? |
| 18:32.15 | RP | I'd use FB_BLANK_POWERDOWN |
| 18:32.43 | mickeyl | yep, me too |
| 18:32.44 | RP | The reason being that one gives the best powersavings if someone ever does imlement different power levels |
| 18:32.47 | mickeyl | i just #define'd it |
| 18:33.14 | mickeyl | we don't include the kernel headers so i have to grab the defines |
| 18:33.59 | RP | Ok |
| 18:35.57 | mickeyl | *commited* (to opie head) |
| 18:39.28 | RP | mickeyl: sounds good :) |
| 18:39.38 | RP | mickeyl: Will that flow into a bb build if I do one now? |
| 18:40.00 | RP | an oe build even... |
| 18:40.01 | zecke | RP: if you set cvsdate for libopie to tomorrow yes |
| 18:40.51 | mickeyl | RP: or use the openzaurus-3.5.3 |
| 18:40.55 | mickeyl | let me sync' mine |
| 18:41.53 | mickeyl | up. |
| 18:42.32 | CIA-5 | 03mickeyl 07 * r1.3020 10openembedded/conf/distro/openzaurus-3.5.3.conf: update oz-3.5.3.conf |
| 18:54.09 | *** join/#oe aloph1 (~aloph@cnet-cable-189-85-185.canbrasnet.com.br) |
| 19:00.34 | CIA-5 | 03pb 07 * r1.3021 10openembedded/packages/gpe-todo/gpe-todo_0.51.bb: update gpe-todo to 0.51 |
| 19:06.04 | kergoth | RP: i was thinking last night that there should be two supplementary libraries for bitbake-ng. one is the handlers for executable metadata, the other is the common metadata store, likely with modular backends for how and where its stored. |
| 19:06.23 | kergoth | that sound good? |
| 19:06.41 | pb_ | afternoon kergoth |
| 19:06.57 | kergoth | hey |
| 19:07.42 | CIA-5 | 03pb 07 * r1.3022 10openembedded/packages/gpe-dm/gpe-dm_0.43.bb: update gpe-dm to 0.43 |
| 19:08.41 | pb_ | stupid thing seems to crash the machine after about three minutes |
| 19:08.58 | RP | kergoth: Yes, that sounds quite sensible |
| 19:09.38 | kergoth | http://hyperion.kergoth.com/bitbake-ng/design_spec/index.html |
| 19:10.03 | kergoth | (mostly empty, but thats the new layout) |
| 19:11.23 | CIA-5 | 03pb 07 * r1.3023 10openembedded/packages/gkdial/ (5 files in 2 dirs): apply gkdial patch from Florian Boor |
| 19:13.28 | kergoth | (the metadata supplementary lib is totally wrong, its just the old metadata component moved to a differnet location in the doc) |
| 19:19.34 | RP | "linked list of variables that refer to this one" - I think that is the key phase for an sql database implementation... |
| 19:21.42 | kergoth | variable referrer tracking and variable expansion actually belongs in the recipe handler, not the metadata library, since how thats done is completely dependent on the file format and variable contents |
| 19:22.06 | kergoth | well, actually i suppose tracking could be in the metadata lib, now that i think about it |
| 19:22.13 | kergoth | yeah, dont mind me, thatll work |
| 19:22.16 | kergoth | heh |
| 19:23.28 | RP | :) |
| 19:23.33 | RP | got to go - back later |
| 19:27.45 | gints | someone knows why Verdana font is removed from packages? |
| 19:27.49 | gints | for opie |
| 19:28.03 | CIA-5 | 03pb 07 * r1.3024 10openembedded/ (4 files in 3 dirs): update dbus to 0.23 |
| 19:29.18 | gints | and also why font rotated versions are not included |
| 19:38.21 | CIA-5 | 03pb 07 * r1.3026 10openembedded/packages/bluez-libs/bluez-libs_2.14.bb: update bluez-libs to 2.14 |
| 19:38.23 | CIA-5 | 03pb 07 * r1.3025 10openembedded/ (8 files in 3 dirs): update bluez-utils to 2.14 |
| 19:42.20 | CIA-5 | 03pb 07 * r1.3028 10openembedded/BitKeeper/deleted/ (8 files): blow away some old versions of gpe-package |
| 19:42.23 | CIA-5 | 03pb 07 * r1.3027 10openembedded/BitKeeper/deleted/ (5 files): blow away some old versions of gpe-appmgr |
| 19:42.35 | treke- | hehe I was right. They don't think they can do it in one day |
| 19:42.57 | treke- | gints: Because we it was not properly licensed for out use. |
| 19:43.06 | treke- | bleh |
| 19:43.11 | treke- | I can type |
| 19:43.18 | pb_ | treke-: crumbs, must be one hell of a tv you have. |
| 19:43.25 | treke- | indeed |
| 19:43.49 | CIA-5 | 03pb 07 * r1.3029 10openembedded/BitKeeper/deleted/ (3 files): blow away some old versions of gpe-todo |
| 19:44.55 | CIA-5 | 03pb 07 * r1.3030 10openembedded/BitKeeper/deleted/ (4 files): blow away some old versions of gpe-gallery |
| 20:20.20 | *** join/#oe [g2] (~g2@66.57.8.35) |
| 20:28.22 | *** join/#oe pclabs (~barnaba@host220-137.pool8251.interbusiness.it) |
| 20:30.30 | *** join/#oe dkey| (~dkey@L0005P29.dipool.highway.telekom.at) |
| 20:49.58 | *** join/#oe bluelightning (~bluelight@203-173-245-45.akl.ihugultra.co.nz) |
| 20:57.48 | zecke | kergoth: I can't figure how to make keypad work |
| 21:00.11 | *** join/#oe CIA-temp731 (~CIA@flapjack.navi.cx) |
| 21:01.03 | RP | mickey|tv: the 2.6 kernel just broke with an undefined reference to an elpp function ;-) |
| 21:09.34 | treke|wow | bad mickey :) |
| 21:09.40 | treke|wow | I just came home to that error |
| 21:14.02 | zecke | yeah what a behaviour. Breaking it and going to watch tv ;) |
| 21:17.21 | *** join/#oe Toi (~pleemans@dD577A871.access.telenet.be) [NETSPLIT VICTIM] |
| 21:17.21 | *** join/#oe Pendalar (Pendalar@h205.64.40.69.ip.alltel.net) |
| 21:18.03 | zecke | kergoth: could it be that the KeyPad is always the same? |
| 21:18.56 | RP | treke|wow: The "fix" is to delete the elpp patch from openzaurus-2.6.11-rc2.bb :) |
| 21:20.01 | *** join/#oe micropal (ident@139.80-202-82.nextgentel.com) |
| 21:21.28 | *** join/#oe darkschneider (~gab@81-208-36-80.fastres.net) |
| 21:27.08 | treke|wow | :p |
| 21:36.17 | jcrouse | hmmm... Honda Acord or Nissan Maxima? |
| 21:36.40 | treke|wow | new car shopping? |
| 21:36.54 | jcrouse | wife |
| 21:37.00 | jcrouse | for the wife, I should say |
| 21:37.17 | treke|wow | ah |
| 21:37.27 | treke|wow | I didn't like the accord much, too cramped |
| 21:37.32 | treke|wow | but your wife may be smaller |
| 21:38.47 | jcrouse | yeah, that was our impression too |
| 21:38.58 | jcrouse | a bit smaller then the maxima, but its a honda |
| 21:39.07 | treke|wow | I knocked my head good trying to get into it :p |
| 21:39.23 | jcrouse | heh - I guess we're biased because of her current car |
| 21:39.28 | jcrouse | Now that sumbitch is a coffin |
| 21:39.36 | treke|wow | what kind? |
| 21:39.48 | jcrouse | Ford Tempo |
| 21:39.56 | jcrouse | 94 - its officially a POS |
| 21:40.45 | treke|wow | ah |
| 21:40.46 | treke|wow | yeah |
| 21:40.59 | treke|wow | my grand father had one of those until the day he died |
| 21:43.59 | *** join/#oe florian (~fuchs@p5092871B.dip0.t-ipconnect.de) |
| 21:44.02 | florian | hi all |
| 21:44.15 | treke|wow | to be fair to the accord, I don't think I was comfortable in many of the japanese cars I tried |
| 21:44.29 | zecke | hey florian |
| 22:15.33 | *** join/#oe mrz80 (~scotsman@ip24-136-33-61.ga.at.cox.net) |
| 22:46.30 | kergoth | i need to fix it, but i need to know where to point the subdomain to |
| 22:48.07 | mickey|tv | RP: ok, i'm checking that now. i want apply the patch unconditionally but just enable/disable it with the options |
| 22:49.02 | koen|tv | mickey|tv: you can start tagging 1.1.9 if you're ready |
| 22:49.30 | mickey|tv | koen|tv: oh so quick? can you give us until tuesday? |
| 22:49.55 | koen|tv | no rush |
| 22:50.18 | koen|tv | you can tag it when you want to |
| 22:50.33 | mickey|tv | i'll alert the folks on opie-devel to checkin important stuff if they've anything left |
| 22:50.49 | mickey|tv | cvs has been more or less calm the last days so i expect it to be ok |
| 22:50.56 | mickey|tv | (except me moving stuff forth and back heh) |
| 22:51.34 | koen|tv | expect some testing images to hit the street around monday/tuesday |
| 22:51.40 | mickey|tv | k, good |
| 22:52.08 | koen|tv | depending on how boring my classes are :) |
| 22:52.27 | mickey|tv | RP: heh, found it |
| 22:52.34 | mickey|tv | RP: yes '' | oe_runmake oldconfig |
| 22:52.37 | mickey|tv | that can be dangerous :) |
| 22:54.23 | *** join/#oe scanlime (~micah@128.138.74.40) |
| 22:56.15 | koen|tv | 'night all |
| 22:56.20 | mickey|tv | g'night koen|tv |
| 22:56.31 | mickey|tv | RP: fixed. |
| 22:57.02 | CIA-4 | 03mickeyl 07 * r1.3031 10openembedded/packages/linux/openzaurus_2.6.11-rc2.bb: oz-kernel-2.6: disable elpp in .config instead of just using the defaults :D |
| 23:06.10 | *** join/#oe macmac (~mac@f03m-2-82.d1.club-internet.fr) |
| 23:12.26 | zecke | good nite |
| 23:13.46 | pb_ | zecke: good night |
| 23:14.05 | zecke | pb_: have fun pal |
| 23:14.08 | zecke | have fun pals |
| 23:15.54 | bluelightning | zecke: night |
| 23:16.26 | bluelightning | zecke: btw, kdepim just finished compiling, so I'll put the results in the bug report |
| 23:16.43 | zecke | yes please do so |
| 23:18.37 | bluelightning | zecke: dunno if you're still there, but it doesn't crash anymore... :-/ |
| 23:18.44 | zecke | lol |
| 23:18.59 | zecke | bluelightning: do you get additional warnings? did it eat your abook? |
| 23:19.04 | bluelightning | I don't see your debugging message either, but maybe I'm just not looking |
| 23:19.08 | zecke | bluelightning: run the app with --nofork |
| 23:19.24 | bluelightning | I didn't give it a chance to eat it, I just used the Konnector debugger |
| 23:19.27 | mickey|tv | --nofork ? |
| 23:20.33 | mickey|tv | g'night |
| 23:20.36 | zecke | mickey|tv: KitchenSync is a 'singleton' app |
| 23:20.42 | mickey|tv | aah |
| 23:20.43 | mickey|tv | ks |
| 23:20.49 | mickey|tv | not a qpe server process |
| 23:24.50 | *** join/#oe aloph1 (~aloph@cnet-cable-189-85-185.canbrasnet.com.br) |
| 23:31.35 | keturn | reiserfsprogs compilation fails. I'm guessing it wants kernel-headers. |
| 23:39.05 | keturn | actually, no, bad guess, the error is at link time |
| 23:42.58 | keturn | well... hm. |
| 23:47.56 | keturn | linking reiserfsck fails with check_tree.o(.text+0x3a80): In function `__put_unaligned': undefined reference to `bad_unaligned_access_length'. that function is declared as extern in linux-libc-headers. I guess I don't understand where it's supposed to be defined. |
| 23:49.04 | [g2] | is there a way to reference the virtual toolchain that bb is using from within a bb file ? |
| 23:50.14 | kergoth | what? |
| 23:50.39 | [g2] | I want to run gcc for armeb-linux in a do_compile |
| 23:50.48 | [g2] | not my native gcc |
| 23:51.04 | kergoth | ${CC} |
| 23:51.05 | pb_ | that'd be ${CC}, then. |
| 23:51.19 | [g2] | excellent |
| 23:51.20 | [g2] | thx |
| 23:51.32 | pb_ | any time |
