**** BEGIN LOGGING AT Tue Nov 06 03:00:00 2018 **** BEGIN LOGGING AT Tue Nov 06 03:26:27 2018 Nov 06 08:19:07 good morning Nov 06 08:34:09 mornin Nov 06 08:44:35 I have a question about native dependencies in event handlers; I have a handler for bb.event.BuildCompleted where I want to rsync some parts of my images; and I use rsync_deploy_dir[depends] += "rsync-native:do_populate_sysroot" which worked in yocto 2.2, but in 2.5.1 it does not do the trick any longer Nov 06 08:44:54 my handler fails saying it can't find rsync Nov 06 08:44:57 what am I missing? Nov 06 09:24:39 Jin^eLD: that will put rsync into the sysroot of the recipe with the DEPENDS. There is now no global native utility sysroot Nov 06 09:25:13 Jin^eLD: you probably need to do the rsync from a task with the right dependencies Nov 06 09:26:53 RP: can I queue a task after "build completed"? Nov 06 09:27:28 basically its something I need to run as late as possible when everything else has been done, so bb.event.BuildCompleted was nice to hook into in terms of timing Nov 06 09:28:43 in 2.2 you guys suggested this route, basically since DEPLOY_DIR_IMAGE is under sstate now and I want to have an incremental history of images I need to rsync them away after each build, that's what this event handler was supposed to be doing Nov 06 09:29:00 Jin^eLD: the event handler is certainly the easiest place to do that but it doesn't get its own sysroot :( Nov 06 09:29:17 Jin^eLD: could you just put a postfunc for each do_deploy task? Nov 06 09:29:48 sounds like a cumbersome workaround... we have a number of different images Nov 06 09:30:03 btw why was sysroot split into sysroot-components? Nov 06 09:30:23 I also figured that binaries are not runnable from there any longer, because their dependncies end up in a different "component" directory Nov 06 09:31:04 Jin^eLD: they're separated to make it easier to build a sysroot per recipe Nov 06 09:32:25 so launching tasks that would get their own sysroot from a handler is not possible, is that right? Nov 06 09:32:32 Jin^eLD: its not that cumbersome in that you'd just have one deploy function which each thing would call so one function should be all that is needed, just means multiple calls rather than one Nov 06 09:32:47 Jin^eLD: correct, you don't launch tasks from event handlers Nov 06 09:32:59 Jin^eLD: world of determinism problems Nov 06 09:34:57 unfortunately we do have different deploy functions, we have some different images and also a package that deployes a genearted configuration with info for live updates and stuff like that, so I'd need to add postfuncs in a number of places Nov 06 09:35:31 at least I now know my options :) thanks RP Nov 06 09:36:31 btw, the only real work around for keeping it in the handler would be to rewrite the rsync functionality in python? Nov 06 09:36:46 or am I thinking in the wrong direction? Nov 06 09:37:26 Jin^eLD: Well, you write some python or make a static binary or have rsync installed externally Nov 06 09:37:46 for some reason it does not find rsync that is installed on the build host, probably PATH gets cleaned up automatically Nov 06 09:37:59 Jin^eLD: you could add it to HOSTTOOLS Nov 06 09:38:24 Jin^eLD: it now just filters the list of things it can see explictly Nov 06 09:38:26 ah! that'd be one way, thanks for the hint, I did not think of it Nov 06 12:50:47 Hi, I want to fetch a package from sources.openembedded.org: http://cgit.openembedded.org/openembedded/tree/recipes/gomunicator/gomunicator_cvs.bb. PV is in format 0.1.3+cvs${SRCDATE}. Nonetheless it's not clear how to fetch it, and I can't for the life of me set up bitbake on this system for oe-classic, so I can't make bitbake build the package and fetch it too. What format does the source archive appear as? Nov 06 12:51:35 I've tried various combinatoins of _cvs.tar.gz and -cvs.tar.gz etc, to no luck. Nov 06 12:52:19 and the actual sources.openembedded.org server doesn't want to list all the packages, nor can I actually fetch the whole server's contents so that I can run a private mirror, which i'd really rather be doing at this point Nov 06 12:52:26 Any ideas? Nov 06 14:20:39 duncan^: its a cvs fetch, so use cvs Nov 06 14:21:11 of course that server is most likely down by now Nov 06 14:21:17 so entirely possible the source is just gone Nov 06 14:21:34 Yup, that's the problem. And I thought snapshots were saved on sources.oe Nov 06 14:21:44 the source is over a decade old Nov 06 14:21:49 It is, yes. Nov 06 14:22:01 so the chances are it won't even build, and if it does it uses apis which are long deprecated Nov 06 14:22:24 I know. I have my own reasons for wanting to build it, though. Nov 06 14:23:44 Is there really no strategy for backing up packages that are fetched only through CVS? Nov 06 14:24:37 remember you're refering to a package that is only in oe-classic so literally nobody has tried to build it forever Nov 06 14:24:50 eight years ago there was a message on the list saying the server is down Nov 06 14:25:18 http://downloads.openmoko.org/developer/sources/cvs/gomunicator/gomunicator/ <-- hooray google Nov 06 14:25:24 for some insane reason, the openmoko server is up still Nov 06 14:25:39 you'll have to recursive wget that as its not a cvs repo Nov 06 14:26:10 wow Nov 06 14:26:22 ah, they do have a snapshot 3 directories up from that Nov 06 14:26:55 Thanks. Nov 06 15:43:28 rburton: OpenMoko will never die :-D Nov 06 15:54:17 someone should archive that content somewhere for when it does go down Nov 06 15:54:28 it bugs me how much old software is literally not available anywhere but someone's hard drive somewhere Nov 06 16:07:00 kergoth: I think we have a whole stuff that angstrom 2012 or so was using mirrored online to be able to build :) have some units in the field that still require it Nov 06 16:07:13 nice Nov 06 16:08:46 if anyone needs the time machine: http://developer.digitalstrom.org/download/oe-sources-mirror-old/ bunch of 2012 tarballs there Nov 06 16:15:28 :) Nov 06 16:46:49 hmm, which package provides native g++ ? Nov 06 16:49:45 there is no gcc-native it seems Nov 06 17:04:48 there isn't one, we use teh host's Nov 06 17:08:49 hmm, its in my HOSTTOOLS, still the package says g++: error: none: No such file or directory, time for some deeper debugging Nov 06 17:09:16 some "gyp" and "npm" stuff whatever that is that the web people want to use now Nov 06 17:11:00 weird Nov 06 17:17:21 it is indeed, because in the devshell g++ is in the hosttools path Nov 06 17:50:08 khem, ping Nov 06 17:53:54 khem, do you seen any down side in trying to add the selftest for OE source mirrors ? OE has its own source mirrors, right? Nov 06 18:53:06 yes sources.oe.org Nov 06 18:53:19 but it does not duplicate the yocto mirror Nov 06 19:50:34 https://apenwarr.ca/log/20181106 is rather interesting Nov 06 21:13:16 kergoth: the log bit is interesting, but i think its fair to say that ninja has won the battle for 'like make but actually fast' :) Nov 06 21:19:13 agreed. i think the only advantage/disadvantage of redo vs ninja is its interesting seemingly unix inspired architecture, but i'm not entirely convinced Nov 06 21:19:22 the log thing was the main thing i found interesting, since we deal with that sort of thing too Nov 06 21:19:38 that loglinear thing alone could be interesting, though buffering until exit is potentially problematic Nov 07 02:16:17 yeah think of building chromium with V=1 and buffer the logs :) Nov 07 02:36:28 ha **** ENDING LOGGING AT Wed Nov 07 02:59:59 2018