**** BEGIN LOGGING AT Mon Jul 04 02:59:58 2011 Jul 04 08:01:27 jo zecke Jul 04 08:04:53 hi florian Jul 04 08:05:10 good morning Jul 04 08:06:01 woglinde: hey Jul 04 08:08:47 gm all Jul 04 08:11:07 he crofton Jul 04 08:11:10 where are you now? Jul 04 08:11:15 Dublin Jul 04 08:11:16 karpats? Jul 04 08:11:20 hm Jul 04 08:11:32 you met the ubuntu guys last week? Jul 04 08:11:39 I am going to talk about the E100 at Trinity Jul 04 08:11:47 not for ubuntu Jul 04 08:14:27 hrw is around with his wife Jul 04 08:14:37 hehe Jul 04 08:14:43 so he stays a bit longer Jul 04 08:14:57 yeah Jul 04 08:15:02 they are being tourists Jul 04 08:15:07 I was working yesterday Jul 04 08:15:09 on my inbox Jul 04 08:28:56 morning all Jul 04 08:29:01 gm Jul 04 08:29:22 hello Jul 04 08:29:36 Crofton: still in EU? Jul 04 08:29:43 yeah Jul 04 08:29:47 leaving in the morning though Jul 04 08:29:55 speaking at Trinity in Dublin in a bit Jul 04 08:30:02 then home, finally Jul 04 08:30:13 heh Jul 04 08:31:07 hi bluelightning Jul 04 08:31:21 hi woglinde, Crofton, ant_work Jul 04 09:13:24 /gobject/glib-mkenums: line 3: use: command not found Jul 04 09:13:47 /git/gobject/glib-mkenums: line 21: my: command not found Jul 04 09:13:51 ? Jul 04 09:19:06 nobody yes? Jul 04 09:20:02 glib/glib-2.0-native- errors Jul 04 09:26:07 im probably missing a dependency Jul 04 09:28:20 you proably should say what you are using Jul 04 09:29:08 huh? Jul 04 09:30:00 oe.dev oe-core Jul 04 09:30:04 the moonbased bitbake Jul 04 09:31:08 oh Jul 04 09:31:21 shoot i dont even know Jul 04 09:31:55 bitbake-1.10.2 Jul 04 09:32:12 The amount of help you can get is directly proportional to the amount of info you can provide :) Jul 04 09:33:11 http://www.openembedded.org/index.php/Getting_started Jul 04 09:33:54 i think it was a dependency missing im installing hella more stuff i was missing Jul 04 09:34:29 quilt m4 you name it i was missing it wich is odd i considered my host build ready for it all Jul 04 09:35:22 guess im running the dev branch Jul 04 09:35:28 http://www.openembedded.org/index.php/OEandYourDistro Jul 04 09:35:49 Check out the instructions for your distro (or near equivalent) at that page first. Jul 04 09:36:00 awesome Jul 04 09:36:16 dunno how i go so far without installing dependencies Jul 04 09:36:17 Also, use bitbake from git not 1.10.2. Jul 04 09:37:48 i.e.: git clone git://git.openembedded.org/bitbake Jul 04 09:39:04 ;) Jul 04 09:40:45 morning Jul 04 09:41:44 Mon Jul 4 05:38:07 EDT 2011 Jul 04 09:42:49 morning Jul 04 09:42:58 yeah i must be weird waking up at 5am on july4 and playing with oe Jul 04 09:43:06 hehe Jul 04 09:43:24 5am, your late to start the beer :-) Jul 04 09:44:06 hi xora Jul 04 09:45:44 hey woglinde Jul 04 09:53:34 hm that bitbake is broken Jul 04 09:56:20 http://pastebin.com/Km4xaaeT Jul 04 09:56:36 nobody_-: always a possibility. Could try the latest tagged version, 1.13.2 IIRC. Jul 04 09:57:12 that doesn't look like bitbake breakage to me Jul 04 09:57:22 what makes you think this is bitbake's fault? Jul 04 09:57:29 i dunno Jul 04 09:57:43 the bottom of the paste is the git bitbake error Jul 04 09:58:07 morning pb_ Jul 04 09:58:12 oh, right Jul 04 09:58:18 what version of python do you have? Jul 04 09:58:33 2.5.2 Jul 04 09:59:25 looks like you need to get a better version Jul 04 09:59:46 using debian stable Jul 04 10:00:14 testing? or (shudder) unstable? Jul 04 10:00:45 dunno. "except as" is supported from 2.6.0, so whatever suite gives you at least that version I guess Jul 04 10:06:07 hm what now with the wiki? Jul 04 10:06:17 get ka6sox it working again? Jul 04 10:15:34 nobody_-, http://openembedded.net/index.php/Required_software - 2.6.x or 2.7.x is required when using the latest bitbake versions Jul 04 10:15:49 oh damn my buildhost just ran out of space on root upgarding Jul 04 10:15:50 and afaik some of the latest bitbake versions is required by now (oe-core) Jul 04 10:16:08 :D Jul 04 10:16:42 ok but i think its going to be a bit of time before i can try to build again heh Jul 04 10:23:18 lul this sux Jul 04 10:23:31 i need a better buildhost Jul 04 10:23:41 dont we all Jul 04 10:23:47 48 cores, 100G of ram Jul 04 10:24:36 i'd be happy with a 3ghz 2GBram and terrabyte IDE Jul 04 10:25:00 currently using an old dell from like the darn late 90's Jul 04 10:25:42 2.4ghz 512ram 40GB root 200GB mount Jul 04 10:25:52 5B (beers) is enough for me Jul 04 10:26:02 the more, the better of course Jul 04 10:26:37 good water cooling, taste, hm yummy Jul 04 10:36:27 ynezz haha Jul 04 10:36:37 ynezz btw. will we met at elce? Jul 04 10:37:02 sure, are you going? Jul 04 10:38:01 yes Jul 04 10:38:15 my company sponsors me Jul 04 10:38:23 good :) Jul 04 10:47:50 hi woglinde Jul 04 10:51:32 pb_: hey Jul 04 10:51:38 hi ant_work Jul 04 10:51:52 I'm totally lost wrt oe-core / sysroots Jul 04 10:51:55 :p Jul 04 10:52:20 what's the problem? Jul 04 10:52:28 I don't recall oe-core being very different from oe.dev in that respect Jul 04 10:52:29 it seems there is any ARCH sysroot Jul 04 10:54:55 so I'm obliged to make klibc machine-specific again :/ Jul 04 10:56:08 (long-term solution will be building against linux-libc-headers instead of kernel's ones) Jul 04 10:56:20 as debian already does Jul 04 11:01:15 03Steffen Sledz  07org.openembedded.dev * re05db51b7a 10openembedded.git/recipes/ppp/ppp_2.4.5.bb: (log message trimmed) Jul 04 11:01:15 ppp-2.4.5: own package for PPPoL2TP plugin Jul 04 11:01:15 Adding that package fixes the following error message. Jul 04 11:01:15 NOTE: package ppp-2.4.5-r1: task do_qa_staging: Started Jul 04 11:01:15 WARNING: the following files were installed but not shipped in any package: Jul 04 11:01:15 WARNING: /usr/lib/pppd/2.4.5/pppol2tp.so Jul 04 11:01:16 WARNING: /usr/lib/pppd/2.4.5/openl2tp.so Jul 04 11:01:17 03Steffen Sledz  07org.openembedded.dev * r0f10089de3 10openembedded.git/recipes/ppp/ppp_2.4.5.bb: Jul 04 11:01:17 ppp-2.4.5: remove `DP = "-1"` Jul 04 11:01:17 Oe-core is using 2.4.5 and it works OK there. Jul 04 11:01:18 Signed-off-by: Steffen Sledz Jul 04 11:01:18 Acked-by: Paul Menzel Jul 04 11:19:19 Which is the preferred style: d.getVar('SOMEVAR', True) or bb.data.getVar('SOMEVAR', d, True) ? I've seen both. Jul 04 11:36:54 hi pb btw. Jul 04 11:43:37 celston: if d has been passed in to wherever your code is I think it would be best to use it in preference Jul 04 13:37:14 hi all, is there someone who can help me to solve a compilation problem for tzdata recipes Jul 04 13:37:16 ? Jul 04 13:37:22 package tzdata-2011d-r9.0: task do_compile: Failed Jul 04 13:37:45 the problem is from the location of tz tools, sysroots/i686-linux/usr/bin/zic: No such file or directory Jul 04 13:37:58 does anyone know this error ? Jul 04 13:37:59 thx Jul 04 13:41:42 hi, I've that at runtime: Jul 04 13:41:44 Package kernel-module-rt2x00usb version 2.6.27.2+svnr10746-r35.9 has no valid architecture, ignoring. Jul 04 13:41:48 with a lot of packages Jul 04 13:41:58 at first boot Jul 04 13:42:02 during opkg configure Jul 04 13:43:10 machine: bug distro: angstrom2010 sources: oe.dev Jul 04 13:44:15 http://pastie.org/2162705 Jul 04 13:45:03 and what is the architecture on those packages, in fact? Jul 04 13:45:35 bug I think Jul 04 13:45:37 let me look Jul 04 13:46:34 (bug == MACHINE_ARCH) Jul 04 13:48:21 Architecture: bug Jul 04 13:48:31 that's what the control file says Jul 04 13:49:30 /etc/opkg/arch.conf has: arch bug 41 Jul 04 13:51:56 BitBake Build Tool Core version 1.13.2, bitbake version 1.13.2 ;) Jul 04 13:52:16 also compat udev doesn't work because of that : Jul 04 13:52:18 if [ $KERNELMICROVER -lt 27 ] ; then Jul 04 13:52:24 I've 2.6.27 Jul 04 13:53:22 if I change to -lt 28 it works and I get a shell Jul 04 13:53:25 else it blocks Jul 04 13:54:20 anyone got an ip number for a public dns server? Jul 04 13:54:32 I am having weird issues with this leached connection Jul 04 13:54:43 213.140.2.12 Jul 04 13:54:55 fastweb italy Jul 04 13:54:59 8.8.8.8 Jul 04 13:55:10 else there is opendns and google Jul 04 13:55:34 pb_, is it an issue if it ignores the configure? Jul 04 13:55:40 for the modules Jul 04 13:56:07 probably not a big deal, but it does suggest that something is broken in either opkg or your configuration Jul 04 13:56:13 I think it would be worth debugging what has gone wrong there. Jul 04 13:56:23 ok Jul 04 13:56:26 where should I start? Jul 04 13:56:56 maybe run opkg under strace and make sure it really is reading your arch.conf file, I guess. if yes, run it under the debugger and find out why it doesn't think bug is valid. Jul 04 13:57:15 RP__: ping? Jul 04 13:57:33 otavio: pong Jul 04 13:57:43 ahhh wait a sec Jul 04 13:57:47 RP__: i got your reply to my sdk issue Jul 04 13:57:51 * opkg_files_cmd: Package kernel-module-rt2x00usb not installed. Jul 04 13:57:55 maybe that's the issue Jul 04 13:58:15 otavio: ok Jul 04 13:59:17 * GNUtoo will look in do_rootfs Jul 04 13:59:39 208.67.222.222 (opendns) Jul 04 14:00:08 RP__: I think SDK_NAME outght to allow to be overriden Jul 04 14:00:39 pb_, btw for udev I guess I send a patch for 's/27/28/' Jul 04 14:00:43 RP__: and maybe use something that is not change instead of TARGET_SYS ought to fix it properly Jul 04 14:00:50 otavio: You can set it to whatever you like Jul 04 14:01:53 GNUtoo: I guess. I don't know anything about udev. Jul 04 14:01:53 otavio: Well, yes, I think the default needs fixing Jul 04 14:01:59 ok Jul 04 14:02:12 otavio: I was just trying to point you in the right direction Jul 04 14:06:11 RP__: it took loong time for me to figure it out Jul 04 14:06:30 RP__: any idea of which var we could use? Jul 04 14:06:59 otavio: I think separate names for the tarball and the directory name are needed Jul 04 14:07:19 RP__: well; in fact we could use $MACHINE instead of target sys Jul 04 14:07:45 otavio: i.e. SDK_NAME should only apply to the toolchain tarball name, not the path Jul 04 14:07:50 otavio: That isn't going to help :( Jul 04 14:07:57 otavio: You need something machine indepdent Jul 04 14:07:58 RP__: I don't think so; we can use both as same, but those need to be stable Jul 04 14:08:02 target independent in fact Jul 04 14:08:41 otavio: I don't think you can use the same in both Jul 04 14:09:01 hum Jul 04 14:47:07 I think the opkg issue is very problematic and not to forget abuot Jul 04 14:47:27 opkg list_installed shows.... 9 packages Jul 04 14:47:59 opkg issue? Jul 04 14:56:27 possible Jul 04 14:56:35 how can I look at that problem? Jul 04 14:57:11 I guess you just have to debug it as normal. Jul 04 14:57:39 morning kergoth Jul 04 15:00:11 ok Jul 04 15:00:20 strace opkg configure under init=/bin/ash then Jul 04 15:00:25 because it's a first boot issue Jul 04 15:17:43 RP_: still here? Jul 04 15:17:56 RP__: still here? Jul 04 15:18:04 celston: yes Jul 04 15:18:55 Hello :) Been reading your email and trying to reconcile our respective viewpoints. Jul 04 15:19:32 Is the goal to provide some restricted configuration opportunities, while maintaining an element of control over things. Jul 04 15:20:06 I'm having trouble equating individual package config with what could be described as a distro feature. Jul 04 15:20:18 s/things./things?/ Jul 04 15:21:04 celston: There are competing view points. The distro people who need consistent package feeds, people like Yocto want strong QA tests and then there are the people who want to customise everything Jul 04 15:21:18 *g* Jul 04 15:22:17 celston: I actually see value in all those different positions but leaning an implementation towards any one in particular gives its own set of problems :/ Jul 04 15:22:34 Understood. I think I'm probably in the third camp. But strong QA is obviously a huge bonus for us, I couldn't give a hoot about feeds :D Jul 04 15:23:16 celston: For QA, putting some kind of throttle on the size of the potential test matrix is useful Jul 04 15:23:26 celston so you are providing the fs as it is Jul 04 15:23:31 right? Jul 04 15:23:39 fs = filesystem Jul 04 15:24:38 woglinde: embedded developer, looking to move a family of projects into OE, around a core middleware stack. Current build has ahem, grown organically. Jul 04 15:24:38 it causes Angstrom no end of issues when two different build machines make different packages Jul 04 15:24:47 Footprint is important. Jul 04 15:25:22 celston: In most places it really makes a difference, things are modular Jul 04 15:25:30 celston uhm what middleware stack? Jul 04 15:25:38 celston: so you take a build time hit but runtime footprint is ok Jul 04 15:26:10 woglinde: not sure I can say, I'd have to check the NDA :( Jul 04 15:26:17 ah okay Jul 04 15:26:23 no prob Jul 04 15:26:31 It's proprietary, and probably not of much interest :) Jul 04 15:27:01 so it would either in a nonfree repos Jul 04 15:27:05 or layer Jul 04 15:27:09 celston: about "equating individual package config with what could be described as a distro feature".. Jul 04 15:27:17 dbus? ( >=dev-libs/dbus-glib-0.92 ) Jul 04 15:27:19 and Jul 04 15:27:21 $(use_with dbus) \ Jul 04 15:27:35 We're definitely talking about a/some layer(s) at this point Jul 04 15:29:22 For us, the win with OE would be to get a sane and maintainable base system, manage our internal dependencies and build with bitbake, but given resourcing and the need to do our own QA, we wouldn't be able to pull very regularly. So it's important that we can have layers which are fairly resilient to change in oe-core - i.e.: well defined interfaces for package config. Jul 04 15:29:44 yeah, that would be quite a big win for us as well. Jul 04 15:30:06 at the moment I have a bunch of h4x0red recipes with custom config in, which is clearly not ideal. Jul 04 15:30:36 obviously I could do better than that by using overrides but thus far I have been too lazy to do so. Jul 04 15:30:42 RP__: what about http://paste.debian.net/121863/ ? Jul 04 15:31:22 So if we could have a 'blessed config' - i.e.: the default package config as used by Angstrom et al, but a nice interface to deviate from that in a layer. We wouldn't be looking to submit config changes to the oe-core recipes - we'd just keep our peculiar config private. Jul 04 15:32:02 I think the "different build hosts producing different packages" line of argument is a slightly spurious one. so long as the build hosts are all using the same configuration, you will get the same packages out: it doesn't matter how many switches there are. if your multiple build machines have their own random differences in local.conf then you are already at risk of hosage and adding more switches is not going to make it much worse. Jul 04 15:32:42 pb_: Its more that if you make this recipe specific, you're going to need to map that config to any new recipe added into the system Jul 04 15:33:04 RP__: sorry, make what recipe specific? Jul 04 15:33:13 * celston is a bit new here ;) Jul 04 15:33:22 RP__: I'm not quite sure I understand what you're saying. Jul 04 15:33:25 pb_: so you could have a general policy of enabling X but if some new recipe is added which deviated from that you have no way to know at a distro level that a new recipe is doing something that goes against you general policy Jul 04 15:33:39 oh, right, yes. Jul 04 15:33:55 that's certainly true, and that's an issue today with DISTRO_FEATURES. Jul 04 15:34:09 in fact Gentoo declares the local/IUSE in the recipe Jul 04 15:34:16 I'm not sure that is an argument for or against what celston is proposing though. Jul 04 15:34:59 pb_: PACKAGE_CONFIG on a per recipe basis would make config at the distro level become near impossible Jul 04 15:35:15 er, I think it was PACKAGE_FEATURES. anyhow... Jul 04 15:35:54 I think that if one cares to build its distro he will probably *never* pull from foreign feeds so the risk of installing 'incompatible' packages is low Jul 04 15:40:26 RP__: well, no, you could still use DISTRO_FEATURES for things which were meaningful to set on a distro-wide basis. I think the idea of PACKAGE_FEATURES was that it would be a way to flip the switches which are, in themselves, specific to a particular package. Jul 04 15:40:29 Grepping shows that DISTRO_FEATURES seems to deal in high-level concepts (i.e.: policy). I don't think 'enable this gstreamer plugin' is really a policy matter. As long as the default package config (i.e.: the set of PACKAGE_FEATURES defined in the actual recipe) meets 'policy', then allowing layers to deviate from that doesn't seem like a problem. This is no doubt because I misunderstand :) Jul 04 15:40:47 for example, to take a recently discussed thing, the set of plugins enabled in the various gstreamer recipes is somewhat arbitrary at the moment. Jul 04 15:41:15 I happen to need the mpegdemux plugin enabled, which is currently turned off. I'm not sure I can think of a sensible way to make that into a DISTRO_FEATURE. Jul 04 15:41:34 the way Gentoo maps Distro-USE flags with the real configure options involves a database Jul 04 15:41:43 without polluting the DISTRO_FEATURE namespace with gst-plugin-XXX Jul 04 15:42:18 Also, if you do "find . -name "*.bb" | xargs grep -- --with", you get a fairly random-looking sprinkling of configure flags. I suspect that a fair number of those are things which one could legitimately wish to customize but which don't necessarily map to a wider distro policy objective. Jul 04 15:42:23 ant_work: the solution I posted encodes that info in the recipe. Jul 04 15:43:02 and for the other having in theory the same dependency? Jul 04 15:43:17 Obviously yes, for things which do have a useful distro-wide meaning (e.g. "use X11"), it would make sense to go on using DISTRO_FEATURES. Jul 04 15:43:44 pb_: I think the policy has always been to enable most things and that build time isn't a major issue Jul 04 15:43:55 pb_: This looks like we're reversing that general principle Jul 04 15:44:15 That "ld-is-gold" thing is an interesting edge case, actually. Although it is (now) a DISTRO_FEATURE it only actually affects one recipe and arguably would be better done as a package feature. Jul 04 15:44:21 pb_: The way of knowning when to use PACKAGE_FEATURES and when to use DISTRO_FEATURES also isn't that clearcut to me Jul 04 15:44:44 RP__: I'm not sure I've ever really seen that policy articulated. It certainly doesn't appear to be represented in the current metadata for things like gstreamer. Jul 04 15:44:45 pb_: you might not want X11 for package foo Jul 04 15:44:52 pb_: what do we do then? Jul 04 15:45:17 pb_: policy is perhaps a strong word, convention maybe Jul 04 15:45:26 'enable most things' doesn't seem a sane policy for an embedded platform :) Jul 04 15:45:39 distribution, yes, specific platform, no. Jul 04 15:45:45 well, either override DISTRO_FEATURES_pn-foo, or make it a PACKAGE_FEATURE as well. I'm not sure it matters that much. Jul 04 15:45:58 celston: I think RP was talking about _building_ everything but not necessarily _shipping_ everything. Jul 04 15:46:09 obviously that does only work for pluginized packages though, and not everything is like that. Jul 04 15:46:15 pb_: ack, but sometimes you can't split things out afterwards. Jul 04 15:46:24 for example, my least favourite recipe rpm. Jul 04 15:47:06 it has a smorgasbord of --enable-foo and --with-bar options, most of which drag in shared library dependencies which you are then committed to ship. so you can't build a maximally featured rpm and slim it down later, you really do need to know what you want at build time. Jul 04 15:47:17 I think the opkg issue is related to udev not starting Jul 04 15:48:00 I'll wait a bit and see Jul 04 15:48:11 ahhh I need sysaccept Jul 04 15:48:24 celston: remember Gentoo's useflags can be *negative* Jul 04 15:48:26 USE="${USE} -ldap -sqlite -cups -mailwrapper" Jul 04 15:48:32 What I don't want to do is turn up and drop in a feature which has unintended consequences, and be cursed for evermore :) Jul 04 15:48:48 heh Jul 04 15:49:36 ant_work: I didn't know that - it's neat. Filtering out of the list in the layer achieves a similar thing, but I think I prefer the '-' notation. Jul 04 15:49:53 I guess curl is another good example of a package which has a plethora of options which are crystallized at build time. Jul 04 15:50:33 RP__: saw the paste? This seems like a good default for me Jul 04 15:50:54 i did bitbake helloworld and its NOTE: Running task 318 of 560 (ID: 83, virtual:native: Jul 04 15:50:58 that normal? Jul 04 15:51:01 otavio: I suspect that its backwards, the SDK_NAME is correct and that SDKPATH needs a new default Jul 04 15:51:22 nobody_-: sounds about right Jul 04 15:52:20 cool Jul 04 15:53:11 03Mario Schuknecht  07org.openembedded.dev * r51cee0c445 10openembedded.git/recipes/udev/udev/network.sh: (log message trimmed) Jul 04 15:53:11 udev: avoid udev stopping persistent pppd connections Jul 04 15:53:11 When a pppd session is disconnected it triggers the udev to ifdown the Jul 04 15:53:11 ppp link which kills pppd and inhibits a reconnection. Jul 04 15:53:11 Now avoid udev stopping ppp connections. Jul 04 15:53:11 See also: Jul 04 15:53:12 https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/396804 Jul 04 15:53:12 RP__: The problem of not using SDK_NAME for the path is that we will have it more difficult to change. My point in reusing it is that it will be neutral against the targetsys but this will be used to separate the tarballs Jul 04 15:54:08 RP__: the sdkname can be stable if targetsys changes as this is what it really is; same sdk Jul 04 15:55:12 celston: I suspect you would love "packages.use": the possibility of expressing different config options for many recipes in a file instead of touching them. This adds one more level of customization Jul 04 15:55:33 oh nice Jul 04 15:55:41 like gentoo ;) Jul 04 15:55:55 * ant_work is not a Gentoo developer ;) Jul 04 15:56:06 ant_work: :) Jul 04 15:56:23 i mean gentoos /etc/use.conf or whatever havent used gentoo in ages Jul 04 15:56:31 otavio: It depend what you think that variable is supposed to mean, that is the problem Jul 04 15:56:37 I suggest it goes to the mailing list Jul 04 16:09:55 So is the status that the technical side of my proposal is OK, but it raises policy issues which we don't know what to do with? Is there an Angstrom developer I could talk to so we could find a technical solution which satisfies both camps, and come up with policy as a result? Jul 04 16:10:40 I see that XorA has posted on the list "with his Angstrom hat on" and seems happy with your plan. Jul 04 16:11:31 Ah, cool :) Jul 04 16:12:57 looks like a nice simple syntax to me Jul 04 16:13:19 and really there is no real test until we start implementing it Jul 04 16:14:12 yeah, the syntax looks fairly decent to me as well. I hate the comma separated list but I can't think of any obviously better solution that doesn't involve significant bitbake surgery. Jul 04 16:15:55 but, of course, RP is the man that you need to convince since he is the one who decides whether it goes in or not. Jul 04 16:17:54 pb_: There is something bothering me about this but I can't put a finger on it :/ Jul 04 16:17:58 Well, like I said: I don't want to be responsible for something which turns out to be trouble later, so I appreciate you all weighing in on this one. Jul 04 16:20:09 RP_: listen to your spidey-sense. When you work out what it is that bothers you then hopefully it's something we can address technically, policy solutions are a PITA to remember to enforce :) Jul 04 16:20:37 It probably needs to brew on the mailing list for a few days and then go in if there are no serious objections Jul 04 16:23:20 btw, looking at the actual patch, what's the "if len(oeconf) > 1" bit about? Jul 04 16:23:40 * RP__ noticed that, should be if oeconf: ? Jul 04 16:24:03 It's so the concatenate can use ' '.join(list) Jul 04 16:24:03 oh, I see, it always prepends an empty string if EXTRA_OECONF was previously empty Jul 04 16:24:27 Apparently joining a list is more efficient that += " " + thing. Jul 04 16:24:33 celston: well, you can join a list of 1 element Jul 04 16:24:37 that isn't a problem as such Jul 04 16:24:38 It also gets the spacing right. Jul 04 16:25:01 Ah right, you mean save the test and join it regardless of whether we added anything? Jul 04 16:25:40 * RP__ would only set it if its not empty Jul 04 16:25:41 Yeah, that's what I was thinking. Jul 04 16:27:40 ? Jul 04 16:27:56 he means, if EXTRA_OECONF was not set at all before, leave it that way rather than setting it to the empty string Jul 04 16:28:02 which probably is indeed a good plan Jul 04 16:28:17 which "if oeconf" will do Jul 04 16:28:30 and so will the existing logic, actually Jul 04 16:28:33 yep Jul 04 16:28:36 so I guess it can just stay as it is Jul 04 16:28:37 ERROR: Function 'Fetcher failure for URL: 'svn://www.eglibc.org/svn/branches/;module=eglibc-2_13;proto=http'. Unable to fetch URL svn://www.eglibc.org/svn/branches/;module=eglibc-2_13;proto=http from any source.' failed Jul 04 16:28:38 that was the plan. Jul 04 16:28:57 ? Is that even a valid svn url? Jul 04 16:29:04 pb_: if it happened to have one item added to an empty string it wouldn't would it? Jul 04 16:29:19 RP__: well, if you added one item then it isn't empty any more, right? Jul 04 16:29:30 so you do want to set it in that case Jul 04 16:29:31 pb_: but the current code won't set it Jul 04 16:29:44 yes, it will. the array will be ['', 'new item'] Jul 04 16:29:47 The idea is that it would create DEPENDS or EXTRA_OECONF if the package feature required it. Jul 04 16:29:49 and len(array) will be 2 Jul 04 16:29:59 so, as far as I can see, it will do the right thing Jul 04 16:30:21 oh, I see Jul 04 16:30:34 it's a bit funky, and not very intuitive, but I think it is logically correct Jul 04 16:30:39 Right, my only concern is none of the rest of the code works like that Jul 04 16:30:58 * RP__ was going from memory which is usually a bad idea Jul 04 16:31:21 I'm happy to make it more 'oe like', but I'll need references to look at. Jul 04 16:31:51 depends = (d.getVar('DEPENDS', True) or '').split() Jul 04 16:32:59 which is ugly in its own right but we're consistently ugly I guess Jul 04 16:33:39 gives you either an empty list, or a list with the value of DEPENDS. Meaning that len is either 0 or 1, so we can't test the len to decide if we should write the variables back. Jul 04 16:34:03 celston: You'd just if depends: Jul 04 16:34:17 RP__: I guess you can use the eleet oe.data.typed_value() to make it a bit less ugly Jul 04 16:34:24 I suppose the downside is you have expanded DEPENDS Jul 04 16:35:03 well, no need to actually expand it there, you could just pass False and I think everything would work out fine. Jul 04 16:35:29 pb_: true, and that also applies in the origin patch too Jul 04 16:35:51 * RP__ thinks we should add an appendVar method to bitbake Jul 04 16:36:07 I keep meaning to do it Jul 04 16:36:18 Yes, I thought that :D Jul 04 16:36:28 yeah. it's a shame that "oe.data.typed_value('PACKAGES').append() doesn't do what you might hope it would. Jul 04 16:36:32 appendVar and appendVarFlags Jul 04 16:37:13 might allow bitbake to do some micro optimisations internally too Jul 04 17:04:09 Time for me to go. Thanks guys. Jul 04 17:16:38 hi all Jul 04 17:17:59 i've some problems trying to build helloworld-image under amd64 linux host. I have errors in desktop-file-utils-native, mtd-utils-native e2fsprogs-native ... anyone faced this ? google didn't helped me :( Jul 04 17:19:00 alx_: could you pastebin the errors please? Jul 04 17:19:49 bluelightning, sure Jul 04 17:21:21 bluelightning, http://pastebin.com/jycHnnq6 Jul 04 17:21:28 here it is the full output :( Jul 04 17:24:58 something has gone very wrong there... I'm not sure what it is, but key things it's expecting to be there aren't Jul 04 17:25:22 bluelightning, mtd can't find lzo Jul 04 17:25:34 was this a from scratch build? it looks like you are continuing from some previous build Jul 04 17:25:47 bluelightning, yes, continuing from previous build Jul 04 17:25:59 not that that's necessarily wrong, it just might have something to do with it Jul 04 17:26:09 I got more error on first build Jul 04 17:26:35 so I put a -k and restarted again and again (lots of race on dependencies) Jul 04 17:26:46 until I came with this error Jul 04 17:26:50 hmm, well to diagnose the problem it would be easiest to have the first error Jul 04 17:27:09 bluelightning, you suggest a clean build ? Jul 04 17:27:18 I would in this case yes Jul 04 17:27:27 then if you get errors please let us know what the first one is Jul 04 17:27:39 bluelightning, should I use -k or not ? Jul 04 17:27:40 and don't continue on (I would suggest not using -k for now) Jul 04 17:27:50 you read my mind ... o.O Jul 04 17:27:52 :d Jul 04 17:27:53 :D Jul 04 17:30:48 bluelightning, restarted now :) Jul 04 17:44:59 bluelightning, http://pastebin.com/040Zc54C here it is (cleaned all tmpdir and all source download dir) - it is as openembedded was just configured for its first build - Jul 04 17:52:44 alx_: I think you maybe best to post this one to the list Jul 04 17:53:44 hmm, did you delete your sstate-cache as well as tmpdir? Jul 04 17:54:18 I deleted the whole tmpdir, so bitbake has no cache Jul 04 17:54:37 alx_: sstate cache != bitbake parse cache Jul 04 17:54:56 kergoth, :$ /me noob Jul 04 17:55:16 where to ? Jul 04 17:55:24 hmm; I'm wondering how it got to a state where you'd need to do that though Jul 04 17:56:55 btw : find $OE_HOME -name *sstate* says no file Jul 04 18:00:00 ok, so it's one for the list Jul 04 18:00:45 bluelightning, which info I should put ? local.conf, logs and output ? is it enough ? Jul 04 18:02:41 hi, I've some questions about udev compat Jul 04 18:03:14 for instance: how compatibility works, is it always comatibility against 141? Jul 04 18:04:45 alx_: versions of OE/bitbake used (should be at the top of the log actually); changes you made to the example local.conf, anything else you did Jul 04 18:04:58 ok Jul 04 18:05:04 host distro & version would be useful also Jul 04 18:05:18 may I use attachments or should I put all in-line ? Jul 04 18:08:06 everytime I ask about udev-compat I've no answers Jul 04 18:08:25 it's been weeks since I'm trying to make udev compat works Jul 04 18:08:29 everytime I try Jul 04 18:08:30 I fails Jul 04 18:08:44 I've still unanswered questions about it Jul 04 18:09:09 (I didn't try during many weeks longs, but some days in the weeks) Jul 04 18:09:36 my understanding of udev-compat is limited but it seems to me it can only solve part of the problem Jul 04 18:09:43 ah? Jul 04 18:09:53 it won't help for things like the extra syscall that current versions of udev need, for example Jul 04 18:10:05 yes like sys-accept4 Jul 04 18:10:22 basically I've too many variables Jul 04 18:10:24 and I'm lost Jul 04 18:10:29 there is udev version Jul 04 18:10:34 udev compat provider Jul 04 18:10:55 what is udev compat provider Jul 04 18:11:12 can I say to udev 171 to be compatible with 165 for instance? Jul 04 18:11:35 or to 168 to be compatible with 165 Jul 04 18:11:40 that would be the best Jul 04 18:11:46 I'm not sure I'm afraid Jul 04 18:12:02 ok thanks Jul 04 18:12:08 *thanks anyway Jul 04 18:12:16 I think your best bet would be to look at what other people using a similar kernel version are using and go with that Jul 04 18:12:31 there are not a lot of people using 2.6.27 Jul 04 18:13:09 do you need newer udev? or could you not just use an old version of the same age as 2.6.27? Jul 04 18:13:09 there is only palmpre that is using 2.6.24 Jul 04 18:13:34 and zarus also used udev compat 141 I think but that got removed Jul 04 18:13:55 yes but I've no idea how Jul 04 18:14:00 and it's not a good solution Jul 04 18:14:08 since I want to push it in oe.dev Jul 04 18:14:11 well there aren't too many choices Jul 04 18:14:34 if old udev versions are there then they ought to be usable Jul 04 18:14:36 I could try to bruteforce the variables but that would takes ages Jul 04 18:14:59 a lot of thing is there but unused or broken Jul 04 18:15:34 hmm... well I'm going to face this sooner or later because old ipaqs need to stay with 2.6.21-hh until someone does the work to bring them up to more modern kernels Jul 04 18:15:45 and to my mind it means pinning and older udev Jul 04 18:15:56 don't forget you need old linux-libc-headers as well Jul 04 18:15:56 you will face different problems: Jul 04 18:15:58 *udev Jul 04 18:15:59 *tslib Jul 04 18:16:06 *libc headers Jul 04 18:16:24 yep Jul 04 18:16:35 it's that, or the machine can't be supported at all... Jul 04 18:16:43 btw did you solve your issue with devices abstractions for stuff like wifi? Jul 04 18:17:02 it was bluetooth I was working on Jul 04 18:17:04 freesmartphone with fsodeviced+fsousaged would be a good candidate Jul 04 18:17:25 for wifi, I'm currently writing a frontend to connman Jul 04 18:17:30 ok Jul 04 18:19:45 maybe I've an idea Jul 04 18:19:54 I try different udev versions Jul 04 18:20:03 and look the last one that works Jul 04 18:20:08 and then try to compat it Jul 04 18:24:57 bluelightning, email sent! Jul 04 18:28:17 Is it a requirement that an OE build should not need root access? Jul 04 18:28:41 *never* run a oe build as root Jul 04 18:28:42 ever. Jul 04 18:29:45 joelangel? do you irc as root? Jul 04 18:35:37 woglinde: no I don't :) Jul 04 18:35:53 Just getting a few things clear. Hope these questions don't sound silly. ;) Jul 04 19:01:29 I for the life of me can't seem to find a decent opkg repo. Would it be terrible to use ftp.debian.org? Jul 04 19:02:36 ? Jul 04 19:02:47 either use angstroem or shr Jul 04 19:03:09 that are the most used distribution builded from oe Jul 04 19:04:06 woglinde, are you talking to me? Jul 04 19:04:42 * IanWizard remembers the early days of SHR, back when you could stil buy a freerunner. Jul 04 19:04:57 yes Jul 04 19:05:10 no one else is talking Jul 04 19:05:14 at the moment Jul 04 19:05:40 woglinde, I didn't know if something was said before I came in, and that was just a delayed responce :P Jul 04 19:05:56 woglinde, ok, I'll look into it, thank you. Jul 04 19:11:13 jo obi Jul 04 20:00:39 Where do temporary files that a recipe needs go? Jul 04 20:01:37 well, not temporary but files other than a .bb, where in the source code tree do we keep them? Jul 04 20:02:00 ? Jul 04 20:02:07 what temp file? Jul 04 20:02:14 as uses /tmp Jul 04 20:02:23 gcc proably too Jul 04 20:02:37 woglinde: I want the file to be available when the source code is checked out Jul 04 20:02:48 ? Jul 04 20:02:54 dont understand it Jul 04 20:02:59 ok, let me explain Jul 04 20:03:03 yes please Jul 04 20:03:20 hi xxiao Jul 04 20:03:28 hi woglinde Jul 04 20:03:32 still buffered by rob? Jul 04 20:03:52 he is a bit quite the last few days, i guess he needs more sleep time at night Jul 04 20:03:58 lol Jul 04 20:04:06 So if my recipe or class needs a file like .img or some other file for its operation, where would they go? Jul 04 20:04:27 snarky? Jul 04 20:04:32 woglinde: is there a GUI (web-based) sort of like openwrt's luci or xwrt in OE? Jul 04 20:04:39 I dont know any class which has SRC_URI Jul 04 20:04:58 xxiao not that I know off Jul 04 20:05:12 but we have apache and lighty Jul 04 20:05:17 and even python Jul 04 20:05:24 and php Jul 04 20:05:28 and a bit ruby Jul 04 20:05:29 I think Jul 04 20:05:38 woglinde: i have a out-of-date freescale ltib, which is a hybrid with openwrti mainly for its luci Jul 04 20:06:03 woglinde: i want to move it to OE, but need an interface for users to configure things Jul 04 20:06:29 hm sorry I dont think we such highlevel in Jul 04 20:07:19 apache.lighty.php.python.ruby are all too heavy, i have 4MB left, working on porting a 120M lighty+postgre+php to 3M haserl+lua+busybox.httpd Jul 04 20:07:31 lol Jul 04 20:07:32 i think 3M will do it Jul 04 20:07:34 give up Jul 04 20:08:23 no way, it's money :) Jul 04 20:09:52 there are tasks you cannt complete Jul 04 20:10:22 actually i tried lua+haserl+busybox+sqlite, it's about 3MB Jul 04 20:10:26 even if drove billions into it Jul 04 20:10:52 it's just not flowing well at this point, need port the sql logic etc Jul 04 20:11:08 yesterday i spent hours to just get haserl to like my lua script Jul 04 20:11:12 sqlite? Jul 04 20:11:17 it worked well on x86, but not on ppc Jul 04 20:11:20 what is haserl? Jul 04 20:11:22 sqlite3 Jul 04 20:11:33 haserl is a cgi wrapper , <100KB Jul 04 20:12:04 hm you could use fefe's stuff Jul 04 20:12:06 gatling Jul 04 20:12:30 http://www.fefe.de/gatling/ Jul 04 20:15:33 new to me, had a really quick chec, Jul 04 20:15:36 check Jul 04 20:15:44 is there a recipe? Jul 04 20:15:48 no Jul 04 20:15:54 I only made one for dietlibc Jul 04 20:16:06 you could try if lua builds with it Jul 04 20:16:10 gatling does Jul 04 20:16:16 hmm...need look into a little deeper Jul 04 20:16:18 so you might save some more space Jul 04 20:16:29 * woglinde should make consulting Jul 04 20:16:35 :) Jul 04 20:16:39 thanks. will have a look Jul 04 20:17:10 you own me a beer Jul 04 20:17:17 but not a american ones Jul 04 20:17:51 normaly dietlibc is compiled static in Jul 04 20:17:57 but that saves space anyway Jul 04 20:20:54 checked again, it needs the owfat lib, which is dated 2008, and the gatling is 'experimental' Jul 04 20:21:25 and? Jul 04 20:21:26 i'll buy you beer when there is a chance :) Jul 04 20:21:30 try it Jul 04 20:21:59 will try Jul 04 20:23:39 I dont think liblowfat needs something new Jul 04 20:25:51 i'll definitely try, considering sometimes i need hack on contiki, storage is qutie limited for certain devices Jul 04 20:26:58 i realized my 64bit env gave me quite some troubles on certain "old" packages, sigh Jul 04 20:32:15 hi ant Jul 04 20:32:35 ehlo woglinde Jul 04 20:34:05 :) Jul 04 20:34:40 i just realized my buildhost only is 1.6Ghz 256mb Jul 04 20:34:51 uhm Jul 04 20:34:53 nowonder it takes days Jul 04 20:35:11 yes Jul 04 20:35:16 told you all i need a new buildhost Jul 04 20:35:57 nobody_-: r u using that to build oe? that should be, ...., 2 weeks? Jul 04 20:36:13 heh Jul 04 20:37:42 * xxiao hopes those yocto.intel guys can fix the build time issue, oe did it worse than gentoo in that regard Jul 04 20:38:10 ? Jul 04 20:38:20 xxiao what you are talking about? Jul 04 20:38:25 too long to build for oe Jul 04 20:38:31 oe-core hase more qa tests than gentoo Jul 04 20:38:38 * mwester-laptop notes that *INTEL* has no interest in improving the build times by tuning software... Jul 04 20:39:02 woglinde: yeah i hope the meta-layer and oe-core will make it better as far as buildtime goes Jul 04 20:40:52 woglinde: i feel a web-based UI is quite useful for OE, just run some cgi scripts via browser will be way more useful comparing to ssh in Jul 04 20:41:12 xxiao sure Jul 04 20:41:14 Say what? Jul 04 20:41:17 OE used to be for handheld which normally has a lcd Jul 04 20:41:29 are you talking about distros that oe builds, or oe? they're very different things Jul 04 20:41:30 ? Jul 04 20:41:37 but now it's adopted for general usage in various fields Jul 04 20:41:45 also, if you're an embedded linux developer who can't be bothered to use ssh, you're in the wrong field Jul 04 20:41:46 xxiao oe is for wide range of devices Jul 04 20:41:55 some has display some not Jul 04 20:42:22 kergoth: i consider myself a kernel hacker who do have some code in kernel.org, and use ssh all the time Jul 04 20:42:36 i'm talking from a product perspective Jul 04 20:42:48 * mwester-laptop has a lolt of OE-supported devices, none of which has a display -- and only some of which are large enough to effectively run webmin or similar tools. Jul 04 20:43:07 mwester-laptop: so...you use CLI to manage them? Jul 04 20:43:11 which is why most companies use oe as a starting point to build their own product / distro. its never used unmodified for something commercial Jul 04 20:43:11 mwester is webmin packaded in oe? Jul 04 20:43:54 kergoth hm buglabs dont modifys this much Jul 04 20:43:58 ups Jul 04 20:44:11 woglinde, good question -- I know we tried it on the NLSU2, but I don't recall if we committed the recipe. Jul 04 20:44:36 xxiao: everything is done via SSH and the shell. Jul 04 20:45:04 mwester-laptop: i assume you're not selling them... Jul 04 20:45:41 I finally mostly understood udev compat Jul 04 20:45:44 Nope. But based on demand, when Linksys stopped selling them, there's still quite a market for such a device. Jul 04 20:45:53 usually you have to compat against udev-141 Jul 04 20:46:16 and so you choose an udev like udev 171 and add compat capability for your device Jul 04 20:46:25 and put that in the machine config: Jul 04 20:46:27 mwester-laptop: sounds like a device could be done by openwrt to me... Jul 04 20:46:50 PREFERRED_PROVIDER_udev-compat = "udev-compat141" Jul 04 20:46:53 xxiao, I think you might misunderstand the use case -- there are many uses for embedded devices to handle monitoring and control where the device itself is physically in a location where a display is of no use. Jul 04 20:47:06 but am I obligated to use udev171? Jul 04 20:47:18 or can I use 168 under angstrom Jul 04 20:47:22 mwester-laptop: that's my case too, that they're asking for web-based UI now Jul 04 20:47:26 so I have the bug-rues Jul 04 20:47:28 *rules Jul 04 20:47:37 and am not obligated to make a new package Jul 04 20:47:40 xxiao webmin is to large hm Jul 04 20:47:45 xxiao, one could use openwrt if one wanted -- by using OE we can build a system that is closer to the "textbook" linux than is openwrt. To each his/her own. Jul 04 20:47:48 woglinde: definitely Jul 04 20:48:26 mwester-laptop: that's my original question, i want to move a deeply embedded device from ltib/openwrt to OE, and need some UI via web Jul 04 20:48:47 hiya mwester-laptop did slugos6 come out of alpha? Jul 04 20:49:09 xxiao, I'd recommend taking a look at webmin, if your device has 64MB or RAM or more. Jul 04 20:49:12 mwester-laptop: currently i am trying to use lua+haserl+httpd+sqlite to do that Jul 04 20:49:41 ka6sox-away: No, but it should. I'm on a project, and haven't been home for more than a couple days at a time for over a month now... Jul 04 20:49:42 mwester-laptop: i only have 32MB, and only 4MB left Jul 04 20:50:12 mwester-laptop, okay, I'm deploying what you have now on 4 boxes....so I'm calling it Beta. Jul 04 20:50:18 xxiao, that's like the NSLU2 then. Webmin is too large. You'll have to do something custom; I've never found anything generic that would fit. Jul 04 20:50:25 ka6sox! Jul 04 20:50:28 fix the wiki Jul 04 20:50:31 ka6sox-away: cool! Jul 04 20:50:41 woglinde, whats broken on the wiki? Jul 04 20:50:45 mwester-laptop: right...trying that custom thing here Jul 04 20:52:15 woglinde, ? Jul 04 20:52:40 pb reported he cannt edit sites Jul 04 20:52:52 ah pb back Jul 04 20:52:53 hehe Jul 04 20:52:55 just in time Jul 04 20:53:12 mwester-laptop: does slugos nslu2 etc have any kinds of UI via web? Jul 04 20:53:30 xxiao, why not package openwrt stuff in openembedded? Jul 04 20:53:31 pb_, wazzup? Jul 04 20:54:03 gnutoo copyright maybee? Jul 04 20:54:04 GNUtoo: that's one method i actually thought, luci is too tightly coupled with openwt, x-wrt/webif could be done Jul 04 20:54:21 woglinde, luci stuff isn't free? Jul 04 20:54:33 dont know Jul 04 20:54:41 I dont know much about it Jul 04 20:54:46 xxiao, hmmm Jul 04 20:54:50 GNUtoo: as far as i know, luci is gpl2 Jul 04 20:54:50 woglinde, try now? Jul 04 20:54:56 indeed Jul 04 20:55:06 * GNUtoo tought it was free and it is indeed Jul 04 20:55:13 ka6sox dont which sites dont work Jul 04 20:55:24 xxiao, what's your device? Jul 04 20:55:30 the last time I looked at luci it seemed unmaintained. Jul 04 20:56:01 a powerpc 8308 Jul 04 20:56:26 ah ok, it's not a wrt54gs then Jul 04 20:57:18 * xxiao also has wrt54gs, atheros boxes, beagles, panda, imx515, imx535 board ... Jul 04 20:57:45 but no wrt54gs Jul 04 20:58:14 it's wrt54g Jul 04 20:58:28 ah usually they are mips Jul 04 20:58:38 ok Jul 04 20:58:44 me too I've a lot of devices Jul 04 20:58:55 devices from buglabs and phone mainly Jul 04 20:59:01 and a wrt54gsv4 Jul 04 21:00:03 * ant__ is looking at the ccache bloat reintroducted in oe-core :/ Jul 04 21:00:24 maybe just CCACHE = ""? Jul 04 21:02:17 I'm pretty sure ccache slows down a typical oe build from scratch Jul 04 21:04:04 * mwester-laptop *still* doesn't trust CCACHE. Jul 04 21:05:24 none of my devs use it. Jul 04 21:06:10 At least with oe-core, it gets built -- so perhaps it will work better than the host-provided ones on Fedora, which seem to misbehave in very strange ways sometimes. Jul 04 21:12:15 i never trusted ccache, distcc, or anything in that nature, it does not worth the debug time Jul 04 21:12:40 woglinde, please test wiki editing...it should work. Jul 04 21:13:01 ka6sox will tell pb tomorrow Jul 04 21:13:02 on www.openembeded.org Jul 04 21:13:05 okay Jul 04 21:13:35 okay need to switch computer Jul 04 21:14:22 woglinde: the doc is still pre-oecore Jul 04 21:27:20 ok i have an idea i'll mount the directory with nfsand build on my laptop Jul 04 21:28:00 wich is slightly better 1.73 1Gb ram Jul 04 21:28:14 and pray it doesnt overheat Jul 04 21:28:19 hm Jul 04 21:28:28 there were some problems with nfs Jul 04 21:28:43 tried already? Jul 04 21:29:09 there are some warnings Jul 04 21:32:00 dude this isnt fair Jul 04 21:35:34 I think nfs should be ok, I used to build on remote filesystems all the time. Jul 04 21:36:26 hi ka6sox-away Jul 04 21:36:37 * pb_ returns from dinner Jul 04 21:36:49 late dinner Jul 04 21:39:07 yeah, we usually eat quite late during the week Jul 04 23:41:53 hm, is there something really straightforward I can do to angstrom to tell it that I'm really not interested in building ANY native documentation? the wiki and online resources are plenty, I don't need docbook and this other crap. Jul 04 23:48:49 also, is there a way to "visualize" bitbake recipe dependencies? something that can give me a dependency tree that is searchable, or even better a way to say "what depends on package 'x' (and what depends on the packages that depend on 'x' and so on and so forth" ? Jul 05 00:03:31 im getting some sanity check problem cause it thinks i changed tmpdir Jul 05 00:03:58 yeah in my (newbie) experience you don't do that. Jul 05 00:04:52 should i just delete tmp? Jul 05 00:04:59 saving my downloads? Jul 05 00:05:13 i could care less if it has to rebuild everything Jul 05 00:05:23 didnt get far to begin with **** ENDING LOGGING AT Tue Jul 05 02:59:57 2011