**** BEGIN LOGGING AT Thu Apr 16 02:59:59 2015
Apr 16 05:22:32 <mimetonbo> redengin here?
Apr 16 07:08:40 <jaeckel> good morning
Apr 16 07:09:07 <jaeckel> is there anything special I have to do to create a core dump of a killed process?
Apr 16 07:20:02 <lpapp> good morning
Apr 16 07:20:06 <lpapp> kergoth: are you around by any chance?
Apr 16 08:18:44 <jaeckel> it was a missing CONFIG_ELF_CORE setting in the kernel
Apr 16 08:33:43 <mckoan> good morning
Apr 16 08:33:58 <bluelightning> morning mckoan, all
Apr 16 08:34:31 <mckoan> hi bluelightning
Apr 16 09:45:07 <_jmleo> morning
Apr 16 09:45:38 <_jmleo> I am trying to compile perf with yocto and the latest 4.0 kernel. And I have an error I didn't have before : config/Makefile:254: *** No gnu/libc-version.h found, please install glibc-dev[el].  Stop.
Apr 16 09:53:58 <_jmleo> I have to add includedir in the bb recipe :diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
Apr 16 09:53:58 <_jmleo> index 19772d8..ca957ea 100644
Apr 16 09:53:58 <_jmleo> --- a/meta/recipes-kernel/perf/perf.bb
Apr 16 09:53:58 <_jmleo> +++ b/meta/recipes-kernel/perf/perf.bb
Apr 16 09:53:59 <_jmleo> @@ -85,6 +85,7 @@ EXTRA_OEMAKE = '\
Apr 16 09:54:00 <_jmleo>  
Apr 16 09:54:02 <_jmleo>  EXTRA_OEMAKE += "\
Apr 16 09:54:04 <_jmleo>      'prefix=${prefix}' \
Apr 16 09:54:08 <_jmleo> +    'includedir'={includedir}' \
Apr 16 09:54:10 <_jmleo>      'bindir=${bindir}' \
Apr 16 09:54:12 <_jmleo>      'sharedir=${datadir}' \
Apr 16 09:54:14 <_jmleo>      'sysconfdir=${sysconfdir}' \
Apr 16 10:09:21 <_jmleo> still not working I would say, as I now get a "perf not found in the base feeds". In fact, I have perf-dbg and perf-dev rpms but no perf rpm
Apr 16 10:12:27 <_jmleo> noticed the error in my includedir line, and yet, still the compilation error... rha !
Apr 16 10:12:37 <bluelightning> that suggests to me that it didn't install anything during do_install
Apr 16 13:03:01 <cart_man> Hey whts the difference between the image-sato-dev and the image-sato-sdk packages?
Apr 16 13:39:52 <rburton> cart_man: -dev has just development headers -sdk has far more tooling
Apr 16 13:39:58 <lpapp> hi, which is task to pass to bitbake -c to get the state before the patch task is run?
Apr 16 13:40:04 <lpapp> I want to get the original content in there.
Apr 16 13:40:14 <lpapp> I could possible say -c fetch and get the tarball
Apr 16 13:40:17 <lpapp> but that is not yet extracted.
Apr 16 13:40:41 <lpapp> -c unpack?
Apr 16 13:53:17 <mimetonbo> hi can anyone help me with a yocto build on the cyclone5 platform
Apr 16 13:53:24 <mimetonbo> Im facing certain issues with it
Apr 16 14:27:13 <kergoth> lpapp: yep, unpack
Apr 16 14:27:33 <kergoth> fetch, unpack, patch, configure, compile, install, populate_sysroot, package, packagedata, package_write*, basically
Apr 16 14:27:37 <lpapp> yes, worked half an hour ago
Apr 16 14:27:38 <lpapp> :-)
Apr 16 14:27:47 <lpapp> btw, I went ahead with the issue yesterday
Apr 16 14:27:53 <lpapp> Are you interested in my findings?
Apr 16 14:27:59 <kergoth> yeah, definitely, any progress?
Apr 16 14:28:02 <lpapp> I can now say that for sure it is an issue in the Yocto environment
Apr 16 14:28:09 <lpapp> cause I wrote a simple lib calling pthread_atfork
Apr 16 14:28:19 <lpapp> in a foo function, and app with a simple main function calling that foo
Apr 16 14:28:22 <lpapp> and I can reproduce the issue
Apr 16 14:28:23 <lpapp> BUT
Apr 16 14:28:40 <lpapp> if I try to reproduce it on my host, either debian or archlinux, I cannot
Apr 16 14:28:41 <lpapp> it just works.
Apr 16 14:28:57 <lpapp> Furthermore, if I replace pthread_atfork with pthread_create for instance or pthread_cancel, it just works even inside Yocto
Apr 16 14:29:11 <lpapp> so it is possibly a broken toolchain version in Yocto or something
Apr 16 14:29:30 <lpapp> I have all the simple files to reproduce the issue. I was going to submit it on the bugtracker.
Apr 16 14:29:35 <kergoth> Hmm, perhaps it's a glibc version thing? I wonder what version it was moved from the .so to the .a
Apr 16 14:29:42 <kergoth> sounds reasonable
Apr 16 14:30:02 <lpapp> my current workaround will be -shared
Apr 16 14:30:12 <lpapp> but in general, this is a very weird linkage process
Apr 16 14:30:26 <lpapp> libgpib does not link against libpthread even though that is the one using pthread_atfork
Apr 16 14:30:38 <lpapp> and instead the gpib app links against both which is not using any pthread directly.
Apr 16 14:30:52 <lpapp> and the libgpib library is dynamic, yet gpibapp links against pthread statically
Apr 16 14:30:55 <lpapp> it is a bit of mess IMHO :)
Apr 16 14:37:07 <kergoth> Indeed. Maybe they don't want the static pthread_atfork sucked into libgpib to avoid conflicts with apps that link against libpthread_nonshared.a themselves? *shrugs* not sure as to best practice when both shared and static libs are involved like that.
Apr 16 14:40:36 <kergoth> if anyone didn't see the email from them: "A member of the Archive Team graciously offered to host gitorious.org as a read-only archive on Gitorious.org and GitLab agreed to allow to use the Gitorious.org domain name for this.", so will still be able to clone read only repos from there for a while even after the hsutdown
Apr 16 15:04:49 <bluelightning> kergoth: thanks, I hadn't seen that - nice
Apr 16 15:05:29 <lpapp> kergoth: yes.
Apr 16 15:13:55 <kergoth> Has anyone else tried building a target gcc with an external toolchain? Seems like all manner of difficulty, since the libgcc/gcc-runtime bits extracted from the external toolchain reside in gcc version + target_sys specific paths, and clearly are bound to that particular gcc version..
Apr 16 15:14:15 <lpapp> kergoth: I do not know a workaround for this issue yet though ...
Apr 16 15:14:19 <kergoth> guess ideally the external toolchain would include a target gcc we could extract which aligns with the external toolchain, or build it from its same gcc sources
Apr 16 15:14:32 <lpapp> unless I can somehow specify that I want to link dynamically rather than staticlaly.
Apr 16 15:14:35 <lpapp> statically*
Apr 16 15:14:49 <lpapp> first I thought -static would do a good job in there, but that is for library creation and not use.
Apr 16 15:34:34 <mimetonbo__> anyone working with yocto on the cyclone 5 platform?
Apr 16 15:46:55 <fishey1> Anyone know how to get meta-qt5 to build qdbus as part of qttools?
Apr 16 15:52:43 <lpapp> what have you tried?
Apr 16 15:54:33 <fishey1> lpapp: I've tried adding IMAGE_INSTALL += "qttools". It appears to install qttools, but qttools (for some reason) doesn't include qdbus. Using 'find' a bunch on tmp/work indicates it hasn't been built at all.
Apr 16 15:55:25 <fishey1> I've also tried qttools-tools
Apr 16 16:20:12 <lpapp> hi, is this a known issue? https://paste.kde.org/pcv1pn592
Apr 16 16:21:08 <lpapp> some bfd issue in there...
Apr 16 16:26:45 <lpapp> x86_64-linux/binutils-native/2.23.1-r3/binutils-2.23.1/bfd/opncls.c:264:5: note: in expansion of macro 'bfd_set_cacheable'
Apr 16 16:26:48 <lpapp> is it a known issue?
Apr 16 16:26:57 <lpapp> I really need to get a build out of the door and this got in my way :-(
Apr 16 16:29:06 <kergoth> from some quick googling: https://sourceware.org/ml/binutils/2014-01/msg00334.html seems appropriate
Apr 16 16:29:15 <kergoth> see also https://sourceware.org/ml/binutils/2014-01/msg00336.html and https://sourceware.org/ml/binutils/2014-01/msg00323.html
Apr 16 16:32:34 <lpapp> yeah, but why did it work for me before on the same machine with the same dylan?
Apr 16 16:33:20 <lpapp> I have been building from our dylan branch for ages and now that I just cloned the branch from a fresh state, it started happening...
Apr 16 16:34:21 <bluelightning> this is native, so, maybe a host distro change of some sort?
Apr 16 16:35:50 <lpapp> unlikely as I have not changed the debian for a long time
Apr 16 16:35:56 <lpapp> either way, how can I fix and move along?
Apr 16 16:36:07 <moto-timo> what makes my meta-python patch 7/7 not show up in patchwork?
Apr 16 16:37:06 <lpapp> I am a bit frustrated now. :/
Apr 16 16:38:00 <lpapp> I have other errors, too. :( https://paste.kde.org/plaxd3ght
Apr 16 16:38:09 <lpapp> I wonder what on earth happened to my Yocto repository!
Apr 16 16:38:23 <bluelightning> that second one is definitely a host issue
Apr 16 16:38:24 <kergoth> lpapp: khem put the fix for this on the dylan branch 6 days ago, as far as i can see
Apr 16 16:38:33 <kergoth> lpapp: "binutils: Fix building nativesdk binutils with gcc 4.9"
Apr 16 16:38:58 <lpapp> oh gosh
Apr 16 16:39:01 <kergoth> well, thats the commit date, not the merge/push date, but still
Apr 16 16:39:02 <bluelightning> well, host- triggered; IIRC there is a patch for it probably went in after dylan
Apr 16 16:39:05 <lpapp> I ran this stuff outside my debian chroot!
Apr 16 16:39:08 <lpapp> on the arch box!!!!
Apr 16 16:39:09 <kergoth> that'd do it
Apr 16 16:39:14 <bluelightning> bingo ;)
Apr 16 16:39:38 <lpapp> quite annoying to have chroot for this as you can see.
Apr 16 16:39:49 <lpapp> but Arch will never work out of the box :(
Apr 16 16:40:17 <bluelightning> FWIW, someone told me he regularly runs builds on Arch with current releases, so it is possible - there just aren't any guarantees, and for stable releases, well, that's not going to work
Apr 16 16:40:18 <kergoth> given arch uses rolling releases, i'd imagine there'd always be problems with older branches that'd require fixing
Apr 16 16:40:28 <kergoth> i used to do builds on arch pretty regularly with master, but it was a while ago
Apr 16 16:40:29 <kergoth> bluelightning: :)
Apr 16 16:40:42 <lpapp> ah, the funny things, screen dit not get the fact that it was in chroot
Apr 16 16:40:54 <lpapp> so it started the screen with the debian console and another arch
Apr 16 16:41:01 <lpapp> I thought screen just worked in chroot
Apr 16 16:41:03 <lpapp> lesson learnt
Apr 16 16:42:41 <bluelightning> moto-timo: good question... can't see what would have caused that :(
Apr 16 16:42:42 <lpapp> it is an interesting question why screen does not respect "systemd-nspawn" or the other way around
Apr 16 16:43:24 <moto-timo> bluelightnin: I suspect it's the comma in python-cryptography,-vectors...but that's just a hunch
Apr 16 16:43:29 <moto-timo> g
Apr 16 16:44:11 <moto-timo> NooB question... can you increase RAM size in qemu?
Apr 16 16:45:10 <bluelightning> hmm, could be that... I know it chokes on some other things
Apr 16 16:45:31 <bluelightning> moto-timo: you can but IIRC there are some hardcoded limits for some architectures
Apr 16 16:46:24 <moto-timo> bluelightning: ptest on python-cryptography chokes qemu RAM, so it would be nice to figure out
Apr 16 16:47:07 <moto-timo> of course 75k unit tests will cause stress...
Apr 16 16:48:39 <bluelightning> moto-timo: basically you should be able to pass qemuparams=-m<number> on the runqemu command line
Apr 16 16:59:31 <moto-timo> bluelightning: great, I'll test that after work
Apr 16 17:46:41 <Crofton|work> zeddii, http://git.yoctoproject.org/cgit/cgit.cgi/meta-cloud-services/tree/meta-openstack/recipes-devtools/python/python-thrift_0.9.1.bb?h=master
Apr 16 17:46:46 <Crofton|work> PR is deprecated
Apr 16 17:46:52 <Crofton|work> also I need 0.9.2 :)
Apr 16 17:52:45 <zeddii_home> Crofton|work: a mass update is about to happen. shiny new versions for everything, the OpenStack releases are all stepping forward.
Apr 16 17:53:24 <Crofton|work> I'd liek to get it into meta-python so I do not need to carry openstack just to get some python :)
Apr 16 17:53:54 <moto-timo> Crofton|work: give me a list you want in meta-python
Apr 16 17:54:10 <Crofton|work> right now, just thrift :)
Apr 16 17:54:14 <zeddii_home> heh. people can do the copies. but my objections to generic categorization remain, so I’ll have duplication for the most part.
Apr 16 17:54:17 <Crofton|work> we'll want it for gnuraido soon
Apr 16 17:54:27 <zeddii_home> until meta-python is a separate git repo, or there’s a reference count on versions.
Apr 16 17:54:37 <Crofton|work> also, I think it might need some DEPENdS
Apr 16 17:54:56 <moto-timo> had some discussion with bruce about making the crypto recipes in meta-python separate as well
Apr 16 17:55:04 <zeddii_home> Crofton|work: similarly, I can’t take the churn of meta-oe just to get some python ;)
Apr 16 17:55:41 <moto-timo> I'll get what you want into meta-python... just ask
Apr 16 17:56:00 <Crofton|work> I can send it in also
Apr 16 17:56:01 <moto-timo> as for spinning it to a separate layer... bluelightning?
Apr 16 17:56:26 <Crofton|work> this just came up in the gnuradio dev call and I am glad to see we have a start, but they need to rev bump
Apr 16 17:57:01 <zeddii_home> if it’s a separate layer, with some level of version pinning possible .. we have a solution for me to move most python libs out. otherwise, I’m stuck.
Apr 16 17:57:08 <bluelightning> moto-timo: I wouldn't mind a separate repo if that helps others
Apr 16 17:57:31 <moto-timo> also, dividing into functional groups (recipes-security, etc)
Apr 16 17:57:42 <bluelightning> right, we can do that too
Apr 16 17:58:03 <zeddii_home> bluelightning: I wonder if it would be possible (since the layer index already knows), to know if a dependent layer is using a version ? (obviously that layer is registered and known).
Apr 16 17:58:35 <bluelightning> what do you mean by using a version?
Apr 16 17:58:57 <zeddii_home> meaning I have specific version requirements in OpenStack
Apr 16 17:59:11 <zeddii_home> if someone bumps a version above what works .. I’m in debug hell.
Apr 16 17:59:25 <zeddii_home> so we could add a new version, versus a replacement in that case. otherwise, I have to copy everything.
Apr 16 17:59:41 <bluelightning> wouldn't it be better to support one of the release branches, where we never do upgrades?
Apr 16 17:59:51 <moto-timo> +1
Apr 16 18:00:15 <zeddii_home> for the most part, yah. but that still leads me to combo layer hell .. but that’s not everyone worry, that’s mine.
Apr 16 18:00:34 <zeddii_home> meaning, I have to stay with an old release because of one damanged component .. that’s my problem :)
Apr 16 18:01:00 <bluelightning> well, honestly I worry for people doing anything serious on master, if you do that you are already opening yourself up to pain...
Apr 16 18:01:11 <zeddii_home> really >
Apr 16 18:01:18 <bluelightning> not that we ever intentionally break anything, but stuff does break
Apr 16 18:01:27 <zeddii_home> development happens on master in my woo.rd
Apr 16 18:01:33 <zeddii_home> or
Apr 16 18:01:49 <bluelightning> sure, development does
Apr 16 18:01:58 <moto-timo> we could definitely pin version(s) in a release branch though
Apr 16 18:01:58 <bluelightning> but to expect that to be stable, that is another thing entirely
Apr 16 18:02:01 <zeddii_home> and that’s what I’m talkign about.
Apr 16 18:02:20 <zeddii_home> analog series of version bumps, when there is a way to know, just forces everyone to chase their tail.
Apr 16 18:03:07 <moto-timo> seems like we would need to put a note in the recipe(s) to help remind us that other users depend on the particular version
Apr 16 18:03:12 <zeddii_home> I’m still making meta-c though ;)
Apr 16 18:03:24 <bluelightning> funny ;)
Apr 16 18:03:31 <moto-timo> meta-cobol
Apr 16 18:03:54 <bluelightning> anyway I have to head to the train
Apr 16 18:04:14 <moto-timo> ponder the ideas and we can discuss more
Apr 16 18:04:29 <moto-timo> I'm open to change and maintainence that will insue
Apr 16 18:04:34 <bluelightning> I really do want us to work together on solving this though, I'll be back on later most likely
Apr 16 18:05:02 <moto-timo> otherwise meta-python is just a hodge podge with no umbrella purpose
Apr 16 18:06:16 <zeddii_home> that’s the big test/quality thing. couple some sort of application to drive them.
Apr 16 18:06:17 <bluelightning> bbl
Apr 16 18:06:24 * zeddii_home disapears for a bit as well.
Apr 16 18:14:59 * moto-timo is not opposed to a testing/quality framework for meta-python
Apr 16 20:03:51 <Cardoe> I have an at91 based device which loads its kernel from NAND. I'm looking to make kernel images available as updates and have opkg's being built but they get installed into /boot. Is there some blessed mechanism to add some rules to that kernel package to nandflash it? I thought I would make a script that does that part and then bbappend the script to the linux-image package. But what I don't know is how I can automatically run that script when the p
Apr 16 20:03:51 <Cardoe> is installed.
Apr 16 20:13:13 <vmrod25_>  /msg NickServ VERIFY REGISTER vmrod25_ pnqspzxyuoyn
Apr 16 20:13:39 <mario-goulart> nice password. :-)
Apr 16 20:14:43 <kapare> Hi there! Just having issue to configure powertop after update on daisy (1.6.3, I think we are at rc3 now) branch. Anyone had such problem ?
Apr 16 20:15:14 <kapare> configure: error: C compiler cannot create executables
Apr 16 20:37:11 <kapare> hmm so it basically search for checking for C compiler version, with -v, -V -qversion, then doesn't found it, here the log: https://gist.github.com/kapare/b5d6ba750d1b3252085f
Apr 16 21:26:46 <xulfer> Anyone have suggestions for debugging a build failure?  Maybe a way to use devshell to run the build and tweak it manually?
Apr 17 00:09:32 <chankit> hey....is CORE_IMAGE_EXTRA_INSTALL = "packagename" the correct way to add packages?
**** ENDING LOGGING AT Fri Apr 17 02:59:58 2015