**** BEGIN LOGGING AT Thu Feb 02 03:00:02 2017 Feb 02 07:50:33 When I do bitbake imx-gpu-viv , do see imx-gpu-viv-1_5.0.11.p4.5-hfp-r0.bb is getting picked but I want it should pick imx-gpu-viv_5.0.11.p7.1-hfp.bb file Feb 02 07:50:43 what I need to do ? Feb 02 08:20:45 Ramose_: different names imx-gpu-viv-1 vs imx-gpu-viv Feb 02 08:39:16 Yocto seems to assume a resistive touchscreen, I have capacitive. x11common rdepends on xinput-calibrator, I can override/patch it out but think there must be a better way? Feb 02 08:43:01 good morning Feb 02 08:44:58 howdy mckoan Feb 02 08:47:17 shiftee_: don't think there's another way. Feb 02 08:48:19 okay, thanks Feb 02 08:58:26 ernstp: ok but when I give bitbake imx-gpu-viv, why by default it picks mx-gpu-viv-1_5.0.11.p4.5-hfp-r0.bb ? Feb 02 09:02:10 Ramose_: maybe its the version number not a different recipe? "1_5.0..."? check what recipe is being used and that will determine how to switch it. Run "bitbake -s" and look for imx-gpu-viv or imx-gpu-viv-1 Feb 02 09:06:21 Ramose_: where do the corresponding .bb files live? I guess you have a special setup... ? Feb 02 09:06:24 marquiz: I don't understand your performance machine's numbers. It is possible the previous build is still being deleted when the next one starts? The numbers just don't seem to be following the right patterns :/ Feb 02 09:06:39 nrossi: I have two different recipes imx-gpu-viv-1_5.0.11.p4.5-hfp-r0.bb and imx-gpu-viv_5.0.11.p7.1-hfp.bb , I want second to be picked up when I do bitbake imx-gpu-viv Feb 02 09:07:41 its placed under /meta-fsl-arm/recipes-graphics/imx-gpu-viv Feb 02 09:09:54 Ramose_: which version of meta-fsl-arm? i don't see the two recipes in master or krogoth Feb 02 09:11:04 nrossi: It was just containing one imx-gpu-viv-1_5.0.11.p4.5-hfp-r0.bb but I copied other one from https://github.com/sigma-embedded/elito-de.sigma-chemnitz.fsl/tree/master/recipes-graphics/imx-gpu-viv Feb 02 09:11:51 and now I want this recipe should be compiled Feb 02 09:11:57 this *new Feb 02 09:12:07 Ramose_: the file name is not that important actually Feb 02 09:12:22 are you setting PN="imx-gpu-viv-1" ? Feb 02 09:13:48 Ramose_: your recipe sets DEFAULT_PREFERENCE = "-1" Feb 02 09:14:17 so, do I need to remove it ? Feb 02 09:15:28 Ramose_: usually used for things that shouldn't be used by default (like development versions): you're expected to override that with e.g. 'PREFERRED_VERSION_ = "x.y.z"' in your local config Feb 02 09:15:57 ok Feb 02 09:16:00 let me try Feb 02 09:17:57 jku: something like this PREFERRED_VERSION_imx-gpu-viv = "5.0.11.p7.1" ? Feb 02 09:21:59 I guess I need to give full recipe name Feb 02 09:23:26 the above seems about right Feb 02 09:26:06 no, you're missing "-hfp" you can't just leave a part of the version string out Feb 02 09:27:08 (well, you can: read the yocto ref-manual for details on PREFERRED_VERSION) Feb 02 09:27:33 jku: I think, now its picked , imx-gpu-viv-1_5.0.11.p7.1-hfp-r0 do_fetch (pid 17048 Feb 02 09:28:51 Ramose_: just checking: you're aware that modern meta-fsl-arm has new versions of imx-gpu-viv? Feb 02 09:30:09 jku: Not sure about it. Feb 02 09:30:33 seems like do_fetch is stuck Feb 02 09:32:05 I guess nowadays it's meta-freescale anyway (?) Feb 02 09:32:33 jku: don't have this layer in my environment Feb 02 09:34:28 RP: you mean the rm_work test? Feb 02 09:35:05 it looks very strange, but i don't understand why, yet Feb 02 09:36:35 marquiz: the normal rootfs one. The rm_work numbers are more stable. Feb 02 09:38:47 jku: May be I should try https://patchwork.openembedded.org/patch/103549/ patch Feb 02 09:39:54 Hi guys, is it possible to ask a question about Yocto multilanguage support? Feb 02 09:40:35 Grynium: jsut go ahead. if someone knows you'll get an answer - if you don't get an answer, probably nobody knows. Feb 02 09:41:34 I'm trying to install some default locales such as: en_GB.utf8, en_US.utf8 Feb 02 09:41:52 Grynium: ...and...? Feb 02 09:41:56 I've configured the build with the following options: Feb 02 09:42:09 GLIBC_GENERATE_LOCALES="en_GB.UTF-8 en_US.UTF-8" Feb 02 09:42:23 IMAGE_LINGUAS="en-gb en-us" Feb 02 09:42:35 if I issue "locale -a" I see: Feb 02 09:42:56 C Feb 02 09:42:58 POSIX Feb 02 09:43:04 en_GB Feb 02 09:43:06 en_US Feb 02 09:43:09 stop Feb 02 09:43:25 can't see: en_GB.utf8 or something similar Feb 02 09:43:37 it seems that the utf8 variant is not installed, can't understand why Feb 02 09:46:31 what is the output of "locale -a" (or "localectl list-locales") on your side? Feb 02 09:49:26 rburton: ed2: do you think https://patchwork.openembedded.org/patch/136609/ could be merged soon? Feb 02 09:50:03 Grynium: i personally do neither use locales nor do i have a running system nearby, sorry. Feb 02 09:54:33 mborzecki: the patch looks good to me. rburton? Feb 02 09:54:46 LetoThe2nd: I'm trying to insert the support to UTF8 locales because I need to manage file names encoded with "esotic" characters Feb 02 09:55:59 Grynium: i'm absolutely not doubting your usecase, there's just nothing i could give as advice. Feb 02 09:57:24 LetoThe2nd: as of now, I can't manage files that simply contains a "é" letter in the filename Feb 02 09:57:47 LetoThe2nd: ok, many thanks for your time Feb 02 09:58:19 Grynium: good luck Feb 02 10:01:47 Just seeing this error when upgraded imx-gpu-viv, ERROR: The recipe imx-gpu-viv is trying to install files into a shared area when those files already exist. Those files and their manifest location are: Feb 02 10:03:14 mborzecki: queued locally. been ill a few days, so i'm a bit behind, sorry Feb 02 10:09:26 #brexit fever? Feb 02 10:10:05 rburton: thanks Feb 02 12:16:55 should it be possible to "reuse" the download and sstate-cache of two separate poky projects? Feb 02 12:17:13 if there's commonalities Feb 02 12:17:16 in both i build kind of equal x86-64 images Feb 02 12:17:57 If I try I get an error in poky/bitbake/lib/bb/command.py Feb 02 12:18:49 OSError: [Errno 2] No such file or directory: '~/downloads/uninative/ac......' but the foder exists? Feb 02 12:22:28 mdnneo: looks like you used ~ in a place that doesn't expand it Feb 02 12:22:33 did you set DL_DIR to ~/downloads/ Feb 02 12:22:43 because nowhere does it say that DL_DIR is shell-expanded Feb 02 12:24:23 rburton: giving the full path in local.conf fixed it ... just copy pated it from somewhere ... thx for the hint Feb 02 12:41:01 RP: where can I find the autobuilder's oe-selftest logs? Feb 02 12:41:37 RP: would like to see if the autobuilder spends as much time stuck in that one wasteful testcase as here locally :) Feb 02 12:43:41 kanavin: do you have ssh access to them? Feb 02 12:44:01 RP: some of them, and I don't remember which ones Feb 02 12:44:33 kanavin: I'd try sshing into the machine which has the run you're interested in Feb 02 12:44:49 kanavin: I assume you can't get the info from the webpage logs? Feb 02 12:45:18 RP: I can, if you point me to the webpage - I only want to know how much it took for the test case to run, on any random machine Feb 02 12:45:48 kanavin: https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/814/steps/Running%20oe-selftest/logs/stdio Feb 02 12:46:20 RP: thanks, couldn't see it in this list https://autobuilder.yoctoproject.org/main/one_line_per_build Feb 02 12:46:43 kanavin: I took it from https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest Feb 02 12:48:27 RP: test_continue (oeqa.selftest.bbtests.BitbakeTests) ... OK (332.375s) - this will go down to maybe 10 seconds. It's much, much slower for everyone else, because of completely cold download dir and sstate. Feb 02 13:05:15 Hi all, Feb 02 13:05:15 Is there a way to add usb ID's to the usbutils recipie ? Feb 02 13:05:41 For now I can install it, bit lsusb is not showing any "human readable" description of the devices Feb 02 13:10:37 i think you want to pull in udev-hwdb Feb 02 13:13:23 rburton: Hmm...... Feb 02 13:13:27 interresting Feb 02 13:14:12 But if I'm not using udev? Feb 02 13:15:54 well usbutils doesn't contain the database Feb 02 13:17:02 Yes, I know that now :) Feb 02 13:17:30 usbutils 008 changelog says Feb 02 13:17:31 Tom Gundersen (2): Feb 02 13:17:31 lsusb: port to hwdb Feb 02 13:17:31 drop dependency on usb.ids Feb 02 13:17:49 even if you don't use udev, udev-hwdb will just contain the database Feb 02 13:19:33 rburton: Ok, so simple IMAGE_INSTALL += "udev-hwdb" Feb 02 13:19:35 is not working Feb 02 13:19:40 how can I add this database? Feb 02 13:19:53 To my distro file? Feb 02 13:20:17 well, that should work assuming it actually installed Feb 02 13:22:58 rburton: I've installed DISTRO_FEATURES += "usbhost" Feb 02 13:23:09 and INSTALL_PACKAGE += "usbutils" Feb 02 13:23:24 but no data base IDs have been installed Feb 02 13:23:34 so, I'm wondering how to install missing IDs Feb 02 13:23:57 according to the usbutils changelog, it's just udev-hwdb (which should be a rdepends in usbutils) Feb 02 13:26:56 rburton: I'm using poky-morty which installs usbutils 008 Feb 02 13:26:59 http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-bsp/usbutils/usbutils_008.bb?h=master Feb 02 13:27:19 when i say should, i mean a patch needs to be sent Feb 02 13:27:59 rburton: :D Feb 02 13:31:33 RSS: 22677.25user 3238.79system 36:16.68elapsed 1190%CPU (0avgtext+0avgdata 918896maxresident)k1337920inputs+114197720outputs (320major+1366659442minor)pagefaults 0swaps Feb 02 13:31:33 Pre-RSS: 22794.25user 2687.88system 30:32.84elapsed 1390%CPU (0avgtext+0avgdata 919056maxresident)k3490608inputs+107113896outputs (506major+1422985844minor)pagefaults 0swaps Feb 02 13:31:58 so a significant increase in system time which I guess isn't surprising Feb 02 13:33:02 rburton: ANy idea of how to fix this quickly? RDEPENDS ="udev-hwdb" ? Feb 02 13:34:07 hello, has anyone here been successful enabling hardware watchdog functionality for imx6ul u-boot? I can not get it to build... Feb 02 13:35:23 jku: Are you looking at that WIP patch I had or do you want me to reply on the list with more info? I was a bit terse last night Feb 02 13:35:49 rburton: NOTE: Resolving any missing task queue dependencies Feb 02 13:35:49 ERROR: Nothing RPROVIDES 'udev-hwdb' (but /opt/eldk/build/work/lukma/yocto/MEN/poky-morty/meta/recipes-bsp/usbutils/usbutils_008.bb RDEPENDS on or otherwise requires it) Feb 02 13:36:18 eduardas_m: you may want to try the meta-freescale mailing list. Feb 02 13:36:29 rburton: How can I get this package? Enable it with udev build? Feb 02 13:37:52 stephano, I will be honest... I am trying to do this outside of Yocto... I just don't know where to ask for help on freenode on such questions elsewhere Feb 02 13:38:29 so meta-freescale mailing list might be not appropriate Feb 02 13:38:52 RP: your symlink approach (wip-rss) looks ok to me (can't say much about gcc-cross*, don't really know the context there) Feb 02 13:40:12 obviously would be nicer if it Just Worked without inherits but since it's just three recipes ... Feb 02 13:40:16 eduardas_m: do you have clear scenario for doing it in u-boot and not in linux? Feb 02 13:40:32 jku: core-image-sato built ok with that change, FWIW, not sure how more widespread any issues may be Feb 02 13:40:47 jku: that gcc stuff is dead code replaced by rss that was not removed yet Feb 02 13:41:42 ernstp, I am working on a dual-image update system... I need hardware watchdog to implement fallback functionality in u-boot when unable to load kernel and/or rootfs Feb 02 13:41:44 yeah, I built sato as well, and compared the symlinks in sysroot-components/ : all changes look fine Feb 02 13:42:31 ernstp, I plan to use this in conjunction with CONFIG_BOOTCOUNT_LIMIT Feb 02 13:43:11 for bootcount to increment in u-boot environment I need to automatically restart in u-boot Feb 02 13:43:27 and for that I need watchdog in u-boot Feb 02 13:45:53 lukma: ah i think eudev fails to have a RPROVIDES for udev-hwdb Feb 02 13:46:30 lukma: try adding a rprovides on eudev-hwdb of udev-hwdb Feb 02 13:46:44 seebs: RP: will one of you be making a tarball of pseudo 1.8.2 ? Feb 02 13:50:43 I think I just spotted why the rss numbers don't add up Feb 02 13:51:21 the /usr/bin/bc binary from bc-native is 80kb pre rss and 217kb post rss Feb 02 13:51:39 the difference appears to be after the interpreter section is edited :/ Feb 02 13:52:19 hi! What is the simplest way for using my own kernel ? I read this - http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc and bit confused. Where should I put my custom kernel? Feb 02 13:52:32 joshuagl: its tagged? Feb 02 13:52:39 I use https://github.com/meta-debian/meta-debian Feb 02 13:54:50 RP: there aren't any tags on the pseudo repo. VERSION has been increased and a branch created Feb 02 13:54:58 Guest3927: make your own kernel recipe, change the preferred provider of virtual/kernel to your recipe. Feb 02 13:59:20 joshuagl: I got the feeling seebs wanted to fix something first Feb 02 13:59:43 RP: ah, OK. I'll hold off for now then Feb 02 14:02:05 er, 80kb to 2.17MB. What the heck is going on :/ Feb 02 14:03:16 I think patchelf must have a bug... Feb 02 14:10:10 patching a binary and it grows? Feb 02 14:10:16 rburton: "warning: working around a Linux kernel bug by creating a hole of 2084864 bytes in ‘bc’" Feb 02 14:10:31 rburton: it grows by 2MB Feb 02 14:10:48 if its a hole is it sparse? Feb 02 14:11:08 rburton: appears not Feb 02 14:11:13 useful Feb 02 14:11:28 rburton: literally just poking at this Feb 02 14:25:06 https://github.com/NixOS/patchelf/blob/master/src/patchelf.cc#L709 Feb 02 14:25:11 rburton: ^^^ Feb 02 14:25:20 "it's probably not worth the effort." Feb 02 14:34:25 rburton: Your reply regarding the libgcrypt-config. So I tried that way, upstream QEMU not really interested in having that change https://patchwork.ozlabs.org/patch/711018/ (i didn't realize libgcrypt didn't do pkgconfig upstream at that point). Do you think that making a wrapper script, libgcrypt-config -> "pkgconfig libgcrypt" would be more effective? Feb 02 14:34:25 (saves having to maintain a qemu patch in oe) Feb 02 14:35:08 is it possible to get source code for kernel from local archive ( tar.gz) not from GIT ? for example set source like SRC_URI = file://my_kernel.tar.gz Feb 02 14:35:54 Guest3927: yep Feb 02 14:42:13 CTtpollard, I copied file "recipes-kernel/linux/linux-own_3.19.bb" . Changed SRC_URI = "file://files/kernel-own.tar.gz" . Copied archive to $home/downloads/files/kernel-own.tar.gz. Run bitbake and got error " S is not set to the linux source directory.." source_dir /u02/yocto/build/tmp/work-shared/qemumips/kernel-source is empty. it stops on action - do_kernel_checkout Feb 02 14:42:25 what did i miss? Feb 02 14:47:34 nrossi: I'm afraid I have a real allergy to -config scripts, they're dated and obsolete and horrid for our builds. I'm be tempted just to patch support into qemu. Bonus marks for asking about this on the upstream mailing list, just to show them that someone else cares about pkg-config support for gcrypt Feb 02 14:48:01 nrossi: the upstream maintainer just ignores me at this point Feb 02 14:48:43 RP: yer, i am not sure its even worth bothering trying to raise it upstream Feb 02 14:49:00 nrossi: I think its worth it just to show them people do actually care Feb 02 14:49:15 nrossi: if nobody does, they'll continue to think their -config only policy is fine Feb 02 14:50:07 RP: maybe after i get the configure script patches or their change applied i might. So you know they don't just ignore me :P Feb 02 14:51:10 nrossi: :) Feb 02 14:51:44 RP: what if i made the -config -> pkg-config wrapper script in QEMU itself instead of at the libgcrypt level? Or maybe a sed replace might be better? just thinking since maintaining patches is a pain Feb 02 14:53:14 nrossi: patches generally work better long term than sed Feb 02 14:53:39 nrossi: I've not looked specifically at this code though Feb 02 14:53:54 RP: sure but im in a case where i would need to put the patch into two recipes Feb 02 14:54:10 (two different qemu's) Feb 02 14:54:16 nrossi: :( Feb 02 15:06:38 hmm. I am using "SRC_URI = "git:///u02/own-kernel/;protocol=file;rev=HEAD" . and got error FetchError: Fetcher faileuer: Unable to resolve 'HEAD' in upstrem git ls-remote output for /u02/own-kernel Feb 02 15:06:40 what sucks about sed replacements instead of patches is it's non-trivial to tell if the sed didn't match and did absolutely nothing, whether due to an upstream change or a typo Feb 02 15:06:45 you can script it, but still Feb 02 15:06:47 what is wrong in my SRC_URI? Feb 02 15:06:59 rev=HEAD isn't valid Feb 02 15:07:10 oh, wait, it should be, but only with recent bitbake, i think? Feb 02 15:07:19 regardless, you should really be using SRCREV, not rev= Feb 02 15:09:00 I changed to "SRC_URI="git:///u02/own-kernel/;protocol=file" and added VAR - SRCREV="HEAD". - I got same error Feb 02 15:10:19 code was copied from /u02/own-kernel to /u02/yocto/build/tmp/work-shared/qemumips/kernel-source Feb 02 15:12:09 Guest3927: your file isn't in git so it's not HEAD Feb 02 15:12:21 it's just a tarball Feb 02 15:13:27 what should I set for SRCREV variable in this case? Feb 02 15:18:57 Guest3927: use file:// not git Feb 02 15:19:00 joshuagl, rburton: we have three genuine looking failures on the M2-rc3 build Feb 02 15:21:10 Pre-RSS:22794.25user 2687.88system 30:32.84elapsed 1390%CPU (0avgtext+0avgdata 919056maxresident)k Feb 02 15:21:11 RSS with patchelf workaround:23571.84user 3383.65system 31:36.83elapsed 1421%CPU (0avgtext+0avgdata 919068maxresident)k Feb 02 15:21:27 so ~60s slower rather than 5mins earlier Feb 02 15:21:50 so whilst my "fix" is an abomination, I think its worth adding until we have a better one... Feb 02 15:21:54 Guest3927: if you want to use git commit the tarball to a local git repo Feb 02 15:23:14 CTtpollard: thanks! Feb 02 15:23:17 CTtpollard: i really woudln't recommend using file:// for a local git repo, that ignores that it's git and blindly copies the tree without any awareness Feb 02 15:23:28 either use git:// with protocol=file or, better, externalsrc Feb 02 15:23:30 * kergoth shrugs Feb 02 15:24:48 kergoth: no I'm saying either use file for a tarball, or commit the tarball and use git Feb 02 15:25:12 ahh Feb 02 15:25:43 :) Feb 02 15:26:25 RP: ok, will take a look at them for SWAT Feb 02 15:28:13 joshuagl: I suspect the aarch64 sdk one is from my meta-environment change, the pip3 one is a missing dependency (Juro's code) and the publish artefacts one ed2 knows about Feb 02 15:29:42 JosePerez1: need to decide what to do about this build from a QA perspective Feb 02 15:32:28 RP: thanks, any idea whether bugs are filed? Feb 02 15:34:06 looks like not yet Feb 02 15:44:49 i can take 10995 Feb 02 15:44:57 some strange audio problem, again Feb 02 15:45:39 RP: ^^ ? Feb 02 15:46:43 RP ok.. I see some reds on AB and selftest just started, I thin if everything goes ok with selftest we can have it QA cycle to execute testimage and selftest Feb 02 15:57:11 maxin: regarding YOCTO #11007 - my first guess is that the sequence of commands leaves a gshadow files behind with an entry that no longer have a corresponding gid in group. Feb 02 15:57:37 It would be useful to look at all files in /etc that are supposed to get sorted. Feb 02 15:58:36 pohly: looks like that .. deleting the "games" user creates that error Feb 02 16:00:17 Looking at rootfspostcommands.py I am not seeing anything obviously wrong. Feb 02 16:01:27 In particular, "shadow" gets sorted by "passwd", and "shadow-" by "passwd-". As long as the files are consistent (= "games" either present or not present), the code should work. Feb 02 16:01:40 pohly: it might be a good idea to provide exception handling there (forKeyError though ) Feb 02 16:02:01 Let's check the content of the rootfs first to understand what the error is. Feb 02 16:02:14 Catching an error without knowing how to report or deal with it doesn't help. Feb 02 16:02:33 pohly: agree. Feb 02 16:03:30 You managed to reproduce it, right? Can you attach the files to the bugzilla entry Feb 02 16:03:31 ? Feb 02 16:05:34 pohly: do you mean the error log or "passwd" and "group" files after building with SORT_PASSWD_POSTPROCESS_COMMAND="" ? Feb 02 16:05:34 joshuagl/rp: actually, the branch is intended to be the thing. I haven't historically modified a release-number branch once I created it, usually. Feb 02 16:05:52 I don't think I ever learned to do "tags" as a thing distinct from branches. Feb 02 16:06:12 maxin: passwd, passwd-, group, group-, shadow, shadow-, gshadow, gshadow- Feb 02 16:06:36 pohly: ok,will do that. Feb 02 16:22:09 can I ask you which is the content of the /usr/lib/locale dir for your Yocto build? Feb 02 16:23:45 pohly: done .attached those files there. Feb 02 16:29:30 seebs: OK, so we should be good to spin a tarball and use it in OE/YP ? Feb 02 16:31:08 seebs: ok, I can make/push a tarball then Feb 02 16:32:31 grr, still getting a ton of those no staging package errors with morty, wonder what's going on there Feb 02 16:32:36 * kergoth checks the latest oe-core branch Feb 02 16:33:04 Yeah, tarball should be fine, no expected problems. I think everything but the xattr fix has been at least somewhat smoke-tested. Feb 02 16:33:27 we'll certainly do some testing once we integrate the release Feb 02 16:44:06 RP: huh build applicance failed with pip3 again Feb 02 16:44:24 halstead: fedora24 is missing pip3, apparently Feb 02 16:49:52 rburton: or missing depends on pip3-native ? Feb 02 17:06:48 rburton, Bizarre. python3-pip-8.0.2-1.fc24.noarch is still installed and most of its files are there but /usr/bin/pip3 is missing. Feb 02 17:07:06 weird Feb 02 17:09:54 halstead: it may be expecting /usr/bin/pip3 , but its actually /usr/bin/pip it depends on the distro Feb 02 17:10:35 aehs29, In this case /usr/bin/pip is from the python2 pip rpm. Feb 02 17:11:38 I've run dnf reinstall python3-pip to get the missing files back and everything installed with pip3 is still there including unittest-xml-reporting (2.1.0). Feb 02 17:11:48 Now to find out what deleted the files. Feb 02 17:12:52 halstead: weir Feb 02 17:12:54 d Feb 02 17:31:17 stephano: I've opened that bug I mentioned, let me know if it makes sense Feb 02 17:31:44 RP: I'll have a look now Feb 02 17:36:09 I keep getting "| install: cannot open 'arch/x86/boot/bzImage' for reading: Timer expired" when I do a $ bitbake core-image-minimal Feb 02 17:42:50 RP: I take it your intention is to patch patchelf, not get a fix upstream, right? Feb 02 17:44:54 I only ask because the comment in patchelf is "it's probably not worth the effort" :) Feb 02 17:46:32 stephano: I'd bet they'd take the patch ;-) Feb 02 17:47:26 RP: never hurts to try Feb 02 17:47:34 okay, I think this makes sense. i'll dig into it a bit and ping you when I hit a wall. Feb 02 17:48:28 stephano: ok. I don't think it should be too difficult, I'm just out of bandwidth and need help :) Feb 02 17:48:43 stephano: I'll probably propose my patch until we get this fixed properly Feb 02 17:48:54 * RP is curious how much it helps the benchmarks Feb 02 17:49:16 RP: sounds goods. Feb 02 17:49:18 stephano: I think that comment is more that they couldn't be bothered to do it rather than it not being a good idea btw Feb 02 17:49:29 stephano: We've now a pressing reason Feb 02 17:49:41 RP: Ah, okay. Feb 02 20:46:28 Hi Feb 02 20:50:18 I have made my own psplash recipe called it psplash_git.bbappend. All of that works and when the build is complete I have a package that looks like this psplash-newSplash-0.1+git0+afd4e228c6-r15.cortexa9hf_vfp_neon.rpm. Feb 02 20:50:18 This package is uploaded to an online site. When smart tries to download it, it cannot find the package because of the '+' sign. This is when I noticed a lot of packages have this '+' sign and none of them can be downloaded. The reason this happens is that the '+' is a special character in the URL. Feb 02 20:50:18 My question is, is there a way to avoid this situation, change the package name or just have smart encode the URL? Feb 02 20:50:18 Thanks Feb 02 20:51:51 sounds like a bug in smart Feb 02 20:51:55 if it's not properly encoding Feb 02 20:52:06 also, psplash_git.bbappend is not a recipe. you're appending an existing recipe Feb 02 20:52:17 yea sorry that's what i meant Feb 02 20:53:07 so If I make a new card all is good, it runs fine I can use my new splash but smart just responds with not found Feb 02 20:53:28 that's really strange because + is very common e.g. in the kernel packages Feb 02 20:53:40 CTNeil: are you doing anything manual to index the packages? Feb 02 20:53:51 no Feb 02 20:54:27 really this is the first append I have made, everything else has mostly been installing random scripts and images Feb 02 20:56:29 I noticed the same '+' issue on other packages too, example: adbd-android+5.0.1_r1-r0.cortexa9hf_vfp_neon.rpm Feb 02 20:56:43 I can't manually download this either. Feb 02 21:05:26 would anyone have a link to a package with a '+' in it that would download via a regular browser, I want to see what might be different. I noticed mine doesn't download through the browser either. But If I access the remote directory via filezilla I can get the file. Feb 02 21:08:51 CTNeil: replace + with %2B Feb 02 21:11:27 doesn't seem to work. The encoding on my site is not working then? Feb 02 21:12:38 hold on - you can't manually download it? that sounds like the web server is at fault... Feb 02 21:14:14 hmm, not sure why that would be happening. What does the plus in the filename mean? Feb 02 21:15:11 should that be treated as a '+' or not. Feb 02 21:17:01 is there an example URL for this? Like would it look like http:///adbd-android%2B5.0.1_r1-r0.cortexa9hf_vfp_neon.rpm Feb 02 21:17:36 hmm, + may actually not be legal in a URL... but %2B ought to work Feb 02 21:17:45 and yes that looks correct Feb 02 21:18:02 but is that how smart will request it? with a %2B Feb 02 21:18:59 google for url encoding. Feb 02 21:20:27 %2b should work and smart should be encoding Feb 02 21:22:50 I understand the + should be %2b, all other packages install. but for the packages with + this is what happens Feb 02 21:22:50 Fetching packages... Feb 02 21:22:51 -> http://cortexa9hf_vfp_neon/psplash-newsplash-0.1+git0+afd4e228c6-r15.cortexa9hf_vfp_neon.rpm Feb 02 21:22:51 psplash-newsplash-0.1+git0+afd4e228c6-r15.cortexa9hf_vfp_neon.rpm Feb 02 21:22:51 error: Failed to download packages: Feb 02 21:22:51 error: http:///cortexa9hf_vfp_neon/psplash-newsplash-0.1+git0+afd4e228c6-r15.cortexa9hf_vfp_neon.rpm: File not found Feb 02 21:23:03 i'm guessing the server is at fault here Feb 02 21:24:01 it's not serving me via the browser either but the file exists Feb 02 21:27:30 Thanks for the help guys, I will check what is happening on that end. Still new to yocto so learning it bit by bit. :-D Feb 02 22:30:31 bluelightning: i just send a patch for bitbake-layers exception and i'm wonder is there is an easy way to get error details from cooker the actual policy seems to only log the error Feb 02 22:34:26 I'm not sure where to report that but the doc for NO_RECOMMENDATIONS states: Feb 02 22:34:34 NO_RECOMMENDATIONS_pn-target_image = "package_name" Feb 02 22:34:39 while it should be Feb 02 22:34:43 NO_RECOMMENDATIONS_pn-target_image = "1" Feb 02 23:00:43 abelloni: if you file a bug in the bugzilla, scott will no doubt fix it Feb 02 23:59:04 abelloni: bugzilla has a category for the docs Feb 02 23:59:32 scottrif's not around or I'd draw his attention to it here Feb 03 00:25:06 Hi! I've built an image using yocto, but it has the wrong version of gstreamer. It's targeting 1.8 which is the recipe "gstreamer1.0" and I don't know how to target the recipe "gstreamer1.0_1.10.2" Feb 03 00:25:10 Any clues? Feb 03 00:31:16 RP, bluelightning: thanks, done Feb 03 00:31:41 abelloni: thank you Feb 03 00:32:11 deivd___: PREFERRED_VERSION is probably what you are looking for Feb 03 00:32:49 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PREFERRED_VERSION Feb 03 00:32:58 typically the higher version is picked, so presumably you have something already setting that or supplying the 1.8 version in a layer with a higher priority Feb 03 00:33:35 you can find the ones you have in your configuration with: bitbake-layers show-recipes gstreamer1.0 Feb 03 00:34:15 bitbake -e | less and search for PREFERRED_VERSION_gstreamer (with /) will let you see if that's set anywhere Feb 03 00:35:28 is 1.10 always greater than 1.8? :) Feb 03 00:36:56 PREFERRED_VERSION_gstreamer is unset, but show-recipes only shows 1.8 Feb 03 00:37:47 the "_git" version is using 1.8 but has DEFAULT_PREFERENCE = '-1' Feb 03 00:38:08 looks like 1.8.2 > 1.10.2 Feb 03 00:38:38 === Matching recipes: === Feb 03 00:38:39 gstreamer1.0: Feb 03 00:38:39 meta 1.8.3 Feb 03 00:38:39 meta 1.8.2+gitAUTOINC+3de8a4f728 Feb 03 00:41:21 if I'm not mistaken, morty doesn't have 1.10 Feb 03 00:41:58 oh it's likely, I've read that somewhere. Feb 03 00:42:19 and master only has 1.10.2 Feb 03 00:42:29 I started today, trying to learn all this. It's pretty hard to wrap my head around it Feb 03 00:42:56 I must've cloned something without checking out morty, that's why I have the bb files Feb 03 00:44:32 yeah I checked out openembedded-core and got the files from there **** ENDING LOGGING AT Fri Feb 03 03:00:00 2017