**** BEGIN LOGGING AT Mon Feb 04 02:59:57 2019 Feb 04 06:38:39 New news from stackoverflow: How to generate lcov report of a package in yocto Feb 04 07:11:43 I am looking at 3.1.9 in the yocto manual: Appending and Prepending (Override Style Syntax. It says "When you use this syntax, no spaces are inserted.". Why? Is there any reasoning behind this? Feb 04 07:53:36 sven^: it acts as .= in python Feb 04 08:02:36 you mean +=? Yeah, but why? Is there a reason why there is no "remove whitespace", "append with one space in between"? Feb 04 08:02:46 it makes writing recipes so error-prone Feb 04 08:06:44 sven^: no, I mean .= append (without space) Feb 04 08:07:37 yeah, that's += in python. .= is not a python operator Feb 04 08:08:03 anyway, my question is why it's simply appended instead of adding a space if there is none Feb 04 08:38:53 ok, different question: I am trying to add a file containing version information using a bbclass. So I wrote some python code to dump the version information to a file and use d.setVar("FILES_" + PACKAGENAME, ...) to add it to the package's files. I add this function with do_install[postfuncs] += "myfunc" and that part works. But for some reason the change to FILES_${PN} is not por Feb 04 08:38:58 working Feb 04 08:39:44 if I do d.getVar in my python code it shows the correctly altered files-variable. But when I use bitbake -e my entries are missing Feb 04 09:06:18 When a recipe is build, all its packages are built. Is all RDEPENDS for these pacakges always built too, or is that for later when putting together an image? Feb 04 09:07:41 sveinse: AFAIK RDEPENDS are not being built Feb 04 09:08:28 I'm making a packagegroup package (in an existing recipe) for specifying the packages that I'd want built into our package feed, but that won't go into an image. Hence I'm looking for a way to specify this list of packages to build. Feb 04 09:09:42 LetoThe2nd: hmm, I tried running bitbake mypackagegroup, and it did build a new RDEPENDS I added... I think. I need to retest. Feb 04 09:10:24 well you said recipe earlier, not packagegroup. in the latter case i would've answered "no idea", as they behave a bit differently at times. Feb 04 09:11:21 LetoThe2nd: aha, ok, I assumes packagegroup were like any other recipe (forgetting the special nature of some things in bb). Sorry. Feb 04 09:12:42 sveinse: np. in that case, i would suggest ot dig into the task-depends Feb 04 09:25:27 AFAICS it does build RDEPENDS of packagegroup packages -- even if the that package isn't explicitly used by any image or mentioned on bitbake cmd line Feb 04 09:27:14 Interesting... That actually implies I should split my all-in-one packagegroup into multiple severeal, since one might not want to build all of a SDK or development packages when building a small image. Feb 04 10:24:08 what exactly do I have to do to alter tthe FILES_${PN} variable from within a bbclass? I am doing d.appendVar("FILES_" + d.getVar("PN"), "something") in a do_install[postfuncs]. If I look at the variable right afterwards the value is there, but when I do bitbake -e it is not Feb 04 10:24:42 oh, sorry, do_compile[postfuncs] Feb 04 10:35:46 sven I think you should be able to see what alters your FILES_${PN} variable using bitbake -e. Just pipe the output into a text file and search. (wild guess would be that something overrides it) Feb 04 10:36:26 that won't work becayse -e won't execute the compile task Feb 04 10:36:38 if -e executed tasks, it would be compiling stuff.... Feb 04 10:37:12 note that appendVar doesn't add whitespace so you'll need to remember to do that Feb 04 10:41:40 RP: yep, not too bad Feb 04 10:48:41 Is there any tools to generate URLs for target to access package feeds? I mean, looking into tmp/deploy/ipk, there are multiple dirs which should be available for any given MACHINE target. Is there a parseable list I can use to determine the target config? Feb 04 10:51:20 For my imx target, I got at least 4 ipk dirs: all, ${TUNE}, ${TUNE}-${SOC} and ${MACHINE}. Of course I can hardcode these, but I'd rather like to extract them Feb 04 11:14:35 Hi there Feb 04 11:15:09 I created a specific ubi image creation on which the rootfs depends on a data img task Feb 04 11:15:32 The data img name is based on timestamp and the rootfs as well Feb 04 11:16:21 My problem is that if I stop the rootfs final image creation and restart this command, the previously created data image doesn't the same timestamp as the new rootfs image Feb 04 11:17:18 Do you have an idea on how to recreate each time the data img as "PHONY" in Makefile or may be there is a better way ? Feb 04 11:21:24 sveinse: set PACKAGE_FEED_URLS in local.conf to the URL of the http youre running over deploydir and it will set up the package manager for you Feb 04 11:34:02 moritz_: I did that for debugging Feb 04 11:34:16 nothing overwrote it but my class just didn't set the variable Feb 04 11:34:44 or for some reason the newly set variable didn't propagate back to the recipes Feb 04 11:35:06 I finally solved it by setting the variable in python __anonymous () Feb 04 11:35:49 but I still don't get why I need to do that when classes like this: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/update-rc.d.bbclass set it right in a normal function Feb 04 11:35:55 Yes sorry that was a wrong shot by me as rb pointed out already Feb 04 11:36:34 I guess it has something to do with when and how the variable is set and how the setting function is called, but I can't find anything in the manual that explains what's happening Feb 04 11:39:37 New news from stackoverflow: Porting driver from static to dynamic on Yocto Feb 04 11:39:50 -e shows the value after parse, which includes anon py Feb 04 11:40:20 a do_compile[postfunc] is a task that is ran, so anything you in there won't be visible at parse time, or even at any point before the function runs Feb 04 11:48:35 rburton: ok, but it also did not work. I think. For the last 15 "tries" I only used -e to check if it works Feb 04 14:52:01 Hi all, I have a problem with Go and prometheus/node_exporter on Thud, it crashes quite a lot (it wasn't in Sumo). Do you know any issue with Go runtime on x86-64 (meta-intel) arch? (recipe here: https://github.com/nefethael/meta-random/blob/master/recipes-connectivity/prometheus/go-nodeexporter_0.18.0.bb). It also crash with backported go1.11.4 version. I raised an issue on prometheus github Feb 04 14:52:02 https://github.com/prometheus/node_exporter/issues/1244 too. Feb 04 14:59:16 @khem any thoughts? (I saw you worked on meta-influx ^^) Feb 04 15:02:44 I notice that the target package "gcc" installs itself as a cross compiler, e.g. "/usr/bin/arm-oe-linux-gnueabi-gcc", and not as "/usr/bin/gcc". Any particular reason for that? Feb 04 15:03:55 rburton: thanks. That worked perfect. Just have to save the config and remove it from the production image Feb 04 15:05:23 sveinse: look for the gcc-symlinks package Feb 04 15:06:53 RP: the latest patch for py3 is still not 100% right, I'll resend Feb 04 15:07:30 RP: there you go, thanks! Feb 04 15:32:37 kanavin: thanks, fired with the updated version Feb 04 15:34:44 RP: thanks, what is the current plan with the remaining virgl patches? Feb 04 15:36:18 kanavin: waiting on rburton Feb 04 15:41:32 rburton: ^^^ :) Feb 04 15:47:53 sveinse: surely you remove package management from production images anyway Feb 04 15:48:01 kanavin: damnit Feb 04 15:51:17 rburton: We used to, but it is actually going to change. The reason is that it is extremely difficult to add stuff post-release (e.g. for in-production debugging) without a pkg manager. So we did a risk assessment if what shipping with a pkgmanager would entail security wise. The only thing a pkg manager adds to the table is a database of packages with its member files. It doesn't actually change anything Feb 04 15:51:23 on the system, so unless this database is critical, it doesn't hurt having it on board. Feb 04 15:52:10 If hackers want to install something on a system, they don't need a pkg manager to do that Feb 04 16:18:19 sveinse: if they have the privs to install things the pkgmanager won't make much difference Feb 04 16:21:27 RP: they don't have access to the cmd-line, so it would be a breach with or without a pkgmanager. Hence the pkgmanager doesn't add or subtract anything securitywise Feb 04 16:25:50 shipping the pkg manager per se is unproblematic. shipping open ssh ports or comparable stuff is much more Feb 04 16:26:17 (my $.02) Feb 04 16:28:12 hi all. I am wondering why my eventhandler does only get "bb.event.RecipePreFinalise" , see https://pastebin.com/L9pX5tND Feb 04 16:28:22 any idea? Feb 04 16:28:52 i can see do_compile etc.. and expect bb.build.TaskStarted Feb 04 16:29:36 taskstarted and buildstarted are global, so must be registered in the config metadata. so that even thandler has to be in a .inc or a bbclass listed in INHERIT, not in a class inherited yb a recipe Feb 04 16:32:39 kergoth: thank you very much! thats it! Feb 04 17:47:36 is there a special "rev=" syntax for SRC_URI for "latest"? Feb 04 17:47:52 lemme guess? "rev=latest"? Feb 04 17:48:40 why not use SRCREV, which supports that already? Feb 04 17:49:59 yates: you're after AUTOREV Feb 04 17:54:22 ok Feb 04 17:55:07 is it as simple as a) SRCREV = "${AUTOREV}", b) remove rev= from SRC_URI? Feb 04 17:56:50 or would it be (in fell swoop): "SRC_URI = "svn://ebtronwsus/svn/SmartDisplaySoftware;module=${SVNMODULE};protocol=https;rev=${AUTOREV}; ? Feb 04 17:58:04 kanavin: x32 failed in testimage in dnf... Feb 04 17:58:45 see section 4.4 here: https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html Feb 04 17:59:30 I have a recipe that depends on a -native package, but the compile task is running before the -native package has installed. Is that normal? Feb 04 18:07:54 that's not how it works. Feb 04 18:30:14 kergoth: are you responding to me? Feb 04 18:30:21 no Feb 04 18:30:32 ok Feb 04 18:30:36 ERROR: rf-control-1.0-r0 do_packagedata: QA Issue: Package version for package rf-control-dbg went backwards which would break package feeds from (0:1.0-rc2-r0 to 0:1.0-r0) [version-going-backwards Feb 04 18:30:42 how do i fix these? Feb 04 18:31:19 it's right, i renamed my recipe since AUTOREV apparently automatically adds "-r0" Feb 04 18:32:21 would i just delete everything in the package feeds? Feb 04 18:32:26 the fix is not to let your version go backwards. but it's only really a concern if you need upgradability when using package feeds Feb 04 18:32:38 nayfe: I have some local work on influx to get grafana influxdb etc to latest, havent pushed it to community repo on github Feb 04 18:32:49 it uses packagedata, not packages, and packagedata will just be restored from sstate as needed Feb 04 18:32:59 personally i disable that error quite often, just not that useful for my use cases Feb 04 18:33:46 i am using smart, and i would like it not to be confused about revisions. in short, i'd like to just nix all those old, previously-named revisions Feb 04 18:34:07 if i have spend 3 hours rebuilding, so be it Feb 04 18:35:16 curious: does the r0 suffix get incremented when the autorev revision changes? (automagically?) Feb 04 18:35:32 s/if i have spend/if i have to spend/ Feb 04 18:36:49 kergoth: i'm not sure what you meant by "...and packagedata will just be restored from sstate as needed" Feb 04 18:37:47 are you implying that if i remove cache-sstate, everything will be rebuilt with correct revisions? Feb 04 18:39:54 let me clarify: i do NOT have existing systems out in the world which would be confused with a backwards package version Feb 04 20:04:22 RP: so now I sent binutils 2.32 update :) Feb 04 20:21:25 kanavin: and a multilib failure but basically looking better :) Feb 04 20:21:32 khem: heh, cool Feb 04 20:51:01 RP: I have been carrying it over for few weeks so should be eventless hopefully Feb 04 20:58:54 khem: the commit message is a little terse (why were the patches dropped) Feb 04 20:59:01 do you break smart package versioning when you use SRCREV=${AUTOREV}? Feb 04 20:59:03 (I know why but it should say) Feb 04 20:59:28 yocto seems to always generate a -r0 in that case. Feb 04 21:01:24 and smart doesn't work.. rebuilding a recipe from a new version "bitbake ", running "bitbake package-index", and then running "smart upgrade " yields "No interesting upgrades available" Feb 04 21:01:44 :( Feb 04 21:03:58 RP: most of backports were dropped Feb 04 21:04:02 rburton: can you help? Feb 04 21:04:02 nothing else Feb 04 21:05:26 further, running "bitbake " after the repository specified in the SRC_URI bumps a revision does not even do a new build. "Attempt N tasks of which N didn't need to be rerun and all succeeded" Feb 04 21:06:19 is there a pointer on how to get all this (SRCREV et al.) to work? Feb 04 21:06:37 i looked for some time and couldn't find the docs for it Feb 04 21:07:03 help? Feb 04 21:08:11 essentially i want yocto to manage the revision of the package. -r0, -r1, -r2, etc. when the repo revision bumps Feb 04 21:08:49 or am i confusing everyone? Feb 04 21:09:02 am i confused? Feb 04 21:12:25 wait..., i have missed some documentation - reading it now. SRCPV and such Feb 04 21:12:40 RP: I Can make it a bit better commit msg wise, Feb 04 21:14:38 yates: set SRCREV, not rev=, and use SRCPV in PV. that'll ensure bitbake sees the revision change as a variable change and re-run the task Feb 04 21:19:48 RP: sent a v2 Feb 04 21:20:13 kergoth: like this? https://paste.fedoraproject.org/paste/x8yiFXRfUM8O1VbUMRPctw Feb 04 21:20:27 yates: turn on pr service Feb 04 21:21:11 rburton: huh? "pr" service? Feb 04 21:21:24 you mean irc private message? Feb 04 21:21:42 yates: http://lmgtfy.com/?q=yocto+pr+service Feb 04 21:21:46 no, PR as in the recipe variable. the PR server maintains a db to bump PR automatically whenever appropriate changes occur Feb 04 21:22:03 yates: PV .= "+svn${SRCPV}" is probably sufficient. the := stuff is just unnecessary, and + is a common convention for an scm based version suffix Feb 04 21:34:43 kergoth: thanks Feb 04 21:34:56 rburton: thanks, but admittedly i didn't follow that Feb 04 21:35:56 so if you use svn, you really don't need the PR service as their revision numbers always increment? Feb 04 21:36:11 assuming you embed the revision into the PV yes Feb 04 21:36:19 *but* Feb 04 21:36:23 yes? Feb 04 21:36:25 if you have a feed you want PR service Feb 04 21:36:30 why? Feb 04 21:36:31 i do Feb 04 21:36:32 because no other recipe has an incrementing PR Feb 04 21:38:02 "because no other recipe has an incrementing PR"...? OH. you mean the PR only increments for the recipe that is being updated? Feb 04 21:38:17 PR is a recipe variable Feb 04 21:38:20 its part of the version Feb 04 21:38:25 1.2-r3 Feb 04 21:38:26 r3 is PR Feb 04 21:38:34 "Package Revision" Feb 04 21:38:36 yes.. Feb 04 21:38:38 yes.. Feb 04 21:38:58 the PR service bump the PR every time a recipe is rebuilt, because if it was rebuilt it potentially changed Feb 04 21:39:09 otherwise, a feed is pointless Feb 04 21:41:08 * yates looks up meaning of PV Feb 04 21:41:53 Package Version Feb 04 21:42:46 yates: modify a recipe, add a patch to SRC_URI. the version in the binary package won't change unless you use the PR service or explicitly bump PR manually every single time you make a cahnge. Feb 04 21:42:48 typically *upstream* version Feb 04 21:43:10 yates: the only exception is scm recipes, since we have srcrev/srcpv Feb 04 21:43:21 oh the good old days of "change configure option" patches followed by "forgot to bump PR" patches Feb 04 21:43:26 but even that benefits from it,s ince not all changes are source changes Feb 04 21:43:31 ugh, yes, that was horrible Feb 04 21:44:46 what would be wrong with using SRCPV to set the PR? bastardization perhaps, but wouldn't it work (for svn)? Feb 04 21:45:04 no Feb 04 21:45:27 because if your recipe changes from --disable-foo to --enable-foo, the revision ID hasn't changed Feb 04 21:45:35 still the same upstream commit Feb 04 21:45:41 but the package is definitely different Feb 04 21:46:05 lets not even think about you change a *class* that some of your recipes inherit Feb 04 21:49:07 was the PR service available on Morty? Feb 04 21:51:27 if you aren't maintaining and using a package feed for more than just image construction, you may well not need the pr server at all. bitbake checksums the metadata nd will use the new packages to build the images when you change the recipe anyway Feb 04 21:52:04 a lot of folks don't use a package manager to deploy upgrades. if i'm going to reflash every time, or roll it out with swupdate, it doesn't really matter Feb 04 21:52:07 depends on your needs Feb 04 21:52:44 i have found a package manager so useful just in development that i'd like to maintain it. Feb 04 21:52:52 yates: looks like its 1.4 onwards Feb 04 21:53:35 good Feb 04 21:54:23 well what i had in mind for this project right now was to fix my PV to 1.0 (production 1.0) and allow the PRs to roll with svn updates. e.g., loadrfcontrol_1.0-r0, then loadrfcontrol_1.0-r1 if the source changes. Feb 04 21:54:24 i kind of wish runqemu automatically started up a web server pointing at our package feed after re-indexing it and configured the runtime to point at it somehow Feb 04 21:55:29 yates: that would be abusing PR, just put the svn id in the PV Feb 04 21:55:34 1.0+svn10 etc Feb 04 21:56:02 why would you call that a version and not a revision? Feb 04 21:56:39 revision implies upstream didn't change Feb 04 21:56:43 PV is the upstream version Feb 04 21:56:48 what is upstream? Feb 04 21:56:50 kergoth: https://github.com/rossburton/meta-ross/blob/master/classes/simplefeed.bbclass Feb 04 21:56:54 yates: the software, not the recipe Feb 04 21:57:08 kergoth: sort of works :) Feb 04 21:57:25 huh, indeed, pretty close Feb 04 21:57:35 kergoth: though the autobuilder can destroy simpleserver in automated qa Feb 04 21:58:53 i'll have to play with that, thanks. it's so common for me to forget to include a package in an image during development and testing Feb 04 21:59:20 kergoth: i think i actually used it to install a package so it *works* but isn't finished Feb 04 21:59:24 * kergoth nods Feb 04 21:59:29 rburton: so you mean to say that, typically, the upstream doesn't changed between r0 and r1, e.g.? Feb 04 21:59:39 s/changed/change/ Feb 04 21:59:57 typically no, unless you count adding a patch. which wouldn't be a PV change but a PR. Feb 04 22:01:22 so policy is that a change to the upstream changes the PV? Feb 04 22:01:43 well, that's typical Feb 04 22:01:49 no wonder i've been confused.. Feb 04 22:01:53 either the tarball being fetched gets a new version Feb 04 22:01:55 (new PV) Feb 04 22:02:13 or the vcs checkout is a new revision, which is the version Feb 04 22:02:34 god i wish i could remember how bash read worked Feb 04 22:03:59 what i'm doing (right or wrong) is to set the SRC_URI to a specific branch (branches/production-1.0) and to consider THAT the version and then auto-increment the revision on updates in that branch. Feb 04 22:04:16 (or rather, what i'm intending on doing) Feb 04 22:04:32 whereas what the convention is, is to use SRCPV Feb 04 22:04:32 recipes-extended/libnsl/libnsl2_git.bb:PV = "1.2.0+git${SRCPV}" Feb 04 22:04:36 to pick a random recipe Feb 04 22:05:14 as kergoth said a while back Feb 04 22:05:19 yes Feb 04 22:06:01 rburton: ugh, i *hate* 'read' in shell scripts. i use it all the time, but it pisses me off Feb 04 22:06:22 i *want* it to be useful for columnar data, but it can't handle empty fields. or rather it compresses them Feb 04 22:06:29 printf 'foo\tbar\t\tbaz' | read -r a b c d -> 'baz' is in c, not d Feb 04 22:07:39 so i am doing it right: echo foo bar fish | read a b c should mean that echo $a is foo Feb 04 22:07:44 i'm just getting blank :( Feb 04 22:08:29 it should, but there are caveats based on when shell creates subshells Feb 04 22:08:37 see i hate read Feb 04 22:09:08 in posix sh that wont work because the use of the pipe basically creates a new shell conceptually.. that is, the vars are only valid in the context of the right side of the pipe Feb 04 22:09:19 i.e. echo foo bar baz | ( read a b c; echo $a ) should give correct results Feb 04 22:09:27 fffffffs Feb 04 22:09:39 goddamnit bash Feb 04 22:09:42 that was it Feb 04 22:09:49 so i just need to wrap this in a block Feb 04 22:10:10 that's what i usually do, yeah Feb 04 22:10:55 occasionally it pisses me off. like i'll want to do cat somefile | foo | while read -r a b c; do foundit=1; done -> found it is *not* 1, since the vars set in the while don't hit the main shell Feb 04 22:11:07 but if you read from a file with a redirect, it doesn't hit that issue Feb 04 22:11:17 so sometimes need a temporary file just to sidestep that issue Feb 04 22:12:20 kergoth: when you wrote: PV .= "+svn${SRCPV}", is the leading "+" a literial "+" (or, e.g., a concatenation operator)? Feb 04 22:12:33 .= is concatenate, right? Feb 04 22:13:20 * yates looks for the section of the manual on variable constructions Feb 04 22:14:05 https://www.yoctoproject.org/docs/2.5.1/bitbake-user-manual/bitbake-user-manual.html#basic-syntax Feb 04 22:16:25 "Command substitution, commands that are grouped with parentheses, and asynchronous lists shall be executed in a subshell environment. Additionally, each command of a multi-command pipeline is in a subshell environment; as an extension, however, any or all commands in a pipeline may be executed in the current environment. All other commands shall be executed in the current shell environment." there it is. "Additionally, each command of a multi-command Feb 04 22:16:26 pipeline is in a subshell environment", running in the current envirionment is an optional extension! Feb 04 22:16:27 from POSIX.1-2008 Feb 04 22:16:59 http://pubs.opengroup.org/onlinepubs/9699919799/ -> shell & utilities -> shell command language -> shell execution environment Feb 04 22:17:12 is that syntax basically python's string manipulation syntax? Feb 04 22:17:18 no Feb 04 22:17:22 .= is concatenation, yes Feb 04 22:17:43 as i said earlier, + is a convention in some version strings to separate the component of the version referring to the scm rev Feb 04 22:17:59 yes, but i put a "-" there and still saw a "+:"! Feb 04 22:18:02 as rburton said, i.e. "1.0+svn10 etc" Feb 04 22:18:06 yates: grep oe-core for SRCPV, loads of examples Feb 04 22:18:13 yeah, good call Feb 04 22:18:18 just trying to understand why Feb 04 22:19:30 nope Feb 04 22:19:35 seeing things.. Feb 04 22:22:50 kergoth: ten minutes of argh because i put foo3.img instead of foo.img3 Feb 04 22:22:57 ugh Feb 04 22:23:01 no wonder the read was returning blank Feb 04 22:23:11 http://www.fifi.org/doc/debian-policy/policy.html/ch-versions.html and https://wiki.gentoo.org/wiki/Version_specifier mostly inspired the original notion of epoch/version/revision in oe as originally the tooling was portage based and the distro was debian based. trying to have a single versioning system work for every upstream version scheme *and* be compatible with any arbitrary target binary package management system is .. a bit of a pain at times Feb 04 22:23:21 but i do now have my recipe, erm, extracting an ext partition from a disk image Feb 04 22:24:41 I actually think equinox p2's "omniversion" scheme is really interesting. it lets you encode the versioning scheme / how the version is parsed by supplying a format string in the omniversion string. completely self contained, no need for a central handler for it Feb 04 22:25:02 https://wiki.eclipse.org/Equinox/p2/Omni_Version#Examples_of_Version_Formats Feb 04 22:28:52 yates: + is also the convention for pre-releases. 0.9+1.0rc0. that way 1.0 is still seen as newer, rather than 1.0rc being seen as newer than 1.0 Feb 04 22:28:56 just as an fyi Feb 04 22:29:31 of course we can now do 1.0~rc1 Feb 04 22:29:38 which sorts before 1.0 Feb 04 22:29:45 ah, true, forgot that was added Feb 04 22:32:29 my do_install now has fdisk, dd, and debugfs calls in. Feb 04 22:32:34 do i win a prize? Feb 04 22:33:58 rburton: scary :) Feb 04 22:37:30 [41924.676444] print_req_error: I/O error, dev sdc, sector 24606768 Feb 04 22:37:31 oh ffs Feb 04 22:37:35 now my usb stick is dying Feb 04 22:41:54 New news from stackoverflow: How can I force bitbake to find my libraries? Feb 04 22:54:26 arhghghghgh Feb 04 22:54:47 debugfs created a file called /this/is/the/long/path/i/wanted in the root of the file system Feb 04 22:55:30 that is not funny Feb 04 22:58:27 can someone help out scottrif and comment as to whether this is a workaround for a bug or a genuine requirement that we should list? https://bugzilla.yoctoproject.org/show_bug.cgi?id=13164 Feb 04 22:58:28 Bug 13164: minor, Undecided, 2.7 M4, srifenbark, NEEDINFO , Include libncurses-dev in the list of required packages Feb 04 22:58:49 thanks Paul Feb 04 22:59:22 thats a duplicate Feb 04 22:59:27 now wheres the original Feb 04 23:00:26 scottrif: closed :) Feb 04 23:01:50 rburton: thanks Feb 04 23:02:20 crazy, the two bugs were even number anagrams of eachother :D Feb 04 23:08:25 yeah i noticed that :) Feb 04 23:12:56 rburton: I'm trying not to smile. Sorry. Feb 05 00:26:43 khem: commit message is better thanks Feb 05 00:37:10 RP: whats your take on mutlilib header patch, I sent a v3 which is a one liner Feb 05 00:38:30 RP: on some arches e.g. arm we are stubbing bits/wordsize.h itself which is a dagenerious proposition given that header template includes bits/wordsize.h Feb 05 00:39:44 khem: I worry we're complicating something I'd prefer not to complicate. I did wonder why the underlying headers didn't protect against renterance Feb 05 00:42:18 New news from stackoverflow: Creating Yocto Mender for Raspberrypi 3 || Self-hosted mender fails to update artifact || Building a Mender Yocto image for a Raspberry Feb 05 00:45:07 RP: the header underlying is unfortunately same Feb 05 00:45:23 which is un-guarded Feb 05 00:45:30 pragma once is a better fix Feb 05 00:46:32 this is the reason https://git.openembedded.org/openembedded-core/commit/?id=90ad502bf8faa233e25cf297c1eeefcb0367aea3 Feb 05 00:47:33 I wonder why do we multilib aarch64/arm they are different backends, unlike x86/x86_64 Feb 05 00:48:39 problem is we are including bits/wordsize.h from bits/wordsize.h ... you see ? Feb 05 00:58:08 khem: the arm situation is a hack :-( Feb 05 00:58:19 khem: I do see now, hmm Feb 05 00:58:38 * RP -> Zzzz **** ENDING LOGGING AT Tue Feb 05 03:00:01 2019