[00:24] mwhudson, ok [00:30] zyga: wb [00:49] mwhudson, ok so now I can run lava commands via celery [00:49] mwhudson, I guess the next step is to lava-toolify the dispatcher [00:49] mwhudson, any objections? [00:53] zyga: nope [00:53] zyga: feel free to fix assorted cruddiness on the way past :) [00:53] mwhudson, would you mid if I moved all board support to extensions? [00:53] mwhudson, and keep the dispatcher a shell for them [00:53] mwhudson, maybe moving code back to core as we see fit for it to be there (and be supported) [00:54] zyga: um, probably not [00:54] mwhudson, initially we'd have one big lava-dispatcher-legacy package with the current code [00:54] zyga: it still should be reasonably simple to install though [00:54] mwhudson, then we could see how to clean that up (maybe redesign on top of the agent code) [00:54] mwhudson, look up celery-and-redis on pypi [00:54] mwhudson, bundles :-) [00:55] pip install lava-stack -> everything -> we could bundle that in .pybundle [00:55] zyga: celery-and-redis? [00:55] ah right [00:55] mwhudson, it's a pypi package that bundles both celery and redis dependencies [00:55] yeah [00:55] something like that [00:55] mwhudson, pip install lava-and-panda ;-) [00:55] mwhudson, pip install lava-tests-for-ubuntu [00:55] or something like that [00:55] could be cool [00:55] anyway [00:55] food for thought [00:56] I spent far too much time playing with celery [00:56] let's use it [00:56] everything ends up looking a bit like debian packaging i guess [00:56] zyga: +1 [00:56] mwhudson, oh, I think I have a semi-elegant way to fix settings [00:56] mwhudson, lava.celery.settings will do magic [00:56] mwhudson, if lava-server is around then we pull configuration from lava-server [00:57] mwhudson, then extensions can contribute_to_settings() to add celery tasks [00:57] mwhudson, broker is configured in settings.conf [00:58] mwhudson, result backend, I think, should be fixed to amqp for the moment, perhaps lava-server might change that to django but I'm not really sure if that is a good choice [00:58] mwhudson, then if lava-server is not available [00:58] mwhudson, right now I hardcode settings for local development [00:58] mwhudson, we only need to support three kinds of users for this module [00:59] mwhudson, celeryd --config=lava.celery.settings # I now see the need to rename that to lava.celery.config ;) [00:59] aaah [00:59] my scheduler changes depend on a new django-restricted-resource [00:59] i think [01:00] mwhudson, lava cloudify ... # I can see it either talking to lava-server if inside one venv or perhaps having some command line switches [01:00] mwhudson, new? [01:00] mwhudson, did you patch it? [01:00] zyga: no, but the most recent release has is_owned_by(user) for group owned resources dtrt [01:00] and i had a too old one installed locally [01:00] mwhudson, ah [01:00] mwhudson, I remember that [01:00] i wonder if staging has the old version [01:01] hm no [01:06] huh [01:06] oh [01:06] zyga: the change i need for django-restricted-resource hasn't been released yet [01:06] mwhudson, oh [01:06] mwhudson, well that's a shame :) [01:07] mwhudson, go ahead and release it please :) [01:09] yeah will do [01:14] Submitting dist/django-restricted-resource-0.2.7.tar.gz to http://pypi.python.org/pypi [01:14] Upload failed (502): Bad Gateway [01:14] COME ON [01:17] I guess pycon is a bad day for any releases [01:18] it's back up now [01:19] .. and released [01:23] Hi , i just download http://releases.linaro.org/12.02/ubuntu/oneiric-images/alip/hwpack_linaro-lt-vexpress-a9_20120221-1_armel_supported.tar.gz and http://releases.linaro.org/12.02/ubuntu/oneiric-images/alip/vexpress-a9-alip.img.gz .. try with linaro-media-create but it report bad checksum. [01:27] zyga: can you look at http://staging.validation.linaro.org/scheduler/ please? [01:27] looking [01:27] if you log in (you may need to log out and in again) you should be able to view job 11979 but not 11978 [01:28] mwhudson, is that openid? [01:28] mwhudson, I still see both now [01:28] mwhudson, I'll log out and back [01:28] zyga: do you have links for the job id though? [01:28] mwhudson, no wait [01:28] mwhudson, I see both as a guest [01:28] right [01:29] no [01:29] just job numbers [01:29] but no details? [01:29] right [01:29] cool [01:29] let me log in now [01:29] mwhudson, works as expected [01:29] mwhudson, is that via openid group membership? [01:30] zyga: yes [01:30] the linaro group on launchpad in this case [01:31] mwhudson, how does it look like in python> [01:31] zyga: thanks for checking [01:31] zyga: what do you mean? [01:31] it looks like OPENID_ENABLE_AUTO_TEAM_MAPPING=True [01:31] mwhudson, does that create "linaro" team in django? [01:31] yes [01:31] mwhudson, and makes me a member of that team? [01:31] no [01:31] wow, cool :D [01:31] :D [01:31] if you create a team in django [01:31] ah [01:32] sane and cool [01:32] it will ask launchpad if you are a member of that team when you log in [01:32] does it check back to kick me out? [01:32] I see [01:32] so we could create a group called ubuntu-core-dev, if we felt like it [01:32] mwhudson, I have a proof-of-concept that captures stdout and sends that back [01:32] nice, really nice [01:32] so [01:32] maybe [01:32] the only issue is that it all happens at log in time [01:33] it's time for lava-lab-job-submitters on launchpad? [01:33] so if someone leaves a team on lp, that isn't reflected until they log in again [01:33] zyga: yes, i think so [01:33] mwhudson, right, that is expected [01:33] mwhudson, good work :) [01:36] zyga: btw [01:36] zyga: anonymous bundle streams are a terrible terrible hack [01:36] i guess you knew this :) [01:36] D:D:D [01:37] I have only myself to blame [01:37] and OAuth [01:37] heh yes, always blame oauth [01:37] I think they have value but are gravely misused [01:37] well [01:38] i was more thinking of the implementation [01:38] user = User.objects.get_or_create(username="anonymous-owner")[0] === davidrusling_ is now known as davidrusling [01:39] robclark kicks it :) [01:39] aaaa [01:39] that is indeed super ugly [01:39] I forgot about that [01:39] I wrote that after d-r-r came to be [01:39] mwhudson, and required ownership of anything [01:40] (django-drm ;-) [01:40] yeah, i can see where it comes from [01:40] mwhudson, it would be nice to cure this one day [01:42] zyga: in d-r-r? [01:42] django-restricted-resource [01:44] mwhudson, OMG [01:44] mwhudson, :D [01:44] mwhudson, OMG [01:44] mwhudson, lol [01:44] zyga: ? [01:44] mwhudson, so have I told you that by accident I can run lava-test remotely via celery [01:44] mwhudson, so now I can run celeryd on a board and run tests there [01:44] :D [01:44] haha [01:45] plars, ^^^^ [01:45] well, that's nice [01:45] so where are we with that agent idea? [01:45] what are the minimal deps to run celeryd? [01:45] lava agent -> run celeryd setup for lava-lab with config in preseeded directory [01:46] mwhudson, kombu, pure python stuff for rabbitmq, celery [01:46] mwhudson, w8 [01:46] mwhudson, anyjson, ampqlib, kombu [01:46] mwhudson, and python-dateutil [01:46] mwhudson, I did not think about this [01:47] mwhudson, this is so cool, we could even _wait_ for the board to be "up" enough [01:47] mwhudson, I see some downsides [01:47] mwhudson, we don't have any yet [01:47] mwhudson, but any network test might disrupt this [01:48] mwhudson, unless this is designed correctly or we run ppp on the serial line [01:48] still [01:48] food for thought :-) [01:48] plars, I told you celery is _the_ thing ;-) [01:48] Dear all : Where to find the document that describe the definition of linaro 'm', 'n'. 'o' ? [01:49] wowon, where did you hear about 'm' 'n' 'o' [01:50] wowon: I'm guessing you are talking about the series of release? This would be for the ubuntu releases based on ubuntu {m=maverick, n=natty, o=oneiric, p=precise} [01:50] ah [01:51] zyga: you accidentally made lava totally distributed? (there's a funny parody of a meme there somewhere I think) [01:51] plars, well all lava-tool [01:51] kiko, I wanted to also include the corresponding drm-prime patch, but I'm still in the middle of rebasing and refactoring/simplifying some of that, but since folks are waiting I decided I couldn't wait for sending out the dma-buf patch/rfc.. [01:51] hopefully will have the drm-prime part of it tomorrow [01:51] plars, lava-test would make a fine agent to run on the board [01:51] plars, we could simply start it after booting [01:51] plars, then just talk to it directly via the API [01:53] plars, well not via API but still close enough [01:53] plars, single codebase is still an annoying factor [01:53] zyga: interesting [01:54] plars : thankyou for your enlightment . so .. is it true that linaro-o-server-tar-20120221-0.tar.gz means --> linaro oneiric server ? [01:55] wowon: yes, linaro-server image, based on ubuntu oneiric, and it's the daily build from February 21, 2012 [01:57] plars : thankyou ... can I later install x11 on it ? ... is it just like (for pc) ubuntu-server version ? [01:59] zyga: eyeballs please? https://code.launchpad.net/~mwhudson/lava-scheduler/private-job-tweaks/+merge/97556 [01:59] (pretty simple) [01:59] applying eyeballs [02:06] mwhudson, done [02:06] mwhudson, nothing wrong with the code but I'd like a change there please [02:06] zyga: ok [02:06] zyga: i don't think d-r-r and the django permissions system intersect at all do they? [02:06] mwhudson, by design, they don't [02:07] mwhudson, there's a description why [02:07] mwhudson, in short: permissions are complicated [02:07] mwhudson, and that was not the point of d-r-r [02:07] mwhudson, user code should implement permissions [02:07] ok [02:07] sounds sensible [02:07] mwhudson, and use the ownership and sharing enums to aid in that [02:08] mwhudson, I was hoping that django 1.3 would bring a better permission system [02:08] mwhudson, and I think it did [02:10] All ..... is there any support for RockChip RK-2918 Cortex-A9 ? [02:12] wowon, linaro focuses on member hardware, that SoC would likely get community support only (whatever is in the current upstream kernel) [02:12] wowon, I'm not familiar with that chip though [02:13] mwhudson, I just looked, I think django has a three-argument has_perm(with the action _and_ the target) but I cannot find any [02:13] mwhudson, I know there are 3rd party extensions that provide that [02:13] mwhudson, perhaps they somehow plug into django but it seems my desire to have a generic permission API is unfulfilled [02:15] zyga: so um [02:15] zyga: i think one can upload using put to any bundle you can see [02:15] mwhudson, :D [02:15] mwhudson, bug? [02:15] looks like it [02:15] mwhudson, ouch [02:15] lava-dashboard-tool put --dashboard-url http://127.0.0.1:8000/RPC2/ 4beb2b83f425a4be77107582f37ab4ddf65735f5 /public/personal/zkrynicki/testing/ [02:15] mwhudson, there goes security [02:15] Stored as bundle 4beb2b83f425a4be77107582f37ab4ddf65735f5 [02:16] so yeah [02:16] * zyga looks at the code [02:16] Zyga : thankyou for your info ... so the only chance for me is to try it my self. anyway ... that RK2918 is commonly used by chinese manufacturer .... their android setop box is priced low. [02:17] wowon, they are free to become linaro members, partners or to work as a community supported variant [02:19] mwhudson, I'm fixing that [02:19] zyga: ok [02:19] mwhudson, I'll add a test case too [02:19] zyga: please make it an api that the scheduler can call :_) [02:20] zyga : kindly please explain me more about 'work as community supported variant' .... well i'm not the manufacturer .. i just in progress at developing such fleet management application, and I found that this kind of appliance will economically match my requirement [02:20] mwhudson, heh, fair enough :) [02:20] wowon, anyone can step up and work as community inside linaro to support non-member hardware [02:21] wowon, I'm not sure anyone has but it's not like we're going to prevent that [02:26] Zyga : Thankyou. Argh .. i'll learn more using qemu ..... and be back soon I have more infos. Thanks [02:38] mwhudson, sorry, on it now [02:46] zyga: let me know when you have something you want me to review [02:46] mwhudson, almost done [02:47] mwhudson, I've realized how much testing with lava-server manage -d test sucks [02:47] mwhudson, plust how many errors there are in the dashboard test suite now [02:48] mwhudson, aww [02:48] mwhudson, now I want your factory [02:48] mwhudson, I have my own but yours is cleaner [02:50] zyga: at least manage -d test completes fairly quickly (if that's using sqlite) [03:00] mwhudson, is there a bug on that? [03:00] mwhudson, I've got the core ready [03:03] mwhudson, do you have the bug number? [03:03] zyga: no, i can file one [03:04] thanks [03:05] * zyga builds docs [03:05] zyga: https://bugs.launchpad.net/lava-dashboard/+bug/955669 [03:05] Launchpad bug 955669 in lava-dashboard "anyone who can see a bundle stream can place a bundle into it" [Undecided,New] [03:05] mwhudson, thanks [03:05] * mwhudson wonders who will get the precious bug 1000000 [03:07] zyga: i need to leave in 10 mins btw [03:07] * zyga hurries up [03:07] zyga: i can check in later, but probably (hopefully?) after you're asleep === DrKmobs[0] is now known as DrKmobs [03:09] ok [03:09] mwhudson, the branch is up [03:10] https://code.launchpad.net/~zkrynicki/lava-dashboard/fix-955669/+merge/97563 [03:11] mwhudson, I guess I'll wait for your review [03:11] mwhudson, and call it a day [03:11] zyga: +1 [03:11] plars, tomorrow I'll release alpha cloudified dispatcher [03:12] zyga: clicked around on lp too [03:13] mwhudson, merged [03:13] zyga: thanks! [03:13] zyga: i assume if i update my branch to call the new method, you'll be happy with it? [03:13] mwhudson, yes :) [03:13] cool [03:13] ttyl [03:13] are you going back today [03:14] or is 10min your daily EOD [03:15] mwhudson, remember you need lava-dashboard >= 0.13.dev [03:15] question about auto root login , how to disable it ? [03:16] zyga: no, i'm stopping early today [03:16] (started early too) [03:18] I see [03:18] see you tomorrow than [03:19] good night === michaelh1 is now known as michaelh1|away [05:08] hi ... kindly please help me .... i really really need to disable the auto root login ... how to do it ?? [06:45] springz: liuyq: do you know where I can find a description/doc of metadata in lava json file? [06:47] fabo, in job definition file or result? [06:47] springz: job definition [06:48] fabo, e.g. http://validation.linaro.org/lava-server/scheduler/job/15586/definition [06:49] fabo, "metadata": { [06:49] fabo, others can be retrieved when test image running [06:50] springz: I don't get it. for example, I'm looking for all key/value pairs that I can put in metadata section. [06:51] springz: the job definition of a running job will give me only the one that have been specified by the user, if I understand correctly [06:52] fabo, right, I don't know where all pairs defined, need to look for [06:55] fabo, springz, maybe there is no definite definition, we can set any key and value pair in the metadata section === e-ndy|afk is now known as e-ndy [06:58] fabo, liuyq yes, if you mean the hidden ones which will collect by lava itself, from lava-dispatcher code, there are like target.hostname, device_type [07:00] springz: liuyq: ok, sounds good. thanks! [07:28] bhoj: ping [07:33] hrw: I've created oneiric-armel-alip-dev successfully [07:34] hrw: I started from my precise-armhf-alip configuration [07:34] it doesn't contain your clean up script yet, I'm testing now === michaelh1|away is now known as michaelh1 [08:05] ndec: a colleague tells me he got null WS working on beagle and panda boards [08:18] HI, I'm using arm-linux-gnueabi from ubuntu, i found that it can only produce code for armv7, i appended the -mcpu paramter according the linaro ppa's instruction, but it doesn't work.please help [08:23] wenyi: it can enlight you -> http://comments.gmane.org/gmane.linux.linaro.toolchain/2185 [08:27] hrw: it worked, including your scripts. config available on http://people.linaro.org/~fboudra/live-build/oneiric-armel-alip-dev.tar.bz2 [08:28] Hi fabo .... know I have linaro image with plain openbox and slim ... build from nano. Currently i'm trying on compiling Navit with it. [08:29] wowon: good progress :) [08:29] fabo: Thanks.I've read the link, and it's helpful. [08:54] aviksil, hi [08:55] bhoj: in my local fast models setup, it takes around 20 s to complete "sleep 1". is it the usual behavior? [08:56] aviksil, yes. its correct. the simulated clock itself is not accurate. [08:56] bhoj: hmm, ok [08:57] bhoj: and do you know how much it takes to run "memtester 64M 1"? [08:57] bhoj: for "memtester 4K 1" it takes few minutes for me [08:58] aviksil, I have never run it [08:58] bhoj: oh ok [08:58] aviksil, may be pundiramit would have tried it . [08:59] bhoj: ok, thanks. will ask him [09:19] i am probably missing something: i crosscompiled my own kernel for the imx53 following some wiki link, then installed the deb into my linaro-ubuntu-natty install but the system isn't picking up the new kernel automagically as it does in my workstation. since there's no grub, is there some extra step i am missing? [09:19] hi [09:19] fabo: fetched [09:20] c10ud: boot board, run flash-kernel [09:21] hrw, thanks, trying asap [09:38] fabo: same problem with your files. will check in oneiric chroot [09:41] heeen: ok... that's certainly possible. that must be with a different DDK than the one we currently maintain... do you know where he got his? there are indeed several different flavours of it.. [09:42] "kernel whatever2.6.38-linaro-mx51 does not match your subarchitecture mx5, therefore not writing it to flash" ..any clues? [09:42] hrw: what's your host? I'm using precise/amd64 [09:43] fabo: precise/amd64 [09:44] hmm I can't reproduce here... [09:50] * michaelh1 waves goodnight === michaelh1 is now known as michaelh1|away [09:50] ndec: romaxa.info/qws-embed/sgx/ [09:55] isn't there some flash-kernel "by hand"? i tried getting an updated version but no luck [09:56] it still complains mx51 != mx5 [09:56] but i cloned from linaro/ubuntu/linaro-natty so i don't know what could be wrong (and used the provided debian folder) [10:00] ohh flash-kernel is a script, now let's see [10:04] c10ud: which mx51 boards are you using? i have a babbage and a sharp pcz1 that i do plan to try get opengl es running on when i get some time [10:05] imx53 but i'm starting to think this kernel is no good for [10:05] it [10:08] the ubuntu flash-kernel has mx5 support since ages, make sure your kernel package is named properly [10:08] mx51 is dead in ubuntu [10:09] ogra_, i found that out the hard way, because it isn't booting up ;) [10:09] heh [10:10] anyway, i cloned from http://git.linaro.org/git/ubuntu/linux-linaro-natty.git i thought it had the right kernels for each board (and maybe mx51 was something like mx5x) [10:10] looks like i was wrong [10:11] mx51 is the old freescale babbage board thats long out of production [10:11] last support for it in ubuntu was 10.04 [10:12] i see. then i just need to find the upstream git for the kernel i was running on the board [10:12] oh man, why don't you build with some more drivers [10:13] eheh [10:13] note there is an ubuntu image for the quickstart board that should work out of the box [10:13] is your HW something different ? [10:14] nope, everything was working well (i created the os with the linaro tools quite some time ago, hence the need for natty kernel..should be 11.04 iirc) but i needed drivers for ftdi and some wifi dongles [10:15] ah [10:19] wow [10:19] good === danilo_ is now known as danilos [10:19] hi [10:20] what will be minimum size for LPDDR for ICS [10:20] fabo: same in clean oneiric/amd64 chroot [10:21] jk_: I would say 512MB [10:21] is it possible to cut down still... by removing things realted to camera, gps and BT etc [10:22] jk_: my nexus s has 512MB ram which means ~380MB for system and it gives feel 'I want more ram' [10:23] really... does this means..very slow when you use camera [10:24] hard to tell but I feel that ICS requires dualcore cpus - it is slow by itself [10:24] yes, i agree with you Dual core is a good option [10:25] but nexus s does not have dual core i suppose [10:25] ics on archos tablet (omap4430, 512mb ram) works nicer then on nexus s (onecore a8/512mb ram) [10:26] that is good... [10:27] omap 4430 is dua core and also has DSP on board I supose [10:28] and more [10:28] yes some h/w acce units for vedio [10:29] do u think archos tablet PC has open source version of linux 3.0 and ICS on it [10:29] nope [10:30] but you will be able to install it soon [10:30] hi av500, thanks ...join command worked well [10:30] hrw: I'm trying on ci as I don't have any clue on what's going on and the differences in our precise/amd64 build host [10:30] fabo: neither do I - checking clean precise chroot now [10:30] fabo, still issues with qemu ? [10:30] av500, soon ? Do you know how it could be done ? I could add any packages since they have a squashfs image on that thing. [10:30] fabo: anyway I will create configs for my images and then push to ci [10:31] bhoj: av500 is archos guy ;) [10:31] hrw, aahhh :) . [10:31] bhoj: and you can run most of archos tablets with ext4 rootfs [10:31] good [10:31] av500 [10:31] i have acer tablet [10:31] ogra_: no, I have a work around for qemu and pm215 has fixed qemu-linaro. 2012.03 should land today. [10:31] jk_: heresy! [10:32] but it is very old model c200 [10:32] fabo, well, i dont see the issue anyway on x86 :) [10:32] hrw, I was expecting archos g9 tab to have standard android partitions but it did not :) . [10:32] bhoj: true [10:32] since we made tablets longer than aapl and google, we had our boot scheme already :) [10:32] bhoj: I have read that you can hack a bit and get it running from mmcblk0p3 [10:33] really av500 [10:33] do you folks take tablet design contract wok [10:33] depends [10:33] means what [10:33] hrw, haven't explored it much . need to try it out :) . [10:33] do you have money? :) [10:33] money...yes VCs have it [10:33] bhoj: basically go to xda develoeprs [10:34] great, send some [10:34] if you give good cost, i can aske VC to pay u [10:34] i hope av500 is not from china [10:35] 怎么回事呢? [10:35] my worry all on LPDDR and fall out elpida [10:35] wowwwwwwwww nooo yea.. i can not read [10:35] neither can I [10:35] what does this means [10:35] then it is ok [10:35] same boat [10:36] slow boat to china... [10:36] do u think 512 MB with OMAP 4460 will be good tablet oc [10:37] oc? [10:37] oc means... free [10:38] how come u did not know this one [10:38] when we wre stiudnets, if some ask some thing ..we call it oc [10:38] students... [10:39] ok, you caught me, I bought my diploma [10:39] means what...where did you buy? [10:40] you have learn and u can not buy [10:40] i think you guys are very cislty [10:40] very costly [10:41] let us go back to old question on LPDDR size [10:45] hi av500... i want to run satellite radio receiver in tablet pc.. this is my app [10:45] and i do not want all kind of games [10:45] thus i think 512 MB is ok [10:49] ji [10:49] hi [10:57] fabo, hi [10:59] hi [11:07] liuyq: Hi [11:08] good morning [11:09] exit [11:09] bah, I got focus issues :) [11:10] fabo, ChiThu, liuyq, hey, how are you doing? [11:10] zyga: hacking :) [11:10] zyga, just fine and what about you ? [11:12] amitk: may I edit https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/QA/Scripts ? [11:16] re [11:16] eh, my machine keeps locking up [11:16] ChiThu, I just woke up [11:16] ChiThu, I was working till 5AM yesterday [11:16] amitk: I finished the job, and I think I should edit that page. I see the notice (!! Don't move/rename without talking to PM QA maintainer!!) there, so I need confirm to proceed. [11:17] zyga, wow. not so healthy. You have not got 8 hours sleep :-) [11:17] I know, I need to eat breakfast and I'll be back here soon [11:18] ChiThu, we'll be able to run dispatchers in our cloud very very soon [11:18] ChiThu, I made it work yesterday, all it needs now is fit and finish [11:19] amitk: I will be off line IRC soon, any information please send to my mailbox, so that I can do the work on my next morning. thanks. [11:19] zyga, great news. [11:20] ogra_: and pm215 just released ;) so I don't need to work around anymore [11:21] it'll probably be a while before steve l does the ubuntu packages [11:21] fabo: I've just missed our sync meeting [11:21] I'm building the package locally [11:22] zyga: no worries. I've read the backlog :) [11:23] fabo, I have a question about the linaro-android-build-tools work item in bp https://blueprints.launchpad.net/lava-android-test/+spec/support-custom-command [11:24] liuyq: shoot, not sure who wrote post-build-lava.py but I'm using it and forked it for CI purpose [11:25] fabo, should we do it ourself, or request the suitable person to do that? [11:26] fabo, I have done modification on it before. But I'm not sure if it's my work scope [11:26] liuyq: as you prefer, submit a merge request yourself or poke pfalcon about it [11:27] I don't think it worths paperwork and will take too much time to do it yourself [11:28] fabo, ok, I will look it, but the design of interface may take some time, and need discussion I guess [11:30] liuyq: pfalcon: please sync, if it's a lot of work -> raise to TL/PM [11:33] fabo, ok, I see, when I have the prototype of that interface, I will send mail to related persons to discuss. [11:33] thanks [11:35] liuyq, fabo: I'm not much in loop on lava stuff, and looking at that BP, I'm not even sure I understand that task right. for example, we allow users to specify (custom) list of tests to run. It's not that? [11:35] liuyq: so, regarding interface, you would no more. [11:36] liuyq: and regarding impl, as fabo says, it would likely take adding few json entries to post-build-lava.py . i can review that for consistency and merge [11:38] do we get better procedure for new git tree then https://wiki.linaro.org/Process/GitHostingAccounts one? [11:39] hrw: what do you want more? :) seems straight forward [11:40] pfalcon: s3.amazon down again? [11:42] fabo: I hope that one day we will move to github so playing with shell will not be needed just to create new git tree [11:42] pfalcon, yes, I should modify post-build-lava.py to sent right lava jobs according the variant set in the android-build page. About how to design the variant on android-build, I guess it needs to discuss, but that may be not your scope. [11:43] hrw: look into my home, you'll find bin/setup-git-repository [11:44] pfalcon, well, when I modified the post-build-lava.py file, I will ask you for review. Thanks for that. [11:44] it takes the name of the repo as parameter [11:44] fabo: once I am on server I am fine with running few commands which your script does [11:45] hrw: if you use it, you'll need to set your working directory... [11:46] hrw: yep, not sure we'll get a web ui for that [12:03] james_w, danilos, http://paste.ubuntu.com/884679/ [12:03] jamestunnicliffe, ^ [12:04] salgado, fwiw, I am finding a replacement for you, only one requirement, "must be nice" :) [12:04] like me, for instance ;) [12:04] james_w, please change your nick to jamesw so that you no longer confuse my IRC client's tab completion. kthxbye ;) [12:04] james_w, please change your real name to something other than James so it doesn't confuse my IRC client either [12:04] danilos, nice like you is easy enough ;) [12:05] fabo: http://git.linaro.org/gitweb?p=people/hrw/ci-sysroots.git;a=summary done, time to login to jenkins and copy your tasks [12:06] hrw: k [12:06] salgado, jamestunnicliffe: the traceback is clear, build_result.name has no "-" in it for a certain build, though I have no idea how that'd happen [12:08] fabo: should I create new project or add builds to your 'ubuntu build service'? [12:08] hrw: add to 'ubuntu build service' [12:09] hrw: we'll polish later, get rid of people/etc... [12:09] salgado, jamestunnicliffe: I am guessing it's the one named "freescale" that's causing the problem (looking at /admin) [12:09] ok [12:09] danilos, salgado: oops, sorry, missed hangout, got distracted by local stuff. not much update from me though - working on androinfra tickets [12:10] danilos, what makes you think so? the errors you see on /admin are only for the web UI and I don't think the build failures are caused by the web UI [12:11] salgado, well, that's the only one not including "-" in the build result name, I am very much wildly guessing, though [12:11] pfalcon, ack, thanks for letting me know [12:12] danilos, freescale is the name of the project. the name of the build will always include a - because the name is auto-generated and includes a "-date" suffix [12:12] except when there's an error and then the build name is ERROR, it seems [12:14] danilos, jamestunnicliffe, I think we need to start by getting the slave logs to see if we find anything [12:14] akgraner: I wasn't, but am now [12:16] danilos, jamestunnicliffe, the build logs are in a 'builds' directory under the root of the offspring tree [12:16] danilos, salgado: going to be AFK for about an hour. [12:17] salgado, ah, ok, but this was about the build_result.name [12:18] hrw: I've hit your issue! please, dpkg -l qemu-user-static live-build [12:18] danilos, ISTM that that's because the build_result.name is ERROR, which is probably a bug. what I was trying to find out is what's causing the builds to fail [12:19] fabo: 1.0.50-2012.02-0ubuntu1 qemu probably? [12:20] hrw: kick them out of the way and use the packages coming in the repo [12:20] ok [12:21] fabo: "pending - All nodes of label 'precise_cloud' are offline" [12:21] hrw: apt-get upgrade will pull a buggy qemu and if you have tools ppa, it will another live-build [12:22] hrw: -> pfalcon: s3.amazon down again? [12:22] salgado, ah, ok [12:22] fabo: thanks [12:22] fabo: is that ci.* ? [12:23] pfalcon: yes [12:23] let me look [12:23] pfalcon: jobs are queued and slave nodes are always offline [12:23] pfalcon: https://ci.linaro.org/jenkins/label/precise_cloud/ lists two dead machines [12:23] pfalcon: it happened earlier today (s3) [12:23] fabo: qemu from repo is older or newer? [12:24] hrw: older. I'm validating 2012.03 atm [12:24] ok [12:24] salgado, how do I get slave logs from alnasl (eg.)? [12:24] fabo, hrw: well, it's main ubuntu archive, not S3 and not even ec2 mirror [12:25] argh [12:25] Get:35 http://archive.ubuntu.com precise-updates/universe Translation-en [12:25] danilos, need to ask IS for that [12:25] salgado, fwiw, alnasl is the only one listed as armhf, all others are armv7l [12:25] salgado, ack, will do that [12:25] (unless of course they switched to transparent s3 mirror or something) [12:25] danilos, yep, although I think fabo changed its arch recently? [12:25] fabo, ^ [12:26] (alnasl was building armel projects, so I thought you might have changed it) [12:26] salgado: yes, we switched temporary to alnasl/armv7l to validate a theory [12:26] it's back to alnasl/armhf [12:26] fabo, hrw: sorry, just killing jobs to avoid dead slave proliferation [12:27] hi salgado, danilos :-) [12:27] hi pfalcon too :-) [12:27] james_w: Hi! ;-) [12:27] james_w, heya :) [12:27] james_w, hi! I was just going to start a vote for Danilo changing his name instead. ;) [12:28] fabo, hrw: watching oneiric_cloud (for qemu) starting [12:28] hey mabac [12:28] pfalcon: it seems only precise_cloud is affected [12:29] mabac, you don't need a vote for that, we all know how that's going to work out [12:29] fabo: yep, it pulls from http://archive.ubuntu.com , oneiric_* from http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ [12:29] danilos, that I win without contest? [12:29] make sense [12:29] mabac, exactly :) [12:29] /rename danilos james_1 [12:29] ;) [12:48] salgado: where would the log files on build slave be for the build? [12:48] danilos, jamestunnicliffe, the build logs are in a 'builds' directory under the root of the offspring tree [12:49] plars: snowball soft/hard reboot - bug 872833 [12:49] Launchpad bug 872833 in igloocommunity "Snowball: Device hangs while bootup with both soft/hard boot" [High,In progress] https://launchpad.net/bugs/872833 [12:50] fabo: thanks! [12:51] amitk, ping [12:54] wookey, g'morning :-) I was researching open hardware as it relates to ARM based hardware and had some questions, I think I have it figured out now - but can I run some slides by you later tomorrow? [12:55] vingu, ping [12:55] ChiThu:hi [12:56] akgraner: sure [12:56] vingu, I am analysing what is the power management test in lava-test is. and why it failed when run on snowball. [12:56] I have some clue on the subject, although others have been doing the running in recent years [12:57] ChiThu: which part of lava-test fails ? [12:58] vingu, do you know who can answer my questions regarding those test cases ? [12:58] wookey - I just have to work it into a keynote and I just want to make sure it passes the sanity check :-) [12:58] vingu, wait.. I should you the lava job [12:59] ChiThu: hi [13:01] amitk, hi. I am asking about power management test cases. vingnu is helping me now. [13:02] vingu, http://validation.linaro.org/lava-server/scheduler/job/15458/log_file [13:02] vingnu, search 'lava-test run pwrmgmt' [13:04] ChiThu: are you talking about "LAVA: (stdout) cpufreq_05.4: checking 'ondemand' directory exists... fail [13:05] or LAVA: (stdout) cpufreq_07.1/cpu0: checking 'ondemand' decrease frequency on idle... fail [13:05] LAVA: (stdout) cpufreq_07.1/cpu1: checking 'ondemand' decrease frequency on idle... fail [13:07] amitk, I wonder why it failed, who should fix it ? we get same error when run the tests in snwoball CI. [13:07] ChiThu: it seems that cpu hotplug doesn't work as well : we have an oops on the 1st unplug. which kernel version are you using ? [13:10] ChiThu: it is either a bug in the script, a forgotten Kconfig option or bug in code. Best this is to file a bug for of the fails against linaro-pm-qa project and someone will investigate it and file bugs against Landing team or fix the scripts [13:15] vingu, it is the latest branch of igloocommunity kernl git. https://ci.linaro.org/jenkins/view/Linux%20Linaro%20Snowball%20builds/ [13:25] ndec: ping [13:26] amitk, vingu : simular errors found on daily builds. http://validation.linaro.org/lava-server/scheduler/job/15623/log_file [13:32] has anyone else seen upstart-udev-bridge eat 100% cpu? [13:32] amik,vingu : I created the bug rapport. https://bugs.launchpad.net/linaro-power-qa/+bug/956004 [13:32] Launchpad bug 956004 in linaro-power-qa "Testsuite fails when run on snowball daily builds" [Undecided,New] [13:39] hrw: pm215: good to go. ubuntu-desktop built with 2012.03. [13:39] hrw: package updated in the repo and ci jobs too. [13:41] cool [13:49] fabo: cool. I did test it in my local setup but live-build is pretty opaque so I wasn't entirely certain where it was pulling its qemu from ;-) [14:06] ramana: ping === davepigott__ is now known as davepigott [14:08] salgado, would https://bugs.launchpad.net/linaro-offspring/+bug/956035 also be an easy bug to start with for offspring? :) [14:08] Launchpad bug 956035 in offspring "Warn about low disk space on the buildds" [Undecided,New] [14:09] alf_, are we mumbling? [14:09] JesseBarker: sure, let me log in [14:09] danilos, might be tricky because such a warning on build logs wouldn't be of much use, I think, so the slaves would have to somehow pass that information for the master to warn users === leio_ is now known as leio [14:12] salgado, right, it might make sense to make that independent of the builds, eg. make it part of master-slave communication [14:12] salgado, perhaps it'd be good for you to mentor me through it next week, I'd like to have a go at it myself [14:14] danilos, sure thing [14:23] fabo: do you happen to know why is toolchain not pushed to snapshots as well but to builds.l.o instead? [14:25] danilos: it has been historically like that. michaelh1|away could give you more info. I suspect it's part of his workflow/ci [14:25] fabo: ack, thanks [14:27] mpoirier, pong [14:27] ramana: good day. [14:27] mpoirier, good day indeed [14:28] ramana: regarding bero's last email. [14:28] mpoirier, yes. [14:28] ramana: actually, it was your last email. [14:29] ramana: know absolutely nothing in those area so I need a little more explanation. [14:29] mpoirier, ok [14:29] ramana: from there I'll be able to go to STE and have thigns done. [14:29] ramana: first, [14:29] ramana: what is a PLT entry ? [14:30] mpoirier, ignore that [14:30] ramana: let's continue here. [14:30] ramana: ignore the PLT entry ? [14:31] mpoirier, ignore that statement. What I wanted to know was how you linked to create that .so file [14:31] mpoirier, whether you were using arm-linux-gnueabi-ld or arm-linux-gnueabi-gcc [14:31] ramana: ok, I don't have it. Someone in house did it. [14:31] ramana: I'm linaro, working with STE. [14:31] ramana: from our conversation I will go to STE. [14:32] mpoirier, i.e. ask them why they are not linking against libgcc.a [14:32] ramana: they probably not aware of that. [14:32] ramana: hence my aim to understand as much as I can. [14:33] ramana: would using the linaro toolchain fix the issue ? [14:33] mpoirier, I don't understand what the issue is :) [14:34] mpoirier, I don't understand what their flow is . [14:34] mpoirier, to create this library . Can they describe that without having to show any source code or anything else to us ? [14:34] ramana: probably. [14:35] mpoirier, lets start from there. [14:35] ramana: If I understand the situation properly, [14:35] ramana: __aeabi_llsr needs to be in libump.so. [14:35] mpoirier, AFAIK . [14:36] mpoirier, yes [14:36] ramana: ok and in this case, it isn't so. [14:36] mpoirier, yes - can we get a small testcase to see why this is happening. maybe they can produce this with a simple testcase with another library and show this [14:36] aviksil, Hi [14:37] mpoirier, if they can get a small testcase where there is a shared library with an external call to __aeabi_llsr then maybe it will help diagnose the problem better. [14:37] bhoj: hello [14:37] ramana: we wont' get that. [14:37] ramana: the best we'll get is another lib. [14:37] mpoirier, ok [14:37] ramana: hence the next question... [14:38] ramana: is compiling with the linaro toolchain ensure __aeabi_llsr is statically linked ? [14:38] ramana: I'm guessing not. [14:38] aviksil, about the procedure to build the images. [14:38] mpoirier, Now Linaro Toolchain for *what* platform ? [14:38] I have given the build instruction on android-build page :https://android-build.linaro.org/builds/~linaro-android/vexpress-rtsm-ics-gcc46-armlt-stable-open/ [14:38] ramana: android. [14:39] salgado: Do you have time to have a chat about patchwork stuff? [14:39] and given the same link in the howto . Let me know if it is not very intuitive . I can just copy those instructions on the wiki also [14:40] mpoirier, they probably have reasons to build it with whatever toolchain they use - [14:40] mpoirier, and they need to be sure they want to switch toolchains and they are happy with the stability of the toolchain they so get. [14:40] bhoj: but will the steps create img.axf file? [14:40] jamestunnicliffe, sure, let's reuse the infrastructure-team hangout room? [14:40] salgado: Sounds good to me [14:41] ramana: so getting the link command is the very first step - pls confirm. [14:41] mpoirier, yes. [14:41] aviksil, the steps will eventually create boot.tar.bz2,system.tar.bz2 and userdata.tar.bz2 . The boot.tar.bz2 has the img.axf image . [14:41] ramana: ack - I'm on it. [14:41] mpoirier, if they are happy to share that and state whether they are using arm*-ld or arm*-gcc ? [14:41] aviksil, I think I need to add this info in the wiki for people new to our android builds. I will do that. [14:42] bhoj: oh ok [14:42] bhoj: thanks [14:42] aviksil, one more missing things I would add is how to add files into the image. [14:42] ramana: ok, one last clarification: arm*-ld or arm*-gcc ? [14:42] ramana: please expand on that. [14:42] mpoirier, what is the tool they are using ? [14:42] ramana: no clue. [14:42] bhoj: yeah [14:43] mpoirier, In their last link step what is the command line - that's all I want . [14:43] mpoirier, if they are happy sharing that. [14:43] ramana: I don't see a problem with that request. [14:43] mpoirier, email would be good. [14:43] ramana: very well. [14:43] ramana: I'll get back to you. [14:43] mpoirier, these things are better discussed over email than IRC. [14:44] ramana: if long lines are to be shared, I agree. [14:44] ramana: ok, I'll got back to STE now - thanks for your time. [14:45] mpoirier, no problem [14:45] mpoirier, any time. [14:45] hrw: all nodes are affected by the dpkg issue [14:46] ok [14:48] Hi guys, I'm still researching what would be the best way to get lava using the qemu client to run x86 images. It seems that it will be quite hard to use lmc to merge hwpacks and rootfs for x86 target. So, what would be the alternative way to get it working? Any idea? [14:48] abner, anything that has pre-installed ubuntu system on it [14:48] abner, write a script that mixes ubuntu core images with some kernel [14:49] rsalveti: Do we have working X11 drivers for snowball precise armel ? That is, can I test unity etc on snowball precise now, or do we have to wait for the armhf drivers? [14:49] zyga, are you suggesting it as the default implementation for lava or only to solve my issue? [14:50] abner, the latter, I'd like to get pre-installed images from ubuntu daily so that this step would not be needed [14:51] zyga, and you would define a different tag in the lava job that would point to an image instead of packs? [14:51] abner, it's already there [14:51] abner, it was added a few months ago [14:51] alf_, back to mumble? [14:51] zyga, ahhh, what is it name? "image"? [14:51] abner, I think it's image_url or just image [14:52] abner, I don't remember off the top of my head [14:52] zyga, I wonder if the qemu client will understand this tag or will try to create an image with lmc anyway [14:53] abner, I don't remember either, anyway, it would be easy to change that if needed [14:54] zyga, gotcha [14:54] abner, a lot of innovation will come to the dispatcher soon [14:54] abner, :) [14:55] zyga, do you know if the linaro image tools libraries provides methods to help this image creation? [14:55] abner, to combine rootfs and hwpack-like thing? yes [14:55] zyga, do you have a list of these innovations? [14:55] abner, linaro-image-tools has a nice library of well-tested functions you can call [14:55] zyga, yeah, I'm wonder if I could use it to generate my script [14:56] abner, it's still shaping but the few things I'm sure about are: cloud support built into all of lava and general re-design of the dispatcher into a small and stable core [14:56] abner, I'm sure it's a good starting point [14:58] jcrigby: good day [14:58] jcrigby: ping [14:58] zyga, hmm.. cloud... [14:58] :) [14:59] abner, you can easily run lots of dispatchers and they will distribute the workload to worker nodes that can be deployed into a cloud [14:59] zyga, looks nice [15:28] tgall_foo: have you ever used multistrap feature? [15:28] fabo: yes. [15:28] in our images? [15:28] yes [15:29] which one is using it, I'd like to take a look [15:29] rsalveti: i've just been talking to tixy about the gator topic branch and it seems there's some confusion (from my end) about what you want and so on, do you have time for a quick mumble with me & tixy? [15:30] fabo: here's the wiki page on that - https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/LiveBuild [15:30] speaking of which I should update that [15:31] * tgall_foo updated that page so it doesn't point at my ppa, but instead the linaro-maintainers/tools one [15:31] ryanharkin: sure, 1 sec [15:32] tgall_foo: when do you plan to push your live-build to offspring? [15:33] fabo: that's more up to infra folks, they have a private ppa that they pull tools out of. really can happen anytime [15:35] tgall_foo: oki, thks [15:36] danilos: Could you check http://lists.linaro.org/mailman/admin/linaro-infrastructure-errors for stuck mails and whitelist the new sender? [15:37] danilos, ^^^ any thoughts ? [15:37] pfalcon, done that just now [15:37] danilos: thanks! [15:43] tgall_foo, I am not sure how we generally do that, please file a request (a bug will do) under linaro-offspring project in LP if you want it done sooner rather than later [15:45] danilos, np ? it's actually really easy to do :-) (the upgrade ?. and the bug too) [15:45] tgall_foo, I assume it's just copying packages, but I am in the middle of something and I am sure everybody else is too :) you may try pfalcon or jamestunnicliffe if they are available though [15:46] yeah.. np [15:49] npitre: hi there, glad you got unblocked with the coherency issues. How was this solved? [16:02] npitre: forget that, I wasn't looking at the right mail folder :) === plars_ is now known as plars [16:02] npitre: Great news that you have it working [16:03] andrey_konovalov: all in all i am impressed by the updated omap4 SGX drivers https://twitter.com/#!/xranby/status/180320678002692096/photo/1/large [16:03] alf_: I believe we'd need to wait for the armhf driver, as the problem with precise is that it's now using a newer ABI [16:03] rsalveti: ok, thanks [16:03] hm, but it might work, as the xdriver itself is open source [16:03] alf_: so recompiling the xorg driver from oneiric, and using the mali drivers from oneiric might work [16:03] if you want to try [16:03] alf_: do you have a snowball to test? [16:04] alf_: https://launchpad.net/~igloocommunity-maintainers/+archive/snowball [16:06] rsalveti: thanks, if I have some free time (not very likely ;)) I might go this route [16:06] alf_: yeah [16:09] zyga: Are the people who have login permissions to v.l.o guaranteed to be affiliated with linaro? [16:09] plars: ^ [16:10] alf_, we're cutting down on that list, I think the answer is true [16:10] well... [16:10] not exactly [16:10] if you mean logging into the webapp [16:10] anyone can do that, with a launchpad id [16:10] but [16:10] there's a group we can use now [16:10] alf_, do you mean ssh or web access [16:11] alf_, I was only talking about ssh access [16:11] alf_, zyga: there is now a "linaro" group that directly maps to people who are in linaro (based on launchpad team membership) [16:12] zyga: web access, I am trying to find out if I can use web app login credentials to decide what kind of information to display [16:13] zyga: in the gfx dashboard [16:13] alf_, then the answer is no (anyone has access) [16:13] alf_, but you can you launchpad group membership if you want to [16:13] alf_, you're desigining it wrong in a way [16:13] alf_, just add a permission to your app [16:13] alf_, check django docs how to do that, it's trivial [16:13] alf_, then you can display stuff conditionally [16:14] zyga: do you have a simple example of this that you can point alf_ towards? [16:14] zyga: ok, but how/when will the permission be mapped to people? [16:14] plars, yes, in a sec [16:14] zyga: it might be useful to add something like this in the demo example [16:14] zyga: I have an example you sent me some time ago [16:14] alf_, you will check if user has permission do do something, we'll add that permission to a group that comes from launchpad, problem solved [16:15] alf_, I'll give to all the pointers again [16:16] alf_, this is how you check and use permissions: https://docs.djangoproject.com/en/1.3/topics/auth/#id8 [16:18] alf_, this is how you declare them: https://docs.djangoproject.com/en/1.3/topics/auth/#custom-permissions [16:19] zyga: it almost had me wondering if we needed a global permission for viewing linaro-only things [16:20] zyga: Would it make more sense to initially have a global "linaro" permission that all apps can use. It seems like an overkill to have such a fine grained permission system, at least until there is a real need for it. [16:20] zyga: but I think that it's actually better to handle it on a per-app basis [16:20] plars: lol, same thought :) [16:20] zyga: because apps can always request to be exempted, what do you think? [16:21] plars, ? [16:21] plars, I don't know what you mean [16:21] alf_, permissions are bound to a model [16:21] zyga: is there a way to then take a permission that we had restricted to just linaro group, and give it to everyone regardless of login status so that the app doesn't have to change on the code side? [16:22] plars, _what permission_ [16:22] zyga: the custom permission the app uses to restrict access to certain data [16:22] hrw: the kernel package cross-compile is still failing at building perf [16:22] plars, any app can have many of those [16:22] plars, the granularity is there for a reason [16:23] zyga: that's what I'm saying, I think it makes sense to have that granularity rather than have a global one for the data policy stuff [16:23] zyga: but [16:23] zyga: what I'm wondering is... say an app is restricted by default at first [16:23] plars, there is no way go have global permissions anyway [16:23] plars, wait [16:23] plars, stop [16:23] zyga: then requests an "exemption" from the data policy - and is approved [16:23] ok [16:23] zyga: hammertime [16:23] heh [16:23] suihkulokki: which one you tried? [16:23] plars, what happens is: alf_ has an app, his app has a permission, say, "can view secret stuff", without it most of his views just say "sorry" [16:24] plars, then we grant that permission to linaro group [16:24] plars, then another app comes along [16:24] plars, with another set of permissions [16:24] plars, we also map those that we see fit to the linaro group [16:24] plars, that's how it works [16:24] zyga: another set of permissions for the exact same purpose, but yeah [16:24] zyga: but [16:24] plars, no [16:24] hrw: the stock ubuntu kernel package [16:24] plars, "linaro only" is not a permission [16:24] zyga: yes, I know that [16:25] zyga: but "can view linaro private" is... [16:25] zyga: but couldn't the permission go in the model for lava-server? and another app could check that the user has that permission? [16:25] zyga: or are the permission checking restricted to the app it was defined in the model for? [16:25] suihkulokki: ok, will check [16:25] I don't see why it would be [16:25] plars, I don't think that's a good idea, if anything I'd like to create lava-linaro that may have such special cases for us [16:25] zyga: but anyway, that's not even what I'm asking [16:25] zyga: I'm agreeing with you [16:26] zyga: the question I'm trying to get to is this [16:26] plars, but still I think it would be bad, it's not hard to grant permissions and we don't have that many "linaro only" apps yet [16:26] zyga: if one of those apps gets an exception, basically saying "yes, we know we would normally restrict this, but we think it's ok to make this view public" [16:26] zyga: can that be done with just a permissions change in django admin, or does someone actually need to go remove the permissions checking from the view? [16:27] plars, that depends [16:27] plars, on how it is coded [16:27] plars, sadly django permission system is limited: it has two argments, not three: (it has user + permission, it should have user + action + target) [16:28] zyga: right, so you end up having to make per-action permissions [16:28] zyga: but I don't think that helps [16:28] plars, you always have to do that, what sucks about django is that you cannot vary permission per objeect [16:28] plars, (at least not yet) [16:29] plars, to answer your question: maybe one could do that with just admin permission changes but without more context I cannot be sure or explain how to code such a view properly [16:29] zyga: so how could an app be coded such that it either checks the permission, or allows it publicly depending on some setting? [16:30] zyga: I'm not sure how much more context I can provide here, I thought the example was pretty specific [16:30] I could be more detailed perhaps [16:30] hrw: hmm apparently bombs while doing man pages of perf, so this might be a packaging issue [16:30] but it's not something that's happened yet [16:31] plars: I've updated the wiki with the hwpack/rootfs info for the val lab [16:31] plars, well if that's what you want you just code it directly [16:31] plars, but I think that global settings are not what you really want [16:31] suihkulokki: started build [16:31] plars: I think we can get rid of the serial number column. We don't track those any more [16:31] zyga: but lets say, for instance, andy's view and alf's view both go in, and both have to check permissions, and both the permissions they check are assigned only (for now) to the linaro group [16:31] suihkulokki: 3.2.0-18.29? [16:31] zyga: then let's say Andy gets permission for his views to be public [16:32] zyga: there's no "public" group to assign the permission to [16:32] zyga: so then do we have to change the code to get it unrestricted? or is there a better way that we can just do a config change somewhere? [16:32] hrw: yeah [16:32] plars, if his views had a permission that could be granted [16:32] plars, I think there might be a way to grant that to everyone [16:32] plars, but I have not tried that yet [16:32] I know it's academic, but the request was made for this, and I want to make sure my assumptions are valid before responding to it again [16:33] agreen-away: please add a [16:33] agreen-away: please add a #ifdef around the panda camera init......... [16:33] zyga: everyone, regardless of login status? Even non-loggedin users? [16:33] plars, yes, not logged in users are mapped to special AnonymousUser [16:33] fabo ping [16:34] zyga: ah, I see [16:34] didn't realize that [16:34] fabo: As I said to plars above: I've updated the wiki with the hwpack/rootfs info for the val lab. I think we can get rid of the serial number column. We don't track those any more. Also, I've done it on a per board basis because we're in a baseline transition phase, so not every board is the same [16:35] plars, we'd need some generic piece installed first [16:35] plars, but then we could grant any permission to anonymous users [16:36] zyga: what do you mean by "some generic piece"? [16:36] davepigott: did you schedule a LAVA job on vexpress? [16:36] ryanharkin: Just about to do that very thing. Get out of my head you. :D [16:36] davepigott: lol :) [16:38] plars, something that would allow us to grant permissions there, there needs to be a model to remember that and a method that implements has_perm() [16:39] davepigott: ok [16:39] zyga: we would need to implement that in the view to restrict access in the first place though right? so it would already exist [16:39] the has_perm() check that is [16:40] plars, yes [16:40] plars, so two pieces needed: [16:40] plars, each app still needs to handle permissions [16:41] plars, and if we really want to, we can implement a module that would allow us to grant permissions to anonymous users (I have not checked, maybe someone already wrote something like that) [16:41] plars: Where's the official place for device-types on control? I need to modify some devices and types files [16:41] plars, and we still may have issues [16:41] plars, with per-object permissions [16:41] davepigott, I guess in the production instance [16:41] suihkulokki: http://pastebin.com/m53yD0Yf was what you got? [16:41] davepigott, we should store our config somewhere I think [16:42] suihkulokki: with this in front: cd /tmp/linux-3.2.0/debian/build/tools/tools/perf && \ make HAVE_CPLUS_DEMANGLE=1 arm-linux-gnueabihf- -j8 [16:43] zyga: Hmmm. But it seems that the only place I can find it is in /etc/xdg [16:44] davepigott, the dispatcher searches all the way up I think, perhaps they were never moved [16:44] zyga: Would it be the ones in /srv/lava/instances/production/lib/python2.7/site-packages/lava_dispatcher/default-config/lava-dispatcher/device-types/ [16:44] ? [16:45] davepigott, no, those are shipped with the source and get changed automatically [16:45] davepigott, /srv/lava/instances/production/etc/ [16:45] davepigott, I don't think dispatcher got all the support pieces needed though [16:45] davepigott, so I may be wrong on our ability to store them there [16:45] zyga: No, it's ok. I found it. Thanks! :) [16:48] zyga: plars: Hmm. When the new dispatcher was rolled out, it doesn't seem to have brought in the new vexpress.conf. [16:48] hrw: I was doing dpkg-buildpackages -aarmel -b -B [16:48] davepigott, was that conf file a part of the source tarball [16:48] davepigott, typically a MANIFEST.in entry is needed [16:49] hrw: if you are calling perf build direcectly, I think you want CROSS_COMPILE=arm-linux-gnueabihf- [16:49] zyga: Ah. OK. Didn't do that bit. That would explain it [16:49] zyga, davepigott: no, manifest should be ok [16:49] suihkulokki: I fixed one bug, other stays [16:49] zyga: OK. It does a recursive include of the conf directory [16:49] plars: so it should be fine [16:50] davelong: it's there, it's called vexpress.conf [16:50] plars: Which directory? I'm not seeing the wood for the trees here [16:51] davepigott: ahh, I see the problem [16:51] davepigott: the vexpress devices are configured as type vexpress-a9 [16:51] not vexpress [16:51] davepigott: and your .conf file was named vexpress [16:51] davepigott: so for now, I think we should just change the vexpress-a9{01,02} to point to vexpress [16:52] plars: OK [16:52] davepigott: if different configs become necessary for vexpress with other core tiles, then we could add those as needed and change the name to specify a9 [16:52] ok? [16:52] davepigott: I can fix that right here if you like [16:52] plars: That's what I was hoping to avoid. Shouldn't need different configs [16:52] davepigott: hopefully not [16:53] plars: OK. I'll change a9[01,02] [16:53] davepigott: ok, go for it [16:53] :) [16:54] suihkulokki: armel or armhf? [16:54] plars, davepigott: if it helps any, the way we use the different platforms (ie A5/A9/A15, ...) should be same, they'll need a different device tree blob setup in UEFI, but the kernel and rootfs is the same too, for example [16:55] ryanharkin: Thanks. I assumed so, which is why I did the generic uefi support [16:55] davepigott: grand [16:55] armhf cross needs another upload [16:55] hrw: armel but is shouldn't make a difference [16:56] suihkulokki: armhf is broken [16:56] hrw: just trying another kernel build with changed rules [16:57] suihkulokki: in 2-binary-arch.mk find HAVE_CPLUS_DEMANGLE=1 and change 'make' to '$(kmake)' and drop CROSS_COMPILE part of it [17:03] suihkulokki: liblzma is not multiarched [17:03] rebuilding kernel [17:04] jamestunnicliffe: around? [17:05] andrey_konovalov: yep. How can I help [17:05] ? [17:07] jamestunnicliffe: this is around bug 944598 and https://ci.linaro.org/jenkins/view/Linux%20Maintainers%20CI%20Builds/job/linux-maintainers-kernel_build-Andrey [17:07] Launchpad bug 944598 in linaro-ci "Setup builds on ci.linaro.org for linux-linaro tree" [High,Triaged] https://launchpad.net/bugs/944598 [17:07] hrw: liblzma5 seems multiarchized to me? [17:08] Hi I'm getting an error with mplayer: relocation error: mplayer: symbol ff_codec_bmp_tags, version LIBAVFORMAT_53 not defined in file libavformat.so.53 with link time reference [17:08] suihkulokki: try to install liblzma-dev [17:08] suihkulokki: unless it is not possible to be multiarched then I am fine [17:10] hrw: seems to install fine for me :) [17:10] jamestunnicliffe: Back in Feb those builds worked ok, but now I am getting "Could not clone http://ci.linaro.org/kernel_git_repo/linux.git". The setup becomes wrong? How could I fix that? [17:10] suihkulokki: armhf and armel conflicted here [17:10] on amd64 [17:11] hrw: right, it's not Multi-Arch: same [17:12] so one can only have only one liblzma-dev installed at the time - but the .so file and .a are already in the multi-arch directory [17:12] andrey_konovalov: Have you tried cloning that URL? I just started. Nothing much is happening yet, but the web view shows something. I don't know if that is how a git tree should look though! [17:13] suihkulokki: binutils-dev is required for perf ;( [17:13] andrey_konovalov: I seem to be receiving a steady stream of data... will let it run. [17:14] and binutils-dev:armel requires binutils:armel which kills whole toolchain [17:15] suihkulokki: should we extract libbfd and libopcodes from binutils to separate packages? [17:15] suihkulokki: so binutils-dev will depend on libraries instead of binutils [17:19] hrw: I think the binutils-dev -> binutils dependency is just to ensure both are same versions [17:19] jamestunnicliffe: trying to clone that URL now [17:20] hrw: but I think it is clear it is not the crosstoolchain at the fault, so sorry for disturbing you :) [17:22] suihkulokki: binutils is also due to libs being in binutils package [17:23] andrey_konovalov: it worked for me. Unfortunately I don't have access to ci.linaro.org via SSH, so I can't check for obvious things, like how much disk space it has free. I will email deepti and pfalcon about it. Hopefully one of them can solve it soon. [17:23] doko: what would you say for patch which makes binutils multiarched? libs/includes in multiarch directories, libbfd and libopcodes split to separate packages [17:25] jamestunnicliffe: ok, thanks! I am still seeing the "Cloning into linux..." and no more progress (but no errors so far too) [17:26] andrey_konovalov: It took a while (it is 972MB checked out), but did finish for me. [17:26] suihkulokki: dpkg-buildpackage: binary only upload (no source included) [17:26] suihkulokki: one patch to not build tools [17:29] jamestunnicliffe: ok [17:32] suihkulokki: http://pastebin.com/LwtJ6jzm [17:37] ryanharkin: Cross fingers. If you look at http://validation.linaro.org/lava-server/scheduler/job/15647 you'll see a job running on vepress-a901. :) [17:40] davepigott: oooo! excellent! [17:40] ryanharkin: Going offline now for a couple of hours. Will check back later. :) [17:41] davepigott: it says "preparing to deploy on vexpress-a901" [17:41] davepigott: is that OK? [17:41] jamestunnicliffe: and WRT the bug 944598, do you need anything from me to add the vexpress board (as per comment #1)? [17:41] Launchpad bug 944598 in linaro-ci "Setup builds on ci.linaro.org for linux-linaro tree" [High,Triaged] https://launchpad.net/bugs/944598 [17:41] davepigott: couple of hours? it's not THAT quick ;-) [17:42] ryanharkin: Yep. It's fine. Why not vexpress-a901? [17:42] ryanharkin: Unless you're making fun of my typo. :) [17:42] davepigott: i thought you were renaming them to remove the A9 out of the names [17:43] davepigott: but that's grand. Oh, i didn't notice your typo above! drat! [17:43] ryanharkin: The root device-type is vexpress. We're keeping the differentiation for instances, in case people want to know what they're testing on [17:43] hrw: yeah, most people don't want perf when cross-compiling [17:43] davepigott: ok, alle ist clar [17:43] ryanharkin: Our feet are the same. :D [17:44] :) [17:44] ryanharkin: Actually, the gating factor in speed here is how long it takes to get the l-m-c lock [17:44] ryanharkin: OK. Off line for a while. Later! [17:47] hrw, really no. that would imply that these libraries do have a stable interface, which they don't [17:49] doko: ok, just trying to find a way to install binutils-dev:armel on amd64 system [17:50] anyway I will wait what #ubuntu-kernel devs will tell about patch. [17:51] have a nice rest of day === pcpa__ is now known as pcpa_ [18:02] suihkulokki: hi [18:03] suihkulokki: how are things going with having a nano image + big.LITTLE under fast models? [18:19] * zyga had a unproductive day after last working night [18:19] zyga: doh [18:30] zyga: what happened, you got excited about the celery stuff and stayed up all night? [18:31] hey guys === ofog_ is now known as ofog [19:13] amitk: ogra told me you may answer a question about the signedness of "current_now" in the linux kernel [19:13] kernel seems to accept +/- currents (for charging and discharging) [19:14] while some user apps seem to dislike negative values [19:14] upower uses abs() on current_now, but I want to be sure if it is a kernel or a userspace problem [19:16] how come i dl a kernel tgz from the linaro ppa (kernel that i have running and working), run a config, rebuild debs, install and uboot remains stuck at "booting kernel"? [19:16] Should 12.02 of Ubuntu for Pandaboard support ALSA? [19:16] i.mx53 and natty https://launchpad.net/~linaro-landing-team-freescale/+archive/public/+packages?field.name_filter=&field.status_filter=published&field.series_filter=natty [19:16] i mean, what the hell? [19:29] morning [19:40] forgive me for the spam, folks, it's for a good cause :) [19:55] mwhudson: with LP update, work-item-editor doesn't work anymore [19:55] fabo: oh hm [19:55] fabo: is it obvious why? [19:57] mwhudson: work items have been splitted from the whiteboard [19:57] fabo: oh [19:57] that should be easy to fix [20:03] fabo: fixed in lp:launchpad-gm-scripts === michaelh1|away is now known as michaelh1 [20:09] akgraner: ping [20:11] joey, pong [20:11] hey akgraner have a sec... I need a muse. [20:12] joey - yes :-) [20:12] I'm trying to come up with a good email address to use at Connect where people can report issues like broken hangouts, not enough power strips, wifi isn't working, etc. [20:13] I have an internal list but I don't want to use this [20:13] I want the internal list to be a member of the larger list [20:13] one suggestion which we all don't like is "complaints@linaro.org" [20:13] I thought of help@ [20:13] but it has to be something that screams "just for connect" in my opinion [20:13] and it has to be SHORT [20:14] it'll be printed on the badges [20:14] connect-help@ is good but too long [20:14] nods [20:14] * akgraner thinks [20:14] lc-help is a bit cryptic [20:15] some people think it has to be easily remembered [20:15] yep [20:15] lcis is the right size but hard to remember [20:15] help would be easiest to remember [20:15] help@ rather [20:16] but that's not LC specific [20:16] yeah, I've been leaning towards that. [20:16] I think the onus is on StephenDoel to come up with a good name but since I have to create it I'm trying to do the work for him [20:16] lch - but that wouldn't mean anything - [20:17] it would have people like you, cjohnston for summit, our wifi guys on it, etc [20:17] nods [20:17] plus arwen [20:17] nods [20:18] helpcon ? [20:18] sounds funny [20:18] reporting network issues to a mailing list, very clever [20:18] we'll obviously have the reg desk there if you're totally down [20:19] and people's mobile numbers from there [20:19] akgraner: how about mru@? :-) [20:19] assist@ [20:20] I still like help@ [20:20] joey - what military radar unit? most recently used? [20:20] much regret unable? [20:21] yeah - I like help too :-) [20:21] Must Rile U :-) [20:21] msdw [20:21] my $%^ doesn't work [20:22] lol [20:22] ok let me see if help is available [20:22] bet people would remember that [20:24] it's available so I've created help@ [20:24] :-) [20:32] akgraner: get those? [20:32] yep [20:32] look ok? [20:33] that it does - did you see my reply [20:34] you have to reply-all [20:34] I got it on my home account [20:34] doh [20:34] but not on the help line [20:34] but I got it so it's working :-D [20:34] resent [20:35] I got that one [20:35] thanks [20:36] more spam [20:36] yay [20:36] :-) [20:37] cjohnston, that's just cause you know summit - I mean you are luv'd! [20:37] but the spam always comes from joey [20:38] yep - he has the keys to the kingdom :-) [20:38] last time it was the keys to linkedin [20:39] here that salgado, the spam always comes from me :-D [20:39] salgado goes a good job of spamming too === ofog_ is now known as ofog [20:40] heh, I do my best ;) [20:43] joey: I have a package that has stopped by to visit you guys out in CO.. :-/ I'd be happier if it was visiting me [20:44] your new ipad? [20:46] plars: vexpress failed here: http://validation.linaro.org/lava-server/scheduler/job/15647/log_file#entry4 [20:46] plars: Seems perhaps the 30 second timeout isn't enough for vexpress? [20:48] davepigott: try 1 hour [20:48] that's not a 30 second timeout [20:48] yeah [20:48] joey: not unless you bought me one [20:48] mwhudson: It's a 30 minute timeout? [20:48] davepigott: so it looks like there were some mmc errors, and it timed out after an hour of trying to deploy the image [20:49] looks like an hour [20:49] joey: you don't pay me enough to buy my own [20:49] davepigott: these are pretty disturbing too, I'm not sure it would have worked even if we waited longer: [ 1416.015482] mmcblk0: error -5 transferring data, sector 4327680, nr 8, cmd response 0x900, card status 0xb00 [20:49] davepigott: the timeout isn't in the log anywhere directly i think [20:49] davepigott: it's from this line of code: [20:49] _deploy_tarball_to_board(session, rootfs, '/mnt/root', timeout=3600) [20:50] plars: We always expect mmc errors on vexpress. It's one of the issues that makes it slow. Ryan made some changes that meant that it falls back from block to byte when mmc failures happen. [20:50] mwhudson: if you look at the log entries around it, it's pretty easy to tell... also I think ChiThu did a patch one time that added in the timeout length if you have debug turned on [20:50] plars: yes, but the debug output is too spammy to leave on by default i think [20:51] mwhudson: OK. So I change the code rather than any parameter. But do I do that on the production system? [20:52] davepigott: yeah, but anyway... this was definitely a case where it took > 1 hour to deploy the rootfs image, so it gave up, which is a bit scary since it was just the developer image [20:52] davepigott: blargh [20:52] davepigott: i guess we can make it a device option, or something [20:52] davepigott: no, you can add a timeout to the deployment [20:52] plars: er, i don't think you can for this bit [20:52] davepigott: 2 things... first try it with nano [20:52] (which is probably a bug in the dispatcher) [20:53] plars: I tried that before and it complained. Maybe I had syntax wrong [20:53] mwhudson: really? I thought that was fixed [20:53] plars: the line i pasted earlier was from trunk and looks pretty hard coded to me [20:53] plars: Will switch to nano [20:53] mwhudson: ouch, you are right, there's no timeout parameter there [20:54] mwhudson: iirc, it's because there are so many steps, it's a bit nasty to figure out which one to apply the timeout to [20:54] plars: yeah, that's certainly part of it i guess [20:54] davepigott: it might actually be worth trying it by hand and seeing how long it takes [20:55] davepigott: time wget ... |tar ... on the board [20:55] davepigott: and use the ubuntu-desktop image :) [20:55] if we're talking 1.5 hours, it's not such a big deal [20:55] if we're talking 29 hours... *ouch* [20:55] plars: OK. Will do [20:56] plars: When I timed the wget before I got only 31 minutes, but that was just the wget, not anything else it did [20:56] davepigott: but it's the mmc write that's really slow, especially in this case :) [20:57] plars: mwhudson: I'll switch to nano. See what happens [21:00] davepigott, are you in the lab ? [21:02] ChiThu: No. I'm at home [21:04] davepigott, ok. Can you put the new sdcard for snowball01 tomorrow ? You can reuse the snowball02 sdcard. [21:06] plars: mwhudson: Job resubmitted with nano image [21:06] ChiThu: I'll make sure I do [21:07] plars: mwhudson: Am off to watch some trash TV and sleep. Catch you all tomorrow. [21:07] plars, I took a closer look at the failing LTP test cases on snowball as well as on panda. do you know why they fail ? [21:07] davepigott: thanks Dave :) [21:08] plars, http://validation.linaro.org/lava-server/scheduler/job/15567/log_file [21:08] ChiThu: are the failures unique to snowball? or to all of the arm boards? [21:08] ChiThu: there's a good chance that many of those tests have intel specific assumptions [21:08] ChiThu: also, at some point we should probably also move up to a newer version of LTP also [21:08] plars, search 'fallocate(5, 0, 49152, 4096)' [21:09] ChiThu: if there are x86-isms, feel free to submit a patch for them upstream to LTP [21:09] plars, fallocate does not seem to be intel specific [21:09] no, it shouldn't be [21:09] just saying that there could be some tests that make assumptions that are not valid on arm [21:09] plars, yes, first I have to know why it fails [21:10] ChiThu: ah, I thought you were saying you already investigated [21:10] plars, here is the test case file. http://paste.ubuntu.com/885443/ [21:10] ChiThu: I seem to recall that someone from dsaxena 's team was going to look at them once upon a time [21:11] plars, some tests rapport not implemented as failure. How to handle those tests ? [21:12] ChiThu: you mean they show up as TFAIL but they should actually be TCONF? or similar? [21:12] patch to ltp if that's the case I think, unless they are things that *should* be implmented [21:13] plars, let me show you some example.. [21:13] ChiThu: which one is that? [21:14] plars, LAVA: (stdout) ftruncate04_64 1 TPASS : Test passed. [21:14] LAVA: (stdout) getcontext01 1 TFAIL : getcontext - Sanity test : Fail errno=38 : Function not implemented [21:14] plars, LAVA: (stdout) sysctl04 1 TFAIL : unexpected error - 38 : Function not implemented - expected 20 [21:14] LAVA: (stdout) sysctl04 2 TFAIL : unexpected error - 38 : Function not implemented - expected 20 [21:15] * plars looks at getcontext01.c [21:15] CONFORMING TO [21:15] SUSv2, POSIX.1-2001. POSIX.1-2008 removes the specification of getcon‐ [21:15] text(), citing portability issues, and recommending that applications be [21:15] rewritten to use POSIX threads instead. [21:15] ChiThu: so in this case, it should not fail [21:16] that's getcontext [21:16] plars, ok [21:16] I have to drive home [21:16] back online in a bit [21:17] mwhudson, I sent a MP for scheduler today. [21:18] ChiThu: i saw [21:18] ChiThu: i'll look at it soon [21:19] mwhudson, I have not tested it yet. Would like to know how to deploy it to staging.validation.linaro.org [21:20] ChiThu: we don't really have a good way other than merging it to trunk and releasing it yet [21:20] (we need one though) [21:21] mwhudson, I see. [21:22] ChiThu: can you merge lava-scheduler trunk to your branch? [21:23] ChiThu: at the revision i just committed (r154) [21:23] mwhudson, what ? I did a bzr pull of trunk before I start to modify it. hmmm [21:24] ChiThu: sorry, i left a bit out there :-) [21:24] ChiThu: i'll try updating staging to your branch [21:24] ChiThu: but i want to get the changes i just committed too [21:24] ChiThu: so if you merge trunk into your branch and i deploy that, we can test both [21:25] mwhudson, no problem. I do it now [21:25] ChiThu: thanks [21:27] mwhudson, done [21:28] ChiThu: thanks === chrisccoulson_ is now known as chrisccoulson [22:52] ChiThu: your branch is on staging now [22:53] mwhudson, thanks [22:53] mm, probably time to update the staging db at some point [22:54] ChiThu: http 500 on http://staging.validation.linaro.org/scheduler/job/11946 [22:54] logs.append((match.group(1), line), "action") [22:55] mwhudson, it should be logs.append((match.group(1), line, "action")) [22:55] ChiThu: ok, i'll fix that on the server [22:56] if the latency doesn't make me punch the wall [22:56] mwhudson, same with the next line logs.append((match.group(1), line, "")) [22:56] ok [22:58] ChiThu: http://staging.validation.linaro.org/scheduler/job/11946 seems better now [22:58] ChiThu: i had to fix this too: [22:58] http://staging.validation.linaro.org/scheduler/job/11946 [22:59] no [22:59] for level, msg, _ in job_log_messages: [22:59] levels[level] += 1 [22:59] ^ that [22:59] aha. as I said I have not tested it :-( [23:01] well, now we have :) [23:01] perhaps not the best way of doing it, but it works [23:03] mwhudson, compare with this one. http://validation.linaro.org/lava-server/scheduler/job/11964 [23:05] ChiThu: yeah, i like it I think [23:05] the log levels in the dispatcher could probably be made a bit clearer [23:05] but finding all of the log messages has to be an improvement :-) [23:06] mwhudson, specially if you click on the incomplete job. [23:07] mwhudson, we could skip to next action in full log view, rather than between lava-dispatcher log as today. [23:08] mwhudson, what do you think about that ? section = per action. [23:10] ChiThu: i think maybe the highlighting in your branch is enough, each action should not produce that many messages [23:10] ChiThu: i think maybe the messages are too truncated though [23:10] maybe we could strip the date off too [23:13] mwhudson,please keep the time, the date can be trip. we should allow more than 95 characters per line. [23:13] ChiThu: yes, i meant only the date :) [23:13] having the time is essential [23:14] i think upping 95 to say 120 would be worth it [23:14] mwhudson, fix the lava-dispatcher "[ACTION-B] Command deploy_linaro_android_image is started wit" => "[ACTION-B] deploy_linaro_android_image with " [23:15] ChiThu: yes [23:15] hm, i just made a dispatcher branch, i'll put that in [23:16] can you update the scheduler as we discussed ? [23:16] I can update the dispatcher. [23:16] let's have a look [23:16] editing the files on the server is very annoying [23:17] oh, it is late. I let you update both scheduler and dispatcher :-) [23:17] heh ok [23:17] good night [23:17] mwhudson, bye.