**** BEGIN LOGGING AT Thu Oct 03 02:59:58 2013 Oct 03 09:27:11 caldav discovery in owncloud delivers useless stuff... :( Oct 03 09:28:22 Garfonso: that is strange as it works with other caldav clients Oct 03 09:28:32 like the caldav sync connector for android Oct 03 09:28:48 its detects the available calendars and let you select them Oct 03 09:29:36 Garfonso: But it is aligns with what I saw in my testing Oct 03 09:29:44 does discovery really work? At least for the OS X stuff the owncloud manual says to put in the exact paths of calendar / addressbook. Oct 03 09:29:47 hm.. Oct 03 09:29:52 moment Oct 03 09:30:12 firefox can't really tell me anything about the principal, neither. Oct 03 09:30:23 http://dmfs.org/wiki/index.php?title=OwnCloud Oct 03 09:30:39 the URLS stated in the setup with OC 4 and 5 is what I use normally Oct 03 09:31:04 I think it was broken before but it should be fine now Oct 03 09:31:19 either that or the android adapter has some quirk for it Oct 03 09:32:23 so, that's what I mean... discovery should tell the client the urls for calendar and addressbook homes.. :( Oct 03 09:32:27 They use sabredav for all this anyway Oct 03 09:33:46 You mean it should even give out the base url for it? As these urls are not for the concrete user or addressbook Oct 03 09:34:28 Or do you say discovery just just work with the .../owncloud url and username? Oct 03 09:35:24 http://code.google.com/p/sabredav/wiki/ServiceDiscovery Oct 03 09:35:40 Anyone here able to help me with UbuntuTouch? I know it has a channel, but no one's able to help it seems. Oct 03 09:35:55 I get a bit confused here what dav discovery handles vs. DNS SRV records vs. .well-known :) Oct 03 09:36:13 I was trying to follow http://forum.xda-developers.com/showthread.php?t=2426924 earlier but I hit a wall with the partition script Oct 03 09:36:20 my TP is OC'd... would that screw things up? Oct 03 09:36:35 Shiggs|i5-2500k: So you decided to go to some random other mobile os channel and ask there? :) Oct 03 09:36:50 as I said, they're not answering my questions Oct 03 09:37:08 and it's not random Oct 03 09:37:23 yeah, but what makes you think people here in webos-ports would know about your problem with ubuntu phone? Oct 03 09:37:53 stefan_schmidt_w: yeah, this confused me a bit, too.. Oct 03 09:38:06 Garfonso: But it is clear to you now? Oct 03 09:39:59 I'm not getting the DNS stuff.. and I'm not sure how the client would be able to use that anyway... Oct 03 09:40:06 for the .well-known stuff, I can try that. Oct 03 09:41:06 Garfonso: I haven't setup .well-known or SRV records for it either Oct 03 09:41:36 What does the dav discovery expect to get is the question Oct 03 09:44:06 I followed this tutorial: http://code.google.com/p/sabredav/wiki/BuildingACalDAVClient Oct 03 09:44:20 on the bottom there is a part about discovery. Oct 03 09:44:49 funny thing is that this works with egroupware, but not owncloud which is based on sabredav... *confused* Oct 03 09:45:28 haha, nice Oct 03 09:45:32 (ok egroupware has a wrong redirect somewhere, so the base egroupware url won't be sufficient, either, but the base webdav url is working properly) Oct 03 09:45:48 So what not works is the PROPFIND with principal, right? Oct 03 09:46:27 for the current-user-principal I always get "/owncloud/remote.php/webdav/" Oct 03 09:46:28 maybe we need to check which version of sabredav OC is using and check for some bug reports Oct 03 09:46:33 could simply be broken Oct 03 09:47:12 ah, so its the wrong principal for addressbook or calendar Oct 03 09:47:20 which version of OC is that? Oct 03 09:48:20 ownCloud 5.0.7+dfsg-2ubuntu1~ubuntu12.10 (Debian) Oct 03 09:48:29 hmm, ok Oct 03 09:48:56 I have OC 5.0.11 but I think I last tried it with 5.0.10 or 9 Oct 03 09:49:25 but it does not work for either one of us Oct 03 09:52:07 running out of time here Oct 03 09:52:43 need to get back to work and my next days are full with packaging stuff and make it ready to be moved Oct 03 09:53:15 Maybe I have some time to look into this as well at the weekend around the 12th Oct 03 09:53:40 that's fine. Oct 03 09:53:56 I'll fiddle a bit more with it.. maybe I'll find something. Oct 03 09:54:11 it could indeed be a bug in OC and the other clients have a quirk for it Oct 03 09:54:18 but I fixed some issues already and also did a dedicated discovery service endpoint ;) Oct 03 09:54:27 cool Oct 03 09:54:52 Just keep in mind to keep the PRs small so I can be faster iin reviewing and merging them :) Oct 03 09:55:10 Quicker positive feedback loop :) Oct 03 09:56:04 yes, I'll try. ;) Oct 03 09:56:26 :) Oct 03 09:56:38 always in a big coding flow :) Oct 03 14:02:45 morning Oct 03 14:04:07 morning Oct 03 14:18:28 Tofe|Away: ping Oct 03 15:40:50 Garfonso: ping Oct 03 16:29:44 morphis: pong Oct 03 16:30:13 Garfonso: I have one question about the new preware Oct 03 16:30:34 does it currently check for a available internet connection before starting to update the feeds? Oct 03 16:31:25 yes Oct 03 16:32:35 ok, great Oct 03 16:33:56 it checks with palm://com.palm.connectionmanager/getstatus Oct 03 16:34:00 ok Oct 03 16:34:03 as it should Oct 03 16:36:37 ups.. currently update feeds is disabled.. lalala Oct 03 16:38:52 :) Oct 03 16:39:13 Garfonso: I am currently trying to get everything ready to reenable preware within luna-next again Oct 03 16:39:29 Garfonso: btw. you said you couldn't boot a recent webos image on your gnexus, right? Oct 03 16:40:12 yep, image from 09/21 won't boot. Oct 03 16:40:28 it stays at the google logo for some time, then vibrates and boots android. Oct 03 16:41:25 you followed the instructions in the wiki, right? Oct 03 16:41:33 Garfonso: btw. you can try it in Virtualbox too Oct 03 16:41:47 btw: preware is still lacking feed management. And probably not all the options are working correctly. (and the options UI is very ugly ;)) Oct 03 16:41:59 those: http://webos-ports.org/wiki/Testing_Gnex Oct 03 16:42:26 adb never saw the device after the fastboot step Oct 03 16:42:34 hm Oct 03 16:42:43 you flashed a recent kernel to the recovery partition? Oct 03 16:43:53 I'm not sure what that means? I download image and kernel from the same date. Is that what you meant? Oct 03 16:44:03 yes Oct 03 16:44:14 and you booted the kernel with fastboot boot ? Oct 03 16:44:33 yes Oct 03 16:45:11 let me check that Oct 03 16:45:15 as it should work Oct 03 16:45:26 and nothing has changed Oct 03 16:45:33 Garfonso: btw. http://webos-ports.org/wiki/Emulator Oct 03 16:45:48 what android version should be on the device? Oct 03 16:48:59 Garfonso: thats irrelavant Oct 03 16:49:10 we're shipping all we need on our own Oct 03 16:49:19 ah, ok Oct 03 16:49:44 what could be the issue, then? Oct 03 16:51:10 let me check that on my own Oct 03 16:51:44 oh, wait. It seems the download of the image got corrupted. Oct 03 16:51:53 it's only ~400 MB Oct 03 16:52:07 oh Oct 03 16:52:11 yeah thats bad Oct 03 16:53:21 sorry for the confusion... stupid browser. ;) Oct 03 16:54:47 np Oct 03 16:55:10 JaMa: I get the errors with docbook-utils-native also with just oe-core Oct 03 16:55:17 JaMa: let me try again within a chroot Oct 03 16:57:59 the same one as pastebin from yesterday, right? Oct 03 16:59:45 ah, another thing: any new plans about the update mechanism? Oct 03 17:08:04 hm.. now my gnex is completely crashed with saying Google on the display but neither reacting to any button presses nor being detected by my PC. Oct 03 17:09:42 whoa.. now it worked. :) Oct 03 17:34:47 Garfonso: great Oct 03 17:36:24 Garfonso: btw. you should retry http://jenkins.nas-admin.org/job/webos-ports_setup_webos-ports-dev-image_maguro/268/ after the build has finished Oct 03 17:41:37 morphis: Garfonso: there could be an issue from staging scripts which aren't finished yet, double check the image you're downloading from this build Oct 03 22:49:48 JaMa: so you're working on staging feeds now? Oct 03 22:57:53 JaMa: ah: http://build.webos-ports.org/webos-ports-staging/ Oct 03 22:58:10 morphis: yes in spare moments Oct 03 22:58:16 :) Oct 03 22:58:29 rsync is now populating "wip" stage Oct 03 22:58:38 wip -> work in progress? Oct 03 22:58:47 yes Oct 03 22:59:10 so we're just doing a build as normal and get a new stage? Oct 03 22:59:24 or it will populate wip and we a new stage manually? Oct 03 23:02:59 it will populate wip only until someone starts separate jenkins jobs to switch to new staging Oct 03 23:03:33 and there will be separate jenkins jobs to merge stages to publid feed Oct 03 23:03:53 ok Oct 03 23:04:34 the tricky part is where to keep "state" as current staging feed number etc Oct 03 23:04:58 but I'll probably keep it on slave Oct 03 23:05:03 once we merge them to the public feed we need to integrate some code to populate the platform manifest database (http://www.webos-ports.org/wiki/System_Upgrade) Oct 03 23:05:37 you mean the latest stage number? Oct 03 23:06:09 yes Oct 03 23:06:22 first I wanted to keep it only on file server side Oct 03 23:06:50 but speaks against this? Oct 03 23:07:06 now I'm inclined to keep it only on jenkins slave and send it over ssh as parameter to stage managing scripts Oct 03 23:09:38 well if I understand System_Upgrade correctly then each staging feed will have own manifest file generated in jenkins builds before they are even rsynced to file server Oct 03 23:10:02 and syncing staging feeds to public, will just overwrite older manifest with newer one Oct 03 23:11:15 there you be only one manifest.json file within http://build.webos-ports.org/webos-ports/ Oct 03 23:11:23 that will list all merged stages Oct 03 23:11:31 with their changes etc Oct 03 23:11:46 we maybe have to port this later to a web service to reduce the file size Oct 03 23:12:15 and we need to include the staging feed number within the generated images Oct 03 23:12:44 and update it with a special package or so Oct 03 23:13:14 you mean that manifest.json accumulates every merged staging feed? Oct 03 23:13:55 having feed number in the generated image breaks the idea of "staging" as it was in SHR Oct 03 23:14:50 because the scripts are just moving images and ipk feeds around to "promote" them as stable Oct 03 23:15:28 we need somehow a number within our images we compare with the number in the manifest to know when we want to update and to show a changelog Oct 03 23:15:33 with feed number in image they would need to let bitbake know the number before image is even created Oct 03 23:15:46 and for example to hold back clients from updating Oct 03 23:15:54 OK, I'll think a bit more about it tomorrow Oct 03 23:16:09 I guess I can use BUILD_ID for that Oct 03 23:16:10 that was the idea but maybe there is a better way if it doesn't suite Oct 03 23:16:21 BUILD_ID is the jenkins build id? Oct 03 23:16:42 no it should be the "staging" number Oct 03 23:16:48 ok Oct 03 23:16:58 because we have multiple builds per one staging feed Oct 03 23:17:11 because of multiple MACHINEs or multiple trials to build it Oct 03 23:18:01 yeah Oct 03 23:18:29 so the last question is if the manifest should grow or be replaced by latest version Oct 03 23:18:52 it should grow Oct 03 23:18:59 I think it should be replaced :) Oct 03 23:19:12 because we can have public with stage 5 Oct 03 23:19:20 so if a client as still version 1 but 2 and 3 got updated the user should still get the list of changes for 2 and 3 and not only for 3 Oct 03 23:19:22 then testing stage 6 and 7 Oct 03 23:19:28 and wip stage (8) Oct 03 23:19:39 any of these feeds should work standalone Oct 03 23:20:01 but 6, 7 and 8 needs to be merged to public anyway, right? Oct 03 23:20:04 even if they fail Oct 03 23:20:27 they need to be merged incrementally one-by-one Oct 03 23:20:29 so once we have a successfull stage 9 we don't merge 6,7 and 8 but then add all to the changelog Oct 03 23:20:47 but still if you as user decide to switch from your stable image with 2 to testing feed 7 Oct 03 23:21:07 thats not supported :) Oct 03 23:21:08 then manifest in feed 7 needs to discover by itself to show diff between 2 and 7 Oct 03 23:21:16 hm Oct 03 23:21:42 my idea was not to have a manifest per staging feed Oct 03 23:21:46 it would work if the manifest grows already on jenkins side Oct 03 23:21:56 but only to add entries to it once a feed gets merged to public Oct 03 23:22:02 or to testing Oct 03 23:22:06 hmm maybe we need to talk a bit more about this Oct 03 23:22:11 for sure Oct 03 23:22:21 how would you test some staging feed? Oct 03 23:22:21 but if things are rolling we can test several things Oct 03 23:22:33 with SHR you just updated opkg feeds to new URL Oct 03 23:22:42 hm Oct 03 23:23:02 JaMa: btw. docbook-utils-native built fine within 12.04 chroot Oct 03 23:23:03 or set opkg feeds to track always the latest "closed" feed Oct 03 23:23:19 so you mean we just need one manifest per feed? Oct 03 23:23:23 morphis: interesting, so it was failing only with 12.10/13.04? Oct 03 23:23:38 13.04 is what I have installed here Oct 03 23:23:49 but can test it later in 13.04 chroot too Oct 03 23:23:50 one "complete" manifest per feed, yes Oct 03 23:24:02 and how would you manage the changelog? Oct 03 23:24:22 so if you merge 6, 7 and 8 how do we get all changes together? Oct 03 23:24:22 I've 12.10 chroot, but doing webos-ports builds only in gentoo chroot Oct 03 23:24:27 ubuntu is for work builds :) Oct 03 23:24:53 :) Oct 03 23:24:56 you replace manifest from 6 with manifest from 7 which contains the same + new changes from 7 Oct 03 23:25:13 hm Oct 03 23:25:18 ok, lets try this way Oct 03 23:25:23 I need to get some sleep Oct 03 23:25:30 lets continue to talk about this tomorrow Oct 03 23:25:31 gn8 Oct 03 23:25:40 so when client with 3 reads manifest from 9 then it will find out that 3-9 are news Oct 03 23:26:06 and different client with 5 can read the same manifest from testing 9 and show diff only between 5 and 9 Oct 03 23:26:54 only tricky part is to keep manifest up-to-date on jenkins side, could be part of webos-setup-scripts repo or something like that, depending on how we'll generate that and where Oct 03 23:27:08 gn8 **** ENDING LOGGING AT Fri Oct 04 02:59:58 2013