**** BEGIN LOGGING AT Fri May 20 23:59:56 2005 May 21 00:33:52 poke May 21 00:51:17 <_law_> is bitbake repo down? May 21 00:51:29 bkbits.net probably is. it was down earlier May 21 00:59:26 kergoth: hi there May 21 00:59:33 hey May 21 01:58:15 morning all May 21 01:58:58 hey May 21 02:00:03 kergoth: still up? :) May 21 02:00:14 yep May 21 02:00:19 playing world of warcraft atm :) May 21 02:00:23 RP: read my latest email yet? May 21 02:00:29 kergoth: not yet May 21 02:00:40 * RP reads May 21 02:08:22 kergoth: It all makes sense. I'd probably push the module idea a little further and create modules for parsing, task management/execution, moinitoring and maybe actual recipe control May 21 02:09:00 Some modules will be sepcific to certain uses - there will be a specific parser module for oe's .bb files May 21 02:09:11 "recipe control"? May 21 02:09:45 kergoth: I'm thinking here something that could plug in and select things like BBMASK visually May 21 02:09:52 but on a bigger scale May 21 02:09:56 thats not the responsibility of hte library. May 21 02:10:04 thats the responsibility of the bitbake (or whatever) application May 21 02:10:52 I see this as having a core with an API. Each segment of functionality interacts with the core through the API May 21 02:11:06 hm? May 21 02:11:12 BBMASK is an _interface_ May 21 02:11:19 Any control should be some through an API May 21 02:11:32 how the user decides what hte application will have the recipe box load is up to the user of the bitbake library May 21 02:11:37 BBMASK is maybe a bad example May 21 02:11:40 not the library itself, or any component of it May 21 02:12:15 But how does the user tell the library? May 21 02:12:20 ? May 21 02:12:35 the application calls bb_recipe_load() or whatever, on each file the user wants loaded May 21 02:12:44 how the user tells the application what files to load is dependent on the application May 21 02:12:57 if you wanted it to act like today's bitbake, you'd have it load BBFILES and BBMASK out of th parsed configuration files May 21 02:13:27 Right. I'm seeing this "application" as a modular part of bitbake-ng May 21 02:13:57 the design i'm working on is the part thats independent of OE/portage/whatever other use case is using the library May 21 02:14:06 portage would have a completely different mechanism for that May 21 02:14:14 i see no reason for that to be in the library, as a module or otherwise May 21 02:14:27 Which I'd see as a different recipe control module... May 21 02:14:53 and if i want a gtk application? how are you going to keep that module independent from the application? May 21 02:15:01 and if it isnt independnet of the application, it doesnjt belong in the library. May 21 02:15:06 i dont see the benefit. May 21 02:15:11 if you have a use case, i'd be glad to hear it May 21 02:15:38 I'm think I'm using the word module in a more general context - a lump of code interacting with another via an api May 21 02:16:14 i'm talking about what libbitbake will dlopen() or link against. May 21 02:16:19 you're talking about what will link with libbitbake. May 21 02:16:26 be very clear what you're talking about here May 21 02:16:55 Yes. We're talking on different levels :-/ May 21 02:18:04 most of what you're talking about is stuff that neednt be a part of the libbitbake API that the application or interface interacts with, but a part of the application or itnerface itself May 21 02:18:31 what we need to focus on is getting the core flexible and extensible enough that it meets the needs of our use cases, which is two of those "modules" you've referred to. OE, and portage May 21 02:18:38 for OE, we might have any number of interfaces May 21 02:18:46 but we cant get that far until the library is written :) May 21 02:20:00 okay, for the design of the library and its components (things it dlopens or links against), does the email i sent miss anything? May 21 02:20:06 I think there is a difference to what we're thinking. You see libbitbake as a library and I'm seeing it as more of a standalone application which gets fed recipe data and then feeds the results back to the caller May 21 02:21:08 it will certainly spawn off threads to do things with asynchonous notification to the application of their progress, but that doesnt make the person we're notifying a part of us. May 21 02:24:03 I think I'm just a little concerned with which functionality is left in the application May 21 02:24:15 the bitbake application creates a pool of May 21 02:24:17 recipe execution threads May 21 02:24:33 I think that should be handled by a part of libbitbake May 21 02:24:37 hm? May 21 02:24:38 no, it doesnt. May 21 02:24:44 the workers component of the library does May 21 02:24:51 That was a quote from your email May 21 02:24:56 perhaps i was unclear in the example then May 21 02:25:04 the earlier portion of the email makes it clear where that resides May 21 02:25:17 the application does create the pool May 21 02:25:21 but only via api calls into the library May 21 02:25:30 bb_threadpool_new() or whatever May 21 02:25:36 Right. You can misread that ;-) May 21 02:25:45 * kergoth nods May 21 02:26:23 the apis arent really established, just the architecture. well, i have an api for bitbake-data, but thats about it :) May 21 02:26:46 any other concerns? May 21 02:26:52 or functionality you think we missed May 21 02:27:24 think of it this way. the application is responsible for obtaining input from the user about what we'll be doing, and presenting results of operations to the user May 21 02:27:28 thats about it, really May 21 02:27:28 I just wonder about how much functionality we're going to end up with in the application May 21 02:27:46 whether you use "BBFILES" or whatever is a function of the user interface May 21 02:28:03 Hence me seeding the application as an IO module ;-) May 21 02:28:15 seeing May 21 02:28:27 they use us, not the other way around May 21 02:28:29 think of it that way. May 21 02:28:36 (generally speaking) May 21 02:29:34 I know what you're saying and it comes back to our definition of module. I'll call it an application and we'll both be happy :) May 21 02:29:40 hehe May 21 02:29:55 just a matter of the perspective you're viewing it from May 21 02:30:00 as long as we're on the same page May 21 02:30:05 functionality wise, thati s May 21 02:30:29 We are. My only concern is how much code ends up in the application May 21 02:30:48 Anything ending up in the application is something we couldn't fit into an api and will not be reusable May 21 02:31:15 That's what we need to be careful of... May 21 02:32:01 bitbake as it stands is the application with no api. zecke's work is that start of a data api if you see what I mean... May 21 02:32:29 yeah, thats a big part of what we're doing here, moving all of this into a library that can be used by multiple users May 21 02:32:54 thats why i did the use cases and requirements. to keep in mind that we _already_ have two people with slightly different needs that can be using it May 21 02:33:08 it should be a good means by which to determine what goes into the application and what not May 21 02:33:20 s/means by which/guideline by which/ May 21 02:34:03 I'd say as little as possible should be in the application. If we can do something via an api and make it a module of libbitbake, we probably should May 21 02:34:23 Even if libbitbake then has some oe specific modules... May 21 02:34:40 it already has oe specific modules, in the form of the oe recipe modules May 21 02:34:45 Just becuase it has some oe specific ones, it doesn't mean other applications have to use them... May 21 02:34:50 to handle that file format, interpreter code emission, etc May 21 02:34:57 right, thats the advantage of the modular setup May 21 02:35:10 and is why bitbake-data isnt part of the core, but something recipe modules can choose wehther or not to use May 21 02:35:18 agreed May 21 02:36:33 anyway, obviously details will need to be hashed out as we establish the apis May 21 02:36:40 and start doing some real world testing May 21 02:36:53 hopefully plugging pieces into the existing bitbake 1.x codebase will help with the testing May 21 02:37:24 i'd like to add an extension to the 1.x codebase to use bitbake-data for example May 21 02:37:31 Yes, in a way I think it would be good to work out some of the api based on the 1.x code May 21 02:37:49 zecke's work on the data api is a good start May 21 02:37:50 i just want to make sure we dont lock ourselves into apis given our oe biases May 21 02:38:01 (pulling all the copydata's out of oe for example) May 21 02:38:03 yes its great real world experience, but we have more than oen use case to cnosider May 21 02:38:05 bah, i cant type May 21 02:38:38 Yes, we need to keep that in mind. I don't think its too dangerous to work against oe though, at least initially as long as we look at what we're doing objectively May 21 02:39:06 thats a big reason for _documenting_ our use cases and their requirements. i want them always kept in mind and not forgotten May 21 02:39:12 as long as we keep them in mind, we should be fine May 21 02:39:45 agree May 21 02:39:51 agreed even :) May 21 02:41:04 once i'm in mn, my first step is to fix up bitbake-data to ensure the scope resolution is working and it has solid error handling, then attempt its use in the 1.x codebase May 21 02:41:25 (if possible, anyway) May 21 02:46:35 after bitbake-data, we'll need to finalize the recipe api and module loading so we can pull in bits from bbp for parsing our .bb files May 21 02:56:58 Sounds like a good plan May 21 02:57:15 It would be nice to get bpp running with the 1.x codebase May 21 03:56:22 mickeyl: Feeling better today? May 21 04:00:26 yeah, the fever is gone and the stumoch behaves May 21 04:00:32 i have no idea what that was May 21 04:00:51 mickeyl: pleased to hear it! :) May 21 04:00:54 :) May 21 04:01:15 mickeyl: I'm busy hacking orinoco ;-) May 21 04:01:28 cool May 21 04:01:36 Trying to split the changes into segments which I can then test May 21 04:01:37 quite a lot of changes from 014 to 015 right? May 21 04:01:48 350kb of patch :-/ May 21 04:01:53 wow May 21 04:02:02 I can rule out 50kb of that straight off May 21 04:02:15 The other 300 is going to be more tricky :-/ May 21 04:02:52 Some of it is already applied which complicates things... May 21 04:03:31 I will find the problem though :) May 21 04:03:38 that's the spirit :) May 21 04:03:45 ~curse udev May 21 04:03:47 May the fleas of a thousand camels infest your most sensitive regions, udev ! May 21 04:04:07 i want to add 058, but I really don't understand the patches kergoth did to their Makefile May 21 04:04:22 kergoth`zzz: wake up and explain :) May 21 04:05:25 kergoth`zzz has rather a late night/morning ;-) May 21 04:05:34 s/has/had/ May 21 04:05:44 RP: moin May 21 04:06:03 mickeyl: We need 058 to go with the 2.6.12-rc4 kernel May 21 04:06:15 hi zecke May 21 04:06:57 mickeyl: The udev changes will be why 2.6.12-xxx is behaving strange on my Z (mmc/cf devices weren't getting seen) May 21 04:09:03 right. seen it in the announcement May 21 04:09:32 mickeyl: do you've some python knowledge regarding to performance? May 21 04:10:35 in how far ? May 21 04:13:35 mickeyl: what the expense of calling methods is, how does it differ if it is a inner method or a method in another module May 21 04:13:42 mickeyl: how expensive 'callbacks' are May 21 04:13:47 ah May 21 04:13:54 pretty much a non issue May 21 04:14:25 regarding overall performance May 21 04:14:43 there's virtually no difference between calling functions in different scopes May 21 04:14:49 or namespaces May 21 04:15:26 calling a function is slow enough anyway, so where it is or if it is a callback or not doesn't really add up May 21 04:15:53 mickeyl: if I've for example bb.data.parser.moo.foo.gruft.copy() May 21 04:16:10 mickeyl: it needs to find bb, see if there is a data in bb... to finally find copy May 21 04:16:29 mickeyl: but calling copy is more expensive than finding out it is a method? May 21 04:16:47 mickeyl: what about map vs for (map with a lambda expression) May 21 04:16:58 yeah, of course, 5 lookups need more time than 1 lookup. in the end the functional call is slow enough that it doesn't make a difference though May 21 04:17:06 map is pretty fast May 21 04:17:14 but it's already deprecated May 21 04:17:19 in favour of list comprehensions May 21 04:17:28 morning May 21 04:17:29 same goes for filter and reduce May 21 04:17:31 btw. May 21 04:17:33 morning CoreDump|home May 21 04:17:43 mickeyl: how does list comprehensions differ from haskell? May 21 04:18:07 zecke: i can't answer that since i never wrote one haskell line :) May 21 04:18:46 [ doSomething(x) for x in list if this or that ] May 21 04:18:55 mickeyl: ohh damn I forgot everything again [ x | x <- [1..10] , iseven (2*x) ] May 21 04:18:57 returning a nice list with the results of doSomething May 21 04:19:07 that looks pretty much comparable May 21 04:19:15 at least without knowing the semantics .) May 21 04:20:33 mickeyl: and one can embed the lambda expression in the comprehensions as well? May 21 04:24:04 yes that should work May 21 04:25:43 d'oh May 21 04:25:52 NOTE: package udev-058-r2: task do_package: completed May 21 04:26:36 i never seen May 21 04:26:43 override CFLAGS += May 21 04:26:46 in a makefile May 21 04:26:51 what does it do? May 21 04:28:20 morning May 21 04:28:38 ~lart bkbits May 21 04:28:38 * ibot follow's bkbits with a gauntlet and ... scratch ... HUMILIATION May 21 04:28:43 morning XorA May 21 04:29:03 Im assuming bkbits has become VERY low priority these days May 21 04:29:27 yeah May 21 04:48:16 good afternoon all May 21 04:57:17 koen: afternoon May 21 04:57:44 hey XorA May 21 04:58:00 koen: just multisynced my opie to gpe, I am happy May 21 04:58:10 cool May 21 04:59:28 just upgraded my no name WAP to an SMC one as well May 21 05:03:37 afternoon May 21 05:04:19 hey proti May 21 05:04:58 mickeyl: could we use the progress callback to also pass the just parsed bbfile? May 21 05:05:06 mickeyl: feeling better? May 21 05:06:44 Hi guys May 21 05:07:36 hey Twiun May 21 05:08:23 bitbake became a hog. Don't really know what it is doing between the depends computation and the recipes execution. May 21 05:08:48 But it takes soooooo loooooonng to do anything useful. May 21 05:09:11 * koen adds some more e modules May 21 05:09:35 proti: don't use trunk May 21 05:09:37 mickeyl: should I depend on virtual/evas, evas or evas-foo? May 21 05:09:58 proti: it is still better than cached cow May 21 05:12:00 proti: also remember what I said yesterday, the world dep graph is generated May 21 05:12:12 proti: each bbfile is loaded 3-5 times into memory again May 21 05:12:28 proti: do the calculation, read the todo and stop whining May 21 05:13:35 zecke: yes, that'd work. i'll look into it May 21 05:13:56 koen: yes, feeling a bit better, thanks. May 21 05:13:59 koen: that depends (sic) :) May 21 05:14:25 koen: in general, depend on virtual/evas and I'll make both the -fb and the -x version provide virtual/evas May 21 05:14:35 i'll also remove all the broken ones when i have a chance May 21 05:14:36 ok May 21 05:14:48 * koen changes esmart and engage May 21 05:15:02 raster really should've used dlopen for the X things May 21 05:15:53 queue the 'enlightened' jokes May 21 05:15:55 zecke: Not whinning, just surprised by this. May 21 05:16:51 mickeyl: and probably virtual/ecore May 21 05:17:11 yes, that one also depends on X/fb May 21 05:21:08 proti: I'm suprised you did not read mails on oe@handhelds.org, bitbake-dev@berlios.de, what I've said yesterday... May 21 05:21:48 * zecke wishes he wouldn't be forced to say everything twice a day and people would start reading... May 21 05:22:09 This would allow me to actually do stuff to improve things instead repeating what needs to be done... May 21 05:23:12 rule of thumb, don't three times and you're on the ignore list May 21 05:23:19 I usually teach ibot that stuff May 21 05:23:40 koen: ibot is already on my ignore list ;) May 21 05:23:50 blasphemy! May 21 05:24:05 zecke: I'll have a look. Wasn't aware of it. Sorry. May 21 05:37:54 is it normal that some of the packages fail patching from a fresh copy of openembedded? May 21 05:41:20 luother: that depends, some sf.net packages fail as you hit the 'mirror' page May 21 05:41:50 is that a rhetoric question? May 21 05:42:06 the word 'fail' implies that something is wrong May 21 05:42:08 luother: we're about to set up a QA infrastructure May 21 05:44:32 koen, ok, one example: i get several "Hunk #1 FAILED at 2." for patch ipkg-link-oe.patch when du_patchcmd runs for ipkg-utils May 21 05:45:46 i just thought that shouldn't be with an current unmodified version May 21 05:49:37 luother: sounds like you have an old CVSDATE May 21 05:51:11 afternoon May 21 06:29:22 Ok, why is this world target always computed ? May 21 06:29:55 zecke: I read all the mails in bitbake-dev. What was I supposed to read I missed ? May 21 06:37:57 hey reeno May 21 06:38:42 zecke: Why is the dep world always computed. There is something I don't get at All. May 21 06:40:52 yo zecke May 21 06:43:07 zecke: could your latest fix to fetch.py have broken something? May 21 06:43:15 15:42:01 (91.98 KB/s) - `/data/build/oe/downloads/imlib2-1.2.0.004.tar.gz' saved [886674/886674]rm: cannot remove `/data/build/oe/downloads/fetch.php?file=imlib2-1.2.0.004.tar.gz*': No such file or directory May 21 06:44:00 koen: could be May 21 06:44:11 it downloads the correct file, but OE/bb thinks it needs to use the fetch.php?file=bla May 21 06:44:14 koen: argh May 21 06:44:15 ~lart empte May 21 06:44:15 * ibot does a little 'dpkg -P empte' action May 21 06:44:17 or emte May 21 06:44:28 ? in a URL is not really recommended May 21 06:44:46 remove that thing and use my imlib bb May 21 06:45:52 koen: which bb file is that? fbonly fetches fine May 21 06:46:02 -core and -x11 May 21 06:46:10 zecke: they fetch ok indeed May 21 06:46:43 koen: ok so basename is file.php?file=imlib2... May 21 06:46:56 yeah, something like that May 21 06:47:18 koen: I wonder how unpacking works May 21 06:48:20 koen: the error is not the rm but that it thinks the file was not downloaded May 21 06:49:06 koen: I would agree with mickey how should one on a url like file.php?file= know what file will be downloaded May 21 06:49:08 argh, edje native fails with unresolved png symbols May 21 06:49:15 ~lart bkbits.net May 21 06:49:15 * ibot pushes the wall down onto bkbits.net whilst whistling innocently May 21 06:49:24 koen: and I really wonder how unpacking used to work :} May 21 06:49:46 zecke: sheer luck May 21 06:49:48 dynamic URLs shouldn't be allowed. they undermine our caching, mirroring etc. May 21 06:49:51 period May 21 06:49:57 imo May 21 06:53:46 03zecke123 * r198 10bitbake/lib/bb/data_smart.py: (log message trimmed) May 21 06:53:46 bitbake/lib/bb/data_smart.py: May 21 06:53:46 -Do a deepcopy of the parent for the persistent May 21 06:53:46 data storage constructor. May 21 06:53:46 -Store the dict as _data member and not the instance May 21 06:53:47 -Operate on the dict in the methods instead of the May 21 06:53:49 DataSmart instances... May 21 06:55:44 ooooh, bugzilla looks much nicer May 21 06:55:52 ~hail ggilbert May 21 06:55:54 * ibot bows down to ggilbert and chants, "I'M NOT WORTHY!!" May 21 06:58:32 I'd vote for the mail notifications to go through a separate ML though May 21 06:59:50 i'd second that May 21 06:59:57 as long as we can't attach the maintainar to the bug they should go through the mailinglist May 21 07:00:15 no May 21 07:00:34 pointless traffic for oe@ subscribers May 21 07:01:15 i don't see the need for a seperate mailing list. all people subscribed to oe@handhelds.org are developers or maintainers hence potentially subject to fix bugs. if it's too much noise, then just use filters. May 21 07:01:58 heh May 21 07:02:10 if we have a seperate list we end up that no one subscribes and no one feels responsible May 21 07:02:21 thus having the same situation as before :) May 21 07:02:58 do you know how long it takes for a single message to go through >5 SPAM filters plus a bunch of procmail rules? May 21 07:03:33 bitbake is computing the world target dep-graph inconditionnaly. This is the reason why bitbake seems to hang after the provider hash build. May 21 07:03:42 reenoo_: 0.1 seconds? May 21 07:04:18 koen: more like 5 seconds in worst case here May 21 07:04:21 Before, the world dep was build only when one did specify the world target. May 21 07:04:31 unless you use the one my uni uses, in that case it's somewhere between 1 sec and 2 weeks May 21 07:05:29 mickeyl: the point being that I don't see a reason why I should be flooded with bug notifications while I can't work on anything OE anyway these days May 21 07:05:43 why can't you? May 21 07:06:04 studies, work, real life? May 21 07:06:14 sad, but fair enough. heh May 21 07:06:20 actually i don't care May 21 07:06:24 lets start another list May 21 07:06:34 you would have to put that up with kergoth and treke though May 21 07:07:29 we could configure it to do a weekly summary May 21 07:07:37 yeah, that'd be nice May 21 07:07:57 bugzilla -> prefernces -> tickbox May 21 07:07:59 done May 21 07:08:10 treke will have to do that May 21 07:11:11 where is bugzilla? May 21 07:25:58 Crofton: see topic :) May 21 07:37:20 heh, I looked and skipped right over it the first time May 21 08:03:02 hi May 21 08:03:21 forgot to change nick... May 21 08:04:14 zecke: dont know where to get knight source other then listed in SRC_URI - I can put it temporary on my website May 21 08:04:51 zecke: http://www.hrw.one.pl/tmp/ May 21 08:12:58 hi May 21 08:17:31 hi hrw May 21 08:22:31 today I got email from Spanish OZ user which will be in Poznan in July - free beers :) May 21 08:24:47 mickeyl: opie/noncore/applets/pcmcia - new applet will come instead of cardmon? May 21 08:24:52 proti: any comments on my latest bitbake-dev email? May 21 08:24:54 * kergoth yawns May 21 08:25:03 morning kergoth May 21 08:25:04 hrw: ya. sooner or later May 21 08:25:06 morning kergoth May 21 08:25:07 'morning kergoth May 21 08:25:11 morning May 21 08:25:27 hmm.. I had to upgrade husky to 20050520 opie.. May 21 08:25:29 someone was knocking on the door and woke me up :( May 21 08:25:41 kergoth: killed him? May 21 08:25:44 they gave up after a cuople minutes and started knocking on my neighbors door, and the ones after them, etc May 21 08:27:52 mickeyl: some kind of mediummount for all cards? May 21 08:29:31 hrw: yeah. it manages a database of cards it has previously seen, and you have the option of configuring new cards May 21 08:29:42 configuring means a small list of options then May 21 08:29:47 i.e. what to do on insertion of card May 21 08:30:04 perhaps later even registering unknown cards with the pcmcia subsystem May 21 08:30:19 I had to ask about unknown ones ;) May 21 08:30:23 heh May 21 08:30:40 from time to time someone report that May 21 08:30:45 ya May 21 08:34:13 hmm.. zautrix stopped kdepimpi development or what.. 2.1.4 is nearly one month old... May 21 08:35:52 perhaps he saw something new to rip off^w^wenhance May 21 08:38:39 wellenreiter/pi May 21 08:38:41 ) May 21 08:38:43 ) May 21 08:38:51 :) (fscked shift) May 21 08:39:10 UAH! May 21 08:39:17 the second he does that i resign from open source May 21 08:39:21 really May 21 08:53:33 Anyone had a chance to look through my patches that i sent it last night? May 21 08:54:45 looking good to me. bkbits is down though May 21 08:59:00 mickeyl: noone choose which SCM we will use? May 21 08:59:37 mickeyl, what did you think about the jornada7xx machine changes? May 21 09:00:52 looks like you're removing a lot of stuff May 21 09:00:58 is that no longer necessary ? May 21 09:02:02 i.e. the EXTRA_IMAGECMD, USE_DEVFS, and SERIAL_CONSOLE look like important settings tome May 21 09:04:12 PREFERRED_VERSION_linuc-libc-headers = "2.6.7.0" - we have that version? I was thinking that 2.6.11.0 are May 21 09:04:26 hmm yes May 21 09:04:48 oh and the PREFERRED_VERSION_qte = "4.0.0-snapshot" May 21 09:04:55 that will fail May 21 09:05:22 i don't think 4.0 snapshot will build, let alone being usable May 21 09:05:35 3BOOTSTRAP_EXTRA_DEPENDS += "pcmcia-cs ncurses nano" - nano needs ncurses iirc May 21 09:25:07 mickey_away, most of the stuff in the old jornada720.conf file was distro specific and should be in the distro file. The things in jornada7xx.conf should be the bare machine stuff. May 21 09:28:56 * chouimat is away: lunch and stuff May 21 09:34:26 Ken|JLime: IPKG_ARCHS are set in classes/rootfs_ipk.bbclass to "all any noarch ${TARGET_ARCH} ${IPKG_ARCHS} ${MACHINE}" - no need to set in machine conf May 21 09:35:29 we probably can drop "any noarch" from there.. May 21 09:35:54 hrw: I encountered some 'noarch' packages May 21 09:35:58 mostly scripts May 21 09:36:23 koen: shouldn't they be "all" rather? May 21 09:37:00 no idea, it's a question of personal preference I guess May 21 09:37:05 in OE we have "all", TARGET_ARCH and MACHINE basically May 21 09:37:20 but the packages are out there, so removing noarch will break those May 21 09:37:26 yep.. May 21 09:38:08 but when we drop setting IPKG_ARCHS from machine confs then tune-xscale.conf should add "arm" ther May 21 09:39:42 it makes sense for the machine to set it's main archs May 21 09:40:10 since I could add a machine without including tune-foo May 21 09:41:04 yep May 21 09:41:27 does anyone else get confused by the arm numbering too? May 21 09:42:00 I think that IPKG_ARCHS in machine conf should be listed only those also-accepted ones (like 'arm' on arm5vte) May 21 09:42:24 arms... arm5vte, arm7, arm9 etc.. argh.. May 21 09:42:35 which should be arm5ve as someone noted May 21 09:42:38 it should list all the packages that will work on it. May 21 09:42:48 hrw: isn't arm9 an arm4 core? May 21 09:42:55 or was that the arm920? May 21 09:42:57 if you're running an armv6, then armv5 binaries will likely work just fine. May 21 09:43:23 koen: dont know May 21 09:44:14 with all those sa, xscale and omap cpu's I can't keep tracks what's what anymore May 21 09:45:07 then let someone else maek sure its accurate and dont worry about it. May 21 09:45:14 yeah May 21 09:45:18 :) May 21 09:51:55 bye May 21 09:53:18 aha, the omap5912 has an arm926 core May 21 09:54:26 I've made some changes to the webpage, the patches link is therefore different, please download from http://www.jlime.com/downloads/releases/shrek/openembedded-dev/6xx/patches/20050520/ May 21 09:55:26 Please let me know when they are applied (so i can bk pull). Any news on the blackbox.bb package i supplied a few days ago? May 21 09:55:57 t looked ok to me May 21 09:57:59 If the jornada7xx.conf machine replaces the old jornada720.conf machine file we need to make some minor changes in for example the qte file. May 21 09:58:15 just change the jornada720 to jornada7xx May 21 09:58:29 so that the touchscreen among other things get properly exported May 21 09:59:22 Also adding jornada6xx (which same settings as jornada7xx) in the qte_2.3.10 file would be great, i pointed this out a few days ago but dont know if anyone actually added it May 21 09:59:59 actually looks like someone did May 21 10:00:15 just change the jornada720 line to jornada7xx in qte_2.3.10.bb May 21 10:07:39 Ken|JLime: Has anyone dealt with those patches yet? May 21 10:12:27 maybe we should people attach patches to bugzilla so the don't get lost May 21 10:12:49 insert "let" somewhere in that sentence May 21 10:13:46 We could always add an ehancements category to bugzilla May 21 10:14:00 that's already there May 21 10:14:05 Having them via email sometimes helps though as you can see them... May 21 10:14:19 that's why we have bugzilla email the list May 21 10:14:27 Moving the Bugzilla stuff to its own list is probably an idea May 21 10:14:52 having bugzilla sends us a weekly summary is a better idea May 21 10:15:19 that way we still get mail, but cuts down on noise May 21 10:15:47 Perhaps. I know I'm going to have to set up filters to move them to their own mail folder at this rate May 21 10:17:04 that's what daily/weekly summaries are for May 21 10:25:19 Ken|JLime: I have those changes applied locally. bkbits.net doesn't seem to want to talk to me at the moment though May 21 10:25:43 RP: bkbits is sulking again May 21 10:25:59 bitmover's gentle way of telling people to piss off May 21 10:26:09 koen: I guess this is just going to get more and more regular :-/ May 21 10:28:46 did anyone test our repo with a different scm yet? May 21 10:28:52 like cogito or monotone? May 21 10:30:06 i tested it with an old monotone, so slow that it was unusable. need to test current May 21 10:30:21 kergoth: I like the idea of cogito May 21 10:31:06 yeah, it seems pretty decent. need to play with it more May 21 10:31:16 morning kergoth May 21 10:31:20 hey May 21 10:31:40 * koen browses to http://kernel.org/pub/software/scm/cogito/ May 21 10:40:43 * france is away: Away May 21 10:42:56 * koen does a bk export to play with cogito May 21 10:43:34 hy all May 21 10:43:50 hey jskcr|mobile May 21 10:44:27 hya koen, ya know if tslib stable is out yet?? May 21 10:44:49 nope, don't know May 21 10:45:14 im at a wifi hotspot drinking a beer using opie-irc on a jornada right now :P May 21 10:46:01 Im testing usablity versus blood alchohol llleevel :::P May 21 10:48:57 * chouimat is away: food gathering May 21 10:56:08 wow May 21 10:56:21 cogito imported a whole OE tree in about 3 seconds May 21 10:56:37 nice May 21 11:02:18 re May 21 11:02:48 zecke, pb_: comments on the last bitbake-ng email? May 21 11:03:08 was that the one you copied to me? May 21 11:03:14 re May 21 11:04:06 kergoth: about gmame? May 21 11:04:14 no, the one summarizing the architecture May 21 11:04:14 yep May 21 11:04:40 ah, I haven't read that yet May 21 11:04:43 I'll take a look in a bit May 21 11:05:14 k, thanks May 21 11:05:28 just looking to make sure i didnt miss anything critical. need eyes on it May 21 11:05:40 ~lart gitweb people May 21 11:05:40 * ibot whips gitweb people with a wet and grimy noodle just because May 21 11:05:51 righto May 21 11:06:00 the 'download gitweb' link leads to a perl script doing May 21 11:06:01 print $cgi->redirect('http://www.kernel.org/git/gitweb.cgi'); May 21 11:06:19 for the love of god, stop messing around! May 21 11:06:21 kergoth: ah recipe boxes et all? May 21 11:06:36 kergoth: nothing I wouldn't agree with (expect I miss python...) May 21 11:07:43 zecke: you'll note that i didnt mention the inline python scripting, because thats likely specific to the .bb recipe module May 21 11:09:06 kergoth: right. The overall design looks ok, splitting out libbitbake-data sound about right as well May 21 11:13:09 zecke: okay, cool. let me know if you think of anything that should be changed May 21 11:14:02 kergoth: scopes sound right, persistent storage, central and configurable work-/executionpool sounds right as well May 21 11:14:17 kergoth: now API and the actual implementation seem to matter May 21 11:14:29 right May 21 11:14:32 koen you are watching the european song contest? May 21 11:14:35 need to iron out the details May 21 11:14:46 woglinde: Frank Herbert's Dune May 21 11:14:57 koen *g* May 21 11:16:45 kergoth: it is obvious that a recipe box 'controls'/defines the syntax of the recipes May 21 11:49:29 Is there, other than the snapshots, an alternative for bitkeeper wrt openembedded? May 21 11:52:46 hertog what you mean? May 21 11:54:20 Well, to get the changes in the packages, I do bk pull, but since bkbits.net is down (seems down in any case) I was wondering if there was an alternative repository May 21 12:03:29 Hertog: doesn't oesources.org have a oe snapshot? May 21 12:07:06 * chouimat is back. May 21 12:26:03 aargh May 21 12:26:20 why don't the cogito docs have a section "publishing your tree" May 21 12:26:33 isnt publishing just rsync? May 21 12:26:47 they babble on and on about adding remote branches, but not about creating your own May 21 12:27:02 kergoth: rsync, file, http, ssh+git May 21 12:27:52 I suspect it involves moving the tree to a remote-visible location May 21 12:28:17 BK servers down? May 21 12:28:20 yep May 21 12:29:14 temporary? May 21 12:29:21 we hope so May 21 12:30:07 koen|tv: i'm curious about how well cogito handles merges/conflicts. May 21 12:30:15 me too May 21 12:30:28 linus' post about it sounded awfully propaganda-ish May 21 12:30:57 doesnt mean its wrong. sometimes when talking about bitbake and oe i sound propaganda-ish too May 21 12:30:59 :P May 21 12:31:05 sometimes? May 21 12:31:09 hehe May 21 12:32:21 aha May 21 12:32:24 cg-export May 21 12:33:47 hmm, that does nothing May 21 12:34:00 just a fancy way of doing mkdir May 21 12:34:39 couldnt you create a mirror of your tree in the remote-visable location, and just push changes to it on occasion? May 21 12:34:44 * kergoth doesnt know the git/cogito terminology, but you get hte iea May 21 12:34:49 s/hte/the/; s/iea/idea/ May 21 12:35:13 that was my next idea May 21 12:37:15 * koen|tv waits for rsync to finish May 21 12:49:31 hmmm May 21 12:49:47 I need a way to convert my .git/ dir to oe.git/ May 21 13:21:29 I don't get it: cg-init should import (cg-add) the current directory in the repo May 21 13:21:40 but cg-ls return nothing May 21 13:24:37 * koen|tv suspects cg-add is broken May 21 13:25:42 heh May 21 13:25:50 cg-add is broken indeed May 21 13:26:06 koen@dominion:/data/build/oe/cogito$ cg-add openembedded/COPYING.MIT May 21 13:26:06 Adding file openembedded/COPYING.MIT May 21 13:26:20 aargh May 21 13:26:24 ~lart me May 21 13:26:24 * ibot eats koen and falls over dead May 21 13:26:34 bk commit != cg-commit May 21 13:31:10 hehe May 21 13:31:30 I actually typed bk commit three times! May 21 13:31:58 for i in `find openembedded` ; do cg-add $i ; done May 21 13:32:31 that's only limited to your diskspeed May 21 13:46:07 /usr/local/bin/cg-commit: line 149: /usr/local/bin/git-update-cache: Argument list too long May 21 13:46:50 I only imported the whole OE tree, shouldnt be more than 2500 files.... May 21 13:47:56 hehe May 21 13:49:48 * koen tries to figure out where to put an extra xargs May 21 13:50:45 * pb_ stabs lilo and his "major downtime" May 21 13:51:08 and his incessant global notices, obviously May 21 13:51:40 ah, the ircperson, not the bootloader May 21 13:52:24 pb_: hi May 21 13:52:33 hi france May 21 13:52:34 * france is back (gone 03:11:50) May 21 13:52:41 I hath returned May 21 13:52:52 koen: heh, yes. I haven't used lilo-the-bootloader for years. May 21 13:53:19 I recently upgraded my server to grub May 21 13:53:37 well, I did that a year ago, but could only test it recently :) May 21 13:54:34 kergoth: you're going to love cogite, it's a bunch of shellscripting around git May 21 13:54:41 lots o' sed May 21 13:54:47 hehe May 21 13:59:04 kergoth: git isn't really what we want May 21 13:59:20 it lacks a easy to use push feature May 21 13:59:47 :\ May 21 13:59:56 the way I see it, the 'main' repo needs to add all branches from the devs May 21 14:00:28 the lack of good docs and howto's is another downside May 21 14:01:43 git is great for publishing what you do and allowing everyone to pull from you as they like May 21 14:01:56 which is exactly the model the kernel works with May 21 14:04:24 kergoth: with our new scm, we might consider having two or three main repo and sync between those May 21 14:04:44 that would limit repo downtime to practically zero May 21 14:08:06 anybody know of a package to handle ddns for ipv6 clients on linux? May 21 14:08:33 windows seems to be able to do it, but I can't find any solution for linux. May 21 14:08:59 haven't got that far in my ipv6 schemes yet May 21 14:09:18 1) ipv6 2) ... 3) world domination May 21 14:10:03 mm. I've just been setting up ddns for our v4 clients at the office, and it'd be neat to make it work with v6 as well. May 21 14:10:56 gotta figure out a solution for the l2tp vpn clients, too, which is a bit tricky. May 21 14:16:41 koen: where are the source tarballs for familiar 0.8.2? I don't see them in the feed directory. May 21 14:18:42 hmm, major policy violatino on hh.org May 21 14:24:08 bye May 21 14:34:55 france: only until it's fixed ;) May 21 14:35:24 true, but the bins should not have been put out with out the source May 21 14:35:42 and it needs to be the real source not a link to cvs, etc. May 21 14:35:43 * Twiun shrugs May 21 14:35:49 we have been burned on this many times. May 21 14:36:10 it is a legal thing required by the gpl May 21 14:36:15 it happens again and again - it'll be fixed at some point, we're not perfect May 21 14:36:26 pb_: http://familiar.handhelds.org/source/ May 21 14:36:26 the correct thing is for me to turn off the server May 21 14:36:53 france: err, no, the correct hing is to stop distributing the offending binaries. May 21 14:37:04 or look in http://familiar.handhelds.org/source/ May 21 14:37:06 which is the entire distro May 21 14:37:10 koen: ;) May 21 14:37:16 koen: looking................... May 21 14:37:45 looks good to me May 21 14:38:24 0.8.1 only took about 4 days of uploading May 21 14:38:24 whois france May 21 14:38:27 ;) May 21 14:39:38 one of the founders of hh.org and author of the bootldr, did the first port to the 36xx. May 21 14:40:29 koen: it looks, good, what about the build envir.? May 21 14:40:30 nah, was curious about the name and wondered if you were in .fr May 21 14:40:35 nope May 21 14:40:37 last name May 21 14:40:49 koen: the FSF is a pain about that as well. May 21 14:40:54 france: you want an bk export or bk tag so you can clone it? May 21 14:41:16 * koen wonders about fsf people using bk May 21 14:41:28 koen: we just need a copy, as they tend to send out legal notices when, folks complain that they can not build something May 21 14:41:50 they even sent us a legal notice once that they could not compile gcc May 21 14:41:59 and it was the version that they had on gnu.org May 21 14:42:21 somehow it was our fault they could not compile their own code. May 21 14:42:37 the trick was to use RH-6.2 May 21 14:42:46 which version was this? sounds fairly old May 21 14:42:58 when (build machine is up && bkbits is up again) I'll upload the OE tree May 21 14:43:01 lots of toolchain folks still use 6.2 May 21 14:43:08 it is a common stable base May 21 14:43:21 it is not unusual May 21 14:43:45 * koen still remembers RH 6.0 aka "crash-o-matic" May 21 14:43:49 so they are all on the same page, as different distros, have different toolchains, that produce different errors in the testsuites. May 21 14:43:53 koen: thanks May 21 14:44:08 but it needs to be the OE tree build for 8.0, 8.1 and 8.2 May 21 14:44:21 0.8.0 + 0.8.1 should be there May 21 14:44:33 I tagged 0.8.2 May 21 14:44:38 cool, do you have a URL? May 21 14:44:49 it should be in the same dir May 21 14:45:01 looking.......... May 21 14:45:05 called OE-export or something similar May 21 14:45:34 if one of those is missing, I'll upload that too May 21 14:46:34 I see the OE snapshots for 8.0 and 8.1 but no packages for 8.1 May 21 14:47:24 crap May 21 14:48:06 could yo dou a 'chmod a-r releases/v0.8.1' ? May 21 14:51:13 sure... May 21 14:51:55 since I don't have the cvs snaps anymore May 21 14:52:18 koen: it looks like you wond it and the sticky bit is set, so you can chmod it. May 21 14:52:26 s/wond/owned/ May 21 14:53:04 done May 21 14:53:50 you will have to fix the web pages, I will have to remove it from ipkgfind. May 21 14:54:04 unless you think you can find the source May 21 14:54:57 hmm, where is the source for v0.7.2? May 21 14:55:14 moving this conversation to #handhelds.org May 21 15:03:46 hi, is there a tutorial how to build a simple hello world using oe? May 21 15:15:17 <[g2]> chrta, I can explain that to you in openslug May 21 15:15:30 ok May 21 15:17:05 'night all May 21 15:17:18 good night May 21 15:40:07 03zecke123 * r199 10bitbake_qa/conf/bitbake.conf: May 21 15:40:07 bitbake_qa/conf/bitbake.conf: May 21 15:40:07 -Try to include the documentation.conf in the test cases May 21 15:40:07 as well May 21 15:49:22 03zecke123 * r202 10bitbake_qa/doc/README: May 21 15:49:22 bitbake_qa/doc/README: May 21 15:49:22 -Document the content_checker and doc_checker tool May 21 15:49:36 03zecke123 * r201 10bitbake_qa/ (4 files in 2 dirs): May 21 15:49:36 bitbake_qa/bin/bittest: May 21 15:49:36 -Include content_checker May 21 15:49:36 bitbake_qa/content_checker/*.py: May 21 15:49:36 -Check for 'bad_signs' in variables. For example May 21 15:49:37 check for '?' in http://foo.foo.foo/foo=?foo.tar.gz May 21 15:49:39 and report these signs. May 21 15:50:14 * pb_ fears zecke123 May 21 15:50:44 pb_: hehe May 21 15:52:14 when I was born my infinite was initialized with 'foo' instead of blank symbols May 21 15:54:18 <[g2]> zecke, congrats on the memory usage changes... I've haven't tested yet but I've heard good things and I'm looking forward to trying it soon May 21 15:54:28 zecke: heh May 21 15:55:00 damn something is wrong with my turing tape... it forgets to spit out words as hell... May 21 15:55:25 <[g2]> I'm also quite keen on the tinderbox and 1.x progress May 21 15:56:01 [g2]: Memory usage is down, but now we've a problem with CPU usage May 21 16:12:02 mickey_away: ping May 21 16:13:13 zecke: yah, I noticed that bitbake does seem noticeably slower now than it used to be. May 21 16:13:29 particularly during the "building provider hash" step. May 21 16:14:32 pb_: yes and the delay after it is due the world tree May 21 16:14:52 right May 21 16:15:09 pb_: I wonder what would happen if you do all the 'data' processing in the progress callback May 21 16:15:25 pb_: I wonder if it is clean to do it May 21 16:15:27 I also had a few weird occurrences where bitbake sometimes just wouldn't do anything. I don't know what was going on there. May 21 16:15:49 zecke: I'm not sure I understand what you mean. May 21 16:16:29 pb_: damn my english is so broken May 21 16:16:42 pb_: we've the progress callback (after each bb file was parsed) May 21 16:17:05 pb_: and I wonder if we could put all the calculations we need into this progress callback May 21 16:18:00 zecke: I guess you could, but I'm not sure what it would buy you. May 21 16:18:46 pb_: I do not have to unpickle the data May 21 16:19:03 oh, right, because you have it on hand right there. May 21 16:19:13 yes, that sounds like a good idea in that case May 21 16:19:28 use the data when it is fresh and juicy May 21 16:19:49 but we would tie make and bin/bitbake together... and I wonder if it is clean(tm) May 21 16:20:11 they're already quite tightly coupled. May 21 16:20:40 originally, make.py contained the common code that was factored out of oemake and oemake2. May 21 16:21:15 now that we only have one oemake/bitbake implementation, it doesn't serve much of a purpose. afaik, nothing else uses that module. May 21 16:23:28 so I think you should feel free to bash that code around any way you like. May 21 16:24:38 okaay May 21 16:26:01 did we ever use BBFILE_COLLECTION? May 21 16:26:11 yes, people use that May 21 16:26:29 (not that I want to throw that away) May 21 16:27:13 its commonly used to have what gentoo would call an overlay. so you can have a local repo of modified packages that override upstream. companies for example May 21 16:27:37 yeah, I use it all the time May 21 16:27:48 * zecke should use it all the time at ROAD :} May 21 16:27:57 any attempt to remove that feature would be met with fierce resistance May 21 16:28:23 again I just asked out of interest May 21 16:28:28 heh May 21 16:40:51 http://bugs.openembedded.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=+ May 21 16:40:59 does that work for you guys? May 21 16:41:54 hmm May 21 16:42:04 no, "order=relevance" isn't valid. May 21 16:42:07 where did that come from? May 21 16:42:55 pb_: Search-> and in Words enter ' ' (dunno how I entered ' ') May 21 16:43:22 oh yeah May 21 16:43:22 weird May 21 16:44:23 actually, it looks like "order=relevance" does work, I'd just never heard of it before. May 21 16:44:33 http://bugs.openembedded.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=oe May 21 16:44:41 that url seems to work fine, for example May 21 16:45:09 now I know what I did wrong... I won't enter a ' ' again May 21 16:45:13 heh May 21 16:45:20 <[g2]> so the higher BBFILE_PRIORITY_... gets used first May 21 16:45:22 I guess you should do like it says and mail the webmaster May 21 16:45:27 [g2]: just so May 21 16:57:41 * tigrux is away: Absent but still around May 21 17:11:36 kergoth: where do I need to set USE_NLS? May 21 17:12:25 ? May 21 17:13:37 kergoth: I've breen tracking the uclibc build problem... May 21 17:14:01 kergoth: it is due a missing USE_NLS but conf/local.conf sounds right for now... May 21 17:14:04 zecke: you cant build gcc-cross with nls support and uclibc without it. May 21 17:14:14 uclibc defaults to without, gcc-cross defaults to with. May 21 17:14:28 so set USE_NLS_gcc-cross = "no" or whatever May 21 17:14:31 that'll take care of it May 21 17:14:44 I did USE_NLS_uclibc = "yes" May 21 17:14:52 no idea whether that works or not May 21 17:15:01 at a minimum uclibc's nls support will hugely increase the size of your binaries May 21 17:15:08 you dont want it. May 21 17:15:14 theres a reason i changed the defautl :P May 21 17:15:29 kergoth: besides documenting it, how to keep track of these inter package deps? May 21 17:15:58 there is no way for one package to depend on something else being built in a certain way, as things stand today. May 21 17:16:15 just make the defautls sane, and document it so users know to change both if they change either. May 21 17:16:23 brb May 21 17:18:07 some distros do TARGET_OS = "linux" some do it with ?= is there a reason for it, could we just use ?= ? May 21 17:18:33 you dont understand how ?= works, do you. May 21 17:18:39 it sets a variable only if its unset May 21 17:18:53 TARGET_OS is _always_ set, because its default is in bitbake.conf May 21 17:18:59 so a ?= assignment is a no-op in this case May 21 17:19:47 heh May 21 17:21:05 kergoth: god damn it is late and I'm tired. some distros (like familiar) do TARGET_OS = "linux" and I can set whatever I want in my conf/local.conf... May 21 17:21:16 no May 21 17:21:22 kergoth: I wanted to ask why distros don't use ?= and if I could change that May 21 17:21:26 if the distro sets it, you cant set TARGET_OS in your local.conf May 21 17:21:29 because it loads after you May 21 17:21:37 if they set with ?=, its a no-op, and you _have_ to set it in your local.conf May 21 17:21:43 there's no clean solution to that right now May 21 17:22:23 kergoth: no distro/${DISTRO}.conf is included after local.conf (which makes sense) May 21 17:22:36 thats what i said. May 21 17:22:43 if the distro sets it, you cant set TARGET_OS in your local.conf May 21 17:22:43 because it loads after you May 21 17:22:45 kergoth: so distro will overwrite it May 21 17:22:49 damn May 21 17:22:49 yes. May 21 17:23:07 if the distro sets with =, stting in local.conf does nothing. if they set with ?=, that does nothing, so you -have- to set it in local.conf. May 21 17:23:13 * zecke slowly heads toward the bed May 21 17:23:14 those are the options. thats it. May 21 17:23:22 right :} May 21 17:30:21 zecke: heh, if the 'include' directive didnt load files that have already been loaded, kthen you could 'include distro/${DISTRO}.conf from local.conf, exactly where you want it loaded, after setting DISTRO.. May 21 17:30:24 but as is that wouldnt work May 21 17:30:55 * kergoth gets fod May 21 17:30:57 s/fod/food/ May 21 17:39:37 kergoth: placing a distro/distro.conf in your local directory (and using BBPATH) will work as well May 21 17:39:46 kergoth: for the people trying uclibc it should be ok May 21 17:47:42 good nite May 21 17:48:56 night May 21 17:55:10 Btw, anyone feeling up to it would be most welcome to add glibc 2.3.4 to OE. So far i'm using a copy of 2.3.3 (due to it using {PV} it downloads the right one). Either just do that or make a new one May 21 17:55:48 As i said before with anything older than 2.3.4, SH3 can't create dynamicly linked files May 21 18:02:11 good nite May 21 19:40:15 hey Ken|JLime, you alive? May 21 20:07:24 I'm trying the OZ 3.5.3 on a Sharp SL-5500 at the moment,,, May 21 20:08:06 miskinis: read the topic of this channel. May 21 20:08:18 miskinis: "This is not a distribution support channel" May 21 20:59:42 kergoth: you could have at least pointed miskinis to #openzaurus May 21 21:00:32 i would have. expected some sort of response May 21 21:00:48 uh huh ;) May 21 21:01:05 like a justificiation for asking it here, or telling me to fuck off, or _something_ May 21 21:01:11 heh May 21 21:35:40 husky? May 21 21:35:46 ibot, husky? May 21 21:36:03 hrm no ibot May 21 21:58:05 hmm.. build bails out a quilt May 21 23:37:57 morning May 21 23:55:16 i think oe is confused **** ENDING LOGGING AT Sat May 21 23:59:57 2005