**** BEGIN LOGGING AT Sat Apr 08 09:59:56 2006 Apr 08 10:00:41 koen: I'd argue that you shouldn't be using -b like that if that is what happened... Apr 08 10:01:10 the -b there definitely does tell monotone, "I think that the .oz354x branch should be merged to the .dev branch" Apr 08 10:03:35 the unsuspecting user would say "I want to commit this to branch , not branch ' Apr 08 10:03:55 the whole ancestor thing is counter-intuitive for cvs/svn users Apr 08 10:06:58 "INIT: PANIC: segmentation violation! sleeping for 30 seconds." can't be good :-/ Apr 08 10:07:47 koen: cvs/svn will actually have the same behavior, if you do that sort of thing _in a checkout_ Apr 08 10:07:58 koen: but I think I take your point Apr 08 10:09:25 most problems we see are either caused by a cvs/svn paradigma or a bk paradigma Apr 08 10:09:58 "but it works in $otherscm" Apr 08 10:10:05 bleh Apr 08 10:10:07 nod Apr 08 10:10:52 I suspect there will be some people that will state that monotone sucks and the servers are badly managed, etc Apr 08 10:11:12 * koen feels his bloodpressure going through the roof Apr 08 10:13:13 koen: The root of the problem is that regardless of the technicalities, monotone has just "broken". We've shut down the servers, stopped people accessing the servers and we don't have an easy way to "fix" things. This is a failing in the SCM Apr 08 10:13:32 true Apr 08 10:13:32 Obviously some are going to see it as a bigger failing than others Apr 08 10:13:42 also true Apr 08 10:13:57 which is their right Apr 08 10:14:17 what I dislike however, is the whining and hate-mail I (and others) have to endure Apr 08 10:14:34 it doens't motivate me to spend time on fixing the problem Apr 08 10:18:57 I guess you might as well turn the servers back on Apr 08 10:19:23 koen: done Apr 08 10:19:25 the clobber solution means that nothing is being removed -- just need to tell people to work off of the correct head, and ignore the other one for now Apr 08 10:20:39 with the epoch solution, you can stop anyone from accidentally syncing in a reliable way, and the point of turning off the servers is just to reduce the probability someone will have the bad thing and sync it accidentally Apr 08 10:20:48 but epochs make that probability effectively "0", so... Apr 08 10:21:25 (the downside of the epochs thing is that in being actually reliable, it actually means _everyone_ has to do the quick check, even people who were out of town and missed the whole kerfluffle.) Apr 08 10:22:57 with either one, though, one might as well put the servers back up :-) Apr 08 10:23:56 My only concern with the clobber solution is it kind of corrupts the data rather than undoing the original mistake Apr 08 10:25:44 nod Apr 08 10:26:28 the dark side of keeping full history Apr 08 10:26:31 that is sort of inherently going to require "working around" the SCM... since SCMs just don't include "undo" as a basic operation, only "do back" Apr 08 10:27:10 njs: Is there some way we could have an alternative implementation of disapprove which would mark revisions as to be ignored? Apr 08 10:27:24 RP: not this week, or next Apr 08 10:27:39 njs: I'm thinking of the future Apr 08 10:27:41 * koen is going to have a long and proper lunch Apr 08 10:27:43 later all Apr 08 10:27:47 RP: now that 0.26 is almost finalized, we have started sketching out plans for proper trust management Apr 08 10:28:19 RP: I _think_ that one thing that will naturally fall out of this is the ability to say "don't trust that cert right there", which, for a branch cert, will make it ignored Apr 08 10:28:53 but these are predictions about the future, and thus something entirely different from facts :-) Apr 08 10:29:24 this is at least a _useful_ case for thinking about what sort of things can go wrong with monotone's model, and what should be done to preserve the good parts while preventing the nasty ones... Apr 08 10:29:25 njs: ok, that sounds similar to what I'm thinking of. I'm just wondering if there's a way monotone can deal with these issues better in future... Apr 08 10:30:09 the general plan goes by the name "project branches" or "admin branches" or "management branches" or similar (the name hasn't settled yet either :-)) Apr 08 10:31:10 we have a reasonable idea how to make them work (and hope to fix a number of other long-standing issues, like providing branch renaming, key renaming and revocation, etc., maybe even movable tags while we're at it), but the details haven't been hashed out at all yet Apr 08 10:33:31 does that sort of answer the question? Apr 08 10:34:50 the other thing that would be useful is what's called "rollback" support, in the merger -- http://revctrl.org/Rollback is a somewhat incoherent and definitely unnecessarily confusing explanation of the concept Apr 08 10:34:54 njs: It does, thanks :) Apr 08 10:35:12 it's a very important, basic feature, but unfortunately no-one knows anything about how to actually do it Apr 08 10:36:03 I'd like to fix that situation eventually, but I've been busy the last 6 months on getting the _last_ round of fancy new merge theory implemented and into users's hands, dunno when I'll have time to sit down and try to make up new math again... Apr 08 10:36:22 (or maybe someone else will solve it, but there don't seem many people interested in this sort of thing :-/) Apr 08 10:37:49 I think I get the idea from the link Apr 08 10:38:08 so the servers stay disabled for now? Apr 08 10:38:44 rwhitby-away: guess so, since koen went to lunch, and I guess he's organizing this... Apr 08 10:38:55 rwhitby-away: Nobody is going to know what to do with the multiple heads so its probably safest for now Apr 08 10:39:43 ok. ask koen to send me mail when he wants it back up again. Apr 08 10:39:56 rwhitby-away: will do Apr 08 10:40:03 njs: Finding interest and ability for things like this is tricky. See my comments earlier about Zaurus kernels... Apr 08 10:40:12 RP: yeah Apr 08 10:44:58 RP: it turns out that most of the text on that page is wandering around the point. a basic property that a versioning model should have is that it is possible to return to an earlier state, to have paths like A -> B -> A. (monotone actually doesn't quite have this property even now, because we don't have file reviving -- this is why file reviving is an important feature!) Apr 08 10:45:27 RP: "rollback" is just the application of this principle to _merge_ nodes -- after a merge, it should be possible to go back to "the same" parent states, like if the merge had never happened Apr 08 10:45:56 RP: this is a much simpler conceptual statement of the problem, which unfortunately totally doesn't show how/if it is actually possible, but, hey... Apr 08 10:48:14 njs: Sadly, I think is slightly over my head as I not deeply familar with version control systems :) Apr 08 10:48:59 njs: A -> B -> A seems simple enough, its when I add C in (which you don't want to revert) that is looks nasty :) Apr 08 10:49:13 RP: not necessarily Apr 08 10:49:27 A -> B -> C, want to get rid of B... just make it A -> B -> C, B -> A, then merge :-) Apr 08 10:49:36 (like how disapprove works) Apr 08 10:50:13 it does definitely get more complicated when you want to do things like revert only part of a change, or if you want to revert two changes at once, that were made in separate commits, etc. etc. Apr 08 10:50:38 http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=9709862327 Apr 08 11:03:38 hi all Apr 08 11:25:00 * njs . o O (Man, monotone 0.25 is slow...) Apr 08 11:32:30 danboid: I've just looked at the bvdd 2.4 kernel patch and someone's going to have to port the driver from 2.4. The accel driver under 2.6 is totally different :-/ Apr 08 11:51:10 gentlemen, will someone be able to add 3D acceleration for zaurii someday ? i know everyone is working really really hard on lots of OE stuffs, but 3d aceleration would be really great for users... Apr 08 11:51:36 alan|laptop: The hardware doesn't do 3D accel? Apr 08 11:52:02 RP, i think it does, but it needs the software part to work... Apr 08 11:52:46 alan|laptop: It doesn't do 3D accel Apr 08 11:53:02 Certain models can do limited 2D accel Apr 08 11:53:46 mmm... i think that c7x0 models and newer do 3d... well, could do 3d... Apr 08 11:54:07 but i may be wrong... Apr 08 11:54:16 alan|laptop: They can't. Trust me on this Apr 08 11:54:21 ok Apr 08 11:54:57 then how did they manage to get some 3D games under pdaxrom, RP ? Apr 08 11:55:43 alan|laptop: 3D games can run without 3D accel Apr 08 11:56:01 haaa... Apr 08 11:56:28 ok, thanks for this info, i didn't know. Apr 08 11:56:53 may i also ask you what you think aboout http://www.oesf.org/forums/index.php?showtopic=17052&pid=122316&st=225&# ? Apr 08 11:56:56 3D is just math... 3D accel just makes some math a little faster :-) Apr 08 11:57:07 right Apr 08 12:02:27 alan|laptop: It looks good. It'd be nice to get some of this into OE :) Apr 08 12:02:44 just got an email from koen|away saying that the servers should be turned back on, cause njs is going to write a special merger which will fix the problem with a single commit to one of the servers. Apr 08 12:02:55 So I'm turning monotone.nslu2-linux.org back on unless anyone objects ... Apr 08 12:03:02 rwhitby-away: Fine with me Apr 08 12:03:21 ...I have that merger, I think, but I am not sure the plan will entirely work. Apr 08 12:03:48 njs: can the situation get any worse by having the servers turned on? Apr 08 12:03:55 njs: :-/ Apr 08 12:04:09 trying to test it, it has taken 35 minutes of cpu time so far. I forgot that in 0.25, various operations take time proportional to the amount of history traversed Apr 08 12:04:22 in this case, that equals all history since .oz354x branched off Apr 08 12:05:06 rwhitby-away: The only issue is that the bad revision will spread further so if this fix fails, more people will have to manually fix their dbs Apr 08 12:05:38 njs: That was a while ago :-/ Apr 08 12:05:41 I also have a working, tested script to do the epoch approach, if that's preferred Apr 08 12:05:44 RP: yeah Apr 08 12:06:03 RP: so, this is cpu time running an unoptimized build, under gdb, so it may not actually be representative; I have an optimized build running too Apr 08 12:06:18 RP: in that case, I'll leave it off until I hear further news. Apr 08 12:06:21 but this gave me plenty of time to write the other script too, so you have options :-) Apr 08 12:06:54 njs: Is it possible to block the bad revision from entering a server? Apr 08 12:06:56 the way the script works is you run 'db-fixup.sh my.db', and every db that has had this script run on them, can talk to other dbs that have had this script run on them Apr 08 12:07:13 but dbs that have not had this script run on them, cannot talk to dbs that have had this script run on them Apr 08 12:07:16 njs: I'm just wondering if its possible to kill the revision without changing epochs? Apr 08 12:07:36 so you could run it on each server db, and then people would have to run it on their dbs before syncing Apr 08 12:07:42 hmm, that's a third option Apr 08 12:08:02 requires running a hacked server, but perhaps that's not that big a deal Apr 08 12:08:22 (you may have to build it yourselves, though, depending on what library version etc. the servers run) Apr 08 12:08:48 njs: It can't be done using the normal server config files? Apr 08 12:08:57 RP: correct. Apr 08 12:09:22 :-( Apr 08 12:09:52 I don't control any of the servers so I can't comment further on that approach then Apr 08 12:10:33 rwhitby-away: what machine configuration is the nslu2 server running on? where do you get the monotone binaries you use to run it? Apr 08 12:11:10 njs: it's a P4 1RU server at OSUOSL (in a rack next to kernel.org). It runs Debian Sarge. Apr 08 12:11:29 (on the theory that really, there only _need_ to be 2 servers, one for NSLU2 and one for OE, and the backups can be brought up later...) Apr 08 12:11:31 ah, that's easy. Apr 08 12:12:09 The only reason why NSLU2 has a separate server is due to the unreliability of the OE servers. Apr 08 12:12:23 (no offence to anyone intended) Apr 08 12:14:04 We also have two separate branches on that server (org.nslu2-linux.dev, which just holds a directory layer which sits above OE and contains a Master Makefile and some nslu2-linux conf files) and an org.nslu2-linux.bitbake which just holds the current working version of bitbake which matches the version of OE in monotone. Apr 08 12:14:14 Good day Apr 08 12:14:37 njs: If we go the clobber route, is this revision going to use a massive amount of CPU for anyone who pulls it? Apr 08 12:15:03 RP: I'm not sure, but that's my main worry. Apr 08 12:15:06 The org.openembedded.dev branch on monotone.nslu2-linux.org is intended to be (and is in practice) identical to the branch of the same name on the OE servers. Apr 08 12:17:31 it would certainly be possible to hack up a copy of monotone that drops the nasty certs on the floor when anyone tries to sync, and distribute a script to let people drop the nasty certs from their own db at their leisure Apr 08 12:17:38 (i.e., whenever they got tired of having two heads.) Apr 08 12:17:50 (I'm assuming there's no real danger anyone would actually _merge_ them.) Apr 08 12:19:28 njs: I think the merge would be beyond most people's skills Apr 08 12:19:37 right Apr 08 12:19:39 and patience :-) Apr 08 12:19:55 * njs sighs... 50 minutes Apr 08 12:23:27 njs: What kind of spec machine is that on? Apr 08 12:23:45 njs: I worry as we have people on some fairly low spec machines :-/ Apr 08 12:23:48 3GHz P4 Apr 08 12:23:53 svk smerge /kitchen/foo /me/mouth Apr 08 12:23:54 yeah Apr 08 12:24:07 hi zecke Apr 08 12:24:10 though, again, this is an unoptimized build, so machine specs aren't necessarily relevant Apr 08 12:26:19 I'm kind of liking the "throw it on the floor" server idea Apr 08 12:26:32 should be quite simple to implement, and I getting a sarge binary at least is trivial Apr 08 12:27:33 njs: I agree its looking like the next best option Apr 08 12:27:54 njs: I've mailed koen in the hope he can comment on at least one of the servers Apr 08 12:28:05 nod Apr 08 12:28:36 I'm missing something. What do we talk about? :} Apr 08 12:29:05 zecke: someone certed a rev that was supposed to be in.oz354x, with a .dev branch cert Apr 08 12:29:23 zecke: i.e., as far as monotone as concerned, merged the two lines Apr 08 12:29:29 oh Apr 08 12:29:30 (just without actually resolving all the conflicts) Apr 08 12:29:32 zecke: hence .dev is a bit broken atm and all the servers are therefore offline until we decide how to fix it Apr 08 12:29:35 I hope that wasn't me Apr 08 12:29:46 hmm I just pulled :} Apr 08 12:29:47 zecke: It wasn't Apr 08 12:29:55 zecke: Pulled from where? Apr 08 12:29:56 njs: how is that possible? Apr 08 12:30:00 RP: vanille Apr 08 12:30:19 should I kill it again? Apr 08 12:30:26 zecke: koen told me he'd shut that down :-( Apr 08 12:30:35 zecke: I'd guess koen restarted the servers Apr 08 12:30:37 reenoo: how is what possible? Apr 08 12:30:56 reenoo: you just do 'commit -b org.openembedded.dev' when you're in a .oz354x checkout... Apr 08 12:31:31 ah it is getting automatically restarted Apr 08 12:31:54 njs: heh Apr 08 12:32:08 zecke: is it monitered by runit or something? Apr 08 12:32:28 monotone: beginning service on all interfaces : 5253 Apr 08 12:32:28 monotone: interrupted Apr 08 12:32:28 monotone: beginning service on all interfaces : 5253 Apr 08 12:32:41 looks like monotone created some sort of... Apr 08 12:33:36 njs: This means the revision is probably out in the wild now so the epoch change might be the best option :-/ Apr 08 12:33:38 ...rift in the space-time continuum? ag_ain_? Apr 08 12:33:58 monotone is now killed :} Apr 08 12:34:06 RP: the modified server thing is pretty much a finer-grained equivalent to the epoch change option Apr 08 12:34:50 njs: true - it also prevents that revision getting in which could happen if someone changed epoch without remvoing the revision? Apr 08 12:35:06 RP: everyone who has the bad rev still has to run a script to get rid of it, but everyone who doesn't have it doesn't Apr 08 12:35:20 RP: true, though I'd _hope_ that doesn't happen... Apr 08 12:36:10 njs: Last time this happened, someone did let the revision we'd tried to kill back in eventually although admittedly we didn't change epochs and just reenabled keys once people had said they'd killed it Apr 08 12:37:06 yeah Apr 08 12:38:20 ljp: hey :) Apr 08 12:42:56 njs: Koen's comments are that the clobber is preferred but if too much cpu, go for the hacked servers approach Apr 08 13:24:05 njs: Is the optimised version still going? Apr 08 13:25:01 RP: yes Apr 08 13:25:24 njs: So that's 40 minutes now? :-/ Apr 08 13:25:31 47 minutes :-( Apr 08 13:27:28 njs: Given users don't have 3Ghz P4's, I don't think this is going to be an option... Apr 08 13:27:43 yeah, this sucks Apr 08 13:28:03 my modified server is compiling now... Apr 08 13:28:51 njs: Ok, thanks for looking into this :) Apr 08 13:30:47 *blinks* dude, it did the merge! Apr 08 13:31:17 hey Apr 08 13:31:53 now it's doing the sanity check... Apr 08 13:33:30 njs: The sanity check will take the same length of time again? Apr 08 13:33:39 that's a question Apr 08 13:33:44 quite possibly :-/ Apr 08 13:48:43 hmm, seems to work Apr 08 14:10:00 by default, opie builds with codecs disabled? Apr 08 14:10:30 njs: sleep well and thanks :) Apr 08 14:10:41 np Apr 08 14:20:34 njs: your solution works Apr 08 14:26:35 RP: everything should be working again Apr 08 14:30:53 koen: Excellent :) Apr 08 14:31:11 * RP pulls Apr 08 14:32:19 I've just found my laptop's hdd is totally corrupt (ext3 went haywire) :-/ Apr 08 14:33:19 koen: Have you sent rwhitby an email? Apr 08 14:54:12 I've recently purchase a c3100 what changes wolud I need to do for an oe installation set up for 5500? Apr 08 14:54:37 darmou: Change MACHINE ? Apr 08 14:57:23 03rpurdie 07org.oe.dev * r5bb08566... 10/packages/keymaps/files/ (collie/keymap-2.6.map poodle/keymap-2.6.map): keymaps: Correct the collie and poodle 2.6 maps Apr 08 14:58:24 is 2.6 kernel usable on collie yet? Apr 08 14:58:33 darmou: not yet, no Apr 08 15:00:33 http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=9709862327 Apr 08 15:01:59 just looking at the gettning started wiki looks like I need to change my machine type in the local.conf and then should be able to build 3100 packages, cool Apr 08 15:02:54 man I have to clean this mess up... Apr 08 15:03:17 03rpurdie 07org.oe.dev * r4cbddd40... 10/packages/elfutils/ (elfutils-0.108/warnings.patch elfutils_0.108.bb): Add elfutils 0.108 (which works with EABI) Apr 08 15:03:27 which mess is that? Apr 08 15:03:35 pb_: my 'desk' Apr 08 15:03:42 pb_: so many cables... Apr 08 15:03:48 ah, that old problem Apr 08 15:10:55 OT: do you have experience in copying a videotype to mpeg2? Apr 08 15:11:53 RP: I've sent rwhitby an email Apr 08 15:17:35 koen: thanks Apr 08 15:31:24 Is there a java version that works with openzaurus? Apr 08 15:31:32 I tried sablevm but it was buggy Apr 08 15:31:51 blackdown vm worked for console apps but not graphical ones Apr 08 15:36:42 hmm mabey blackdown will work better for c3100 Apr 08 16:14:09 should start using monotone 0.26 Apr 08 16:14:23 not that it would solve the problems occurring today Apr 08 16:14:34 it's as good a time as any though to make a transition Apr 08 16:15:39 jnc: no it isn't Apr 08 16:15:49 i don't think i meant transition Apr 08 16:15:53 the most obvious one is that 0.26 isn't out yet Apr 08 16:16:17 is there a monotone 0.26 server running and syncing with the regular one? Apr 08 16:16:37 no, since that's impossible Apr 08 16:16:44 at the moment, yes Apr 08 16:16:52 0.26 uses a different netsync protocol and a different port Apr 08 16:16:56 exactly Apr 08 16:17:10 it would be possible to transparently run both versions Apr 08 16:42:29 anyone tried uclibc EABI support? Apr 08 16:42:51 RP: how can I fix the host-modules issue? Apr 08 16:46:10 hi Apr 08 16:46:15 hey CoreDump|home Apr 08 16:47:38 zecke: host-modules issue? Apr 08 16:47:51 it doesn't compile Apr 08 16:48:03 host or hostap? Apr 08 16:48:03 RP: and IIRC we wanted to use the kernel modules Apr 08 16:48:13 hostap.. sorry :} Apr 08 16:48:40 zecke: Is this for a Zaurus? Apr 08 16:49:03 zecke: For recent kernels we use the internal kernel hostap module Apr 08 16:49:22 RP: c7x0 and KERNEL_VERSION 2.6... Apr 08 16:49:33 mehhhh, wlan is screwed in .354x branch. Apr 08 16:49:41 zecke: It shouldn't be building hostap-modules then... Apr 08 16:49:58 RP: reading, and grepping indicates the same Apr 08 16:50:18 CoreDump|home: Can you define "screwed" a bit more? :) Apr 08 16:51:00 zecke: Is this .dev or the branch? Apr 08 16:51:20 for whatver reason "wlan0" is now "eth0". And the "iwconfig" options were not applied. Ejecting the card fixed the iwconfig issue Apr 08 16:51:25 RP: yes Apr 08 16:51:59 zecke: note that hostap-* is unreliable in .dev due to the zaurus machine overloading KERNEL_VERSION Apr 08 16:52:19 RP: yes hostap-utils picks up host-modules Apr 08 16:52:26 for virtual/kernel-hostap... Apr 08 16:52:49 zecke: PERFERRED_PROVIDER_hostap-conf = "host-conf" might help Apr 08 16:53:39 RP: hehe, now you did the same mistake as well (host vs. hostap) Apr 08 16:53:57 zecke: Its evidently infectious :) Apr 08 16:54:08 koen: I guess now would be a good time to remove some 2.4 zaurus machines... Apr 08 16:54:41 RP: have we more than one hostap-conf provider? Apr 08 16:55:09 zecke: We did. We might not have after hrw's changes Apr 08 16:55:38 RP: okay, we don't have them anymore Apr 08 16:56:59 RP: should zaurus-clamshell.conf should set a PREFERRED_PROVIDER for virtual/kernel-hostap? Apr 08 16:58:24 zecke: Maybe linux-openzaurus.inc should RPROVIDES_kernel-module-hostap-cs = "hostap-modules" Apr 08 16:58:36 zecke: and we remove all this virtual stuff Apr 08 16:59:15 I wouldn't mind that Apr 08 16:59:24 CoreDump|home: What problems does wlan0 becoming eth0 cause? Apr 08 17:00:37 it made me years-old backed up /etc/network/interfaces deprecated and confused the heck out of me for a minute ;) Apr 08 17:01:12 CoreDump|home: Ok, so long as it doesn't break the alpha2 image outright, that's not so bad :) Apr 08 17:01:28 wlan0 always confused me... Apr 08 17:01:32 heh Apr 08 17:02:05 ok, so how does the new pcmcia thingy work. /etc/init.d/pcmcia start does no longer work to kickstart WLAN Apr 08 17:02:28 CoreDump|home: udev calls ifup and ifdown at present Apr 08 17:02:52 * CoreDump|home patches altboot's NFS script Apr 08 17:06:09 * koen is thinking about creating a local.conf-o-matic for angstrom Apr 08 17:07:24 hmm... strange Apr 08 17:08:11 hmmm, WLAN is not always started on boot Apr 08 17:10:43 hey XorA Apr 08 17:10:48 morning Apr 08 17:11:10 RP: it doesn't consider the PROVIDES of the OpenZaurus kernel Apr 08 17:12:14 zecke: Why not? Apr 08 17:12:20 hi XorA Apr 08 17:13:05 hi XorA Apr 08 17:14:50 * XorA reads back, some database fun and games today then Apr 08 17:15:37 RP: dunno, bitbake bug is the closes guess Apr 08 17:15:42 BB>> peek linux-openzaurus PROVIDES Apr 08 17:15:43 virtual/kernel-hostap virtual/kernel Apr 08 17:15:50 ERROR: Nothing provides runtime dependency virtual/kernel-hostap Apr 08 17:15:51 ahh Apr 08 17:16:04 RPROVIDES? Apr 08 17:16:08 right Apr 08 17:16:27 why would hostap-utils RDEPEND on the modules? Apr 08 17:16:43 zecke: It RRECOMMENDS iirc Apr 08 17:16:59 okay Apr 08 17:17:18 zecke: but if you look at the second line in linux-openzaurus.inc, you'll see it does RPROVIDE Apr 08 17:17:38 RP: okay, bitbake bug then? Apr 08 17:17:58 zecke: Kind of. Its because its not a package in PACKAGES Apr 08 17:18:25 zecke: bitbake doesn't have any idea that linux-openzaurus has a package called kernel-modules-hostap-cs Apr 08 17:18:44 RP: it sounds like, it should have an idea... Apr 08 17:19:03 zecke: Its the dymanic modules business Apr 08 17:19:43 We know that linux-openzaurus can RPROVIDE kernel-modules-* but not which ones until its built them Apr 08 17:20:19 So we can't lookup kernel-modules-hostap-cs to find the variable REPDENDS_kernel-modules-hostap-cs Apr 08 17:20:42 zecke: The solution might be PACKAGES_append = "kernel-hostap-modules-cs" to linux-openzaurus.inc Apr 08 17:20:44 kernelconfig-parser.bbclass? Apr 08 17:21:06 koen: no way - too many risks of bugs Apr 08 17:21:38 The solution is if you set Runtime variables of dynamically created packages, you need to add them to PACKAGES Apr 08 17:22:05 (if you're going to RDEPEND on them elsewhere) Apr 08 17:22:23 RP: what if that .bbclass fills in PACKAGES? Apr 08 17:23:33 my build is insisting in trying to build hostap-modules since yesterdey, is this what is being discussed? Apr 08 17:23:44 koen: There is a nasty hole in the logic here. The bottom line is don't REDEPEND on dynamic packages :-/ Apr 08 17:23:57 XorA: .dev or the 344x branch? Apr 08 17:24:12 RP: I've been advocating using RRECOMMENDS for a while Apr 08 17:24:18 RP: okay, PACKAGES += works Apr 08 17:24:34 koen: Any runtime option will have the same problem, RRECOMMENDS included Apr 08 17:24:40 ~hail mickeyl for the bitbake shell Apr 08 17:24:42 * ibot bows down to mickeyl for the bitbake shell and chants, "I'M NOT WORTHY!!" Apr 08 17:25:15 RP: .dev Apr 08 17:25:43 XorA: This is what's being dicsussed. In summary, add PACKAGES_append = "kernel-hostap-modules-cs" to linux-openzaurus.inc Apr 08 17:26:09 RP: ok cool, just checking Id got the right end of this stick :-) Apr 08 17:26:55 PACKAGES_append = " kernel-hostap-modules-cs" Apr 08 17:27:16 otherwise you're in for a awkward debugging session Apr 08 17:27:26 koen: heh heh, nice catch Apr 08 17:27:40 yes. or use += Apr 08 17:27:57 I make that mistake yesterday as well :-/ Apr 08 17:40:42 03rpurdie 07org.oe.dev * r7b0d8b04... 10/packages/ (4 files in 2 dirs): Remove virutal/kernel-hostap as linux-openzaurus just needs to RPROVIDES hostap-modules. Apr 08 17:45:38 RP: http://oe.pastebin.com/648159 Apr 08 17:47:15 zecke: Its not enough - you need RDEPENDS_* and RPROVIDES_* Apr 08 17:47:34 RP: I just wanted to find out about the dependencies Apr 08 17:47:48 zecke: Ah, right Apr 08 17:48:19 RP: I save the vars unexpanded ;) Apr 08 17:48:36 RP: currently it is 1.4mb Apr 08 17:48:55 that means you can store it on a floppy! Apr 08 17:49:36 NOTE: Unpacking /home/koen/OE/downloads/pkgconfig-0.15.0.tar.gz to /data/build/koen/OE/build/tmp/angstrom/work/${PACKAGE_ARCH}-linux/pkgconfig-native Apr 08 17:49:40 r2/ Apr 08 17:49:41 hmmm Apr 08 17:49:45 * koen kills the cache Apr 08 17:49:49 koen: wait Apr 08 17:50:21 koen: peek into pkgconfig please Apr 08 17:51:25 BB>> peek pkgconfig Apr 08 17:51:27 Usage: 'peek ' Apr 08 17:52:19 PACKAGE_ARCH Apr 08 17:52:26 BB>> peek pkgconfig PACKAGE_ARCH Apr 08 17:52:26 None Apr 08 17:53:43 not good :) Apr 08 17:54:39 okay you may clean the cache now Apr 08 17:55:13 * koen does so Apr 08 17:55:35 RP: hmm, it still does not compile Apr 08 17:57:56 NOTE: current path: opie-image (opie-image) -> task-bootstrap (task-bootstrap) -> hostap-utils (hostap-utils) -> hostap-modules (hostap-modules) Apr 08 17:58:05 Do I split tosa into tosa and tosa-26? Apr 08 17:59:18 zecke: http://oe.pastebin.com/648193 Apr 08 18:00:25 koen: heh? Apr 08 18:00:53 and http://oe.pastebin.com/648196 Apr 08 18:01:18 * koen is clueless on why its happening Apr 08 18:01:49 koen: do me a favor and open bin/bitbake Apr 08 18:02:36 * koen does so Apr 08 18:02:56 remove except Exception, e: Apr 08 18:02:56 bb.error("%s while parsing %s" % (e, f)) Apr 08 18:03:06 in collect_bbfiles Apr 08 18:03:16 I would tell you the line number, if I just could use my vim Apr 08 18:03:43 1074 Apr 08 18:07:34 zecke: check /data/tmp/log on ewi in a few minutes Apr 08 18:07:41 hey benlau Apr 08 18:07:43 ehm Apr 08 18:07:45 hey Bernardo Apr 08 18:08:14 hi koen Apr 08 18:08:39 I've just blasted my tmp and I'm doing a clean 3.5.4.1 build Apr 08 18:09:08 koen: as for which weekend for bug hunting, as long as it isn't the 22nd/23rd... Apr 08 18:11:07 Bernardo: no worries :) my next uni deadline is right after that weekend Apr 08 18:18:04 koen, I have the same weekend hassle :) Apr 08 18:18:15 except I will be in a cow field with beer :) Apr 08 18:21:14 Crofton: for me it won't be a cow field, but my backyard... :) Apr 08 18:42:12 RP: ping Apr 08 18:54:06 koen: where is the log? Apr 08 18:54:10 RP: the issue is not fixed ;) Apr 08 18:54:52 ehm Apr 08 18:55:19 it's on it's way Apr 08 18:59:13 zecke: try now Apr 08 18:59:21 zecke: PACKAGES doesn't help? Apr 08 18:59:59 RP: you also removed virtual/hostap-kernel... Apr 08 19:00:06 RP: so we have an similiar issue now Apr 08 19:00:23 RP: now hostap-utils will directly build hostap-modules Apr 08 19:00:27 zecke: but I added hostap-modules? Apr 08 19:00:36 RP: to satisfy hostap-modules... Apr 08 19:00:50 zecke: or http://ewi546.ewi.utwente.nl/tmp/log Apr 08 19:00:51 RRECOMMEDS hostap-modules Apr 08 19:01:03 we have kernel-hostap-modules though Apr 08 19:01:46 koen: weird Apr 08 19:01:50 zecke: linux-openazurus RPROVIDES_kernel-module-hostap = "hostap-modules" Apr 08 19:06:50 RP: will test later Apr 08 19:12:48 03rpurdie 07org.oe.dev * r9e9815b6... 10/ (38 files in 27 dirs): Apr 08 19:12:48 * Remove 2.4 machine support for c7x0, akita, spitz and borzoi. Apr 08 19:12:49 * Remove borzoi machine entirely as its now equal to spitz. Apr 08 19:12:51 * For remaining 2.4/2.6 split machines use ZKERNEL_VERSION instead of KERNEL_VERSION Apr 08 19:12:54 to fix a long standing bug - people will need to update local.conf. Apr 08 19:12:56 * Add dummy terrier MACHINE to point at spitz. Apr 08 19:19:59 whooo! Apr 08 19:26:18 pb_: | arm-linux-libtool: compile: unable to infer tagged configuration Apr 08 19:26:18 | arm-linux-libtool: compile: specify a tag with `--tag' Apr 08 19:26:43 zecke: rebuild libtool-cross Apr 08 19:26:58 reenoo: what was the issue? Apr 08 19:27:05 zecke: not sure what's going on there but that works around it Apr 08 19:27:25 for me anyway Apr 08 19:27:29 oh well... Apr 08 19:27:45 autotools and libtool should just die... Apr 08 19:28:12 must be some multimachine related breakage. I've never had that in non-multimachine builds and now it's fairly reproducable. Apr 08 19:30:23 reenoo: hmm, I think libtool sucks regardless... Apr 08 19:30:36 heh Apr 08 19:31:03 it's not libtool's fault that the multimachine stuff is subtly broken Apr 08 19:31:22 reenoo: well, arm-linux-libtool gets created Apr 08 19:31:40 reenoo: from a m4... multimachine should have not any influence on that Apr 08 19:32:19 well Apr 08 19:32:24 it is not 'nice' to know that this issue is known... Apr 08 19:32:29 $ ls -d tmp/work/*/gcc-cross*r3 Apr 08 19:32:35 tmp/work/arm-linux/gcc-cross-3.4.4-r3 Apr 08 19:32:35 tmp/work/arm-linux/gcc-cross-initial-3.4.4-r3 Apr 08 19:32:35 tmp/work/i686-linux/gcc-cross-3.4.4-r3 Apr 08 19:32:35 tmp/work/i686-linux/gcc-cross-initial-3.4.4-r3 Apr 08 19:32:42 that's clearly broken Apr 08 19:33:10 and it's just one example. haven't had the time to figure out what's going on there Apr 08 19:35:46 * CoreDump|home wonders why zaurusd dies on the first start Apr 08 19:37:18 RP: I am getting a "tslib config not found" error. Is that coming from tskeys by chance? Apr 08 19:52:09 reenoo: true... can't be too hard to fix that Apr 08 19:53:18 native.bbclass used to forget to set the right ARCH bits if ${MACHINE}.conf is overriding it (i.e. arm5vte stuff) Apr 08 19:53:36 some part of got fixed in .dev, but not all (IIRC) Apr 08 19:55:29 CoreDump|home: Ah, probably, esp if you haven't calibrated the screen yet :-/ Apr 08 19:55:46 the screen is calibrated Apr 08 19:56:01 however, the first start of zaurusd is always failing Apr 08 19:56:18 03rpurdie 07org.oe.dev * rd62bbd0d... 10/packages/linux/linux-openzaurus.inc: linux-openzaurus.inc: Correct the maximum zaurus kernel size (#816). Apr 08 19:56:23 the next works fine. Kinda hard to debug heh Apr 08 19:57:31 CoreDump|home: Strange :-/ Apr 08 19:57:55 indeed Apr 08 19:58:38 zecke: That error is when you have a symlink in some bitbake path Apr 08 19:59:46 RP: weird, not that I would know Apr 08 20:01:18 RP: http://handhelds.org/scap/port.15338.png Apr 08 20:01:26 zecke: Actually, that's a different error I'm thinking of, sorry :-/ Apr 08 20:01:59 CoreDump|home: those udev errors look nasty Apr 08 20:02:31 koen|tv: not really ;) It's booted of NFS and udev is already running at the time Apr 08 20:07:03 someone mentioned that OE's initscripts try to mount stuff before the network is up, breaking nfs Apr 08 20:07:11 has anyone seen that as well? Apr 08 20:09:10 IIRC yes Apr 08 20:10:02 zecke: you get that error when ${CC} doesn't match what libtool is expecting Apr 08 20:10:24 which generally means that you are accidentally using the libtool "binary" from staging rather than a freshly generated local copy Apr 08 20:10:26 pb_: ah okay, this would match with reenoo claims Apr 08 20:10:37 hi for a moment Apr 08 20:10:41 hey hrw Apr 08 20:10:58 gcc native is fscked Apr 08 20:10:59 yo hrw Apr 08 20:11:17 hrw: there's a bug report on that (IIRC) Apr 08 20:11:33 koen|tv: yep - will try it Apr 08 20:11:51 hi hrw Apr 08 20:11:57 even helloworld.c is not buildable currently Apr 08 20:12:50 native - as in native for build host or native for handheld? Apr 08 20:13:08 polyonymous: handheld Apr 08 20:13:20 hrw, like this: http://bugs.openembedded.org/show_bug.cgi?id=812 Apr 08 20:13:42 polyonymous: yep Apr 08 20:13:57 Yeah. Not sure if I patched it right, but it worked for me... Apr 08 20:13:59 zecke: I seem to remeber that can also happen if you change CFLAGS, particulary the tuning flags, There is supposed to be a patch in OE to stop that brekaing libtool but it doesn't seem to be working Apr 08 20:14:36 polyonymous: anyway we provide wrong binutils in OZ 3.5.4 ;( Apr 08 20:15:21 hrw, wrong as in having this bug? Apr 08 20:15:22 RP: here's the problem: http://handhelds.org/scap/port.16764.png Apr 08 20:15:37 is ts.conf generated on boot? Apr 08 20:15:53 polyonymous: 2.15.99+csl-arm+cvs20050416 instad of 2.15.94.0.1 (which was used to build OZ) Apr 08 20:16:00 Ah, I see Apr 08 20:16:03 CoreDump|home: does it honour TSLIB_TSCONFFILE? Apr 08 20:16:57 CoreDump|home: No, but we do need to have sourced the ts file in /etc/profile.d/tslib.sh Apr 08 20:17:05 CoreDump|home: a lot of device don't use /etc/ts.conf, but set TSLIB_TSCONFFILE (or whatever it's called) to the actual location Apr 08 20:17:17 Well, I only have 3.5.4.1-*... And the fix worked for me on my handheld. Can't think of the reason why there's different sysroot, but can't be sure of my solution either. Apr 08 20:17:18 koen|tv: you are correct Apr 08 20:17:43 The problem is that we need those variables set and the file I mentioned won't have been sourced at that point in the boot process Apr 08 20:17:50 the second run (which always works) uses /usr/share/tslib/blahh Apr 08 20:18:08 CoreDump|home: The second run works as you're in a shell which sourced the files in profile.d Apr 08 20:18:14 ahhh Apr 08 20:18:49 well, we could just put this var in the machine config of zaurusd, right? Apr 08 20:18:58 noooo Apr 08 20:19:02 heh Apr 08 20:19:07 tslib.sh exists for a reason Apr 08 20:19:11 Slightly ugly... Apr 08 20:19:28 this isn't hardcode-o-rama like opie Apr 08 20:20:02 people might use zaurusd on a non-OE built distro Apr 08 20:20:04 koen|tv: ?? hardcoding == setting a variable to one value? Apr 08 20:20:43 hmm qHeapSort sucks Apr 08 20:21:12 ok, tslib.sh it is then Apr 08 20:21:29 I guess we should source /etc/profile.d/tslib.sh Apr 08 20:21:53 sourcing it from whithin /etc/init.d/zaurusd would be "slightly ugly", too ;) Apr 08 20:22:17 I don't see how else we can do it Apr 08 20:22:23 right Apr 08 20:22:41 its slightly less ugly in that tslib always installs that file Apr 08 20:23:23 one problem down Apr 08 20:23:50 do you want to add that upstream or should I add an OE patch? Apr 08 20:24:03 I'll "fix" upstream :) Apr 08 20:24:16 great! thanks ;) Apr 08 20:24:42 now to the god damn resolv.conf thingy Apr 08 20:24:57 CoreDump|home: look in /etc/default/volatiles for it iirc Apr 08 20:25:10 hmmm Apr 08 20:25:18 did I put the fix in .dev yet? Apr 08 20:25:22 someone tried USE_FEED_FOR_IMAGES patch? Apr 08 20:25:24 * koen|tv can't remember Apr 08 20:25:37 hrw: only the first version ;) Apr 08 20:25:48 koen|tv: try final one Apr 08 20:25:56 how do you override the bootstrap_rrecommends Apr 08 20:25:56 USE_FEED_FOR_IMAGES = 1/0 Apr 08 20:26:15 hrw: OE doesn't build anything right now.... Apr 08 20:26:31 koen|tv: http://bugs.openembedded.org/show_bug.cgi?id=818 anyway Apr 08 20:27:17 I noticed Apr 08 20:28:21 btw - could binutils/gcc be changed so I will get 'gcc' not 'arm-linux-gcc' on device? Apr 08 20:29:04 hrw: we could abuse update-alternatives for that Apr 08 20:29:48 koen|tv: I rather prefer to change 'program-prefix' in EXTRA_OECONF Apr 08 20:29:55 CoreDump|home: Upstream fixed but untested :) Apr 08 20:29:55 right Apr 08 20:30:14 u-a should be used to select between gcc3 and gcc4 Apr 08 20:30:34 RP: thanks Apr 08 20:31:33 ok. time to build root-on-sd kernel Apr 08 20:31:55 hrw: Isn't there a symlinks package you can install to get the nicer names? Apr 08 20:32:56 RP: maybe it is. but why native gcc is not just gcc? Apr 08 20:33:54 hrw: I don't know - I'm just saying I think there are a set of symlinks available already iirc Apr 08 20:34:47 hrw: I think the program-prefix should be moved to gcc-cross Apr 08 20:35:10 probably Apr 08 20:35:15 slightly related: it would be cool if OE could build cross-cross toolchains Apr 08 20:35:26 like sparc-linux-gcc for arm Apr 08 20:35:52 well, you want to have both "arm-linux-gcc" and "gcc" anyway. Apr 08 20:36:33 doesn't matter too much which around you do the symlinking Apr 08 20:36:41 which way even Apr 08 20:40:47 zecke: do you have any idea what would cause "ERROR: too many values to unpack while parsing ..." for every file? Apr 08 20:42:23 pb_: you use a modern/unstable/crappy bitbake Apr 08 20:42:24 pb_: You probably need to wipe tmp/cache Apr 08 20:42:41 pb_: and should remove tmp/cache as RP asked you :) Apr 08 20:43:05 * emte yawns Apr 08 20:43:26 zecke: oh drat. what version of bitbake should I be using? Apr 08 20:43:29 wrong window Apr 08 20:43:59 pb_: Try r410 ish - that's what I ended up reverting to Apr 08 20:44:11 zecke: and why do I need to remove the cache? Apr 08 20:44:37 pb_: the cache format changed from one dict to a list of dicts Apr 08 20:44:46 pb_: and we do not have a version in it... :( Apr 08 20:44:56 RP: what version has trunk? Apr 08 20:44:57 zecke: and there's no compatibility code? that is... unfortunate. Apr 08 20:45:18 pb_: compability was implemented as human interaction Apr 08 20:46:02 zecke: r423 Apr 08 20:46:14 r412 is the one I ended up reverting to Apr 08 20:46:19 zecke: ah, that seems like a poor implementation. Apr 08 20:46:34 pb_: yeah, humans suck Apr 08 20:46:53 well, I need to focus on this code... cya later or tomorrow Apr 08 20:48:57 md5 checking in updater.sh could be nice... Apr 08 20:49:23 indeed Apr 08 20:49:32 hrw: Filesize checking for the kernel would be an even better start :-/ Apr 08 20:49:44 * CoreDump|home is _not_ going to touch updater.sh Apr 08 20:49:58 yeah.. its ugly as... Apr 08 20:50:05 yep Apr 08 20:55:32 heh.. 1st kernel patch for 2.6.16 from me will be needed... Apr 08 20:55:42 move pretec wlan from orinoco -> hostap Apr 08 20:56:28 ~lart pretec for using vendor/product ids of intersil reference card Apr 08 20:56:28 * ibot slaps pretec upside the head with a wet fish for using vendor/product ids of intersil reference card Apr 08 20:56:41 CoreDump|home: mickeyl and discussed making a static binary containing logic and launch that from updater.sh Apr 08 20:57:05 koen: that would be way cool Apr 08 20:57:34 CoreDump|home: and eventually do a full blown graphic installer that way Apr 08 20:57:38 =D Apr 08 20:57:52 this would rock Apr 08 20:58:22 I'm trying to get something like debian-installer Apr 08 20:58:46 so you can choose between a complete .jffs2 file or installer + feed on CF Apr 08 20:59:06 * koen needs more time Apr 08 20:59:16 * CoreDump|home knows the feeling Apr 08 20:59:41 * RP makes no comment Apr 08 21:00:01 the current updater.sh is an ugly mess, I wouldn't touch it if my life depended on it... Apr 08 21:00:28 CoreDump|home: I particularly like the spitz hacks Apr 08 21:01:07 To me it looks no different to the rest of the 2.4 kernel Apr 08 21:01:24 never looked at those ;) Got a good scare from akita and left it at that Apr 08 21:01:49 RP: sharp at its finest... Apr 08 21:02:10 CoreDump|home: Try the touchscreen driver sometime Apr 08 21:02:32 cu Apr 08 21:02:37 bye hrw|gone Apr 08 21:02:45 That is just really badly written. The PM code is worse as its unintelligible as well as badly written Apr 08 21:03:43 heh, that's sad somehow. I mean the Zaurus PDA line rocks (IMO) but man, the shipped OS is a joke Apr 08 21:04:15 CoreDump|home, if it wasn't would there be OZ? Apr 08 21:04:59 polyonymous: hmm I don't think so, no Apr 08 21:05:12 Then it's not all that bad :) Apr 08 21:05:21 ;) Apr 08 21:06:00 * CoreDump|home looks at populate-volatile.sh and shivers Apr 08 21:07:10 * polyonymous is trying to fix libxine .bb instead :) Apr 08 21:08:00 my todo list isn't really getting shorter Apr 08 21:08:24 todo lists aren't supposed to shrink. Apr 08 21:08:44 Unlike entropy they tend to increase no matter how much effort you put into it. Apr 08 21:08:58 well said =) Apr 08 21:09:08 :-) Apr 08 21:12:58 omg my head hurts Apr 08 21:13:11 ergo sum :) Apr 08 21:13:21 that's one complicated and unreadable way to pupolate /var :\ Apr 08 21:13:32 Okay, libxine compiles now Apr 08 21:13:56 CoreDump|home: iirc tmbinc knows the dark magic involved Apr 08 21:14:14 I wonder if I should file a bug with patch or append it to this one: http://bugs.openembedded.org/show_bug.cgi?id=312 Apr 08 21:14:37 "could we resolve/close it? " Apr 08 21:14:45 yes, that one Apr 08 21:14:53 if "no", attach the patch ;) Apr 08 21:15:01 Looks like "no" :) Apr 08 21:15:05 Will do. Apr 08 21:15:20 CoreDump|home: check http://handhelds.org/~bugzilla/show_bug.cgi?id=1445 Apr 08 21:15:27 I also wonder whether I should attach a patch to configure.patch or the whole new configure.patch :) Apr 08 21:15:48 * CoreDump|home reads Apr 08 21:16:23 * CoreDump|home would prefer a new patch, easier to commit / try out Apr 08 21:17:12 Then I will attach a new patch. I have both, of course, patch to patch is easily produced by monotone diff :) Apr 08 21:18:15 In fact, I fixed build and attaching a patch makes sense, anyway, but I want to test the functionality before submitting it. Apr 08 21:22:53 koen: the code is missing the right magic words to not trying to link over existing links -> patching... Apr 08 21:37:26 njs: ping Apr 08 21:38:14 njs: since the monotone.nslu2-linux.org server does not even take the oz354 branch, does that mean that we don't need to worry about this problem and don't need to run the modified server? Apr 08 21:38:37 rwhitby: the problem is in .dev Apr 08 21:38:43 e.g. I just ran db-fixup.sh on our nslu2-linux.db and it did nothing. Apr 08 21:38:55 slug@limax:~/monotone$ ./db-fixup.sh nslu2-linux.db Apr 08 21:38:55 Cleaning nslu2-linux.db: Apr 08 21:38:55 'delete from revision_certs where id = '6e205d2fe108f337e62ed13f8db67e9a2e70c954' and name = 'branch'' -> 0 rows Apr 08 21:38:55 'delete from revision_certs where id = '78a4544b0da0db7bef0ee08f054a51321fc0d271' and name = 'branch'' -> 0 rows Apr 08 21:38:57 Cleaning successful. Apr 08 21:38:59 Database nslu2-linux.db is now fully operational. Apr 08 21:39:15 rwhitby: monotone.nslu2 only serving .dev is also breaking my sync scripts Apr 08 21:40:15 koen: I think I'll have to ask you to change the scripts, cause we're unlikely to add other branches that are not related to our work. Apr 08 21:41:11 So that "0 rows" bit does not look good? Apr 08 21:41:46 koen: (in the same way that I doubt that you would want to add the org.nslu2-linux.dev branches to the OE servers ...) Apr 08 21:43:06 actually I was about to ask if you want me to add those branches Apr 08 21:43:58 ibot: botmail for zecke: the survey mails are getting caught by spamassassin, could you make it less spam-like? Apr 08 21:43:59 Well, the problem I see is that adding branches makes the database bigger on the server and increases incremental pull times for the users. Apr 08 21:44:19 users won't notice a bit Apr 08 21:44:59 i.e. my pull time for .dev isn't affected by org.oe.dreambox being present Apr 08 21:45:12 (being present on the server) Apr 08 21:45:40 ok, let me discuss with the nslu2-linux core team Apr 08 21:46:05 In the meantime, does anyone have a Debian Sarge version of monotone-sid-0.25.2+oe-hack ? Apr 08 21:46:22 * rwhitby doesn't have time this morning to be building stuff ... Apr 08 21:50:46 * CoreDump|home wonders why merging .dev takes so long Apr 08 21:51:45 CoreDump|home: because your db still has the 'bad' revs? Apr 08 21:52:04 CoreDump|home: you did run the fixup script, did you? Apr 08 21:52:13 nope? Apr 08 21:52:32 * CoreDump|home was at work all day Apr 08 21:53:05 it's a merge with nslu2 allright Apr 08 21:53:08 well, your commit this morning pulled in .oz354x into .dev (if you would merge it) Apr 08 21:53:20 argh Apr 08 21:53:27 i disapproved it Apr 08 21:53:36 that doesn't help Apr 08 21:53:56 we have a special version of monotone now that kills your csets Apr 08 21:54:02 see 'heads up' on oe@ Apr 08 21:54:04 heh Apr 08 21:55:06 jesus why would it commit the whole tree when I commited a single directorx Apr 08 21:55:32 because the ancestor is in .oz354x Apr 08 21:55:53 so if you would merge the heads it would apply .oz354x to .dev (that's the short story) Apr 08 21:56:03 njs can give you the detailed version Apr 08 21:57:11 ouch, sorry for that :( Apr 08 21:57:42 CoreDump|home: see http://dominion.kabel.utwente.nl/koen/pda/files/screwage.tiff Apr 08 21:57:58 monotone viz shows it as a nice 'island' Apr 08 21:58:30 hehe Apr 08 21:58:38 i'll try thescript... Apr 08 21:59:46 Cleaning successful. Apr 08 21:59:46 Database ./OE.db is now fully operational. Apr 08 22:00:28 lets see whether my commits survived Apr 08 22:06:15 03coredump 07org.oe.oz354x * rd7bf9fef... 10/packages/xserver-common/ (files/Xdefaults-200DPI.patch xserver-common_1.8.bb): xserver-common: Use propper Xdefaults for 200DPI machines. This fixes the infamous "200 DPI" bug. Apr 08 22:06:19 03coredump 07org.oe.oz354x * r98bfe10e... 10/packages/gpe-session-scripts/gpe-session-scripts_0.66.bb: gpe-sessionscripts: Remove 200DPI work-around Apr 08 22:06:23 03coredump 07org.oe.oz354x * r20b787ae... 10/packages/udev/ (udev-084/init udev_084.bb): udev: Fix init script for busybox Apr 08 22:06:27 03coredump 07org.oe.oz354x * r6c0a5c01... 10/packages/altboot/ (altboot_1.0.6-rc1.bb altboot_1.0.6-rc2.bb): altboot: Add 1.0.6-rc2 Apr 08 22:06:31 03coredump 07org.oe.oz354x * r2f1b16a7... 10/packages/initscripts/ (initscripts-1.0/populate-volatile.sh initscripts_1.0.bb): initscripts/populate-volatile.sh: Do not try to overwrite existing symlinks (removes resolv.conf error on boot) Apr 08 22:06:35 03coredump 07org.oe.dev * rdb58973b... 10/packages/xserver-common/ (files/Xdefaults-200DPI.patch xserver-common_1.8.bb): xserver-common: Apply 200DPI bugfix from .oz354x Apr 08 22:06:39 03coredump 07org.oe.dev * r51b8d6bb... 10/packages/udev/ (udev-084/init udev_084.bb): udev: Apply busybox fix from .oz354x Apr 08 22:06:43 03coredump 07org.oe.dev * r905314e5... 10/packages/altboot/ (altboot_0.0.0.bb files/altboot-menu/Advanced/40-bootNFS): altboot: Fix NFS booting with kernel 2.6.16 (not pcmcia-utils) Apr 08 22:06:48 03coredump 07org.oe.dev * r659da00f... 10/packages/altboot/ (altboot_1.0.6-rc1.bb altboot_1.0.6-rc2.bb): altboot: Add 1.0.6-rc2 Apr 08 22:06:52 03coredump 07org.oe.dev * ra1939217... 10/packages/initscripts/ (initscripts-1.0/populate-volatile.sh initscripts_1.0.bb): initscripts/populate-volatile.sh: Include change from .oz354x Apr 08 22:25:02 03coredump 07org.oe.oz354x * rd007b5b0... 10/conf/distro/openzaurus-3.5.4.1.conf: openzaurus-3.5.4.1.conf: Upgrade zarusd to 20060409 to resolve startup bug Apr 08 23:30:01 03rpurdie 07org.oe.dev * r7c80dc8d... 10/packages/linux/ (7 files in 3 dirs): Apr 08 23:30:01 linux-oz-2.6 .inc updates. Apr 08 23:30:01 * Split shared config into spitz and akita. Apr 08 23:30:01 * Make ext3 modular on akita Apr 08 23:30:01 * Make jffs2 modular on spitz Apr 08 23:30:02 * Enable EABI and OABI_COMPAT when using linux-gnueabi Apr 08 23:30:04 * Add sed script to remove defconfig lines we override Apr 09 00:12:36 Does anyone can help me to use OE and bitbake ? A quite new to OE and didn't find enough information in the Wiki to make'bitbake nano' work Apr 09 00:16:12 In fact, I do not succeed how to configure to tell OE to use a toolchain I created with crossdev Apr 09 00:17:43 I got a 'C compiler cannot create executables' because configure does not seems to take the target conf into account (I set it to arm, but the configure use ' --target=i686-linux' instead) Apr 09 00:21:54 What files do I need to edit to build OZ, org.openembedded.oz354fam083/conf/bitbake.conf and build/conf/local.conf only ? Apr 09 00:23:33 cromain: you don't edit org.openembedded.oz354fam083/conf/bitbake.conf, your build/conf/local.conf overriddes it Apr 09 00:24:36 Zero_Chaos: ok thanks, so I just have to edit the build/conf/local.conf file ? Apr 09 00:24:55 cromain: yup Apr 09 00:25:22 zecke helped me a bit, i.e. to add ' ASSUME_PROVIDED += "virtual/libc virtual/arm-linux-gcc" ' Apr 09 00:29:43 hum... I don't have the default value anymore in bitbake.conf now... so I'm going to restart the wiki instructions and just editing local.conf file Apr 09 01:08:14 * chouimat is away: Zzzz Apr 09 03:03:57 I know this is a long shot, but does anyone know where I can get an akita, *cheap*.... Apr 09 03:04:12 * Zero_Chaos wants an akita, but is very poor. Apr 09 03:22:19 Zero_Chaos: ebay, maybe? Apr 09 03:23:04 NA|Gone: naw, barely any there, and not cheap.. I've seen for ~375USD, but I want cheap.... Apr 09 03:26:15 ~akita Apr 09 03:26:17 from memory, akita is the Sharp SL-C1000, or a dog Apr 09 03:26:38 Hm, that's pretty cheap for a device like that.. I've got a borzoi, picked it up for ~650USD Apr 09 03:28:38 hey schurig_ Apr 09 03:28:52 i am trying to remember... you own openhand? Apr 09 03:29:00 or am i thinking of someone else? Apr 09 05:04:13 RP: what about optimize for size, on the cxx00 defconfig? Apr 09 05:04:26 when I use opie-console or opie-embeddedkonsole, is there an /etc/profile or /etc/bashrc or something that gets read? Apr 09 05:10:39 Zero_Chaos: i'm not sure Apr 09 05:10:49 Zero_Chaos: it may depend on whether or not that is a login shell Apr 09 05:11:25 jnc: just tested it, opie-embeddedkonsole reads /etc/profile Apr 09 05:11:29 ;-) Apr 09 05:11:33 jnc: thanks for the response though Apr 09 05:22:47 sure Apr 09 05:28:16 i got my C3000 back, the guy couldn't come up with $300 i was asking for it Apr 09 05:28:17 heh Apr 09 05:28:26 now i'm loading up oz 3.5.4.1 to test out Apr 09 05:28:32 hopefully it works well Apr 09 05:48:53 btw -- mtn 0.26 is released. Apr 09 05:49:05 oooh! Apr 09 05:49:37 njs: hey i just built one of the prereleases into a debian package using dpkg-buildpackage, and now there is a 'mtn' binary, but no monotone symlink Apr 09 05:50:01 that's expected? Apr 09 05:50:14 I didn't hack the debian scripts to make a symlink Apr 09 05:50:20 I don't think anyone else did either Apr 09 05:50:54 oh okay Apr 09 05:51:02 that may be a question you are asked about then Apr 09 05:51:07 "where'd monotone goooo?" Apr 09 05:51:08 :) Apr 09 05:51:35 true... it's sort of an annoying little thing, there's really no _graceful_ way to make the transition Apr 09 05:51:58 it *is* listed in your log though Apr 09 05:52:00 the old name has to go away at some point, and we can't guarantee its presence anyway, so everyone has to figure out the change sooner or later... Apr 09 05:52:02 * jnc reads Apr 09 05:52:22 is monotone a trademark or something? Apr 09 05:52:39 not unless graydon was replaced by a pod person while I wasn't watching? Apr 09 05:53:00 hah. that sounds funny. i'm missing a reference to something Apr 09 05:53:01 why? Apr 09 05:53:11 wondering why the names are changing Apr 09 05:55:53 oh, just because it's tiresome that every user makes up their own short form Apr 09 05:56:28 it's the kind of pointless annoyance that has no reason to exist, so we are making it not exist. Apr 09 05:56:36 ah Apr 09 05:56:54 'mtn' does look easy to type on qwerty Apr 09 05:57:59 i'm not actually serious about that Apr 09 05:58:10 it's late and my mind is excited Apr 09 06:14:46 njs: does monotone still use ~/.mtn ? Apr 09 06:14:52 i mean, ~/.monotone Apr 09 06:14:55 yes Apr 09 06:15:08 hmm, maybe I should have mentioned that Apr 09 06:15:13 oh well Apr 09 06:16:24 i'd say that if you're going to use 'mtn' as an abbreviation, but not abbreviate the settings directory, then the old 'monotone' command should still be valid Apr 09 06:16:56 kind of minor Apr 09 06:17:00 but important IMO Apr 09 06:17:40 the other possibility is to change the settings dir to .mtn, and also accept .monotone Apr 09 06:18:00 preferring .mtn over .monotone; more complicated Apr 09 06:19:07 though i guess this is consistent with other SCM (namely subversion) Apr 09 06:19:22 subversion keeps info in .subversion, and its command is only 'svn' no 'subversion Apr 09 06:24:48 njs: the 'source' link at http://www.venge.net/monotone/ still links to 0.25.2, FYI Apr 09 06:25:04 maybe that's what you want, maybe not Apr 09 06:25:09 * njs whistles Apr 09 06:25:15 dunno what you're talking about Apr 09 06:25:21 heh Apr 09 06:25:32 (thanks) Apr 09 06:32:49 njs: some SCMs have a feature where you can make a changeset, and have other people review those changes by its tag, before you ever commit the changes globally Apr 09 06:33:03 njs: might that be possible with mtn? Apr 09 06:33:30 yes Apr 09 06:33:34 "commit on a branch" :-) Apr 09 06:33:55 hey Apr 09 06:34:44 dangerz: hi Apr 09 06:42:35 jnc: at least, that's the theory -- is there something you want that that doesn't give you? Apr 09 06:45:33 to say to another devloper "hey, look at changeset xyz and tell me what you think, before i apply it to the rest of the world" Apr 09 06:45:48 the theory is Apr 09 06:46:09 what is happening now in OE is that *nothing* gets applied until people discuss patches and bugzilla attachments. it's all very cumbersome Apr 09 06:46:58 if i commit something, people get upset. so i'm wondering if there's a better way for me to give someone the whole picture of what i want to do with a set of changes, without the duplication, and without impacting the global tree before being approved Apr 09 06:47:38 'mtn ci -b my-testing-branch', "hey, Sally, can you look at my-testing-branch and tell me if it looks good to you?", "Sure, looks fine, there were just a few typos, I just went ahead and fixed them", "Cool, thanks, I noticed a few too" 'mtn pull' (fetch's Sally's checkin), 'mtn merge -b my-testing-branch' (combines both of your fixes to it), 'mtn propagate my-test-branch mainline' (integrates your changes with the world) Apr 09 06:48:12 okay Apr 09 06:48:15 :) Apr 09 06:49:14 there's some rough spots around the edges, you probably want some conventions on how you name branches, monotone could do with better tools for keeping track of the large number of branches that can eventually accumulate, etc., but the basic stuff should work _awesome_. I hope. Apr 09 06:50:42 this is the sort of thing the whole system was built around supporting (e.g., if you think about the trick where Sally can just make some fixes to the change she's reviewing, monotone's unusual branch model with multiple heads and all may make more sense!), so we'd be very curious whether it works or not :-) Apr 09 06:50:59 ah Apr 09 06:54:20 you might want to check around before just starting to make dozens of branches, one for each buzilla bug, to make sure people are okay with it... I just make the tools, I have no say in how your project uses them :-) but it's an option that might be worth considering. Apr 09 06:54:55 it would end up being several thousand branches Apr 09 06:55:04 potentially a lot more Apr 09 06:55:29 also i wonder if there's a way to indicate who is working on what at the moment Apr 09 06:56:17 say i want to edit my/foo.bar, and someone else is already working on my/foo.bar Apr 09 06:56:23 there's probably going to be a conflict Apr 09 06:56:35 it would be nice to know ahead of time that there is going to be a conflict Apr 09 06:57:01 jnc: Most distributed SCMs don't allow for that kind of locking Apr 09 06:57:06 err, probably not several thousand branches immediately; there are only like 6000 commits in OE _total_. We can worry about thousands of branches when it happens... Apr 09 06:57:06 ah okay Apr 09 06:57:28 Hell, most don't allow for locking at all, just dirty merges.. Apr 09 06:57:48 i wouldn't even want real locking Apr 09 06:58:03 just a little note that says "hey, fool, somoene else indicated they are going to edit this file" Apr 09 06:58:18 it's sort of an inherent thing. how exactly are we supposed to know that someone's sitting on the beach has opened some file in emacs on their laptop? telepathy? :-) Apr 09 06:58:31 nah Apr 09 06:58:43 they'd use some sort of command to indicate they're about to edit a file Apr 09 06:58:53 that's not entirely unreasonable Apr 09 06:59:00 it'd only apply to files that already exist Apr 09 06:59:18 new files would have to be added. i mean, that's already quite reasonable Apr 09 06:59:26 new files aren't added by telepathy Apr 09 06:59:45 I mean, people are online some of the time too, you could do it then :-) but monotone just doesn't really help that much, it assumes a lossy, decoupled network of databases, which is totally the wrong architecture Apr 09 07:00:01 ohhh Apr 09 07:00:05 good point Apr 09 07:00:45 I bet it'd be trivial to write a little CGI that accepts "edit", "unedit" XML-RPC calls, and displays a little web page of every outstanding edit, if you wanted. Apr 09 07:01:07 plus some little client commands. of course, the problem is getting people to _use_ them... not all that likely... Apr 09 07:01:16 oh Apr 09 07:01:40 i was thinking, to make everything read only. you'd use an edit command, and the SCM would change your files to the correct permissions for editing Apr 09 07:02:00 that's not appropriate for p2p style though Apr 09 07:02:53 every package I try to build stops with the following error: CVS moved to cvs.savannah.[non]gnu.org Apr 09 07:02:58 where do I update the link to CVS Apr 09 07:03:36 cyrus__: there's some goofy things going on with the tree lately Apr 09 07:03:57 jnc - so what can I do, I can't build any packages Apr 09 07:04:09 not sure Apr 09 07:04:35 i'm waiting for the team to upgrade to monotone 0.26, which changes a lot of stuff. it's going to be a few weeks i think before this happens Apr 09 07:04:54 for you, it might make sense to grab an oe.db database from someone who has a known good copy Apr 09 07:04:55 good morning Apr 09 07:04:59 hey B Apr 09 07:05:03 what's the good news? Apr 09 07:05:11 lol Apr 09 07:05:25 k Apr 09 07:05:29 the good news is that kernel 2.6.16 works well on my akita Apr 09 07:05:37 ah Apr 09 07:05:45 i'm testing out 3.5.4.1test on spitz Apr 09 07:05:46 the bad news is that I still can't do a svn checkout with bitbake Apr 09 07:06:08 Bernardo: i just did 'svn up' in my bitbake dir Apr 09 07:06:10 it worked fine Apr 09 07:06:14 what's the matter? Apr 09 07:06:47 I can do a svn checkout from the command line, and do a svn up for bitbake, but now trying to get zaurusd 20060409 svn called by bitbake doesn't work Apr 09 07:07:10 ohhh Apr 09 07:07:34 NOTE: Fetch svn://svn.o-hand.com/repos/misc/trunk;module=zaurusd;proto=http Apr 09 07:07:34 NOTE: Task failed: Fetch failed: zaurusd Apr 09 07:07:34 NOTE: package zaurusd-0.0+svn20060409-r2: task do_fetch: failed Apr 09 07:07:49 and I've had that problem for ages. Apr 09 07:08:12 since zaurusd isn't yet on the mirrors, now I can't build a image for my akita Apr 09 07:10:15 aha Apr 09 07:10:38 it seems svn in my mandriva install is segfaulting if I give it a date... Apr 09 07:13:50 time to reinstall it Apr 09 07:43:35 good morning all Apr 09 07:44:44 njs: the 'commit on a branch' model doesn't work well with monotone if you want to propagate say 5 commits from a total of 10 Apr 09 07:45:58 koen: it works if you knew ahead of time that you would want those 5 as a group :-) Apr 09 07:46:30 koen: (which seems likely, if those 5 are one bug fix and the other 5 are another one...) Apr 09 08:18:50 Hi! Apr 09 08:19:19 again, I'm looking for mr RP- is he about? Apr 09 08:20:46 danboid: he is occasionally Apr 09 08:21:00 what's up? Apr 09 08:22:17 I managed to blag zodttd into having a go with getting the video accel patches for the pxa270 into 2.6, just need to know where to find them and it would be nice if RP could give zod some tips Apr 09 08:23:09 ah okay Apr 09 08:23:24 there's a number of things on Richard's hitlist Apr 09 08:23:54 you don't know anything of these patches? Apr 09 08:24:12 not specifically. i know that they exist Apr 09 08:24:13 somewhere Apr 09 08:24:18 that's about all i know Apr 09 08:24:35 it would be best to be subscribed to the OE mailing list and apply your inquiry there Apr 09 08:25:48 also there is a good chance that RP is the goto guy for pxa270 patches, and inclusion into mainline 2.6 Apr 09 08:29:21 ok- thanks jnc! Apr 09 09:38:16 morning Apr 09 09:40:06 hey CoreDump|home Apr 09 09:40:22 morning all Apr 09 09:40:29 hey RP Apr 09 09:40:32 hello RP Apr 09 09:41:22 danboid: You have a potential problem as there are two ways people have implemented video accel on the pxa. bvdd is one of them, then there's the extra framebuffer approach that Intel used and people are trying to get into mainline Apr 09 09:41:44 I can tell you straight off that bvdd will never make mainline. Apr 09 09:42:09 but mplayer probably doesn't support the extra framebuffer approach :-/ Apr 09 09:42:49 that's what -vo x11 is for ;) Apr 09 09:43:12 actually -vo SDL;) Apr 09 09:43:29 SDL uses bvdd :-/ Apr 09 09:43:58 and this mplayer-stty thingy supports it Apr 09 09:44:38 and it supports "fbdev2" what ever that is Apr 09 09:44:53 CoreDump|home: It might be fbdev2 which we need Apr 09 09:45:37 well, whatever it is called, accelerated video would be very nice indeed heh Apr 09 09:45:45 * koen wants w3220 accell Apr 09 09:46:04 koen: atilib should work with that Apr 09 09:46:33 yay! Apr 09 09:52:11 koen: Is there anywhere you know of that patches and/or tips appear to get the csl gcc branch working? Apr 09 09:52:32 heh Apr 09 09:52:44 the csl branch is already patched to hell Apr 09 09:53:04 koen: But latest CVS still doesn't work :-/ Apr 09 09:53:53 RP: csl is saving some patches for their "release" Apr 09 09:54:29 koen: Ah :-( Apr 09 09:55:29 Damn. Another ext3 failure. I'm going to have to reboot :-/ Apr 09 09:55:31 the 2005q3 stuff should work Apr 09 09:56:19 I'd rather stick with mainline and get the necessary patches from csl and vet them Apr 09 09:59:08 koen: The 2005q3 looks like my best bet I guess, thanks **** ENDING LOGGING AT Sun Apr 09 09:59:56 2006