**** BEGIN LOGGING AT Fri Aug 26 02:59:57 2011 Aug 26 08:23:35 What does "cannot check archive integrity" normally mean? I have fetched libpng, and the checksums seem ok, but I get that error. Aug 26 09:01:54 I tried changing libpng to use http instead of ftp, since my ftp port is firewalled. Aug 26 09:28:02 morning all Aug 26 09:29:19 good morning Aug 26 09:30:53 hi florian, bluelightning, all Aug 26 10:02:28 Hello all Aug 26 10:07:55 I have but my work in github repository at https://github.com/Noor-Ahsan/benchmark-recipes/tree/master/meta-oe/meta-oe/recipes-benchmark and not I wanna create pull request for it Aug 26 10:08:26 should I use create-pull-request -u origin -b master in the local repo Aug 26 10:08:27 ? Aug 26 10:08:43 BTW this command is saying this No branch of git://github.com/Noor-Ahsan/benchmark-recipes is at: Aug 26 10:13:53 er, recipes-benchmark or benchmark-recipes? Aug 26 10:14:43 Noor: really, what I would recomment is have your origin as meta-oe, and then use "git remote add" to add a "contrib" remote that points to your github branch Aug 26 10:14:53 it won't matter for now but that works best Aug 26 10:15:35 s/github branch/github repo/ Aug 26 10:15:59 bluelightning: yeah my plan is like this but right now I want to send the stuff and will set my setup in a correct way afterwards Aug 26 10:16:07 Noor: sure Aug 26 10:16:26 but right now I have pushed my stuff to github Aug 26 10:16:43 but finding it difficult to create pull request Aug 26 10:16:46 so I think you just have a mistake in your command, your repo says recipes-benchmark and the error is talking about benchmark-recipes Aug 26 10:17:36 er, hang on, no that's not it Aug 26 10:17:55 bluelightning: remo name is benchmark-recipes ... yeah Aug 26 10:18:02 repo Aug 26 10:18:51 maybe the pull request script doesn't understand github repos Aug 26 10:19:17 how did you create that repo, did you clone it from meta-oe? Aug 26 10:19:33 pb_: no Aug 26 10:19:42 it looks as though it has absolutely nothing else in it apart from your new files, and I'm not sure that the create-pull-request script can cope with that Aug 26 10:19:52 this is my own repo created by using github Aug 26 10:20:07 OK Aug 26 10:20:38 ah yes, it needs to be repo cloned from the original, with your changes on top Aug 26 10:20:40 I thought that this script can handle any repsitory Aug 26 10:20:55 aaaaahhhhhh Aug 26 10:20:58 OK Aug 26 10:21:05 well, I'm not all that au fait with the yocto tooling and how exactly their create-pull-request script works, maybe t does support what you are trying to do. but, conventionally, what you'd do is use the github "fork this repo" button to make a clone of upstream, then make a new branch, commit your changes into it and then send a pull request from that branch. Aug 26 10:21:10 any repo, but with the right contents :) Aug 26 10:21:18 pb_: it doesn't :) Aug 26 10:21:39 ah, heh Aug 26 10:21:57 it does however support github in its function to check if the remote repo exists Aug 26 10:22:06 so that should be OK as long as the repo contents get fixed Aug 26 10:22:12 OK .... I though I just need to put my changes in repo and it will do the trick Aug 26 10:22:41 Noor: yes but what you have is not changes, they are brand new files as far as git is concerned Aug 26 10:22:52 or, as far as that repo is concerned Aug 26 10:23:18 yeah I need to add brand new file in meta-oe as well Aug 26 10:23:28 dont need to change any existing file Aug 26 10:23:34 sure, but you need the history Aug 26 10:24:55 bluelightning: I am bringing in these recipes from oe.dev Aug 26 10:25:15 initiall i created initiall recipes Aug 26 10:25:23 which did not have history Aug 26 10:25:41 yes, I know, but for the pull request script to work, the repo needs to have the history of *meta-oe* in it plus your additions/changes on top of it Aug 26 10:26:23 just clone meta-oe, add your files & commit, then force push that to your new repo Aug 26 10:27:17 it'll be easier actually if you set up your repo as a separate remote on with meta-oe as the origin now Aug 26 10:27:19 yeah doing that now :) Aug 26 10:27:41 got it forked in my github Aug 26 10:27:44 thanks Aug 26 10:28:47 no worries Aug 26 13:32:12 ok now my meta-oe repo is at https://github.com/Noor-Ahsan/meta-oe Aug 26 13:33:45 and and this command create-pull-request -u origin -b master is saying that patch is created but I cant see it in the mentioned dir Aug 26 13:34:01 sed: can't read pull-27323/0000-cover-letter.patch: No such file or directory sed: can't read pull-27323/0000-cover-letter.patch: No such file or directory ls: cannot access pull-27323/*: No such file or directory The following patches have been prepared: Aug 26 13:34:12 Review their content, especially the summary mail: pull-27323/0000-cover-letter.patch Aug 26 13:34:39 it also give me some warning or stuff in the start Aug 26 13:34:53 sed: can't read pull-27323/0000-cover-letter.patch: No such file or directory Aug 26 13:35:08 what I am missing in my command Aug 26 13:37:14 Noor: origin points to your repo https://github.com/Noor-Ahsan/meta-oe/ ? Aug 26 13:37:50 remote origin Fetch URL: git@github.com:Noor-Ahsan/meta-oe.git Push URL: git@github.com:Noor-Ahsan/meta-oe.git Aug 26 13:38:58 Noor: the script has to have something to compare your branch to Aug 26 13:39:31 ideally your branch has a name and master is the original meta-oe, that will make it work automatically Aug 26 13:39:41 otherwise you can specify the comparison branch Aug 26 13:42:50 Noor: just tried and seems it's working here: http://paste.pocoo.org/show/464829/ Aug 26 13:44:42 Noor: but those warnings are really bad Aug 26 13:50:56 yeah, it's simply because the script expects you to be operating on a branch other than master Aug 26 13:51:17 this can be overridden however Aug 26 13:51:33 it also has no detection of when there are no changes between the comparison branch and the branch with the changes, which is a bug Aug 26 14:01:14 ahh right, it "works" for me only because my local master is real meta-oe/master and comparison works Aug 26 14:51:08 quiet today... Aug 26 15:01:48 yep Aug 26 15:02:35 it seems Aug 26 15:02:43 nearly the weekend, maybe everybody has gone home early Aug 26 15:37:27 * pb_ fights with virtual/libgl Aug 26 15:37:43 this is weird, for some reason I get a bunch of diagnostics about mesa even though I don't have that selected as my preferred provider. Aug 26 15:37:51 I guess I should try masking it out altogether. Aug 26 15:56:30 * cbrake wonders what he is missing with the angstom setup scripts. Setting a hash for a repo initial checkout does not seem to work. may be back to git-submodules ... Aug 26 15:56:56 cbrake: you tried the combo layer stuff yet? I haven't had a chance, but I'm skeptical Aug 26 15:56:59 heh Aug 26 16:03:41 hmm Aug 26 16:07:39 kergoth: no, I have not Aug 26 16:07:43 kergoth: don't understand it yet Aug 26 16:08:11 afaict its like git-subtree, but relies on in tree metadata rather than commit message metadata, and it implements it using format-patch/git-am rather than merges Aug 26 16:08:24 basically it pulls in commits from external repositories and applies them locally,w ith path adjustments Aug 26 16:08:31 "combining" many repositories into one Aug 26 16:08:33 gahh, layerman is feeding a buch of stuff through awk to a bash script with no error checking. Aug 26 16:09:57 kergoth: hmm, seems rather fantastic if it works. I wonder how extracting things back out of it goes Aug 26 16:10:18 that was my main concern Aug 26 16:10:33 I really prefer git-subtree, but what git-subtree can't do is pull a subdir of a remote Aug 26 16:10:40 for example, in poky, meta is oe-core/meta Aug 26 16:10:51 subtree and submodule can't pull a subdir of a different repo, only its root Aug 26 16:10:58 nod Aug 26 16:11:21 it claims to provide some sort of patch extraction, but i dunno Aug 26 16:11:35 is the combo layer stuff Koen's work, or is the layer stuff Yocto is working on? Aug 26 16:11:37 its definitely less convenient for those of us who interact with the upstreams of the components on a regular basis Aug 26 16:11:52 koen is playing with yocto's combo-layer tool in an Angstrom-combo-layer repo Aug 26 16:11:57 i don't think he's using it elsewhere yet Aug 26 16:12:01 but i'm not sure Aug 26 16:12:11 yeah, seems like things are getting way too complex Aug 26 16:12:13 it was written by one of the ycoto folk Aug 26 16:12:16 agreed Aug 26 16:12:29 why split things apart and then combine them back together? Aug 26 16:13:03 and then basic things like fetching the HEAD of a SVN repo is broke Aug 26 16:14:01 but has nothing to do with the layer tool Aug 26 16:14:03 well, everyone looking to use layers ends up combining them in some fashion, its just a matter of whether the integration involves pointing at an upstream ref, or applying all of upstream's commits locally Aug 26 16:14:15 let's not pick a cause at random for effects Aug 26 16:14:32 well, I need something that is rock solid, gives errors when there are errors, guarantees to give me the right repo version, etc, so its back to git-submodules for this project ... Aug 26 16:15:49 which is fine, no one is mandating the use of the layer tool or suggesting it's a one size fits all solution afaics Aug 26 16:16:29 incandescant: agreed, the SVN HEAD fetching issue is not connected with layering. My only point is oe-core does not seem to be getting any more "usable" for people building products. I still have hopes long term and continue on ... Aug 26 16:16:40 it seems pretty poky specific to me, yet it lives in oe-core Aug 26 16:16:59 i still think it's incredibly stupid for the sato stuff to be living in a supposedly "core" later Aug 26 16:17:05 incandescant: yup, nice to have options. Just trying to undertand if I'm missing anything. Aug 26 16:17:07 blah, layer Aug 26 16:17:49 cbrake: we're working hard to try and make it usable, I'm sorry you don't feel it's ready Aug 26 16:17:57 combo-layer is not intended for end-users Aug 26 16:18:19 that depends on who you consider the end user Aug 26 16:18:22 it's for people producing distros or projects like Yocto where you want a single checkout Aug 26 16:18:23 incandescant: understood, with change there is churn Aug 26 16:18:23 that's it Aug 26 16:18:34 kergoth_: there's a desire to have a graphical DE in core, sato is fulfilling that role for now Aug 26 16:18:52 if you consider the companies consuming oe to produce products as end users, then certainly they'll need or use an integration of some sort Aug 26 16:19:21 incandescant: as far as I'm concerned, no gui is ever "core". meta-oe's gui layers make a hell of a lot more sense to me, personally Aug 26 16:19:36 if you want demos, use a demo layer, don't cram it into the core Aug 26 16:20:03 kergoth: I'm merely trying to explain the rationale Aug 26 16:20:23 yeah, I'm not blaming you, just saying I disagree with the rationale :) Aug 26 16:20:40 but it's less for demo and more for testing, genuine demo's have been maintained out of core Aug 26 16:21:04 yeah, even the tests could go in their own layer just as well. Aug 26 16:21:08 exactly Aug 26 16:21:16 it is slightly irritating having sato contain, for example, a specific webkit recipe. Aug 26 16:21:19 oe-core/meta isn't the only layer in poky/yocto Aug 26 16:21:36 aiui the webkit portion of sato was dropped Aug 26 16:21:51 yeah, it's so arbitrary. pick one of the many guis at random and calling it somehow "core" doesn't make sense to me Aug 26 16:22:11 incandescant: it's still in the oe-core tree I have here, but maybe my checkout is slightly outdated Aug 26 16:23:09 so it is, maybe it was simply removed from the default images Aug 26 16:23:44 so you end up with this weird situation where webkit-gtk is "core" because sato uses it, but other variants of webkit are not, and hence it's hard for them to share code. Aug 26 16:25:59 oe-core was intended to be the common subset. which implies the portion of linux distributions which is common to most, or all, setups. choice of gui is obviously specific, not general, so doesn't seem to fit the definition of a common subset of metadata Aug 26 16:26:10 * kergoth shrugs, rant over, back to real work Aug 26 16:26:26 kergoth: I've argued with RP for a while; I believe things should be further split. I.e.., bitbake and the core classes (the build system) should all be separate from the recipe/feature/distro (meta data) layers Aug 26 16:28:22 that might make some sense, though I am not sure that separating bitbake and the "core" classes from the core set of recipes would buy you all that much in reality. Aug 26 16:28:56 clearly you can't use the recipes without bitbake, and practically speaking it seems unlikely that anybody would use bitbake without at least the core parts of oe. Aug 26 16:29:42 conceptually that would make sense, but as you say, practically it doesn't seem to, unless you wanted to set up tighter access controls, and that can be dealt with in other ways Aug 26 16:30:32 don't forget that we also have a vocal set of users complaining about there being too much separation Aug 26 16:34:34 yeah, though that problem seems like it should be soluble by mechanical means Aug 26 16:34:35 I know people seem to like the notion of layers for things like x11, but part of me still feels like the original notion of not categorizing the recipes because doing so is so arbitrary holds some water. now we can't find anything, because my notion of what goes here is different than your notion of what goes there Aug 26 16:34:40 * kergoth mutters Aug 26 16:38:20 true, and in the particular case of x11 I have recently been discovering that there are a bunch of packages labelled as being "x11" when in fact they are not, and a further set of packages which are "x11" in the sense of being written by x.org but not actually part of the x window system as such. Aug 26 16:38:21 anyone know what license http://cpansearch.perl.org/src/AUTRIJUS/Language-SIOD-0.01/slib.c is, offhand? it appears to be a variation on the 3 clause bsd license Aug 26 16:39:07 I like the notion of an oe-core, because that separation makes sense, from the standpoint of having a sane, functional, known quantity as the base (in theory), but beyond that... *shurg* Aug 26 16:40:07 i wish open source projects would always grab an existing license. there's almost never a good reason to come up with something else Aug 26 16:43:55 heh - thats the same argument for code reuse. Replace "license" with "linked list implementation" and it is still true Aug 26 16:44:00 hehe Aug 26 16:44:04 true Aug 26 16:44:10 Maybe thats the problem - licenses get some "not invented here" creep Aug 26 16:44:13 have you seen CCAN? looks cute Aug 26 16:44:23 | patch: invalid option -- U Aug 26 16:44:24 ccan? Aug 26 16:44:35 hell, i think quilt is using a patch option that doesn't exist on old distros Aug 26 16:44:42 * kergoth grumbles Aug 26 16:44:50 http://ccan.ozlabs.org/ Aug 26 16:47:17 hm for hast stuff there is uthash Aug 26 16:48:44 is ccan new or am I just slow? Aug 26 16:48:49 to find out about it Aug 26 16:49:20 I don't think there's all that much in it. i knew about it for a while, but never really paid much attention. just seemed interesting Aug 26 16:49:26 not sure how new it is *shrug* Aug 26 16:49:30 It needs better marketing - its a good idea Aug 26 16:49:41 it's like a common snippet library, which is good, but better yet, it's *tested* Aug 26 16:49:46 unlike snippet web sites.. Aug 26 16:49:57 heh Aug 26 17:24:58 please remind me, do we have plan to release in September? Aug 26 17:25:13 or October? Aug 26 18:32:23 I have BB_GENERATE_MIRROR_TARBALLS set but im not getting git tarballs created in my source ld dir.. am I missing something? Aug 26 18:32:25 :q Aug 26 18:32:26 :q Aug 26 18:32:26 :q Aug 26 18:32:58 whoops =) Aug 26 18:44:57 msm: maybe, they're named differently now Aug 26 18:45:15 git tarballs are (imho) not mirror-ready anymore since they don't encode the hash in them now Aug 26 18:47:11 oh Aug 26 18:47:16 so i can use them over http then? Aug 26 18:47:22 err can't Aug 26 18:51:15 You can Aug 26 18:51:23 It just sucks when upstream changes the githash again Aug 26 18:51:27 Since you need a new tarball Aug 26 18:58:27 so one needs to delete all the old tarballs and recreate them since the new hash wont be in the old tarball? Aug 26 19:00:42 wow, this is strange. I have a recipe that matches in bbfiles, yet bitbake says there's no provider. it isn'td oing anything strange, not raising skippackage or anything crazy.. makes no sense Aug 26 19:00:53 and -b works.. Aug 26 19:00:55 hmmm Aug 26 19:01:02 oh, duh, i'm a moron Aug 26 19:01:10 forgot about a rather greedy bbmask :P Aug 26 19:01:49 * kergoth rolls eyes Aug 26 19:42:02 Tartarus: so i need to delete all tarballs after each build? Aug 26 19:42:08 or forcily overwrite the tarballs? Aug 26 19:42:14 forcibly* Aug 26 20:42:55 Well, when it changes and you copy stuff over, it will overwrite Aug 26 20:47:53 well with INHERIT += "own-mirrors" it's still falling back to git clone for some reason Aug 26 20:48:22 might be my rsync though let me look Aug 26 20:50:07 or maybe the users local downloads is not getting updated? Aug 26 20:57:49 Is someone handling static libraries inside a same repository? Aug 26 20:58:14 We have a repository that is used by two projects but this is a static library Aug 26 20:58:28 what about it? Aug 26 20:58:36 We need it to be handled inside of each of recipe that is used Aug 26 20:58:53 so in case we update it, we don't need to recall to bump the revision of theirs user Aug 26 20:59:23 let's say, recipeA and recipeB use libcommon Aug 26 20:59:38 oh, you're wondering about handling of srcrev with multiple git repositories in SRC_URI? Aug 26 20:59:41 we want libcommon revision be at recipeA and recipeB versions Aug 26 20:59:43 for the child repo? Aug 26 20:59:47 kergoth: yes Aug 26 20:59:51 no clue :) Aug 26 21:00:14 * kergoth *hates* the way srcrev works Aug 26 21:00:50 hmm. Aug 26 21:01:29 heh Aug 26 21:02:26 I wonder if it'd be useful to make a tool which parsed a set of layers, then "installed" recipes you requested into a local dir, by doing the fetch/unpack/patch to populate S, pulling the recipe over, and making it use srctree Aug 26 21:02:30 * kergoth ponders Aug 26 21:03:28 kergoth: the problem is that it won't be included on the image Aug 26 21:03:39 what do you mean? Aug 26 21:05:41 * kergoth glares at his build Aug 26 21:23:58 khem ping? Aug 26 21:24:05 hi ka6sox Aug 26 21:25:02 hi woglinde how goes? Aug 26 21:25:15 hm Aug 26 21:25:20 hot Aug 26 21:25:26 now we have some summer Aug 26 21:25:51 I'm so ready for winter Aug 26 21:25:54 I hate arizona Aug 26 21:35:09 rofl Aug 26 21:35:23 kergoth, I'm in Mountain View Ca at the moment Aug 26 21:35:32 the weather here is just dull Aug 26 21:35:44 comfortable most of the year, but dull Aug 26 21:37:53 * incandescant spent a week in AZ. Did. Not. Like. Aug 26 21:38:36 You just have to like crazy heat Aug 26 21:38:55 yes....but is "DRY" heat... Aug 26 21:40:08 ka6sox: so's the inside of my oven Aug 26 21:40:24 :) Aug 26 21:40:45 sort of like the jetway at the phoenix airport Aug 26 21:40:58 * Crofton went through phoenix on the way to vancouver **** ENDING LOGGING AT Sat Aug 27 02:59:57 2011