**** BEGIN LOGGING AT Thu Dec 04 02:59:59 2014 Dec 04 03:12:20 DougReeder, post-inst runs after the files are placed in the file as a lump…for anythings you need to d Dec 04 03:12:30 pre-dm cleans up the mess before things are removed. Dec 04 03:12:52 and that folder goes in the top Dec 04 03:15:51 https://github.com/webos-internals/build Dec 04 03:49:36 DougReeder, https://github.com/webos-internals/preware/tree/master/control Dec 04 03:49:39 thats a good example Dec 04 03:58:26 That’s exactly the files I’m looking at, but it’s not clear if or when they get executed. Dec 04 03:59:30 They don’t exist in /usr/palm/applications/org.webosinternals.preware on-device - are they copied elsewhere? Dec 04 04:01:59 Can palm-package include them, or must one use another tool? Dec 04 04:04:16 look in /media/cryptofs/applications Dec 04 04:05:32 they get executed when you install (post-inst) and when you tell Preware to uninstall (perm) Dec 04 04:05:36 pre-rm Dec 04 04:06:23 I use build.git to "build" the package for me Dec 04 04:06:43 its a series of makefiles that allow it to eventually be included in a repo. Dec 04 04:06:57 and all the metadata is there for cataloging. Dec 04 04:10:30 I guess my questions aren’t clear. The file control/postinst exists in the git repository for preware. What has to happen for it to be executed on-device? Dec 04 04:12:16 Preware runs it *after* it does a normal ipkg install. Dec 04 04:12:36 "after you put things where they normally go…do these additional steps" Dec 04 04:13:38 "before you remove the package…do these additional cleanup steps" Dec 04 04:14:24 a good example is things like... Dec 04 04:14:38 drop bear is the normal ssh server on a webOS device. Dec 04 04:14:40 I understand what postinst is *for*, I’m asking *what steps have to happen to get the file in source code to a location where it can be run* Dec 04 04:15:16 since I don't use Palm-pkg I can't answer how that works. Dec 04 04:15:54 but build.git knows how to take the file structure that you see and roll it up into the .ipk format that includes all the bits of the App + the control file. Dec 04 04:16:14 control file(s) Dec 04 04:16:19 Where do I obtain build.git? Dec 04 04:16:49 https://github.com/webos-internals/build Dec 04 04:18:12 create a makefile that follows the format of the apps in there and it will create a .ipk for you. Dec 04 04:18:24 which you can then upload to wherever you will be hosting it. Dec 04 04:19:00 if its a link in a web browser and you download it to the device Preware is associated with .ipk's as the helper app and will install it. Dec 04 04:42:33 So, running luna-send -n 6 luna://com.palm.appinstaller/install on an IPK will *not* run postinst? Only installing with Preware will run the postinst? Dec 04 05:22:05 DougReeder, as far as I know that is the case. Dec 04 05:22:12 now I've not used that method Dec 04 05:22:18 * DougReeder nods Dec 04 05:22:28 as I've been solely focused on Preware installs. Dec 04 05:22:45 is this a core OS app or a user app Dec 04 05:22:46 ? Dec 04 05:23:16 It’s Preware itself. Dec 04 05:24:13 Currently, it starts with only one feed: feeds.webos-prots.org/weos-ports/all Dec 04 05:24:56 In the source code is control/postinst, which appears to set up all the usual feeds Dec 04 05:26:00 There’s a commit to Preware on webos-internals which we don’t have, which updates the standard feeds to access preware.net instead of preware.org Dec 04 05:26:13 … which we should pull in any case Dec 04 05:28:18 okay…so you want to add MORE feeds? Dec 04 05:28:56 I'm pretty sure WOSQI can properly install Preware…and he upgraded it recently Dec 04 05:29:23 and if you have an old version it will happily install a new one over itself. Dec 04 05:31:00 so anything we are doing now would go in Alpha feeds and Garfonso has been doing upgrades there. Dec 04 05:31:36 we can get a PR issued agains't alpha Dec 04 05:50:28 Garfonso, I attempted a git merge of Preware with the latest revision at webos-internals, the results are at https://gist.github.com/DougReeder/89fffb2256fdf769b434 Dec 04 05:52:33 The files deleted in our fork appear to be unnecessary to us, and the changes to appinfo can be resolved. Fortunately, the changes to control/postinst merged cleanly, and those were the changes we’re really interested in. Dec 04 05:53:07 Shall I submit a PR on that basis? Dec 04 06:02:23 DougReeder: postinst and prerm scripts are specified in the ipk specifications. I'm pretty sure they are always executed. Dec 04 06:03:31 I'm also quite sure that palm-package won't add them. But you can also add them to the archive later. Saw a command for that somewhere. Dec 04 06:04:28 DougReeder: I don't know about this, tbh Dec 04 06:05:12 Better ask morphis. Also I'm still not sure we want to have the whole feeds in there. Dec 04 06:08:25 The Precentral feed would certainly make sense, and possibly optware. Dec 04 06:18:54 Did you try if the optware stuff works or can be installed at all? Dec 04 06:19:46 And Precentral includes a lot of mojo apps which will never work. Dec 04 06:20:42 I don't like the perspective to have these huge feeds of not working apps where everybody has to do trial and error. Dec 04 06:21:02 That is certainly a concern. Dec 04 06:21:22 Right now, we have the opposite problem - nothing to install Dec 04 06:21:24 I'm still in favor for a new feed with apps that work, rudimentary at least. Dec 04 06:21:54 That’s certainly a possibility. Dec 04 06:22:12 But everybody can add the feed and try, if he feels like it. :) Dec 04 06:26:13 morning: We can also extend the packaging standard so we can see which apps are LuneOS compatible, made a first draft of 2.6 here: http://www.webos-internals.org/wiki/Packaging_Standards Dec 04 06:26:19 Needs some work I'm sure Dec 04 06:27:27 Added DevelopmentFramework (Draft) , MinLuneOSVersion (Draft) , MaxLuneOSVersion (Draft) and LuneOSCompatible (Draft) Dec 04 06:28:03 Quite sure DevelopmentFramework would be good to add, have doubts about min and max LuneOSVersion Dec 04 06:28:25 LuneOSCompatible is good to have as well but not sure what the values would be Dec 04 06:34:27 I presume MaxLuneOSVersion is mainly for packages that depend on the older version of some breaking change. Dec 04 06:38:38 Yeah Dec 04 06:39:01 It's just a draft and Preware changes would need to be made to Preware 1 and 2 to accommodate this Dec 04 06:39:40 In place of Develpment Framework, I’d have a Prerequisites. At present the two values would be Mojo and Enyo1 (i.e. that framework must be presinstalled on the device). Dec 04 06:40:08 We'd also need to go through the 600 or so existing apps to add these flags and figure out how to add them to the Precentral feed for app authors for example. ka6sox would send me something for that Dec 04 06:40:11 I’m not sure where PDK apps fit in. Do they run under LuneOS? Dec 04 06:40:23 DougReeder: They don't hence I specified them seperately Dec 04 06:40:37 I'm not sure if we only have mojo pdk apps or also enyo ones tbh Dec 04 06:40:57 And we have the non-js ones of course (mainly games) Dec 04 06:41:16 Probably the best way to treat the PreCentral feed is to mark everything as requiring Mojo, and have authors of non-Mojo apps update their listing. Dec 04 06:41:55 If the author isn’t around to update the listing, it’s probably Mojo. :-S Dec 04 06:43:01 Yes, PDK would also make sense as a Prerequisite, meaning “requires support for PDK apps” Might need to diviy that by processor. Dec 04 06:43:37 … though there are different feed for different architectures Dec 04 06:45:10 IIRC, there are no “pure” PDK apps, so there has to be some JS to jumpstart the PDK. Dec 04 06:47:49 MinLuneOSVersion is probably superfluous - a MinWebOS Version of 3.5 or higher should do. Dec 04 06:48:10 And likewise MaxLuneOSVersion. Dec 04 06:50:21 Optware Bootstrap does an endless cyclo on my TP, epeatedly announcing it’s installed. Dec 04 06:53:06 We might get by without any changes to the ipkg standard. Mark existing apps as havign a MaxWebOSVersio of 3.0.5, and if/when they’re updated for LuneOS, change MaxWebOSVersion. Dec 04 06:55:19 DougReeder: Yes currently MaxWebOSVersion would allow x.x.x format Dec 04 06:56:12 But LuneOS uses the coffee names, but since it's alphabetically ordered we could re-use the Min/MaxWebOSVersion for it and just modify the Preware code a bit Dec 04 06:56:15 Herrie, we need to get with morphis to talk about a numbering scheme that would accommodate this. Dec 04 06:56:27 ka6sox: Yes Dec 04 06:57:07 But having the coffee names isn't necessarily a problem since they're in alphabetical order so you can still check if it's < = > quit easily Dec 04 06:58:06 ka6sox: Can you send me across that scraper file we talked about y'day? Dec 04 06:58:33 I think we should make use of the webOS version numbering scheme - just stick with 3.5.0 until we go beta, at least. Dec 04 06:58:47 DougReeder: I could download the 600 or so IPK's from Precentral feed and check them one by one. If I check 20 a day it would take me a month to identify them ;) Dec 04 06:59:13 That’s certainly doable. Dec 04 06:59:40 It's a 1 time effort and we then just have to make sure that the newly submitted apps have the flags already available Dec 04 07:00:26 I think having the DevelopmentFramework or whatever we'll call it would be good, just for easy identification Dec 04 07:01:33 looks like the scraper is python Dec 04 07:01:41 So when we have 10 Enyo apps that don't work now on LuneOS we could easily revisit those in the future for testing when some "stuff" has been implemented/fixed Dec 04 07:01:49 ka6sox: I can read that as well I guess Dec 04 07:01:58 Just need to understand what it does :P Dec 04 07:02:25 If we need changes I'm sure I can figure it out or ask morphis/JaMa or whoever else is good with python ;) Dec 04 07:02:56 why would we need changes to the scraper? Dec 04 07:03:23 it only finds what is on precentral's feeds and puts the metadata into Preware compatible JSON Dec 04 07:03:27 To capture the "new fields" maybe? I haven't seen the scraper code, so I don't know :P Dec 04 07:11:37 Is it possible for Preware under webOS 2.x to detect if Enyo is installed? Dec 04 07:12:37 Enyo 1, that is. Dec 04 07:19:04 You could see if the framework is available in filesystem Dec 04 07:19:29 But not sure you can do that out of the box or you need filemgr service for example Dec 04 07:19:51 Hm.. I don't think Preware really knows about Enyo. Dec 04 07:20:01 Then, specifying an Enyo 1 prerequisite would be helpful there, too. Dec 04 07:20:21 That would be a good thing to point out when asking others to change their data formats. Dec 04 11:51:12 Herrie: to see the luna-next debug output, you need to start it outside of systemd; we don't know why we lose the output with systemd yet Dec 04 11:51:25 Herrie: so you need to systemctl stop luna-next Dec 04 11:51:50 Herrie: and then export all the variables from /etc/luna-next/environment.conf in your shell Dec 04 11:52:08 Herrie: and start "luna-next $LUNA_NEXT_OPTIONS" Dec 04 11:53:05 Herrie: then, you will certainly when to start LunaWebAppManager independantly too, because systemd will have stopped it ; you just have to start it by hand from a shell. Dec 04 11:53:19 s/when/want/ Dec 04 12:56:01 Tofe: ah so that's different then just adding the LUNA_NEXT_DEBUG=1 to environment file and reboot? Dec 04 13:39:36 Herrie|Veer: that flag is already set when build the -dev image Dec 04 13:39:53 Ah ok Dec 04 13:40:08 Herrie|Veer: it *should* output things in the journald, but... it doesn't. Frankly, right now, it's a mystery to me. Dec 04 14:00:22 Minego has a feed for Macaw 2, which runs under LuneOS: http://minego.net/preware/macaw-enyo/ Dec 04 15:57:21 I’m getting build errors after a make update-conffiles && make update: https://gist.github.com/DougReeder/d197e85bf66fb151d9f7 Is this a known problem? Dec 04 15:58:42 DougReeder: which version? testing or stable? Dec 04 15:59:16 I don’t know; I just follow the diretions at http://webos-ports.org/wiki/Build_for_Mako Dec 04 16:00:02 $ export ENV_NAME=testing Dec 04 16:00:11 echo $ENV_NAME returns a blank line Dec 04 16:02:20 Setting that and rerunning bb webos-ports-dev-package get the same error. Dec 04 16:02:51 Does ENV_NAME need to be set before make update and/or make update-conffiles? Dec 04 16:08:35 http://webos-ports.org/wiki/Build_for_Mako Dec 04 16:08:51 it's only used to download Makefile Dec 04 16:09:20 and I don't know if you used testing or not Dec 04 16:09:22 DougReeder feel free to suggest improvements to the instructions Dec 04 16:09:50 I followed them to the T and they worked for me. Dec 04 16:09:53 I believe I would have done “export ENV_NAME=testing” when I set up my build environment. Dec 04 16:10:28 you probably need to call make update again Dec 04 16:10:43 I was able to build without errors yesterday. Today I ran make update-conffiles && make update and now I get those errors. Dec 04 16:10:44 master branch was rebased recently and a0c5ba81f4646e574eb1e436f87bde55da46942c is now only in master-next branch Dec 04 16:11:48 morphis: did you forgot to push something when switching the branch in cc02e26ed3b966e7961c4832a2e9f680e078d910 ? Dec 04 16:49:46 morphis: I've tagged current webOS-ports/master as webOS-ports/master-2014-12-04b and pushed webOS-ports/master-next instead of it to unblock current builds Dec 04 16:49:52 DougReeder: ^ Dec 04 16:50:46 So, I should be able to make update and then bb webos-ports-dev-package ? Dec 04 16:52:01 you don't even need the update Dec 04 17:10:29 Bother, ran out of disk space again (with a 100GB virtual disk!) Dec 04 17:15:55 Building Distros is an intense messy business. Dec 04 17:35:34 It turns out we can set BB_NUMBER_THREADS = "${@oe.utils.cpu_count() * 2}" in local.conf so devs don’t have to set that manually. Dec 04 17:36:10 …but local.conf isn’t directly part of a git repository. Where does it come from? Dec 04 17:40:47 DougReeder: it is part of the git repository Dec 04 17:41:09 DougReeder: and the problem is that different people consider different value to be the optimum for their machine Dec 04 17:41:09 Which one? Dec 04 17:41:21 I definitelly hate cpu_count * 2 for BB threads Dec 04 17:41:33 webos-ports-setup Dec 04 18:33:35 DougReeder: if you have a lot of cores (we have workstations with 24 cores) memory becomes a serious issue with too many threads and can hang your system. Dec 04 18:34:54 disk IO is even worse Dec 04 18:35:06 * DougReeder nods “The default of 1 thread/CPU is good” Dec 04 18:35:27 with 32 cores you can run either 64 disk intensive tasks (like unpacking sstate or do_populate_sysroot) Dec 04 18:35:54 or in the middle of qt* build you can see 64*64 gcc processes Dec 04 18:36:03 which is also a bit too much for 32 core machine :) Dec 04 18:37:28 * JaMa sets -j to cpu_count and BB_NUMBER_THREADS to some smallish number based on IO performance (2 for desktop where I want some response while build is running on background, 8 on server with fast SAS) Dec 04 18:38:15 and because IO doesn't scale with cpu_count I really hate to use cpu_count in BB_NUMBER_THREADS especially when doubled Dec 04 18:39:24 if you really care then you should run OE benchmark on your own machine to find optimum http://wiki.webos-ports.org/wiki/OE_benchmark **** ENDING LOGGING AT Fri Dec 05 02:59:58 2014