**** BEGIN LOGGING AT Thu Sep 15 02:59:58 2016 Sep 15 07:33:03 good morning Sep 15 08:56:13 hello guys, some question: lets say i have 4 targets (machines) in conf/, few tasks for building artifacts in classes/, and while executing bitbake my-image I want to build 4 targets at once. how can I achieve that? thanks for any tips Sep 15 09:55:13 sla: you can't, but you can concatenate bitbake commands using && Sep 15 09:55:52 sla: and specifying MACHINE=xxx on the commandline before each bitbake Sep 15 11:50:45 I have a recipe which adds a new user via useradd but another recipe which depends on it fails because the user does not exist, when I go to the target sysroot I can't find the user in /etc/passwd. Can something overwrite the file in the sysroot (I don't do it intentionally)? Sep 15 12:26:11 armpit: had a look at the Xorg failure on your krogoth-next nightly-musl: khem fixed this in master , oe-core rev e279c9a30f Sep 15 12:36:23 aratiu: can you share the recipe? Sep 15 13:09:31 Hi Sep 15 13:10:04 has anyone seen this waring when building pulseaudio? 'WARNING: /home/josealar/poky/meta/recipes-multimedia/pulseaudio/pulseaudio_8.0.bb: Getting checksum for pulseaudio SRC_URI entry : file not found except in DL_DIR' Sep 15 13:10:40 (krogoth branch) Sep 15 13:11:22 I don't know how to debug what is the file that is not found... Sep 15 13:12:42 well, is there a SRC_URI entry that doesn't exist alongside the recipe Sep 15 13:13:30 no, all are there Sep 15 13:14:05 then do you have a layer that appends pulseaudio? Sep 15 13:14:47 (bitbake pulseaudio -e | less and search for SRC_URI to check) Sep 15 13:15:13 huh Sep 15 13:15:30 thanks Sep 15 13:15:30 the message is "Getting checksum for %s SRC_URI entry %s: file not found except in DL_DIR" Sep 15 13:15:43 so the entry is "" Sep 15 13:15:58 bad whitespace causing problems? Sep 15 13:18:56 oh, yes we are appending it in our layer... Sep 15 13:20:11 and we have four SRC_URI entries that don't exist... Sep 15 13:26:09 that was it, thanks rburton! Sep 15 13:26:33 btw when looking into this I found this in the pulseaduio .inc file Sep 15 13:26:36 LIC_FILES_CHKSUM = "file://GPL;md5=4325afd396febcb659c36b49533135d4 \ Sep 15 13:27:04 shouldn't this be LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6 ? Sep 15 13:27:20 no Sep 15 13:27:28 oh Sep 15 13:27:33 that is relative to ${S} and refers to the GPL file in the tarball Sep 15 13:27:41 i see Sep 15 13:27:46 LIC_FILES_CHKSUM is designed to detect license changes *in the source itself* Sep 15 13:27:56 so there's no point to pointing it at a file that isn't in the source Sep 15 13:28:27 makes sense Sep 15 13:28:39 it should be pointing at LICENSE as that is where the terms are, it's a fair assumption that "GPL is going to be the GPL Sep 15 13:28:45 but if LICENSE changes then we need to be warned Sep 15 13:29:37 * rburton adds Sep 15 13:32:08 rburton: thanks for cmake cleanups! Sep 15 13:33:05 JaMa: i hate cmake Sep 15 13:33:19 JaMa: those patches took about a day of fiddling and testing. Sep 15 13:33:29 JaMa: that said, buildstats-diff is AWESOME and now queued for oe-core Sep 15 13:38:10 rburton: that's why there was bugzilla report for that, sorry that in the end it fall on you to handle Sep 15 13:42:16 don't listen to rburton, he loves hacking around buildsystems Sep 15 13:43:15 it doesn't help my case if i say i have the start of a meson recipe does it Sep 15 13:43:55 it absolutely does not Sep 15 13:44:08 in fact I almost asked you how it was going so as to prove the point :-) Sep 15 13:44:43 Hi, is it possible ffmpeg isnt building with mp3 support? I'm having a double free with mpd playing a mp3 stream using ffmpeg Sep 15 13:45:05 and apparently gst-ffmpeg is blacklisted Sep 15 14:30:19 rburton: I'm not convinced about the build-appliance fix btw :/ Sep 15 14:30:43 rburton: its defeating the artefact manifest the deploy_dir changes were meant to help Sep 15 14:31:29 Who would i do an:Ä Sep 15 14:31:31 RDEPENDS_${PN} += Sep 15 14:31:37 but only for certain arches? Sep 15 14:31:52 I.e. I want to add libasan-staticdev Sep 15 14:31:58 but its not there on arm Sep 15 14:39:23 Do i use RDEPENDS_${PN}_append_x86-64 ? Sep 15 14:41:51 alexlarsson: that looks like it would work Sep 15 14:42:39 rburton: cool Sep 15 14:43:08 this whole parsing-variable-names thing scares me to no end Sep 15 14:43:38 Who defines what are valid prefixes? and what about ordering, conflicts, etc Sep 15 14:43:44 * alexlarsson shudders Sep 15 14:45:00 mwhahaha Sep 15 14:45:40 I guess i don't really want to know... Sep 15 14:45:58 what would _x86-64_append do? Sep 15 14:46:06 nothing Sep 15 14:46:18 ordering is wrong Sep 15 14:46:18 What about a package called "append"? Sep 15 14:46:50 well in this case the logic actually looks for a variable called "RDEPENDS_" + pkg Sep 15 14:47:06 so don't call a package append Sep 15 14:47:37 little bobby drop tables... Sep 15 14:50:08 alexlarsson: yeah… Sep 15 14:51:11 hello , I have a question in Toaster. I used Toaster to make an rpi-hwup-image for raspberrypi 2 , but it didn't generate the sdimg file , does anybody know how to do that using Toaster ? Sep 15 14:53:29 yahya93: you would need to add the image type to the IMAGE_FSTYPES variable. If you are using the master branch, you can do so from toaster. Sep 15 14:55:00 belen: thanks for your answer, but the sdimg is not listed in the IMAGE_FSTYPES Sep 15 14:56:56 yahya93: There use to be bug report/feature request about that Sep 15 14:57:26 yahya93: And you can directly edit the proper file which is using Toaster to add sdimg in it Sep 15 14:58:05 yahya93: present is correct. The bug is fixed, but only in master, not in the last stable release Sep 15 14:58:42 when I creat a new project , I don't find master listed in the options, only Jethro and Krogoth Sep 15 14:59:35 belen: when I creat a new project , I don't find master listed in the options, only Jethro and Krogoth Sep 15 15:00:12 yahya93: yes, that's because you are using the Yocto Project krogoth release. When I say master, I mean the Yocto Project development branch Sep 15 15:02:20 yahya93: a possible workaround is to edit the poky/bitbake/lib/toaster/orm/models.py file. That file contains a list of image types: you can add sdimg to that list, and you will then able to select it from the toaster web ui Sep 15 15:03:10 yahya93: I think the proper name is rpi-sdimg, but I am not 100% sure Sep 15 15:04:59 yahya93: ( http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/toaster/orm/models.py?h=krogoth#n645 ) Sep 15 15:08:08 belen & michaelwl: That was great help! thank you very much Sep 15 15:14:07 yahya93: no worries. Any other questions, let us know Sep 15 17:27:01 kergoth: precisely, yes its for older gcc Sep 15 17:27:35 kergoth: or for arches where libatomic in gcc does not _yet_ support Sep 15 17:28:09 when you go back in versions then the support for atomics came in in pieces Sep 15 17:50:11 Is there an official Yocto project leadership? Or some people working full time on Yocto? kergoth, rburton maybe? Sep 15 17:50:58 Or is there a mail address to send offers for the project? Sep 15 17:57:15 neverpanic, see https://www.yoctoproject.org/about Sep 15 18:02:13 armpit: Thanks, that answers my question Sep 15 18:02:23 np Sep 15 18:19:34 Is someone using Docker to run KVM instances? We use it as a set of our test infrastructure and we are having problems to run multiple docker instances with KVM in parallel Sep 15 18:40:16 Dear all, Sep 15 18:40:25 Please correct me if I'm wrong Sep 15 18:41:06 Is it doable to create my own core-image-XXXXXX image to be layer on top of for example core-image-minimal ? Sep 15 19:04:46 lukma1: you could create a core-image-minimal_%.bbappend and append to vars in there, though I'm not sure that's really recommended practice. Sep 15 19:25:00 lukma1: what do you mean by layer? if you just want to use that as a starting point, your best bet is to just copy it to your own image. and core-image- isn't really appropriate naming anymore in that case Sep 15 19:55:00 you can do that Sep 15 19:55:24 lukma1: easier to just copy core-image-minimal and then modify it as you want Sep 15 20:00:13 just *how* evil is something like this in a recipe : ${B}/*-libtool --mode install install $b ${D}${bindir} Sep 15 20:01:21 should work as long as the shell properly processes the wild card -and- only matches one instance Sep 15 20:01:29 problem is if there are multiple matches it can fail Sep 15 20:01:36 yeah Sep 15 20:01:41 well its out-of-tree autotools Sep 15 20:02:05 and i'm now getting gnu hash errors so obviously i do need to patch this makefile after all Sep 15 20:02:27 BTW I'm trying to avoid producing a backtrace in an event handler in case of a specific failure.. last week RP mentioned that he though it was a simple 'raise' exception (which I'm forgetting which exception) that will cause the system to clean up an exit, but no backtrace.. Sep 15 20:02:39 Anyone know what is needed? Sep 15 20:02:52 (bb.fatal prints an exception, which causes the actual error message to be obscured) Sep 15 20:04:51 started looking at someone elses autotools and now i want to drink Sep 15 20:05:00 conveniently its beerbods night Sep 15 20:05:13 "we don't need automake" Sep 15 20:05:18 fails to pass ldflags Sep 15 20:05:23 missing install targets Sep 15 20:05:40 that is relatively normal.. there is a reason why people use the auto* tools.. Sep 15 20:05:44 even though they do often get in the way Sep 15 20:05:51 fray_: I don't think there's any way to avoid a traceback in all cases fro an event handler, i ran into this too. i was trying to exit out with an error from TaskStarted to prevent the ability to build in a certain case, but no exception really seemed to do the job, given what exceptions were handled where in the code Sep 15 20:06:01 we need to catch more from event.fire() at various places in the code Sep 15 20:06:07 300 line makefile.in, 80% of which is boilerplate that automake does Sep 15 20:06:18 FuncFailed -> traceback, bb.fatal -> traceback.. Sep 15 20:06:20 * kergoth shrugs Sep 15 20:06:48 kergoth that is pretty much what I'm trying to do.. Sep 15 20:07:11 rburton: ugh. reinventing the wheel badly.. Sep 15 20:07:18 I can see the event handler is parsing "SystemExit".. but that doesn't seem like necessarily a good thing to raise Sep 15 20:07:31 fray: also if you use the wrong one from the wrong event, you can end up exiting the main build process without proper cleanup Sep 15 20:07:36 fray: bb.fatal generates SystemExit. Sep 15 20:07:38 exactly Sep 15 20:07:44 Ahh didn't realize it did that.. Sep 15 20:07:45 bb.fatal runs sys.exit which raises SystemExit Sep 15 20:07:49 try: Sep 15 20:07:49 ret = handler(event) Sep 15 20:07:49 except (bb.parse.SkipRecipe, bb.BBHandledException): Sep 15 20:07:58 except SystemExit as exc: Sep 15 20:07:59 ... Sep 15 20:08:08 so I was expecting BBHandledException to "work".. but it doesn Sep 15 20:08:08 't Sep 15 20:08:30 at least, bb.fatal used to. maybe it raises handledexception now, would ahve to double check the code Sep 15 20:08:42 at any rate, sys.exit() raises SystemExit, so you don't usually have to raise it explicitly Sep 15 20:08:59 fatal calls sys.exit(1) Sep 15 20:09:09 ah, okay, figued Sep 15 20:09:52 the problem is, even if the code in bb.event.fire catches errors, prints them,a dn raises handledexception, we'd still need to catch handledexception from every call to event.fire(), which we don't do, afaik Sep 15 20:10:01 need to add try/catch blocks to every fire() call either way Sep 15 20:10:02 ya, I wasn't expecting bb.fatal to produce a trace Sep 15 20:10:14 well, I clearly have the backtrace for the event handler.. ;) Sep 15 20:10:19 :) Sep 15 20:10:37 problem is I don't understand what to do if I do catch the BBHandledException.... Sep 15 20:10:41 we need a test for that apparently, because it sounds like it's regressed... Sep 15 20:10:50 (I'm looking for an example).. Sep 15 20:10:58 fray: i think it depends where the event is fired from Sep 15 20:11:03 I'm also not finding where the backtrace is actually fired Sep 15 20:11:05 i.e. cooker would want to initiate a shutdown Sep 15 20:11:29 seems like the place the backtrace is fired from is where the BBHandledException should be caught Sep 15 20:11:31 whereas a build running a function probably wants a FuncFailed to indicate the function failure to the runqueue Sep 15 20:11:48 so as always with exception handling, the answer is it depends on context :) Sep 15 20:12:00 the comments on BBHandledException is that anything that inherits it has already given the user enough information to fix the problem -- so not to print a backtrace. .:) Sep 15 20:12:04 obviously not working Sep 15 20:12:16 right, but it still has to appropriately handle the failure in some cases Sep 15 20:12:24 otherwise you'd just be ignoring the event handler failure, which is wrong Sep 15 20:12:35 the fact that a message has been printed is great, but we still need to shut down the build Sep 15 20:12:44 so depends on what it means by handled, i guess :) Sep 15 20:13:05 afaik that message usually indicates 'an error has been printed, silently take whatever action is appropriate' Sep 15 20:13:12 erm, s/that message/that exception/ Sep 15 20:14:10 * kergoth isn't a fan of BBHandledException, it was a massively brute force answer, when we should really have handled more on a case by case basis.. but bitbake is huge, so can understand why that route was taken Sep 15 20:14:34 problem is something along the lines broke.. this "used to work" AFAIK.. Sep 15 20:14:58 maybe it still does in some cases, but I can't figure out where the actual backtrace is being dumped.. if I could, I could avoid it in the BBHANdledException, and but still do the rest of whatever the cleanup is Sep 15 20:15:51 last part I get in the backtrace is: Sep 15 20:15:51 File "/home/mhatle/git/oss/oe-core/bitbake/lib/bb/cookerdata.py", line 271, in CookerDataBuilder.parseBaseConfiguration(): Sep 15 20:15:51 Sep 15 20:15:51 > bb.event.fire(bb.event.ConfigParsed(), self.data) Sep 15 20:16:05 so it's one level 'above' that.. whatever caught the fault in the base config processing Sep 15 20:16:50 fire() does result in handlers being run, the only question is whether they run in the server or the ui, afaik Sep 15 20:17:12 would have to double check event.py Sep 15 20:18:12 hmm Sep 15 20:18:56 found the parse block in the parseBaseConfiguration Sep 15 20:19:14 it sure would be nice to break up some of bitbake's functionality to reduce the tight binding between the components and modules. i.e. split out fetch into a separate standalone package or cli tool, make the runqueue generation emit scripts + metadata so you culd use make or ninja to actually run the tasks, etc Sep 15 20:20:18 the three except blocks in the parseBaseConfiguration, all eventually raise bb.BBHandledException Sep 15 20:20:36 so why the hell is it doing a traceback Sep 15 20:21:28 is python itself doing the traceback? Sep 15 20:22:12 I'm not seeing any try / exception blocks around tinfoil and it's BBCooker, which is what eventually runs the parseBaseConfiguration Sep 15 20:23:00 fray: python itself prints tracebacks for uncaught exceptions Sep 15 20:23:16 I'm looking at knotty and such.. and I don't see any BBHandledExceptions code either Sep 15 20:23:27 that's why you get "Traceback (most recent call last):" if you type "cduishciusdh" into the interactive interpreter :P Sep 15 20:25:15 so should hte UI be the one handling the exception to finish the shutdown? (I don't understand this part of bitbake) Sep 15 20:34:19 fray: yes, an uncaught exception gets a traceback, as Ulfalizer says Sep 15 20:34:54 I added a catch in the event fire function, and suddenly the logger went away, so I saw all fo the 'debug' messages.. Sep 15 20:34:56 really odd Sep 15 20:36:08 wait.. no it worked this time.. Sep 15 20:36:12 I must have broken my environment.. :P Sep 15 20:44:32 AH-HA! I figured it out! Sep 15 20:44:47 the block in cookerdata.py was not explicitly handling bb.BBHandledException.. Sep 15 20:45:08 so it was getting caught by the 'except Exception:' block what was doing logger.exception("Error parsing configuration files") Sep 15 20:45:15 and logger.exception was producing a backtrace Sep 15 20:45:27 ah. that explains that one event, anyway :) Sep 15 20:45:36 almost none of the event.fire()s actually catch exceptions of any kind :( Sep 15 20:45:42 after that it worked fine.. I think I have a fairly simple fix Sep 15 20:45:48 nice Sep 15 20:46:18 - except bb.data_smart.ExpansionError as e: Sep 15 20:46:18 + except (bb.data_smart.ExpansionError, bb.BBHandledException) as e: Sep 15 20:46:23 that look 'reasonable'.. Sep 15 20:46:26 logger.error(str(e)) Sep 15 20:46:27 raise bb.BBHandledException Sep 15 20:46:43 (reset of it).. not sure if it makes sense to unconditionally print the 'e'.. since some instances of BBHandledException won't have an 'e' Sep 15 20:47:00 you shouldn't print a BBHandledException at all, by defintiion its error has already been printed Sep 15 20:47:22 ok.. I found some examples where people were doing 'BBHandledException('some message here')' which was confusing me Sep 15 20:47:28 easy enough, the line above: Sep 15 20:47:31 except SyntaxError: Sep 15 20:47:31 raise bb.BBHandledException Sep 15 20:47:37 can just be extneded to include BBHandledException Sep 15 20:47:46 are those really raising BBHandledException, not BBHandledException()? Sep 15 20:47:52 raising an exception class instead of an object is a bit odd Sep 15 20:48:04 thats what it says Sep 15 20:48:26 what I have now: Sep 15 20:48:27 - except SyntaxError: Sep 15 20:48:27 + except (SyntaxError, bb.BBHandledException): Sep 15 20:48:27 raise bb.BBHandledException Sep 15 20:48:27 except bb.data_smart.ExpansionError as e: Sep 15 20:48:27 logger.error(str(e)) Sep 15 20:48:35 that is cookerdata.py BTW Sep 15 20:49:03 raising a new BBHandledException instead of the one we already have is a little odd, though admittedly minor Sep 15 20:49:18 except bb.BBHandledException: raise; might be slightly cleaner, though at the cost of more lines of code Sep 15 20:49:20 debatable. Sep 15 20:49:23 I have to raise instead of letting it fall through.. but ya.. laternative is ... Sep 15 20:49:33 you beat me to it, but I don't see any real advantage in this code.. Sep 15 20:49:52 agreed, particularly since the class isn't carrying any information, it's not even an object half the time Sep 15 20:49:53 :) Sep 15 20:49:53 I don't see any real examples either way in the bitbake code...... Sep 15 20:51:15 I'll send up a change to the bitbake-devel Sep 15 20:54:16 'raise Foo' is the same as 'raise Foo()' if Foo is a class btw. you're only allowed to raise stuff that inherits from BaseException, so raising a class object wouldn't make sense anyway, making it unambiguous. Sep 15 20:54:33 DAMNIT.. I think I just sent crap to the mailing list.. Sep 15 20:54:42 drat Sep 15 20:55:07 fray: git format-patch... --subject-prefix="PATH v2" ... ;) Sep 15 20:55:27 could add a --cover-letter that explains what you changed since v1 too Sep 15 20:55:42 no.. it didn't send the commit ID I pasted.. it sent the commit ids of all of the patches AFTER the one I wanted (which are still in progress) Sep 15 20:55:43 :P Sep 15 20:56:02 at some point the git send-email changed behavior and no longer works like git log, git show, etc.. Sep 15 20:56:16 Ulfalizer: BBHandledException does inherit from BaseException, so really don't see your point there Sep 15 20:56:39 fray: also, bb.fatal() raises BBHandledException in current bitbake, but bb.msg.fatal() does a sys.exit Sep 15 20:56:41 * kergoth rolls eyes Sep 15 20:57:01 kergoth: i meant at the language level. 'raise Foo()' can be shortened to 'raise Foo'. Sep 15 20:57:57 there we go.. the RIGHT patch sent this time Sep 15 20:58:15 Ulfalizer: interesting, didn't realize that. i like the () for consistency, but didn't realize raise would instantiate for us. cool Sep 15 20:58:25 "It must be either a subclass or an instance of BaseException. If it is a class, the exception instance will be obtained when needed by instantiating the class with no arguments." Sep 15 20:58:44 yep Sep 15 20:58:55 ahh.. with that patch, you are right.. bb.fatal works again.. no more backtrace! Sep 15 20:58:58 sweet Sep 15 20:59:41 fray: thanks for the inspiration, i realized i can fix my use case pretty trivially too. i needed to be able to fail from TaskStarted, so just had to move event.fire() into the try/except and add a clause for BBHandledException :) Sep 15 20:59:47 * kergoth will send a patch too Sep 15 21:00:23 I know some of this worked in the past (w/o dumping backtraces) so I'm guessing some code was changed around which triggered the faults (or maybe even python3 differences) Sep 15 21:01:04 clearly missing test cases, as bluelightning pointed out :\ Sep 15 21:02:04 this is an issue, I'm not sure how to implement a test case.. :| Sep 15 21:02:10 that was an unsubtle hint btw ;) Sep 15 21:02:23 pretty easy.. run an event handler, run a bb.fatal(...) inside of it.. but do we have an existing event handler tests? Sep 15 21:02:50 not that I know of Sep 15 21:02:51 (I don't see any, but maybe I'm not looking in the right place) Sep 15 21:03:05 unusually this is one you could probably do in the bitbake tests comfortably Sep 15 21:03:08 so if someone figures out the right way to implement event handler tests, I'm happy to add one Sep 15 21:03:55 I'm honestly now sure how to implement it.. the other tests all run functions inside bitbake.. Sep 15 21:04:02 I don't think that is what we want in this case Sep 15 21:04:26 right, yeah, you won't have access to both sides Sep 15 21:04:34 probably easier as an oe-selftest test then Sep 15 21:04:55 meta/lib/oeqa/selftest/ Sep 15 21:06:00 we'd need a small layer or something to implement the 'fatal' event handler.. again, not sure how to do that in the oe self-tests.. but overall, I think you are right it would be easier in that environment Sep 15 21:06:03 I think Sep 15 21:06:19 meta-selftest exists for that kind of thing (oe-selftest requires it to be in your config when running) Sep 15 21:06:20 problem is you have to cover all the codepaths for event.fire() in bitbake. we cant' fire them ourselves, it's not being cought in the bitbake code that's the problem Sep 15 21:06:33 so i.e. bitbake -p would be insufficient depending on which event handler is fatal'ing Sep 15 21:06:54 I wonder if we should test the runqueue task events, too Sep 15 21:06:56 kergoth, I think (over time) we could built up a reasonable set of event handlers and such to capture many of the cases.. Sep 15 21:07:03 those catch nothing, but any event could error out in the metadata Sep 15 21:07:25 * kergoth tried erroring out from the runqueue task started event which immediately exited the bitbake server process, not pretty :) Sep 15 21:07:26 some events don't make it to the task handlers, that's true Sep 15 21:07:37 er Sep 15 21:07:49 I've only ever done this stuff on events that run on 'early' Sep 15 21:07:52 handlers defined in the metadata, that is Sep 15 21:08:28 "class handlers", that's the term I meant to use Sep 15 21:13:31 * kergoth scratches head Sep 15 21:14:26 if i bb.fatal() in a TaskStarted handler, should I fire TaskFailed? technically the task never ran... though I guess if TaskStarted fired at all, one should fail to ensure the mirrored events line up, even though not all TaskStarted event handlers ran.. Sep 15 21:15:14 i wonder if it should continue to run the other event handlers when one of them fails, and collects the various errors/exceptions and shows them all, otherwise which event handlers run is highly dependent upon event registration order.. though maybe that's okay.. Sep 15 21:16:03 certain parts of bitbake really hurt my head Sep 15 21:18:05 I'm not sure.. and I know eventually if the tasks and the controller are on different machines this is even more complicated Sep 15 21:22:46 among other things, i think we should, one of these days, adopt oe-lite's change which added addtask-style dependencies / ordering control to event handling Sep 15 21:25:05 kergoth, did you see the LAYERRECOMMEND patch that was sent? Sep 15 21:25:22 yep. i'm a fan of the feature, haven't had a chance to review the code, though Sep 15 21:25:28 From the oe-arch conversation nobody really cared, and most were surprised there was auto priority stuff in bitbake -- but I think it should be fine Sep 15 21:25:36 * kergoth nods Sep 15 21:25:49 it's more or less a copy of the existing dependency checking, but stripped of 'errors'.. debugging was added.. and any miss deps are just excluded Sep 15 21:25:55 yeah Sep 15 21:26:03 actually turned out easier then I thought it would be.. Sep 15 21:26:15 for what its worth it has my ack for 2.3, i want to see it merged eventually Sep 15 21:26:17 we're currently working on adding a 'recommends' flag to the layer index as well (for the layerDependency) data structure Sep 15 21:26:22 nice Sep 15 21:27:14 what we want it for is primarily our 'download layers'.. We've got special layers that are just the cached download components for a given layer, like oe-core or meta-oe, or meta-networking, etc.. we'd like those to be 'recommended' depedencies so toaster and others can optionally pull them down from our servers Sep 15 21:27:33 user can basically choose to pull down everything right now -- or not do it and take the download hit 'later' Sep 15 21:27:42 (now also facilitates off-line building) Sep 15 21:29:00 but I expect over time, we can do other recommended layers and filtering w/ bbmask and such if a collection is available or not Sep 15 21:36:36 ah, interesting. hadn't thought about using layers for downloads Sep 15 21:36:53 we do a lot of 'inherit this class only if this layer is available' in our distro Sep 15 21:36:56 (and similar) Sep 15 21:37:26 downloads as layers make it easy to keep pieces 'connected' at least Sep 15 21:37:45 you can also automate this by adjusting the DL_DIR to include the layer name in the generated path.. ;) Sep 15 21:37:50 then do a bitbake -c fetchall universe -k Sep 15 21:38:05 Hey. Trying to add avahi to my image. I added "avahi" to my IMAGE_INSTALL_append list but now I get "avahi not found in the base feeds" when I try to bitbake the image Sep 15 21:38:06 about 90% of the stuff is already in the right place for you at the end Sep 15 21:38:28 avahi definitely builds and I can see the binaries in the work folder Sep 15 21:38:34 avahi is not the anem of a generated package.. you will need to look at the recipe, or the package output and figure out what the name of the -package- produced is Sep 15 21:38:48 recipe and package names are not always the same Sep 15 21:39:34 a1cypher: I think you want avahi-daemon instead Sep 15 21:39:44 a1cypher: http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#viewing-package-information-with-oe-pkgdata-util might be helpful Sep 15 21:39:48 (the 'PACKAGES' variable in the recipes helps determine the names.. and I think he's right.. avahi-daemon is likely what you want) Sep 15 21:40:09 i've updated the DEPENDS and RDEPENDS glossary entries in the 2.2 reference manual to try to clear up recipe vs. package confusion too Sep 15 21:40:16 I think perhaps the issue is the recipe lies and says it produces an ${PN} package, if it didn't do that at least you would get an error earlier Sep 15 21:40:17 if I do bitbake -e avahi | grep ^PACKAGES= I get "PACKAGES="libavahi-gobject avahi-daemon libavahi-common libavahi-core libavahi-client avahi-dnsconfd libavahi-glib libavahi-ui avahi-autoipd avahi-utils avahi-dbg avahi-staticdev avahi-dev avahi-doc avahi-locale avahi" Sep 15 21:40:28 I thought since "avahi" was at the end there that If I chose that one I would get them all Sep 15 21:40:38 bluelightning it is.. certainly one of the complaints I've had from customers.. why is it in the list, if it's not provided Sep 15 21:40:39 :/ Sep 15 21:40:53 a1cypher: right, it claims it will produce that package, it either should produce it or not claim that it does Sep 15 21:41:01 a1cypher that is how a few things were implemented, but not everything.. Sep 15 21:41:15 more of a frustration than an outright bug, but IMO we should correct it Sep 15 21:41:20 ok, so I'll try just including the specific ones that I want and see if that helps Sep 15 21:41:40 might be a cleanup worth exploring in YP 2.3, a test that exposing things not produced, then someone can go in and cleanup the PACKAGES.. (there will always be SOME package entries that are dynamic... but most are not) Sep 15 21:42:18 also the specific error message is like 10 screens of red text with no linebreaks. Sep 15 21:43:07 a1cypher: yuck - can you pastebin that? Sep 15 21:43:15 sure Sep 15 21:44:52 http://pastebin.com/EibjpVP4 Sep 15 21:45:36 I believe you can thank fray for that message ;) Sep 15 21:45:46 I've always thought it was pretty hideous myself Sep 15 21:46:30 confused.. the error you care about is at the very end.. Sep 15 21:46:36 isn't it? Sep 15 21:47:00 ahh no.. it was reorderd.. Sep 15 21:47:03 fray: "not found in the base feeds ()" Sep 15 21:47:04 no idea why Sep 15 21:47:22 should be hte other way around.. the command being run was (long list).. error was (end) Sep 15 21:47:31 I don't know if that is produced in the code or in smart Sep 15 21:47:39 in our code Sep 15 21:47:56 the utility of that list itself is questionable Sep 15 21:48:08 I suspect thiswas introduced in conversation ot the lib.oe version then Sep 15 21:48:39 the lsit is needed.. it's stupid, but the number of questions I get from customers as "Why is XYZ failing, when I didn't ask for it" (when it's explicitly in the list of packages you asked for) Sep 15 21:48:58 so thus, the list of explicitly asked for packages is there... Sep 15 21:49:09 but I agree, ordering is backwards.. Sep 15 21:49:12 error should be last Sep 15 21:49:16 the rest is simply diagnostics Sep 15 21:49:52 fray: maybe i'm blind, but it doesn't seem to explain what that list is either. it just dumps it out. Sep 15 21:50:08 it's a list of everything user asked for Sep 15 21:50:11 that simple Sep 15 21:50:31 don't think that'll be obvious to people Sep 15 21:50:40 last time I made any substantial changes was when this was still shell code.. Sep 15 21:50:45 it used to have text around it to indicate just that Sep 15 21:50:52 a lot of things disappeared when it went to python Sep 15 21:51:23 with that said, I don't know if this is in smart or not.. but I don't rmember it being there.. Sep 15 21:51:39 fray: erm, the list is the list of all packages in the feeds, not the list that the user has requested for the image Sep 15 21:51:57 list is fine, but maybe put some line breaks in there so that its one package per line or something Sep 15 21:52:03 bluelighting, then the list has changed Sep 15 21:52:10 "This is the set of packages that was requested to be installed into the root filesystem. Note that some of these packages might have been pulled in via dependencies between packages even if they were not explicitly requested." Sep 15 21:52:13 it was originally the list of the items the user asked for Sep 15 21:52:18 i'd add something like that. makes it clear. Sep 15 21:52:20 if that's what it is Sep 15 21:52:28 someone needs to check the code Sep 15 21:53:28 bb.note("Installing the following packages: %s" % ' '.join(pkgs)) Sep 15 21:53:33 that is the list I was referring to Sep 15 21:53:38 so it si still in the code Sep 15 21:53:44 that's not the list I'm referring to ;) Sep 15 21:53:58 yes, but that is what should have been printed -before- the error message Sep 15 21:54:07 err_msg += " ".join(self.fullpkglist) Sep 15 21:54:09 (which I suspect it is in the log) Sep 15 21:54:13 that's what makes it excessive Sep 15 21:54:43 make it a '=+' instead and you'd at least get the order right Sep 15 21:55:15 why do we need that list though? especially given it's not the list you're referring to Sep 15 21:55:16 ya.. this is all from the original conversion of the shell code to the python code.. Sep 15 21:55:35 I'm saying there are at least two problems here.. Sep 15 21:55:36 by all means write it to a file so you can look at it, if it helps debugging Sep 15 21:55:41 problem 1.. the error message should be last.. Sep 15 21:55:44 =+ would fix that Sep 15 21:55:51 problem 2... there is too much crap there for most people Sep 15 21:56:20 as long as the error message is last, and some qualification of what that list is.. I don't care either way if it's presented or not.. but as is, nobody knows what the list is anymore Sep 15 21:56:47 problem 3: it ought to to give more details about what that list is, imo. the explicitly requested packages? all packages? what does the thing after the @ refer to? Sep 15 21:57:05 yes.. I consider that part of 2.. Sep 15 21:57:13 the log itself does list what was being attempted.. Sep 15 21:57:29 it's only on error that is generated.. and it should be generated as "available packages" \n "error message" Sep 15 21:57:46 littlery should say something about "available packages" Sep 15 21:58:33 - err_msg += " ".join(self.fullpkglist) Sep 15 21:58:33 + err_msg =+ "List of available packages: " + " ".join(self.fullpkglist) Sep 15 21:58:46 there that would be a reasonable simple change.. Sep 15 21:58:50 if we're making a change, we should drop that list Sep 15 21:59:33 so the question is, do we have a simple way for a user to know what packages are listed in the smart database? if not, we need to dump diagnostics "somewhere" in this type of failure Sep 15 21:59:49 and if it's not in the main log, then at least a message to indicate where it was dumped Sep 15 22:01:58 * Ulfalizer dislikes the term "base feed" Sep 15 22:02:17 I'm not sure what that means either, if anything Sep 15 22:02:35 "'avahi' not found among the packages that were built" seems much more concrete Sep 15 22:02:39 or something like that Sep 15 22:03:14 it could have been built.. and not loaded into the feeds.. Sep 15 22:04:16 - err_msg = '%s not found in the base feeds (%s).\n' % \ Sep 15 22:04:17 + err_msg = '%s not found in the deploy feeds (%s).\n' % \ Sep 15 22:04:18 that better? Sep 15 22:04:29 might be guessable that the package also needs to be copied into some common area after it's built though Sep 15 22:04:35 packages that were built really has no meaning here.. Sep 15 22:04:35 and registered Sep 15 22:04:56 deploy is where the stuff ends up once constructed.. the stuff in deploy is used to generate the feeds Sep 15 22:05:21 i guess i just dislike the term "feed" :P Sep 15 22:05:31 but whatevz Sep 15 22:05:31 me looks at others for that.. Sep 15 22:05:34 feed is not my term Sep 15 22:07:08 I'd call it a package repository myself -- but that is not the OE term for that.. it's a feed.. (and apparently it has been called a feed for a very long time, much longer then the Yocto Project has been around) Sep 15 22:07:10 feed is really the right term here, other issues aside Sep 15 22:07:43 yeah, i'd go for package repository too Sep 15 22:08:02 other option w/ that part of the message, is just say "%s not found in the feeds (%s).\n" Sep 15 22:08:37 originally it was expected that the user could add additional feeds (outside of the build system) for the image install.. but I don't think that was ever implemented nor will it likely be at this point Sep 15 22:08:55 we probably ought to add a hint for the user as to the cause, which is almost always the scenario that prompted this whole thing (recipe claimed to package somehting and didn't) Sep 15 22:09:12 regardless of what the established terminology is, i suspect many of the people that would be helped the most by that message have a very vague idea of what a "feed" is Sep 15 22:10:34 ahh I know why it said 'base' Sep 15 22:10:44 there are two different error message paths: Sep 15 22:11:03 if you select 'lib32-bash', the message is not found in the lib32 feeds (%s)... Sep 15 22:11:07 otherwise it's 'base'.. Sep 15 22:11:16 what else do we call the non-multilib.. thus it was 'base' Sep 15 22:12:07 I'd just say 'lib32 feeds' and 'feeds', and know that the lack of lib32 indicates not lib32, but *shrug* Sep 15 22:13:23 "'%s' not found in the package feeds (found in %s). Make sure that some recipe builds this package." would give a tiny hint at least Sep 15 22:14:41 if references to the manual are okay, there's stuff to link there too Sep 15 22:15:19 kergoth: yeah, that seems better Sep 15 22:15:47 it's not clear what "base" means (obviously, from earlier discussion :P) Sep 15 22:19:21 http://pastebin.com/gCvfakHV Sep 15 22:19:46 Ugh.. no sorry premature pastebin.. ;) Sep 15 22:26:13 there we go... Sep 15 22:26:23 http://pastebin.com/Tqd5wb5U Sep 15 22:26:28 that was what I was trying to paste before Sep 15 22:26:37 order is now more logical Sep 15 22:27:09 and if you look at the logs it all still makes sense.. Sep 15 22:27:33 "'%s' not found in the package feeds (found in %s). Make sure that some recipe builds this package. Note that a package declared in PACKAGES within a recipe will not get built if it turns out empty (unless ALLOW_EMPTY_ = "1" is used)." Sep 15 22:27:50 how about that version? that also explains what the problem might be (if i've understood it correctly). Sep 15 22:35:22 "'ahavi' not found in the package feeds (qemux86 i586 x86 noarch any all - found in /.../tmp/deploy/rpm). Make sure that..." Sep 15 22:35:42 i think that'd help a lot more people diagnose the issue themselves Sep 15 22:38:13 fray: opinions? Sep 15 22:41:01 http://pastebin.com/yG2XWeRM Sep 15 22:41:44 i'd add a "-" before the "in", to make it clear that it's not part of the list Sep 15 22:42:04 and also the rest of the hint :P Sep 15 22:42:17 I'm not sure how i feel about that.. either way Sep 15 22:43:50 http://pastebin.com/KTGX4VkW Sep 15 22:44:43 lgtm (sans hint) Sep 15 22:47:46 there sent to the oe-core list.. Sep 15 22:48:25 ahhh... didn't notice that you added the hint :) Sep 15 22:48:28 sorry Sep 15 22:48:35 maybe it could be on the same line Sep 15 22:48:38 but too late :P Sep 15 22:49:00 it doesn't look good on one line, you end up with the same jumbled mess as the one line list of all packages Sep 15 22:49:23 yeah, it might just be me being blind Sep 15 22:49:29 (not for real) Sep 15 22:50:06 it's hit the list.. feel free to ack it Sep 15 22:50:28 damned thunderstorm keeps knocking me offline for 2-10 minutes at a time.. Sep 15 23:01:13 ha someone asked to have a meeting with me, I said sure.. meeting time comes and all the invite says is "Lets meet".. no dial in info, urls, etc.. ;) Sep 15 23:01:19 "whoops" Sep 15 23:01:39 not sure if the meeting person forgot the info, or if exchange ate it Sep 15 23:01:43 (I really hate exchange) Sep 15 23:03:24 sounds nice depending on the meeting Sep 15 23:22:44 fray: one more unimportant nit that i feel bad for sending a mail for: lines do not to be escaped with \ within (). Sep 15 23:23:16 urr, *newlines Sep 15 23:23:37 I've had hit and miss experiencing not escaping it Sep 15 23:24:28 the rule is that newlines don't terminate python statements within braces Sep 15 23:24:46 outside braces, newlines need to be escaped though Sep 15 23:24:59 thats what I thought, but I've still had parse issues in the past.. to the point where I always just add the escapes.. Sep 15 23:25:04 urr, *brackets :P Sep 15 23:25:05 english fail Sep 15 23:25:13 I knew what you meant.. ;) Sep 15 23:48:15 i am using recipetool to generate bbappend, it always parses the recipe every single time. is there a way to store the parsing of bb file so that the second time it is faster? **** ENDING LOGGING AT Fri Sep 16 02:59:59 2016