**** BEGIN LOGGING AT Mon Aug 10 02:59:59 2015
Aug 10 06:02:29 <drou> hi guys
Aug 10 08:14:56 <drou> has anyone managed to build matchbox-wm with the composite support ?
Aug 10 08:15:51 <drou> i'm getting the following error :
Aug 10 08:15:55 <drou> | /yocto/build/tmp/sysroots/i686-linux/usr/libexec/i586-poky-linux/gcc/i586-poky-linux/4.9.1/ld: composite-engine.o: undefined reference to symbol 'exp@@GLIBC_2.0' | /yocto/build/tmp/sysroots/vecow-jdebug-bni-desk-chief/lib/libm.so.6: error adding symbols: DSO missing from command line | collect2: error: ld returned 1 exit status | make[2]: *** [matchbox-window-manager] Error 1
Aug 10 08:16:13 <drou> looks like -lm is missing
Aug 10 08:39:46 <bluelightning> morning all
Aug 10 09:05:34 <AzaToth_> i notice when I'm building nightlies, that even though deploy_artifacts is "'choices': ['True', 'False']", when it's run by a schedule, it skips the artifact deployment. Have I missed som variable here?
Aug 10 09:06:08 <AzaToth_> I thought it defaulted to the first entry in the choices field
Aug 10 09:06:19 <AzaToth_> or should I set some other variable?
Aug 10 09:31:37 <sm0ketst> hi all, i'm trying to build a 32b in a 64b target and i'm checking the multlib support in yocto. besides https://wiki.yoctoproject.org/wiki/Multilib is there another place where to check for the actual status/example? also looking lib32-bash in OE. TIA
Aug 10 11:43:18 <khalebios> hi guys
Aug 10 11:44:56 <khalebios> I want to copy a script in /etc/init.d/ directory. I my do_install() I put:
Aug 10 11:46:02 <khalebios> cp ${D}${bindir}/hello ${D}/etc/init.d/
Aug 10 11:46:10 <khalebios> and i have an error.
Aug 10 11:46:16 <khalebios> how to fix this?
Aug 10 11:47:10 <bluelightning> khalebios: is that source path really correct?
Aug 10 11:47:27 <khalebios> yes
Aug 10 11:47:58 <bluelightning> did you create ${D}/etc/init.d/ first?
Aug 10 11:48:03 <khalebios> the error is : cannot create regular file :
Aug 10 11:48:07 <khalebios> no
Aug 10 11:48:14 <bluelightning> ok, you need to do that
Aug 10 11:48:23 <khalebios> with mkdir?
Aug 10 11:48:35 <bluelightning> install -d is the convention
Aug 10 11:49:12 <gan> Is there a way to get bitbake to list all its task but not perform them? I.e. create a list of the tasks it intends to do, in the order it intends, basically...
Aug 10 11:49:38 <bluelightning> gan: -n ?
Aug 10 11:50:04 <bluelightning> gan: you may need to pipe it through cat to get a meaningful result
Aug 10 11:50:16 <khalebios> <bluelightning> : ok thank . i am trying this solution
Aug 10 11:50:28 <gan> Since you write a question mark, I will test it and come back and answer :)
Aug 10 11:53:49 <bart0sh> sujith_h: hi
Aug 10 11:55:04 <bart0sh> sujith_h: do you need my help with toaster?
Aug 10 11:56:10 <gan> Sorry, got disconnected.  Anyone else have an idea, I'd like to create a script that steps through every job one at a time and allows me to inspect the result between them...
Aug 10 12:00:09 <gan> OK, found a log file. I guess an idea is to parse it out of the log from a successful build and then recreate it, but that really only works for fully successful builds
Aug 10 12:06:47 <gan> Goddamn connection.
Aug 10 12:06:51 <gan> bluelightning, -n followed by reading tmp/logs/*.log is pretty close to what I want.  -n writes to the log but not the terminal.  OK thanks for that.  Answered my own question pretty much.  Sorry for the noise.
Aug 10 12:07:10 <bluelightning> gan: np
Aug 10 12:07:24 <bluelightning> gan: that's why I mentioned piping it through cat though
Aug 10 12:15:35 <tasslehoff> I've created a rootfs and an sdk for my board. The executable does not run, and http://pastebin.com/vcpU9KEG gives a hint why. But, I still don't understand what I've done wrong.
Aug 10 12:24:10 <tasslehoff> When I manually create the ld-linux.so.3 symlink, it works. Am I using the toolchain wrong, or is there a bug here?
Aug 10 12:37:30 <sujith_h> bart0sh: yah
Aug 10 12:40:03 <tasslehoff> I'm on 1.7.2, btw
Aug 10 12:40:51 <sujith_h> bart0sh: I have an updated config file http://pastebin.com/JqQX7LjX. With I am not able to get the view updated. I have updated loadconf.py http://pastebin.com/rwHUezzF
Aug 10 12:41:49 <sujith_h> bart0sh: When I reload the webpage I am getting http://imagebin.ca/v/2BevIc26I5w5
Aug 10 12:54:34 <sm0ketst> what is the best way of defining a SRC_URI for git/ssh which includes submodules ?
Aug 10 12:55:49 <bart0sh> sujith_h: I'll look at it.
Aug 10 12:56:24 <bluelightning> sm0ketst: use gitsm:// as the prefix, and suffix ;protocol=ssh
Aug 10 12:56:25 <bart0sh> sujith_h: however, last time I tried to load your config toaster failed.
Aug 10 12:56:36 <bart0sh> sujith_h: as it didn't find your layers.
Aug 10 12:57:12 <bart0sh> sujith_h: is it possible to get them somehow?
Aug 10 13:03:13 <sujith_h> bart0sh: well most of the layers are private.
Aug 10 13:03:47 <sujith_h> bart0sh: Let me create a config by adding meta-qt5 and other public repos
Aug 10 13:03:49 <sujith_h> or layers
Aug 10 13:04:03 <sujith_h> bart0sh: give me time
Aug 10 13:05:43 <tmcguire> I use IMAGE_INSTALL_append = "perf", which does create perf packages - however the perf packages don't end up in the sysroot
Aug 10 13:05:48 <tmcguire> What am I doing wrong?
Aug 10 13:06:32 <tmcguire> I can confirm there is a "perf" binary in tmp/deploy/deb/imx6qsabresd/perf_3.10.17-r9_armel.deb, but no perf binary in tmp/sysroots
Aug 10 13:07:11 <bluelightning> tmcguire: do you have a leading space in that value?
Aug 10 13:07:31 <tmcguire> yes, I actually have, sorry, I cut down the example a bit
Aug 10 13:07:35 <bluelightning> ok
Aug 10 13:07:56 <tmcguire> after adding "perf" to IMAGE_INSTALL_append, bitbake actually built the perf package, so it had some effect.
Aug 10 13:09:19 <khalebios> ...
Aug 10 13:09:43 <khalebios> I want to set simply my /etc/network.interfaces file.
Aug 10 13:09:49 <khalebios> How can i do that?
Aug 10 13:10:13 <bluelightning> tmcguire: I don't think we stage target binaries under bin or usr/bin into the sysroot - the binary "perf" would be building would be one for the target, so we assume it's not something that would be needed on the host
Aug 10 13:11:12 <bluelightning> khalebios: here's an example: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-core/init-ifupdown
Aug 10 13:11:33 <sujith_h> bart0sh: Can you try with: http://pastebin.com/vXtrD74b ?
Aug 10 13:11:41 <tmcguire> bluelightning: ah ok, I am not familar how the image building process works, I thought everything would end up in a sysroot directory for the target before the SD card image is built.
Aug 10 13:12:44 <bluelightning> tmcguire: right, you may be confusing the sysroot (which is used where one recipe needs files produced by another, for example library linking, headers etc.) with the rootfs directory we assemble for the image (the rootfs subdirectory under the workdir for the image)
Aug 10 13:13:22 <khalebios> this example doenst xork for me
Aug 10 13:13:23 <tmcguire> right, I confused the two, let me check the rootfs
Aug 10 13:13:26 <khalebios> work*
Aug 10 13:14:26 <bluelightning> khalebios: have you tested this *exact* example?
Aug 10 13:15:37 <khalebios> let me retry again
Aug 10 13:15:49 <sm0ketst> bluelightning: thanks a lot!
Aug 10 13:20:37 <khalebios> after a retry .nothing change
Aug 10 13:22:23 <khalebios> my bitbake version: BitBake Build Tool Core version 1.20.0, bitbake version 1.20.0
Aug 10 13:22:57 <bluelightning> khalebios: I'm fairly sure this does work
Aug 10 13:26:34 <khalebios> one question. does this changes be taken on account in my core-image-minimal ... command?
Aug 10 13:28:02 <bluelightning> khalebios: yes; and I just tested here - it works
Aug 10 13:29:01 <tmcguire> bluelightning: thanks for your hint - /usr/bin/perf is present in rootfs. Upon further debuggging, it turned out I used dd on the wrong partition, hence the new image never ended up on the SD card...
Aug 10 13:29:05 <bluelightning> khalebios: what is your FILESEXTRAPATHS line and what is the relative path from the recipe to the file?
Aug 10 13:29:14 <tmcguire> Now I know a bit more of the system, that's useful :)
Aug 10 13:29:17 <bluelightning> khalebios: (the replacement interfaces file)
Aug 10 13:29:23 <khalebios> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"  ?
Aug 10 13:29:44 <bluelightning> khalebios: right, and the relative path to the file?
Aug 10 13:30:24 <bluelightning> tmcguire: ah ok - I hope the accidental destination wasn't a device with valuable data on it...
Aug 10 13:30:34 <tmcguire> luckily not.
Aug 10 13:31:00 <bluelightning> tmcguire: you may wish to start using scripts/contrib/ddimage - it has some safeguards built in (including printing out info about the target device)
Aug 10 13:31:13 <khalebios> init-ifupdown/init-ifupdown-1.0/npe-x1000
Aug 10 13:31:24 <khalebios> where npe-x1000 is my repo
Aug 10 13:32:06 <khalebios> sorry my machine
Aug 10 13:32:11 <bluelightning> khalebios: the recipe is in that init-ifupdown directory though right?
Aug 10 13:32:16 <tmcguire> bluelightning: thanks for the hint, looks useful.
Aug 10 13:32:44 <khalebios> yes
Aug 10 13:33:29 <khalebios> in recipes-core directory
Aug 10 13:33:38 <bluelightning> khalebios: does bitbake-layers show-appends list your bbappend? if so, does it list any others for init-ifupdown?
Aug 10 13:36:52 <khalebios> yes
Aug 10 13:37:11 <bluelightning> khalebios: was that yes to the first or the second question?
Aug 10 13:38:00 <khalebios> Sorry. Yes bitbake list my bbappend. But i have two bbappendfor init-ifupdown
Aug 10 13:38:06 <khalebios> init-ifupdown_1.0.bb:   (hide)../meta-fsl-arm-extra/recipes-core/init-ifupdown/init-ifupdown_1.0.bbappend   (hide)../meta-npe-x1000/recipes-core/init-ifupdown/init-ifupdown_1.0.bbappend
Aug 10 13:39:33 <bluelightning> khalebios: if you rename the meta-fsl-arm-extra one temporarily does it fix the issue?
Aug 10 13:46:38 <khalebios> now i have only one bbappend for init-ifupdown
Aug 10 13:48:23 <khalebios> I re-run my bitbake command for my filesystem.
Aug 10 13:48:29 <khalebios> no changes
Aug 10 13:49:53 <khalebios> <bluelightning>: how can i know the order of the modification when i run my bitbake command?
Aug 10 13:50:54 <bluelightning> khalebios: check log.do_fetch for init-ifupdown, it will tell you where it looked for the file
Aug 10 13:52:32 <khalebios> in whixh directory?
Aug 10 13:52:45 <khalebios> in which directory?
Aug 10 13:53:15 <bluelightning> khalebios: under temp in the workdir for init-ifupdown, which you can find with: bitbake -e init-ifupdown | grep ^WORKDIR=
Aug 10 14:05:42 <khalebios> <bluelightning> : i find several directory of init-ifupdown  in my do_fetch file.
Aug 10 14:07:37 <bluelightning> khalebios: just before we dig into this too deeply - the interfaces file in the package/ subdirectory of the workdir - is it yours or some other file?
Aug 10 14:10:01 <khalebios> can u look at this http://pastebin.com/hewskjCC ?
Aug 10 14:12:54 <bluelightning> khalebios: is that the entire file or have you cut parts out of it?
Aug 10 14:15:47 <sujith_h> bart0sh: This is the data I have in my machine for orm_layer table: http://pastebin.com/7cRLJSmU
Aug 10 14:16:08 <khalebios> this is my all do_fetch log for init-ifupdown
Aug 10 14:20:13 <bluelightning> khalebios: I don't see "interfaces" mentioned in that file at all, that is odd
Aug 10 14:20:29 <bluelightning> khalebios: you aren't changing SRC_URI are you?
Aug 10 14:21:48 <khalebios> SRC_URI .... ? in Which file?
Aug 10 14:23:53 <khalebios> <bluelightning> : I yes verify that bitbake copy my interfaces file in the working directory
Aug 10 14:23:59 <khalebios> i just*
Aug 10 14:24:55 <bluelightning> khalebios: so it's in package/ as well?#
Aug 10 14:25:46 <khalebios> yes
Aug 10 14:26:49 <khalebios> i have the correct file in this directory .../package/etc/netwok
Aug 10 14:31:11 <bluelightning> khalebios: ok then... so go to the workdir for the image recipe you're building and look in rootfs/etc/network/interfaces - which file is it ?
Aug 10 14:34:02 <khalebios> it's my file
Aug 10 14:34:14 <bluelightning> right
Aug 10 14:34:26 <bluelightning> how were you determining this hadn't all worked, then ?
Aug 10 14:34:41 <bart0sh> sujith_h: I've got this error when trying to load your config: https://gist.github.com/bart0sh/441fe18d915acd1c30c5
Aug 10 14:35:42 <khalebios> I make my rootfs image. I run in my device and i look in my interfaces setting .
Aug 10 14:35:52 <bluelightning> khalebios: right now it sounds like when you thought you'd written the updated image to the target device/media, that didn't work properly - because the image definitely has the updated file in it
Aug 10 14:36:34 <khalebios> i have my all interface in dhcp setting .... and I want eth0 to be static
Aug 10 14:37:06 <khalebios> I don't think so
Aug 10 14:37:47 <bluelightning> ok, if you think that can't be true - mount or unpack the image file, then you'll know for sure
Aug 10 14:38:13 <khalebios> I erase the fs.jfff2 file and after i upload it. I do the same command for my uImage I see the changes in he kernel version
Aug 10 14:40:05 <bluelightning> uImage is just the kernel image though right? it's not actually a file system image
Aug 10 14:40:25 <khalebios> yes I know.
Aug 10 14:40:35 <bluelightning> ok, so it's not the same thing
Aug 10 14:40:45 <khalebios> for my file system it is fs.jffs2
Aug 10 14:43:45 <bluelightning> khalebios: so I would suggest mounting that and checking which interfaces file is in it
Aug 10 14:43:50 <khalebios> so. In my bootloader ... I erase my rootfs image with  : nand erase.part rootfs; I do it to Time
Aug 10 14:44:22 <khalebios> two times..
Aug 10 14:44:47 <khalebios> and after i run this : nand erase.part rootfs; tftp 0x78000000 fs.jffs2; nand write.trimffs 0x78000000 rootfs ${filesize}
Aug 10 14:45:04 <bluelightning> I've honestly got no way to verify if that's correct or not
Aug 10 14:45:14 <bluelightning> it's completely specific to your machine and bootloader setup
Aug 10 14:45:26 <khalebios> so i have my rootfs image running now. but my interfaces file isn't the right one
Aug 10 14:45:38 <bluelightning> please just mount the image...
Aug 10 14:47:12 <khalebios> It's done.
Aug 10 14:47:19 <khalebios> but no changes.
Aug 10 14:48:03 <bluelightning> ok, so how does that fs.jffs2 get created?
Aug 10 14:48:57 <khalebios> I am going to do one other test. modify all my interfaces files in my meta-* directories . and then may be i will know which one is taken in my do_rootfs
Aug 10 14:49:44 <bluelightning> I doubt that will help
Aug 10 14:50:15 <bluelightning> you've already verified that your custom file is in the rootfs directory, that means everything up to that point has worked as it should
Aug 10 14:50:37 <bluelightning> any problem that exists must be after that point
Aug 10 15:18:01 <khalebios> bluelightning: I am back !!
Aug 10 15:19:28 <khalebios> my rootfs/etc/network/interfaces in tmp/work/ if the one i want. from the init-ifupdown-1.0.bbapend file
Aug 10 15:19:58 <khalebios> the same in the rootfs/etc/network/interfaces
Aug 10 15:20:18 <bluelightning> I thought that was the state before ?
Aug 10 15:20:47 <khalebios> i thing that bitbake just use the one from download package
Aug 10 15:21:04 <khalebios> yes it was the state before.
Aug 10 15:21:22 <khalebios> I hust want to tell you that nothing changes after my last try
Aug 10 15:24:11 <khalebios> I just want to tell you that nothing changes after my last try.
Aug 10 15:25:30 <bluelightning> you didn't really answer my last question - how is that fs.jffs2 being created?
Aug 10 15:38:50 <khalebios> have a look on this : http://pastebin.com/KkTibh4i
Aug 10 15:39:24 <khalebios> it is my micro-base-image .bb file
Aug 10 15:41:48 <bluelightning> khalebios: the reason I ask is, a .jffs2 file written out by our system when IMAGE_FSTYPES = "jffs2" wouldn't be called fs.jffs2, it would be called <imagename>.jffs2 - so I was trying to find out what process might be creating that if it wasn't the standard one
Aug 10 15:45:27 <khalebios> Ok. I understand.
Aug 10 15:50:00 <khalebios> <bluelightning> : do you find a mistake in my bb file?
Aug 10 15:51:28 <bluelightning> khalebios: well, neither of ROOTFS_POSTPROCESS_COMMAND nor IMAGE_PREPROCESS_COMMAND are going to work as you're setting them, you need to define shell functions containing those commands and add them to the variable value instead
Aug 10 15:51:42 <bluelightning> but that's got nothing to do with the problem at hand
Aug 10 17:26:10 <kergoth> RP1: Any thoughts on the implementation of git shallow clones, by chance? Afaict it won't be doable in a clean way without modifying the fetch2 core, was hoping to avoid that, but don't think it'll be possible
Aug 10 17:38:06 <khem`> shallow clones would be quite sensible thing to do
Aug 10 17:45:40 <kergoth> khem`: actual shallow clones aren't viable, though, since we don't know the depth from branch= to SRCREV, unless we hardcode that in a url parameter. but shallow clone mirror tarballs, those would work and be useful
Aug 10 17:45:54 <kergoth> working on a design for that
Aug 10 17:52:57 <khem`> kergoth: correct it has to be a wrapped solution
Aug 10 18:14:16 * kergoth ponders
Aug 10 18:16:02 <kergoth> khem`: my issue is, I don't want shallow clones to end up in ${DL_DIR}/git2/, since that could lead to potential problems if you have multiple recipes doing shallow and non-shallow simultaniously. better to fetch a shallow tarball and unpack it either into its own dir under DL_DIR, or better yet just unpack it directly into workdir. but i still want it to fall back to a non-shallow mirror tarball fetch, and the localpath() of the url ends up different
Aug 10 18:16:02 <kergoth>  between the two..
Aug 10 18:16:35 <khem`> yeah shallow clones are more like tarball downloads
Aug 10 18:16:41 <kergoth> indeed
Aug 10 18:16:44 <khem`> thats how I think it should be treated
Aug 10 18:19:41 <kergoth> sadly you can't just use a different fetcher as a premirror, which was my initial thought, as even when using a mirror, it still checks for the localpath of the original urldata to determine if the fetch succeeded.. since the tar fetch didn't create the dir under git2, it'll assume the fetch failed. might need to introduce an indirection there, add support to the git fetcher directly, and make its localpath point to a done stamp
Aug 10 18:22:54 <kergoth> maybe it'd be better handled in the metadata in do_fetch. for each git uri, checkstatus the shallow mirror tarball, try to get it, if we can, replace the git uri in SRC_URI entirely before we pass it off to the fetcher :)
Aug 10 18:23:32 <kergoth> course then revision checking and whatnot would be problematic
Aug 10 18:38:46 <rburton1> kergoth: just rewrite the fetchers, can't be that hard
Aug 10 18:38:55 * rburton1 sniggers
Aug 10 18:41:49 * kergoth shudders
Aug 10 19:27:29 <fishey1> So I'm using linux-yocto-custom, what is the right way to handle all of the kernel module packages so they don't complain about PREFERRED_PROVIDERS?
Aug 10 19:44:20 <otavio> rburton: hello
Aug 10 19:44:25 <rburton> hi otavio
Aug 10 19:44:32 <otavio> rburton: please take a look at the mesa and mesa-demos fixes
Aug 10 19:44:46 <otavio> rburton: also wpa-supplication CVE patch
Aug 10 19:45:03 <otavio> rburton: those are the three patches I sent while you were out ;)
Aug 10 19:45:05 <otavio> :)
Aug 10 19:45:10 <rburton> wpa merged to mut already
Aug 10 19:45:13 <rburton> will find mesa ones :)
Aug 10 19:46:07 <rburton> otavio: can't see anything from you about mesa
Aug 10 19:47:28 <otavio> rburton: I can resend
Aug 10 19:47:54 <otavio> rburton: resent as v2
Aug 10 19:56:26 <rburton> otavio: recent mesa doesn't provide openvg
Aug 10 19:56:40 <rburton>     mesa: upgrade 10.5.8 -> 10.6.3
Aug 10 19:56:41 <rburton>     * Removed openvg references in PACKAGECONFIG, FILES and PACKAGES since OpenVG
Aug 10 19:56:41 <rburton>       support was removed in mesa 10.6
Aug 10 20:18:44 <RP1> kergoth: I've not really had a chance to think about the details, no :/
Aug 10 20:18:58 <kergoth> no worries, i know you have a lot on your plate, i'll get something figured out eventually
Aug 10 20:19:23 <kergoth> just not as intimately familiar with the fetch internals, but that's starting to change, whether i like it or not :P
Aug 10 20:20:10 <RP1> kergoth: there are some interesting subtleties in there, for better or worse. The test suite at least manages to test the basics at least...
Aug 10 20:20:24 <kergoth> cool, will keep that in mind
Aug 10 20:24:33 <RP> kergoth: the mapping to a different url type using our mirror code does seem like a reasonable idea though FWIW
Aug 10 20:26:46 <kergoth> the issue is i'd need the mirror's fetcher to be used for localpath and unpack rather than the main url fetcher, i think.. maybe i could pass the mirror urldata into the appropriate method(s) of the main fetcher and let it decide whether how it was fetched matters to it or not
Aug 10 20:31:57 <thunders> Hi everybody
Aug 10 20:36:38 <thunders> I'm currently experiencing an issue during the creation of an image. I 've got an error during do_rootfs and I don t really know what's happening
Aug 10 20:36:54 <thunders> Could someone help or drive my in the right direction ?
Aug 10 20:37:26 <kergoth> Actually, I think it might be cleaner to let the git fetcher handle it entirely. I'd just need to add support for 1) multiple mirror tarballs in the core, and either using a stamp for localpath or adjusting localpath in Git.download() based on what we have, or 2) avoid the hardcoded knowledge of mirror tarballs in the core at all, in favor of use of explicit mirror tarball / shallow tarball name substitution in MIRRORS/PREMIRRORS along the lines of
Aug 10 20:37:26 <kergoth>  MIRRORNAME, coupled with passing the mirror urldata which was used into the download()/unpack() calls
Aug 10 20:37:40 <kergoth> thunders: post the log to a pastebin
Aug 10 20:37:52 <thunders> Here is the pastebin : http://pastebin.com/UVJQewtN
Aug 10 20:38:16 * kergoth has no idea on that one, sorry, probably one of the intel folks will know though
Aug 10 20:42:39 <thunders> Thanks kergoth :-)
Aug 10 20:48:09 * kergoth ponders
Aug 10 20:49:10 <thunders> The main issue is related to /home/thunders/yocto-fido/build/tmp/deploy/images/wandboard-quad/bootscript-wandboard-quad: No such file or directory . I don t know why it needs this file/directory or what should feed it... Thanks in advance for your help
Aug 10 20:56:50 * kergoth mulls over multiple options for supporting multiple mirror tarballs in the fetch core
Aug 10 22:36:54 <benjamirc> halstead: PM
Aug 11 00:02:00 <kergoth> hmm, anyone know if it's possible to fetch multiple git branches shallow with different depths? I think I might need to manually construct the graft(s) that it usually does automatically after touching the shallow file
Aug 11 00:06:20 <kergoth> ah, good, .git/shallow can contain multiple refs, was wondering about that
Aug 11 00:07:56 <kergoth> more than that, you can set up .git/shallow manually, and ahead of time, and fetch will obey it when determining what objects to get
Aug 11 00:08:10 <kergoth> basically i can shove every SRCREV for every name in ud.names into that file and run git fetch
Aug 11 00:08:18 <kergoth> nice
Aug 11 00:09:01 <kergoth> ah, wait, need to also limit the branches being fetched, otherwise any non-grafted branches will be fetched with full history, wouldn't want that
Aug 11 02:08:38 <parrot1> Hi, I've been getting weird error of not finding revision thingy when I use linux-yocto-dev
Aug 11 02:08:45 <parrot1> Full err msg at http://pastebin.com/eJt0m7eH
Aug 11 02:09:21 <parrot1> I don't think there's network error though since it did download the the git repo
Aug 11 02:29:26 <kergoth> there we go, fixed the expansionerror handling to be best of both worlds now, we do show a traceback, but only of the entries from the metadata, nothing from bitbake internals (previously we had none of the traceback from the metadata function calls)
Aug 11 02:29:50 <kergoth> still some minor visual issues due to how we compile the inline python, but not too bad
Aug 11 02:32:01 <kergoth> damnit, why does bitbake want a SRC_URI checksum for my mirror tarball
Aug 11 02:32:03 <kergoth> this makes no sense
**** ENDING LOGGING AT Tue Aug 11 02:59:58 2015