**** BEGIN LOGGING AT Mon Jul 04 02:59:58 2016 Jul 04 06:13:53 poky uses rpm by default, so it seems you have customised your distro its not vanilla poky, please list your changes and version of release being used Jul 04 07:37:46 good morning Jul 04 08:56:35 hi Jul 04 08:56:59 i have a problem with genivi git repos access Jul 04 08:57:09 however, i have a local downloads/ directory Jul 04 08:57:26 still, yocto complains about the upstream being inaccessible Jul 04 08:57:48 is this because they try to see if there is any up[date upstream? Jul 04 08:57:54 s/they/it Jul 04 09:04:23 c0rnel: this has been brought up in #automotive Jul 04 09:04:33 c0rnel: yes... I think you can set NO_NETWORK=1 or something like that to avoid it Jul 04 09:04:38 look in the mega manual Jul 04 09:05:02 c0rnel: there has been an infrastructure migration and the new git server now requires authentication: http://lists.genivi.org/pipermail/genivi-projects/2016-July/002591.html Jul 04 09:05:42 genivi IT is looking into it Jul 04 09:13:34 fredcadete, boucman_work thank you Jul 04 09:18:49 anybody knows if there's a mirror on github for genivi? the email seems to imply this Jul 04 09:24:04 c0rnel: some of the repositories have been migrated to https://github.com/GENIVI Jul 04 09:24:06 but not all Jul 04 09:24:37 fredcadete, thank you, that's what i've thought since i've not seen dlt-daemon there, for example Jul 04 09:29:03 Hi! I am trying to create a new recipe for a package. I am using the 'SRC_URI' varaible to define the url of a .tar.gz package containing the source. I have tested it and it correctly fetches and unpackages the files. Jul 04 09:29:17 My question is, how can I modify the name of the folder in which the package gets extracted? Jul 04 09:30:24 jdtlk: I don't think you can, but you can tell yocto what the name will be by setting the "S" variable Jul 04 09:31:35 oh, so instead of changing the directory in whcih the files get extracted to the working directory, I should do it the other way around: change the working directory to the one in which the files are extracted Jul 04 09:31:40 is that what you mean? Jul 04 09:32:10 SRC_URI says what uris to download and unpack, S says where the main source ends up after unpacking Jul 04 09:32:22 you cant change the directory structure of a tarball, as that's up to the tarball itself Jul 04 09:32:44 I see Jul 04 09:32:44 no, you don't change the workdir, you change the sourcedir (which is a subdirectory of the workdir) Jul 04 09:33:03 I just the wrong word, 'S' is the sourcedir, not the workdir Jul 04 09:33:06 workdir is where yocto stores all the stuff it needs to work, including but not limited to the sourcecode Jul 04 09:33:06 Okey, i got it Jul 04 09:33:15 Thanks for your help! =D Jul 04 09:33:18 np Jul 04 09:36:06 Oh, I also want to ask you guys about another thing. This recipe should build the package only for the SDK, using native compilation Jul 04 09:36:29 From similar recipes, I saw the BBCLASSEXTEND = "native nativesdk" line at the end, which seems to add the recipe to the SDK and using native compilation Jul 04 09:36:33 but it also adds it to the target Jul 04 09:36:47 How can I make the recipe so that the package is not added to the target? Jul 04 09:46:44 BBCLASSEXTEND just makes it *possible* to build in various forms Jul 04 09:46:59 you decide where it gets used Jul 04 09:47:49 rburton: I understand the question as "how can I disable non-native builds" (which I don't know the answer to) Jul 04 09:48:01 How do I decide? Now when I execute 'bitbake mypackage' it tries to crosscompile it Jul 04 09:48:04 (which fails) Jul 04 09:48:19 that would be because you asked it to do a target build :) Jul 04 09:48:21 I would like it to compile it (as this is an application for my dev machine, not for the target) Jul 04 09:48:45 could you clarify where am I selecting a target build? (in local.conf?) Jul 04 09:48:57 bitbake foo is a target build of foo Jul 04 09:49:00 jdtlk: did you add the recipe to IMAGE_INSTALL ? Jul 04 09:49:07 if you want the native form for host, you want foo-native Jul 04 09:49:18 if you want something you can run on the host in a sdk, you want nativesdk-foo Jul 04 09:50:30 Oh, I see. Runing 'bitbake mytarget-native' works just fine! =D. Jul 04 09:50:33 Is there a way to make it so that just 'bitbake mytarget' uses the native compilation? Jul 04 09:50:55 not really Jul 04 09:51:13 you can not have a non-native form if you name the recipe to foo-native Jul 04 09:51:50 Okey Jul 04 09:52:08 Thanks again, I am making this work as I expected, which is nice =) Jul 04 09:52:31 Yocto is really easy to use, im liking it a lot. Developing new recipes is not that easy, but I guess it takes sometime =) Jul 04 12:35:58 hi, how do I install a directory structure containing files etc. in a do_install() method? Jul 04 12:36:09 I've read that cp should not be used.. Jul 04 12:40:02 <_stephan> mwarning, just use "install -d" or "install -m" Jul 04 12:40:33 <_stephan> from ${WORKDIR}/... to ${D}${sysconfdir}/... for example Jul 04 12:41:03 <_stephan> install has a manpage, it's a standard linux tool Jul 04 12:41:58 ah, thanks Jul 04 12:46:33 mwarning: the thing is cp will often use *your* UID for files, whereas you want files with root:root ownership. Jul 04 12:46:39 install lets you set ownership Jul 04 12:52:45 rburton: btw, I always wondered... is do_install run under fakeroot, or does it use another trick to keep the permisions when run as a normal user ? Jul 04 12:53:08 rburton: ok, thanks for the clarification Jul 04 12:54:40 boucman_work: yeah install happens in fakeroot Jul 04 12:55:52 ok,, thx Jul 04 13:03:38 I get "Getting checksum for atlas-common SRC_URI entry foo-orig.tar.gz: file not found except in DL_DIR" - what do I have to do? Jul 04 13:04:09 I have created foo-orig.tar.gz and placed it in the download directory Jul 04 13:04:45 if you want to pretend that the fetcher did a fetch, then you need to touch foo-origi.tar.gz.done, as otherwise the fetcher will run and delete the file you just put there Jul 04 13:04:55 on the assumption that as there's no .done file, it didn't finish the fetch Jul 04 13:05:12 basically: don't just put files into DL_DIR unless you're deliberately avoiding the fetcher. Jul 04 13:07:26 I want to deliberately avoid the fetcher. :-) Jul 04 13:07:39 mwarning: if you don't fetch "for real" for the web, i would advise saving the .tar.gz in a directory next to your recipe and use a file:// uri in SRC_URI Jul 04 13:08:50 what boucman_work said Jul 04 13:09:33 the only time you should avoid the fetcher is if you have a file that you should be able to download but can't, say the host is down. then put the file in DL_DIR and touch filename.done. Jul 04 13:11:43 and even then, own_mirror is your friend :P Jul 04 13:29:01 boucman_work, what is own_mirror? Jul 04 13:29:14 i don't see it in the mega manual :) Jul 04 13:34:34 it's a way to specify a local directory as a "real mirror" (download is more a cache than a mirror, IIUC) Jul 04 13:35:22 http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#setting-up-effective-mirrors Jul 04 13:35:41 note that this is the "latest" version of the mega-manual, so this might be an unrelease feature, i'm not sure Jul 04 13:37:47 ah, because it's '-' not '_' :) Jul 04 13:37:57 thank you boucman_work Jul 04 13:39:09 does our local source file package need to have a specific root folder name? Jul 04 13:42:47 not, as far as i understand Jul 04 13:43:24 about the common downloads directory: is the read access enough? Jul 04 13:43:56 my understanding is that if the recipe is updated and you _need_ to download a newer version then you need to have write access Jul 04 13:44:27 I would like to call a bash script from a recipe. How can i get the path? Jul 04 13:44:36 The relative path to the recipe, or to the layer Jul 04 13:48:11 jdtlk: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-THISDIR <= is that what you are looking for ? Jul 04 13:49:26 boucman_work: thanks, that could work Jul 04 13:49:38 the path of the layer itself would be great, though, so I can have recipes less coupled Jul 04 13:50:34 I'm not sure why you would want that... layers are a pretty weak concept once recipes are parsed, you usually don't want to rely on them... Jul 04 13:50:39 could you explain ? Jul 04 13:51:22 I have a bash script for a post-compilation process (sign + encryption) which needs to be done after my recipe has compiled Jul 04 13:51:34 So i would like to call that bashscript in the do_deploy_append, so that the final artifacts are ready Jul 04 13:51:56 I need to have a way to get the path of the bash script so I can call it Jul 04 13:53:34 jdtlk: wouldn't do_compile_append be a better place ? Jul 04 13:53:59 since at that point $S points to where your sources have been unpacked (to find your script) Jul 04 13:54:13 and $B to where the builartifacts have been generated by do_compile Jul 04 13:54:28 (it is common for $B == $S but it is not always the case) Jul 04 13:55:12 The script is not with the sources, it is an external script that needs to be executed on the final artifacts Jul 04 13:55:22 It cannot be distributed along with the sources Jul 04 13:56:18 jdtlk: so... is it in your meta ? (next to your recipe) Jul 04 13:56:38 in that case, add it as file:// in the SRC_URI and yocto will copy it in WORKDIR Jul 04 13:56:55 that's how it's usually done Jul 04 13:57:50 okey, that can work Jul 04 13:57:51 thanks Jul 04 13:59:48 are there any plans for a YPDD or OEDEM at berlin this year Jul 04 14:10:20 Is it possible to set the PV in a recipe based on a script? Jul 04 14:10:56 I have multiple files that only differ in their version number and just want to use the latest number Jul 04 14:15:47 mwarning: it is possible, but this is probably not what you want... can you explain your use-case a bit better ? Jul 04 14:17:21 our jenkins instance build our package with a version number included (e.g. foo.1.0.0.tgz) and places in a directory. When the yocto build is triggered, the recipe should build a new package. Jul 04 14:17:28 you can set PKGV Jul 04 14:17:43 PKGV? I will check the docs? Jul 04 14:17:46 ! :) Jul 04 15:09:39 is there a known issue with python 2.7.9? Jul 04 15:09:39 site.conf seems to not work on Fedora 22 Jul 04 15:36:13 CoLa|work: Fedora 22 is (almost?) at EOL but it worked fine a few months ago. Pastebin your error? Jul 04 15:40:30 seebs: around? we've found a few issues in pseudo master Jul 04 15:43:40 seebs: I had to `chmod +x` ports/unix/subports to build — http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/tree/meta/recipes-devtools/pseudo/pseudo_1.8.0.bb?h=joshuagl/pseudo#n16 Jul 04 15:44:57 seebs: the others we've seen so far are unexpected owners on files, we're trying to determine whether that's just the new pseudo exposing latent bugs. Will keep you posted. Jul 04 15:56:44 seebs, fray: What we're seeing is that we can have a do_install which installs something as root.root , then we do a sed -i -e 'xxx' and its owned by the build user again. Is that what you'd expect? Jul 04 15:56:59 joshuagl: ^^ Jul 04 16:09:25 * zeddii hopes that seebs and fray are drinking beer for the 4th. Jul 04 16:10:24 yeah happy treachery day Jul 04 16:10:31 damned colonials Jul 04 17:06:39 I would like to remove a file (script) from the initscripts recipe, what would be the best way to do this? Jul 04 17:08:09 I would also like to add a script, but this is pretty straightforward, not sure how to remove one however. Jul 04 17:08:47 aren't those scripts part in the files directory of the recipe? Jul 04 17:09:01 just under different names maybe? Jul 04 17:09:38 the scripts are there yes Jul 04 17:10:01 so just remove them from the recipe's SRC_URI Jul 04 17:11:08 I would like to avoid modifying poky recipes directly if possible. I suppose I could patch the scrip I want to remove to do nothing... Jul 04 17:11:43 you could do that i suppose, or redeclare SRC_URI in a bbappend Jul 04 17:11:49 to just not include that script Jul 04 17:13:05 Yes, that would be ok, thansk obsrwr_ Jul 04 17:13:10 np Jul 04 17:14:08 there is no method for blacklisting a file though, right. Redeclaring SRC_URI is the only way correct? Jul 04 17:14:57 i ain't saying that Jul 04 17:15:02 i'm just too lazy to think of one Jul 04 17:15:31 fair enough, i searched the mega-manual, i didn't see one Jul 04 17:19:22 it would also be ok to supply my own version of the script, if I placed this file in my append file location, would it use this instead of the one located in initscripts? Jul 04 17:21:00 you can probably have a separate version of the recipe and set a PREFERRED_VERSION of that recipe in your local.conf Jul 04 17:45:25 hmm, so yeah if i append the recipe and FILESEXTRAPATHS_prepend with my replacement file location, it preferst to use my file over the one in the files location in the original recipe Jul 04 18:14:26 I have to move a few files between packages, so I'm trying to set RREPLACES properly Jul 04 18:15:05 Seems like it should be straight forward, except that I'd like to limit which versions of the original package the new package can replace files in Jul 04 18:17:13 for example, package A-1.2 replaces files in B-1.1 and below. Can I specify a replaces relation for B version 1.1 and below only, so that I continue to get the sanity check once the migration is complete? Jul 04 20:06:05 is it possible to extend a do_install in a bbappend file? Jul 04 20:09:46 RP: I would not expect 'sed -i' to change ownerships, no. Jul 04 20:09:50 But it is totally possible that something got broken by the updates. Jul 04 20:11:10 seebs: its something in http://git.yoctoproject.org/cgit.cgi/pseudo/commit/?id=58e4171525d5f319906a53ea169eac74631e7605 but go and enjoy the holiday, I'd forgotten about that earlier Jul 04 20:12:05 seebs: its also wider than just sed breaking, its as if sometimes the ownership goes to the real current user rather than root when it should go to root Jul 04 20:14:12 seebs: this is in addition to http://www.rpsys.net/wp/rp/fix.patch which is clearly needed, mind if I just commit that? Jul 04 20:16:18 sure. do_install_append Jul 04 20:16:30 is it that simple -_- Jul 04 20:16:38 huh. that's slightly surprising since I wouldn't have thought that would affect non-xattr things. Jul 04 20:16:48 Hmm. Jul 04 20:16:55 seebs: that last bit just breaks logging a bit Jul 04 20:17:18 Huh. Go ahead, but now I'm really curious as to how that escaped notice. I mean, it should have prevented things from working, I think. Jul 04 20:17:35 seebs: my builds had errors in the logs from that Jul 04 20:18:12 Ahh. Jul 04 20:18:42 seebs: the other issue is bisected down to 58e4171525d5f319906a53ea169eac74631e7605. I don't know why that commit makes this break but it does seem to be that one Jul 04 20:19:03 seebs: only some recipes show it, linux-yocto and e2fsprogs in particular Jul 04 20:19:11 Huh. Jul 04 20:19:46 seebs: that was it indeed. Thank you Jul 04 20:20:11 oops i just realized Jul 04 20:20:15 i'm not supposed to work on holidays Jul 04 20:20:19 vin, pretend i didn't answer that question Jul 04 20:20:26 otherwise we get in trouble and they take away our fireworks Jul 04 20:20:34 * vin whistles and looks around minding nobodies business Jul 04 20:20:47 just imagine that every time I answer a question or think about programming on July 4th, a bald eagle cries. Jul 04 20:20:53 seebs: and stop you throwing perfectly good tea in harbours? Jul 04 20:21:19 they said you could scale the recipe up to ten thousand people :( Jul 04 20:25:25 another (non) question. Is it possible to add a user in a bbrecipe? Jul 04 20:25:49 i think it must be, because users get added somehow Jul 04 20:26:03 and since I think everything is technically done by recipes... Jul 04 20:26:30 found it Jul 04 20:26:36 extrausers Jul 04 20:41:24 vin: for users associated with a particular recipe I think you want useradd rather than extrausers Jul 04 20:41:40 maybe, because extrausers does not work :P Jul 04 20:42:15 thanks for the tip Jul 04 20:43:39 there are lots of examples of the useradd class in the core recipes Jul 04 21:10:57 RP: ah that extra comma was important then? Jul 04 21:11:34 rburton: yes, that fixes the logging but not the permissions problem Jul 04 21:14:06 well logs that are not spammed is good i guess :) **** ENDING LOGGING AT Tue Jul 05 02:59:59 2016