**** BEGIN LOGGING AT Mon Sep 26 02:59:58 2016 Sep 26 07:06:23 good morning Sep 26 07:33:06 Hi all. How would i reference a local git repository using SRC_URI? Using file:// or rather git://127.0.0.1/ or somehow else? Sep 26 07:36:07 Usually the repo lives on a remote but i'd like to be able to build it against my working copy during development so i don't have to push some wonky stuff Sep 26 07:50:28 Anticom: have you looked at externalsrc.bbclass? See http://www.yoctoproject.org/docs/2.1.1/dev-manual/dev-manual.html#building-software-from-an-external-source Sep 26 08:30:45 erbo: well i've got the SRC_URI set up for our remote repo. However i'd like to swap that to a local working-copy for development purposes and revert that change before committing Sep 26 08:31:44 erbo: because with file:// i now get, that the directory in work-dir could not be found (probably because i've set S to ${WORKDIR}/git Sep 26 08:34:46 And also file://<...>;subdir=git doesn't seem to help Sep 26 09:56:34 Hi.Can anyone tell me, how to increase the filesystem size ? Sep 26 09:57:44 I am getting the following error while installing package "error: installing package lxc-2.0.0-r0.core2_64 needs 449MB on the / filesystem". Sep 26 10:01:09 That may be related to the space you have left locally Sep 26 10:01:13 there's a few variables that affect the filesystem size Sep 26 10:01:14 http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-IMAGE_ROOTFS_SIZE Sep 26 10:01:14 http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-IMAGE_ROOTFS_EXTRA_SPACE Sep 26 10:01:14 http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-IMAGE_OVERHEAD_FACTOR Sep 26 10:03:06 joshuagl_:So if I change these variables will it increase my filesystem space? Sep 26 10:07:10 CTtpollard:I have 33GB of free space locally. Sep 26 11:01:41 joshuagl_: Thanks . It worked . I was able to increase the filesystem size upto 1 GB by changing "IMAGE_ROOTFS_EXTRA_SPACE". Sep 26 11:29:25 guys, is it possible to view current building process of yocto in the jenkins output? I only see the Build configuration info and some warnings Sep 26 13:21:09 RP: Hi, would you still accept u-boot 2016.09.01 update for 2.2 ? Sep 26 13:25:17 Marex: no, its too late Sep 26 13:26:43 RP: so 2.2 will be 2016.03 ? Sep 26 13:26:56 Marex: I guess so Sep 26 13:27:01 OK Sep 26 13:44:21 Quick question: Should existing recipes used on the jethro branch port fairly easily to the krogoth branch? Sep 26 13:45:15 is it possible to silence the «WARNING: Host distribution "DebianGNULinux-8" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.» somehow? Sep 26 13:46:47 Well, probably by editing the code producing it. :P Sep 26 13:47:26 yeah, that might be the easiest :p Sep 26 13:47:28 sandsmark: it's in the distro config, do git grep Debian on it Sep 26 13:47:34 ah, ok Sep 26 13:47:34 thanks Sep 26 13:48:23 hmm, «Debian-8.*» is in SANITY_TESTED_DISTROS Sep 26 13:48:35 so whatever generates the name is wrong somehow Sep 26 13:51:04 no /etc/lsb-release or or lsb_release in debian 8 it seems Sep 26 13:51:39 sandsmark: 'Host distribution "DebianGNULinux-8"' Sep 26 13:51:43 15:49 < sandsmark> hmm, «Debian-8.*» is in SANITY_TESTED_DISTROS Sep 26 13:51:49 yeah Sep 26 13:52:00 Debian-8 yet, DebianGNULinux-8 no Sep 26 13:52:04 s/yet/yes/ Sep 26 13:52:05 so distro_identifier() generates the wrong name Sep 26 13:52:22 or SANITY_TESTED_DISTROS should be updated I guess Sep 26 13:52:41 sandsmark: possibly, that's beyond my ability to judge which one it is Sep 26 13:54:37 «Debian GNU/Linux» is what is in /etc/os-release, and distro_identifier() just strips the space and /, so I guess SANITY_TESTED_DISTROS should be updated Sep 26 14:32:13 mrk377: There's no general answer to this. I'd just give it a try and see whether it blows up on you or not Sep 26 14:42:52 Anticom: the url scheme (the 'file' part of 'file://') determines which bitbake fetcher is used. if you use file, it'll just copy or symlink a local file/dir, it won't use git at all. what you'd want is git:// + protocol=file, to use the git fetcher, but pass a file:// uri to git as the git repo url. Sep 26 14:43:04 or just use externalsrc, as was suggested Sep 26 14:43:05 * kergoth yawns Sep 26 14:46:05 kergoth: thank's i've found git://+protocol=file to be working :) Sep 26 14:47:00 There seems to be something wrong with do_rootfs for my image... it doesn't seem to do any progress Sep 26 14:47:14 can i do something like bb -c cleanall img && bb img ? Sep 26 14:47:37 Or will this break anything? Sep 26 14:48:02 I don't want to rebuilid everything but there seems to be something wrong with my rootfs Sep 26 14:50:32 Anticom: by chance are you building for an x86 target? I've used cleanall on image recipes without any issues. Sep 26 14:50:46 challinan: no, for arm Sep 26 14:51:23 ah ok. I've run into do_rootfs getting stuck when my image size grows bigger then 4GB, but that's probably not your issue. It' unique to live image types Sep 26 14:51:46 quemu-arm seems to have some hickups according to htop Sep 26 15:02:29 Anticom: each rootfs construction starts from scratch for the recipe, so i doubt a cleanall on the image would do much, but it certainly wouldn't hurt Sep 26 15:03:02 kergoth: didn't seem to help Sep 26 15:03:12 why is there even quemu involved in do_rootfs? Sep 26 15:03:17 nothing useful in the do_rootfs log file? Sep 26 15:04:35 kergoth: i'm watching it with tail. Last message is "NOTE: to be installed: " Sep 26 15:05:06 Anticom: there are postinsts / postinst intercepts that can only run on target or with qemu, using it lets us avoid doing more on first boot Sep 26 15:05:55 kergoth: i see. Oh i also was wrong on the last message. It's "Note: /path/to/smart <...>" Sep 26 15:06:43 Is there any other log which is more verbose? Sep 26 15:07:03 not that i know of, maybe one of the rpm/smart experts around can advise how to increase verbosity. fray_ perhaps? Sep 26 15:07:04 * kergoth shrugs Sep 26 15:09:00 Anticom: how do you know it is stuck and not just busy? Sep 26 15:09:07 Anticom: Thx. I am porting my "custom" jethro scripts to krogoth. It is moving forward. Sep 26 15:09:09 iotop/top shows nothing happening? Sep 26 15:10:54 sandsmark: it's taking way longer than usual. and nothing changes htop Sep 26 15:11:14 Oh wait Sep 26 15:11:30 Now it's doing something. However quemu was only at arround 2% cpu utilization Sep 26 15:11:35 how about iotop, it's not given that a lot of io == high cpu usage Sep 26 15:12:03 sandsmark: sounds legit Sep 26 15:12:12 never heard about iotop, i'll take a look at this one Sep 26 15:12:29 mrk377: great! Sep 26 15:13:47 is it possible to override KERNEL_DEVICETREE in local.conf? Sep 26 15:14:29 use an override (see the docs about OVERRIDES). specifically either the pn- or forcevariable overrides should do the job Sep 26 15:26:08 Anticom and et al.: I remember first starting out with yocto, and hacking the existing files (big no-no). After creating custom layers, append files, and machine tuning, the port to krogoth has been easy. Well done mates!! Sep 26 16:19:53 kergoth: thanks Sep 26 19:40:55 We use a gerrit (git repository) to store source code that gets downloaded during a do_fetch. On gerrit we do not allow a git clone "https://username:password@host" using the password as follows. I have a SRC_URI = "git://host/gerrit/repo.git;protocol=https;name=latest;user=${username}:${html_password}" Is there a way to break this up so it works. I can't easily upload ssh keys to gerrit since we have many docker instances Sep 26 19:43:15 The SRC_URI is in a specific *.bb package group Sep 26 20:01:40 mrk377: i'd recommend setting the user/password in a .netrc rather than hardcoding credentials in a recipe, or use a git credential helper, of which there are a number available Sep 26 20:02:31 kergoth: Thx. I'll look into that! Sep 26 20:03:05 I'm pretty sure there's a way to do it in the url, though i'd have to check the fetcher code to verify, but IMO out of band is best Sep 26 20:03:20 the bitbake manual may well mention it, it covers the fetcher url syntaxes to some extent Sep 26 20:17:42 Roger Sep 27 02:30:40 Hello guys... I have a question Sep 27 02:30:42 about yaffs Sep 27 02:31:19 I know it's old, but I am investigating a problem of sometime ago. I mounted by mistake a non yafs partition with yafs, passing the -o ro, and I was wondering to see if there is a way i can detect yafs traces in that mtd area Sep 27 02:31:33 I checked header (e.g.: starting bytes) and they seems ok Sep 27 02:31:39 is this sufficient? Sep 27 02:32:10 I mean - is this sufficient to establish my data as not corrupted? Sep 27 02:36:57 Thank you guys, any help would be greatly apreciated **** ENDING LOGGING AT Tue Sep 27 02:59:59 2016