**** BEGIN LOGGING AT Tue Mar 07 03:00:02 2017 Mar 07 13:14:46 geniuses: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=devmem2 Mar 07 13:15:36 we need new separate layer for devmem2! Mar 07 13:15:53 lol Mar 07 16:58:12 what is the best place in OE meta land to get a beaglebone black kernel recipe? Mar 07 16:58:27 we just built one from meta-ti and USB is not working Mar 07 16:59:19 cbrake: what's the issue with usb? Mar 07 17:03:50 cbrake: usually meta-ti is the best place now a days meta-beaglebone has been getting stale Mar 07 17:04:24 khem: no changes in 3 years is called abandoned, not getting stale :) Mar 07 17:05:41 I call no changes in many years "stable"... Mar 07 17:05:51 :] Mar 07 17:05:58 it's only when it no longer works it moes to 'stale', and then 'abandoned' Mar 07 17:06:09 but the problem is that nobody reports back any problems (like details of this USB is not working claim), everyone is just looking for a best place... Mar 07 17:06:13 fray: LOL :) Mar 07 17:07:15 (seriously though, I would like to see us go through the layers in the index in 'master' and turn off things that are clearly no longer being updated.. since it gives a false impression to people using the index) Mar 07 17:07:27 hi, i am trying to build a simple autotools project with an OE SDK (generated with populate_sdk, out of recent master). and all i am getting is Mar 07 17:07:27 xxx/sdk-test/sysroots/aarch64-linaro-linux/usr/include/gnu/stubs.h:7:29: fatal error: gnu/stubs-soft.h: No such file or directory Mar 07 17:07:44 it's been a while since i've tried sdk.. is there anything that i am missing? Mar 07 17:08:47 fray: speaking of index - how does that get indexed? how often does it check for layer changes? Mar 07 17:09:07 there is an updates field. Select a layer, select the update and look.. Mar 07 17:09:30 (looks like about every 3 hours on the '33) Mar 07 17:10:04 if you login to the index, under tools there is also an updates 'tool' that you can get more info on Mar 07 17:10:26 fray: for example, this is not correct - https://layers.openembedded.org/layerindex/branch/master/layer/meta-arago-distro/ Mar 07 17:10:44 what is not correct about it? Mar 07 17:11:04 denix: heh, if you ask mobile guys I agree, if you ask medical/automotive guys its probably not deployed yet in 3 years Mar 07 17:11:10 If you select updates, you can see why it's no longer being indexed.. Mar 07 17:11:13 ERROR: Cannot resolve dependency meta-optee (version None) for meta-arago-distro Mar 07 17:11:13 ERROR: Dependency toolchain-layer of layer meta-arago-distro does not have branch record for branch master Mar 07 17:11:52 http://arago-project.org/git/?p=meta-arago.git;a=blob;f=meta-arago-distro/conf/layer.conf;h=c86a41a16cef11f8910c44051ca7ff23fe73a536;hb=HEAD Mar 07 17:12:00 ndec: your project probably is not getting the SDK env Mar 07 17:12:01 someone added meta-optee at some point, but never added it ot the index.. Mar 07 17:12:18 if bitbake can't load the layer it can't be indexed Mar 07 17:12:27 ndec: it needs to use CC that SDK env builds one for you Mar 07 17:13:16 fray: well, bitbake has no issues with the layer :) but I got your point - never seen that updates tab for some reason Mar 07 17:13:41 updates tab was added a bit over a month, this will allow people to see what issues may be there Mar 07 17:13:54 denix bitbake has a problem with the layer, it says that the meta-optee doesn't exist Mar 07 17:14:20 when bitbake runs to index, it uses the contents of the layer index dependencies and the layer itself to try to put together the set needed to run the layer for scanning Mar 07 17:14:24 it's a good feature, but kind of not advertised, or did I miss it? Mar 07 17:14:47 fray: well, it's a problem with layer index, not bitbake Mar 07 17:14:57 No, go to the layer index, search for 'meta-optee' Mar 07 17:15:00 nobody has added it to the index Mar 07 17:15:07 you can't depend on something that isn't in the index.. Mar 07 17:15:15 that's what I'm saying Mar 07 17:16:04 there are many layers out there that are not public or not indexed and bitbake has no issue working with them Mar 07 17:16:29 If the user of the layer can't download the layer, bitbake can't use it and the dependency scanning fails.. Mar 07 17:16:37 so bitbake -will- fail, since the user can't find it Mar 07 17:16:53 If an indexed layer states a hard dependency, then it has to be indexed or the layer itself is broken.. Mar 07 17:17:02 if it requires it as a 'recommended' layer, that is non-blocking Mar 07 17:17:08 that's only true for indexing Mar 07 17:17:20 perhaps the user should create a local layer index instance and add the "other" layers to it? Mar 07 17:17:22 no it's true for any use.. Mar 07 17:17:41 if I go and download that layer, and try to use it.. I won't have that layer and thus bitbake will error Mar 07 17:17:51 I can not use that layer today w/o the 'missing piece' Mar 07 17:18:02 no issue here Mar 07 17:18:11 ok, where did you get meta-optee from? Mar 07 17:18:18 since it has to be in your project or it will fail to parse Mar 07 17:18:18 from meta-linaro Mar 07 17:18:27 of course it's in my project Mar 07 17:18:29 ok, then someone needs to add that to the indexer Mar 07 17:18:42 this is my point.. if it's not known to the index, how is someone supposed to find it? Mar 07 17:18:44 denix: no response when inserting a USB device. Is BBB still a supported platform in meta-ti? (using morty version) Mar 07 17:18:49 I agree with the "adding" part Mar 07 17:19:04 but disagree with bitbake will fail if a layer is not in the index Mar 07 17:19:11 denix: I suspect we doing something wrong here, or don't have the right bits Mar 07 17:19:23 cbrake: yes, it is Mar 07 17:19:38 cbrake: morty and 4.9? Mar 07 17:19:40 denix: ok, thanks -- I'll re-verify I have everything included correctly Mar 07 17:20:07 denix, how do you get the layer into your project to use it, if you don't know where it is.. if I don't download it then bitbake -will- fail Mar 07 17:20:27 cbrake: 4.4 should be very stable and well-tested. but 4.9 should also work, but there's currently active development going on, so it might get broken... Mar 07 17:20:27 khem: i am sourcing the env file, and doing ./configure $CONFIGURE_FLAGS Mar 07 17:21:07 denix: zImage--4.9.8+git0+5482e86724-r22a.2 Mar 07 17:21:18 fray: downloading a layer != bitbake Mar 07 17:21:34 denix: looks like linux-ti-staging recipe Mar 07 17:21:37 how do I run bitbake (against a layer) if I don't have the layer Mar 07 17:21:40 they are very much related Mar 07 17:21:51 fray: isn't the whole discussion about your setup tool to standardize on the layer downloading practice? Mar 07 17:22:03 yes Mar 07 17:22:04 fray: why are you saying you don't have a layer? Mar 07 17:22:32 I have that layer, everyone else has that layer who uses meta-linaro. it's just not indexed. so bitbake will not fail Mar 07 17:22:32 If i'm a user.. and I clone oe-core... (and bitbake)... Mar 07 17:22:56 then I clone this meta- other meta layer.. and I add it to my project.. Mar 07 17:22:57 I will get: Mar 07 17:23:18 fray: that's not how you setup ANY project or any distro Mar 07 17:23:41 sure it is, people do this all the time Mar 07 17:23:42 you just don't go and manually download layers one by one based on what layer index says Mar 07 17:24:09 I go to the index, I look up and find this magic meta-arago-distro is what I want.. Mar 07 17:24:15 cbrake: current is 4.9.13 - have you tried that? Mar 07 17:24:20 I then download the dependencies... I try to run it, and I get an error Mar 07 17:24:36 I then go back to the index and look up this missing piece and can't find it.. I'm now 'screwed' and have to hope google can help me Mar 07 17:24:40 denix: will do so next ... Mar 07 17:24:47 denix: thanks Mar 07 17:25:01 cbrake: otherwise you can try 4.4 stable kernel Mar 07 17:25:48 (and yes, I see that meta-optee is defined in the README file of that layer as part of meta-lianro.... but my point still stands.. if it's not in the index, it can't be easily found by users) Mar 07 17:26:09 cleaerly we need machine learning Mar 07 17:26:10 cbrake: if it works with 4.4 but doesn't in 4.9, I'll get people to look at it Mar 07 17:26:28 denix: thanks for the options -- will report back this afternoon Mar 07 17:27:30 fray: I've never heard of anyone composing a project from layers listed in layer index... :) usually it's some sort of setup tool (and everyone has their own) that does the "magic" assembly Mar 07 17:28:14 ndec: which package are you trying to build Mar 07 17:28:34 ndec: issue here is that its choosing wrong ABI Mar 07 17:28:40 denix, I hear it all the time from customers trying to add some magic thing they've found, or some semi provided BSP or... Mar 07 17:29:04 ndec: your SDK is probably tuned for hf but the package it trying to build with sf Mar 07 17:29:06 with the layer index, toaster and other things, this is where users are being told to go to find new things to use Mar 07 17:29:24 (speaing of meta-linaro, I just fixed the web link in the index) Mar 07 17:30:31 khem: I remember seeing that issue long time ago with stubs-soft.h in hardfp environment... was even discussed on the list, IIRC Mar 07 17:31:46 yes, I think its a problem for stand-alone apps like u-boot Mar 07 17:32:01 argument is we want to use same toolchain to build them Mar 07 17:32:05 which is a fair one Mar 07 17:32:15 fray: sure, that's the future. but you have to give people time to catch up - none of our customers are even aware of layer index, toaster, devtool, etc. many of them are on some old releases... Mar 07 17:32:35 fray: layer index being pretty much broken past few months is another example Mar 07 17:33:58 fray: BTW, it's been many hours since I requested to reset my password on layer index, still nothing Mar 07 17:34:00 usual experience i hear is someoen downloaded the layer.. run bitbake, and it complained it was missing something.. so they just walk the chain till they have it all.. (or adjust the dependencies in what they downloaded to remove things they don't want/need) Mar 07 17:34:15 denix, talk to halstead... otherwise I can reset it Mar 07 17:36:12 denix, You didn't receive the password reset e-mail? Mar 07 17:36:55 halstead: nope Mar 07 17:37:07 lemme check spam :) Mar 07 17:37:10 halstead ya, and I don't see how to change a users password in the admin interface, or i would Mar 07 17:37:59 not in spam either Mar 07 17:39:38 halstead: ok, got it - was using the wrong email address :) Mar 07 17:40:26 denix, Oh good. I was looking through the mail logs and I see several to you but it's not easy to see which came from the layerindex. Mar 07 17:41:38 halstead: apparently I registered with my work email on layer index, while otherwise I use my personal email for OE stuff. thanks and sorry for the noise Mar 07 17:42:13 fray, I don't know the admin interface very well. It looks like you'd do it at https://layers.openembedded.org/admin/auth/user/73/password/ Mar 07 17:42:23 No problem. Mar 07 17:42:42 halstead how did you get to that link, I don't see a link there.. Mar 07 17:43:54 AHHH! found it Mar 07 17:43:56 fray, I typed https://layers.openembedded.org/admin/ clicked on user, searched for denix, and found a tiny link under the password field for a reset form. Mar 07 17:44:00 it's not a button or drop down.. Mar 07 17:44:10 it's a tiny link that is nearly the same color (on my screen) as the link next to it.. Mar 07 17:49:37 looks like the :30 update is still in process... Mar 07 17:49:55 so it'll be about 3 hours before it indexes again Mar 07 17:50:38 fray, I can interrupt and restart if desired. Mar 07 17:50:50 no it should be a big deal.. Mar 07 17:50:59 we'll let you know if anything needs to be reindexed manually Mar 07 17:51:09 (regular update or reloaded) Mar 07 17:52:33 halstead: when I try to login it fails, so I click the reset password link and it says email was sent... but I didn't receive email Mar 07 17:52:52 moto-timo, which uname, I can check your email account (and now I even know how to chang ethe pw) :) Mar 07 17:53:05 moto-timo is what my password locker says Mar 07 17:53:13 moto-timo, I just closed out of all the logs. One moment. Mar 07 17:53:36 I don't see a username by that.. Mar 07 17:53:40 hmmm Mar 07 17:54:09 email is ticotimo AT gmail DOT com Mar 07 17:54:36 not found in the index.. I'd suggest add yourself new.. Mar 07 17:54:37 maybe username is ttorling? Mar 07 17:54:41 ok.. looking Mar 07 17:54:41 sigh Mar 07 17:54:54 any way to see "my layers" at once? Mar 07 17:55:14 denix, not that I've found.. but that is likely a good enhancment Mar 07 17:55:22 (might be something under 'tools'?) Mar 07 17:55:33 moto-time, nothing there either.. Mar 07 17:56:08 ok thanks fray Mar 07 17:56:52 moto-timo, Do you have layers you've added? We could maybe track it down that way. Mar 07 17:57:00 ahh forgot about that.. Mar 07 17:57:38 meta-python, meta-maker Mar 07 17:57:46 ya, you are in the index for meta-python at least.. Mar 07 17:58:06 i did just create the moto-timo user but it says account is inactive Mar 07 17:58:14 ok.. I'll authorize it Mar 07 17:59:34 moto-timo, Yeah. It looks like the layers had your e-mail listed but there wasn't a matching account until now. Mar 07 17:59:46 halstead ya that is what I saw as well Mar 07 17:59:55 I probably created that account multiple years ago (at least two) Mar 07 18:00:06 dunno maybe a reset somewhere in there? Mar 07 18:00:08 maybe it shriveled up in the shade of the basement Mar 07 18:00:11 :) Mar 07 18:00:21 anyway, ya you should be able to login and edit your layers now Mar 07 18:05:50 so, if I have a layer I'm co-maintaining, which uses my personal email, do I need to register another account for that? Mar 07 18:07:18 fray, halstead: ^^^? Mar 07 18:07:44 denix, I bet we can change the address associated. Mar 07 18:08:16 denix, Which layer? Mar 07 18:08:21 ya.. thats the thing.. the associated address is the linkage Mar 07 18:08:34 so either a second account or change your addr to match Mar 07 18:08:34 halstead: well, I have work layers which use my work email, and then I have non-work layer which uses my personal email Mar 07 18:08:53 I'd suspect two accounts would be better in this case.. I don't think there is any other way to link them Mar 07 18:09:00 denix, So 2 accounts or set them all to one address... Mar 07 18:09:12 ok, got it. Mar 07 18:09:29 would supporting multiple emails for one account be a good enhancement? Mar 07 18:09:49 * fray notes meta-optee just got hte publish flag set Mar 07 18:10:12 denix probably, I don't know that piece of the system as far as difficulty to implement though Mar 07 18:10:40 fray: yay, thanks for approving meta-optee Mar 07 18:11:05 I'd say these are the kinds of things we should add to the YP bugzilla as enhancements.. then Paul, myself (and hopefully others) can try to find time to implement them Mar 07 18:12:56 sounds good Mar 07 18:13:48 halstead if it's not too much of a bother, can you kick a regular update.py ? I'd like to verify that the new meta-optee indexes right and the dependency is added to the index as we expect Mar 07 18:16:47 fray, Started. Mar 07 18:17:01 fray: where does layer dependency actually come from - layer.conf/LAYERDEPENDS or is README being parsed too? Mar 07 18:17:04 thanks Mar 07 18:17:17 denix, layer.conf LAYERDEPENDS and LAYERRECOMMENDS Mar 07 18:17:23 (or manual entry) Mar 07 18:19:48 ah, manual, that explains it... was assuming layer.conf overwrites and corrects those Mar 07 18:20:26 ya, manual entries don't get 'removed' when the layer.conf has things removed.. Mar 07 18:20:33 but when layer.conf changes, 'new' things are added Mar 07 18:20:50 was a compromise to deal with layers that don't use LAYERDEPENDS at all Mar 07 18:22:07 fray: ok, fixed that too. thanks! Mar 07 18:28:27 fray: FWIW, morty has been updating and parsing just fine, even w/o meta-optee... but master was giving update errors Mar 07 18:28:40 morty must not have had the layer dep Mar 07 18:29:12 there is a new error... Mar 07 18:29:19 meta-arago-distro master Mar 07 18:29:27 ERROR: Dependency toolchain-layer of layer meta-arago-distro does not have branch record for branch master Mar 07 18:29:31 layer dep was in morty, probably not enforced? Mar 07 18:29:44 it was there is morty and enforced (in bitbake) Mar 07 18:29:56 fray: that's the manual entry I was asking and fixing Mar 07 18:31:07 meta-linaro-toolchain master has the same issue.. Mar 07 18:31:24 "toolchain-layer" is a -really- poor name for a collection.. Mar 07 18:31:32 but ya, it doesn't know what that is, but it's required Mar 07 18:32:27 ya, I don't see a 'toolchain-layer' defined in any of the meta-linaro layer.conf files Mar 07 18:33:01 odd, I don't see it as a REQUIRED either.. Mar 07 18:33:20 fray: that was part of meta-openembedded for few years, but has been removed some time ago. It's still being referred to from old manual entries - I fixed mine, but koen has to fix one for meta-linaro-toolchain Mar 07 18:33:35 gotcha.. I understand now Mar 07 18:33:44 I'll fix meta-linaro-toolchain Mar 07 18:34:22 do you remember the name of the layer that provided that collection? Mar 07 18:35:04 ahh found the entry for it.. Mar 07 18:35:05 https://layers.openembedded.org/layerindex/branch/fido/layer/toolchain-layer/ Mar 07 18:35:14 the last branch it was on is fido Mar 07 18:35:26 ok.. I'll make sure anything newer then fido is sanitized then.. Mar 07 18:40:55 'er.. meta/conf/documentation.conf that is Mar 07 18:41:10 TMPDIR[doc] = "The temporary directory the OpenEmbedded build system uses.... Mar 07 18:41:20 DL_DIR[doc] = "The central download directory used... Mar 07 18:41:21 etc Mar 07 18:41:44 if you find ones not documented and want to knwo what they are for.. then we can likely answer and they should be added to the documentationf ile Mar 07 18:49:12 denix are there any other bad deps (like toolchain-layer) that you know if? Mar 07 18:49:22 (I can search pretty quickly with a small script I just cobbled together) Mar 07 18:50:52 not that I know of, no Mar 07 18:51:08 ok Mar 07 18:51:27 Tools->Updates shows the latest errors, but no dependency ones besides toolchain-layer Mar 07 18:52:18 halstead still around? mind kicking the update ONE more time? Mar 07 18:52:43 fray, No problem at all. Started. Mar 07 18:52:46 thanks Mar 07 19:07:53 ARGH.. I swear the meta-arago-distro was fixed (removed the toolchain-layer) Mar 07 19:07:59 d'oh.. either I missed it 'or it came back'? Mar 07 19:08:35 this is strange.. when I dump the data out of the layer index.. the toolchain-layer is not listed in the dependencies.. Mar 07 19:08:40 I wonder if my program is filtering it? Mar 07 19:08:47 (since it can't be resolved) Mar 07 19:16:59 fray: that is weird - it came back and I had to un-check it again... Mar 07 19:18:17 this is odd.. I've got no idea why it would have come back Mar 07 19:18:43 what is even stranger, I'm not seeing the dependency (it's gone now of course) in the dump I'm doing via the rest API Mar 07 19:20:02 there aren't any indirect layer dependencies, right? Mar 07 19:20:10 no there should not be Mar 07 19:21:04 denix: we were missing some kernel modules -- bbb USB working now. Missing the pm firmware -- do you happen to know where that comes from? The CPU seems to be running very slow, so not sure if that is a symptom of missing pm firmware Mar 07 19:21:13 halstead still here, can you do update.py -b master -l meta-arago-distro Mar 07 19:21:22 I want to see if that nasty dependency comes back on us Mar 07 19:21:37 cbrake: all firmwares should be in meta-ti Mar 07 19:22:26 cbrake: for pm you need amx3-cm3 Mar 07 19:25:27 denix, if you see that depenency come back again let me know.. if so we need to track this down. My screen shows it is -definitely- gone now Mar 07 19:25:44 (it shouldn't even be possible to bring it back in master, since there is no corresponding master layer) Mar 07 19:27:44 fray: sure, will keep an eye on it. all I was doing is un-tick the checkbox next to it in the list and save. is there anything else there to it? Mar 07 19:28:04 thats all there should be to it.. Mar 07 19:28:10 I looked on the admin console and the dep is not there.. Mar 07 19:28:30 I looked for the toolchain-layer and it's only valid in fido, dizzy, dora, daisy danny and dylan.. anywhere else it shouldn't be legal Mar 07 19:28:45 so we likely a have a bug there that the dependency is appearing when it's obviously not legal Mar 07 19:29:06 fray, -b master -l meta-arago-distro done. Mar 07 19:29:12 let me check.. thanks Mar 07 19:29:38 excellent.. it worked this time! Mar 07 19:29:40 yay! Mar 07 19:29:44 I have no idea why that thing came back Mar 07 19:29:51 thanks, fray and halstead! Mar 07 19:29:53 and the 'distros' were incorporated Mar 07 19:30:15 I'm tempted to try to 'fix' th other 11 update errors.. :P Mar 07 19:30:59 btw, distro is picking up all the .conf files in the directory, it seems. maybe need to cross-reference against DISTRO variable? Mar 07 19:31:23 yes.. if the file is not a distro, you should be calling it .inc instead Mar 07 19:31:32 i.e. a common file between multiple distros Mar 07 19:34:06 yeah, I can make that change quickly. I don't mind it, but it's just we are making assumptions and imposing limitations based on that, which aren't explicitly documented, AFAIK... Mar 07 19:35:12 anything ending in .conf can be selected whent he user does 'DISTRO = ....' Mar 07 19:35:18 thus the same is done for the indexing Mar 07 19:36:07 * fray is going to remove lxcbench... it can no longer be retrieved, and I find no references genivi moved it to a newer repository area.. it just seems to have died.. Mar 07 19:36:19 (gianpaolo had a github version, but it was last updated in march of last year) Mar 07 19:37:51 fray: should distro at least set some basic variables like DISTR_NAME and/or DISTR_VERSION? I understand that theoretically any blah.conf in that dir can be specified by user as DISTRO, but as you said before, bitbake will fail :) Mar 07 19:40:33 I don't know what the rules are.. Mar 07 19:40:49 the OE 'nodistro' one is a bit unqiue in this Mar 07 19:46:39 we probably need to look at how we are getting the description for each distro entry... I think we're currently relying on a mechanism that almost nobody is using Mar 07 19:47:45 bluelightning: yeah, I only see few layers have description populated, the majority is empty Mar 07 19:48:31 yes.. that is something I never had time to explore, but it's implemented the same way that the machine descriptions are.. Mar 07 19:48:34 it did work for a few things.. :P Mar 07 19:49:46 @TYPE, @NAME, @DESCRIPTION fields in the comments. that was common for machines, but not distros... Mar 07 19:49:48 yeah, unfortunately not as many people cargo-culted the description mechanism for distro conf files as they did for machine conf files ;) Mar 07 19:50:15 (I don't think that's actually documented) Mar 07 19:50:17 "cargo-culted" LOL :) Mar 07 19:50:21 yup Mar 07 19:50:43 I'm glad they did for machines because that worked out nicely Mar 07 19:51:03 there were plenty examples from OE classic days Mar 07 19:51:06 :) Mar 07 19:51:09 not so with distros Mar 07 19:51:16 well I've seen a lot of examples of that with entries like 'generic machine' Mar 07 19:51:18 right, the syntax has been around for a while Mar 07 19:51:21 umm, ya, not so helpful.. ;) Mar 07 19:52:17 actually let me go look at the distro description thing now, shouldn't take long Mar 07 19:52:27 bluelightning there is a bug where you can have a dependency on a defined layer, but one where that layer (branch) doesn't exist.. Mar 07 19:52:36 we likely should have a check for that.. Mar 07 19:52:57 fray: well, we do, the layer update script complains about it Mar 07 19:53:13 fray: the issue is a chicken-and-egg one with when the branch records are created Mar 07 19:53:13 lol.. Mar 07 19:53:30 when you submit they may not exist, so we can't enforce it at that time Mar 07 19:53:43 layerbranch records, I mean Mar 07 19:54:07 at least those errors are a bit more visible now Mar 07 19:54:15 with the new dependency scanning that should not longer be an issue.. (and the manual selection on submission, I'd almost recommend removing) Mar 07 19:54:23 (still useful on the 'edit' screen) Mar 07 19:55:24 that assumes people have defined their layer's dependencies completely in the .conf... I guess over time people might be encouraged to, I'm not sure they generally are at the moment Mar 07 19:55:41 I haven't done an actual survey though Mar 07 19:56:29 bluelightning thats why I'm thinking leave it in edit, but not on the submit.. Mar 07 19:56:34 that way if it's NOT right, they can be edited.. Mar 07 19:57:19 the assumption there is that submitters can easily edit... many will be able to, but you don't need an account to submit whereas you need to create one (with the same email address) to edit Mar 07 19:58:09 what I'd really like is to be able to scan the layer in real time during submission, but that carries with it some risks of course (leaving aside the required engineering) Mar 07 19:59:38 yup Mar 07 20:03:19 denix: cpufreq-set -f 1000MHz gets CPU freq up -- it defaults to 300MHz -- we're probably missing gov setup or something ... Mar 07 20:03:35 denix: anyway, we're up and running now -- thanks for the help Mar 07 20:03:38 bluelightning: if I change email in my profile, will I lose ownership of my layers? Mar 07 20:04:03 cbrake: hmm, should default to 800MHz, not 300... Mar 07 20:04:08 denix: yes, until the branch records also get updated Mar 07 20:04:22 denix: there's a todo item to make that self-service Mar 07 20:04:37 cbrake: but I'm glad you got it working - let me know if you have other issues or questions Mar 07 20:05:23 bluelightning: trying to figure out how to handle own work vs. non-work layers registered to different emails Mar 07 20:05:41 bluelightning: we discussed earlier if it would make sense to allow multiple emails for one account Mar 07 20:05:56 denix: right now the only way would be multiple accounts Mar 07 20:05:57 denix, I think for now two accounts, eventually we may be able to link accounts.. but someone would need to implement that.. :P Mar 07 20:06:07 * fray politely begs for resources Mar 07 20:06:39 * fray thinks he has the update down to one (expected) error now.. and I've emailed the owner of that layer to fix it or I'll remove it for them Mar 07 20:07:00 bluelightning, fray: yes, 2 accounts for now... :) Mar 07 20:07:02 * fray figures it's 2pm.. time to get lunch before it's too late Mar 07 20:08:51 well, to clarify, the maintainer email update is self-service right now, but it's painful, because you have to go and update the email address per layer *per layer branch* and if you typo one of them you'll lose access to fix it Mar 07 20:10:00 of course, you can always poke me or fray or another person who has admin access to fix entries, but ideally you wouldn't need to Mar 07 20:55:56 hey anarsoul Mar 07 20:56:16 hey ant_home Mar 07 20:56:42 I saw your e-mail, will try to get 4.10 working on h1940 when I get some time Mar 07 20:56:51 shouldn't be too hard Mar 07 20:57:32 great, thx. I'm building 4.10.1 for sa1100 and pxa atm (testing new binutils vs. armv4) Mar 07 21:27:24 ok, after a bit of messing around I have the distro config parsing Mar 07 22:52:22 khem: back... it's an aarch64 sdk. i am a bit confused.. i am now just trying to compile 'helloworld', and have the same issue. that's with the linaro-gcc recipe. though. Mar 07 23:04:40 khem: hmm. so right, something is wrong in the sdk.. stubs.h is the armv7 version.. Mar 07 23:08:18 khem: hmm.. and we have multilib enabled by default.. i guess this is enough to mess up with the sdk.. Mar 08 01:04:51 ndec: no, we do not ship sfp headers thats known **** ENDING LOGGING AT Wed Mar 08 03:00:01 2017