**** BEGIN LOGGING AT Mon Jun 06 02:59:58 2016 Jun 06 09:33:27 Is there a way to force OE to create a package even if the corresponding packages-split folder is empty? Jun 06 10:09:06 RagBal: set ALLOW_EMPTY_ = "1" Jun 06 10:10:18 pohly, so easy, thanks =) Jun 06 12:24:18 Hello everyone Jun 06 12:24:32 i have successfully managed to build core-image-minimal and i have added my own custom recipes Jun 06 12:24:35 that is great Jun 06 12:24:59 but , the core-image-minimal file system does not look like ubuntu server for instance. Jun 06 12:25:11 it does not contain /usr/share , /usr/lib.....etc Jun 06 12:25:17 also , there is no sudo or apt-get Jun 06 12:25:30 how can i include these into my core-image-minimal Jun 06 12:26:48 How can i include "sudo" and "apt-get" into core-image-minimal Jun 06 12:29:33 core-image-minimal certainly does contain /usr/share and /usr/lib Jun 06 12:29:57 you add apt-get by ensuring IMAGE_FEATURES contains package-management, and sudo by adding it to IMAGE_INSTALL (IMAGE_INSTALL_append = " sudo") Jun 06 12:30:14 note that when you start doing this you're battling against core-image-minimal which intends to be *minimal* Jun 06 12:30:20 so i'd start with something like core-image-base Jun 06 12:30:41 and if you want apt then set PACKAGE_CLASSES to package_deb, but be aware that rpm and ipk are better tested/supported Jun 06 12:31:22 ruburton, Nice to see you here Jun 06 12:31:30 can i speak with you privately ! Jun 06 12:32:52 you can ask in public so others can learn Jun 06 12:33:04 also excuse the crumbs as i'm eating my lunch Jun 06 12:34:24 rburton, bon appetite Jun 06 12:34:44 let me check something and get back to you until you finish your lunch Jun 06 12:44:11 rburton , how can i change the name of the OS when the user writes , uname -a Jun 06 12:44:16 into the command prompt Jun 06 12:49:27 rburton, i used core-image-minimal , because the whole idea of creating a linux distro from scratch is to be secure , i wanted to get rid of ALL packages except only the ones i do need them along with their dependencies Jun 06 12:49:51 well minimal explicitly disables some bits that you may not want disabled Jun 06 12:49:56 i took a bottom-up approach , it is better to know each and every piece of installed packages on this OS Jun 06 12:49:56 basically, write your own image recipe :) Jun 06 12:50:20 write my own ! Jun 06 12:50:22 for what ! Jun 06 12:50:27 for changing the linux name ? Jun 06 12:50:41 i want to change the linux name when user types "uname -a" into the shell Jun 06 12:56:33 no, write your own image recipe as the core-image-* are just examples Jun 06 12:56:42 not sure how to change uname actually Jun 06 12:57:59 what bit do you want to change? Jun 06 12:58:14 if the bit where it says linux, then 1) why and 2) the kernel, i imagine Jun 06 13:01:10 rburton, i will be back Jun 06 14:20:18 hi, i'm trying to add cmake to my yocto image, but just adding the recipe doesn't provide the binary Jun 06 14:20:25 just /usr/lib/cmake Jun 06 14:55:33 Are there statistics about how many people are using Yocto (in percent compared to other embedded solutions) ? Jun 06 14:57:18 Who would generate such statistics? Jun 06 14:58:44 Good question :) Jun 06 14:59:17 there are survey results that show usage or OE, Yocto, and commercial offerings based on the YP are the majority of embedded Linux development these days.. Jun 06 14:59:34 I'll see if I can find the figures.. Jun 06 14:59:48 That'd be awesome. It is quite popular, right ? Is there a chance, that it is the most popular solution nowadays ? Jun 06 15:00:02 it is the most popular solution from what the last survey.. Jun 06 15:00:16 I don't know if it hit 50% yet.. but a lot of the stuff is custom home created.. Jun 06 15:00:50 Wow, that's a lot. Jun 06 15:01:05 Android is a big chunk as well.. Jun 06 15:01:30 I'm not finding the survey.. (least the most recent) but my memory was something like 30-40% was OE/YP/Commercial Jun 06 15:01:35 abotu 20% was Android.. Jun 06 15:02:01 Ok, thanks a lot. Jun 06 15:02:13 and the rest was buildroot (a few %), commercial solutions (not YP based) (a few more) and then home grown the rest.. Jun 06 15:02:24 there is a lot of roll-your-own Linux still Jun 06 15:03:56 Interesting. I have to convince some managers here to do the right choice ;) Jun 06 15:04:17 I'd tell anyone these days to stay away from roll-your-own.. Jun 06 15:04:27 Android is useful, but I prefer YP for the things I do.. Jun 06 15:04:37 (and you can get commercial versions if appropriate for your org) Jun 06 15:05:23 We have a lot of (hard) real-time stuff, and I have the feeling that Android is not so realtime-related than YP ? Jun 06 15:05:34 Android is Linux with a different userspace Jun 06 15:05:46 Understood Jun 06 15:05:52 you need to define what YOU need for hard real-time to decide if Linux is even correct for you.. Jun 06 15:06:26 I've got customers with real time requirements in the 'second' range (Linux is no problem), ms range (usually Linux is no problem, assuming good drivers), and micro second range.. not really a Linux solution there.. (but Linux is 'better') Jun 06 15:06:31 According to our measurements, Linux ha less Jitter than even VxWorks and QNX. (Took 6 months to measure). Jun 06 15:06:52 Let me grab the figures ... Jun 06 15:06:54 Roelof (I can only speak for Linux and VxWorks) and the answer all depends on hardware and drivers Jun 06 15:07:27 VxWorks, tuned properly can perform better then Linux, especially at the small time scales.. Jun 06 15:07:46 but Linux can hold it's own in the ms range, and definitely second range.. Jun 06 15:08:08 (and yes, real-time in seconds is a thing.. people often confuse real-time for performance, it's usually the opposite) Jun 06 15:09:07 Just if it's interesting: We used the default Yocto for i.mx6 and had a jitter of max. 42 us at a 1ms tick. That's pretty cool. VxWorks was 67 us and QNX 47 us. Jun 06 15:09:40 But we did strange stuff: We had to process everything in the user-space for some reasons. Jun 06 15:10:00 I have very little experience on the i.mx6 so I'm not sure how good/bad that is.. but it seems reasonable for that processor Jun 06 15:10:32 yes.. the only way to get low time slice numbers in Linux is process in user-space, as it lets the system keep processing the data at a faster rate Jun 06 15:10:48 that is pretty standard implementation on Linux, and somewhat 'strange' on VxWorks.. (model is just different) Jun 06 15:11:47 Yes, we ended up with using VxWorks for other reasons. (Our demand was 100us jitter, so all thre OSes were feasible). Jun 06 15:12:18 BTW I found part of the 2014 survey.. and in this one android is around 30% and YP (and all related) are closer to 20% from what I can tell.. Jun 06 15:12:33 I seem to remember the 2015 survey the YP surpassed android.. Jun 06 15:13:51 Linux if you want Open Source.. VxWorks if you want closed source... (I work for Wind River, but on the Linux side.. so I only have passing knowledge of VxWorks).. Jun 06 15:13:58 that is pretty much the sales model for the two Jun 06 15:15:43 Ok, we appreciate that WindRiver has a steak in Yocto, we also evaluated WindRiver Linux two years ago. Jun 06 15:16:10 (stake) Jun 06 15:16:19 as I tell customers regularly.. don't buy into the hyper.. and don't keep buying what you always have.. you need to investigate, otherwise you are going to get stuck.. Jun 06 15:16:39 it's part of my job to make sure Linux continue to improve in useful ways for OS creators Jun 06 15:17:27 ya.. I can't find any public surveys news then 2014.. Jun 06 15:17:37 and the ones I'm finding are not breaking out Linux specifically.. Jun 06 15:17:58 (I was in a talk somewhere, wish I could remember where, that did break the numbers out int he Linux OS market and they were 2015 numbers) Jun 06 15:18:35 YP and Android were the two clear 'embedded' Linux OSes.. with re-use of workstation/server (Ubuntu, Debian, Red Hat) and Roll-your-own a combined third (roughly) Jun 06 15:19:18 Ok, thanks for looking. At least I can tell now, that Yocto is one of the biggest players, and as WR Linux ist based on it, it would be a reasonable solution.. Jun 06 15:19:55 Thanks a lot ! Bye, bye :) Jun 06 15:30:57 Hi everyone Jun 06 15:33:22 I'm using datetime in a receipe version 'PV := "${PVBASE}.${SRCPV}.${DATETIME}"'. I used this without any errors but now with krogoth, I got those kind of errors : skellgip2-svn.10498.20160606152022-r0 do_install: Taskhash mismatch a63aac1b85f10faa47a6a3766acef59e verses 503595a3fab2b3d93c5da4f6d6a1ee9b for /home/aurele/workspace/yocto/moniteur-krogoth/sources/meta-castel/recipes-castel/skellgip2/skellgip2_svn.bb.do_install Jun 06 15:34:22 how could I keep the "datetime" in my receipe version (to have a file updated according to build time during every build) Jun 06 15:34:51 rburton,i am back Jun 06 15:34:59 i am sorry my friend , i had an urgent meeting Jun 06 15:35:00 thanks for any idea Jun 06 15:35:29 rburton, i had added PACKAGE_CLASSES +=" package_deb" Jun 06 15:35:39 but apt is not added Jun 06 15:38:09 rburton, when the user execute "uname -a" , it shows linux yocto something like this Jun 06 15:38:16 i would like to give the linux a name Jun 06 15:38:29 it is the default name for core-image-minimal Jun 06 15:51:24 snouto: that's the kernel version, so that's where you want to fiddle the strings. have a look at the kernel recipes Jun 06 15:51:43 snouto: and if you don't get apt installed then you didn't have package-management in IMAGE_FEATURES Jun 06 15:52:12 rburton, i managed to get it to work Jun 06 15:52:17 you were absolutely right Jun 06 15:52:44 the thing is that package_classes was declared above in the local.conf , i didn't see this at first and it was pointing to package_rpm instead Jun 06 15:52:56 i configured this and i successfully installed apt-get Jun 06 15:53:45 please rburton , do you know how can i generate an .iso for my linux Jun 06 15:53:50 through "live" image Jun 06 15:54:00 but where can i declare "live" Jun 06 15:54:12 IMAGE_FSTYPES Jun 06 15:54:16 morning all Jun 06 15:54:27 kergoth, thanks Jun 06 15:54:32 in local.conf , right ? Jun 06 15:55:54 IMAGE_FSTYPES ?="live" Jun 06 15:55:55 right Jun 06 15:55:59 that is all ! Jun 06 15:57:59 rburton, where is the kernel recipe should be located ? Jun 06 15:58:11 in meta-poky , right ? Jun 06 15:59:18 found it Jun 06 15:59:27 it is in meta folder Jun 06 16:07:35 kergoth, after adding "live" to IMAGE_FSTYPES ?="live" Jun 06 16:07:38 i received this error Jun 06 16:07:39 ERROR: Nothing PROVIDES 'syslinux' Jun 06 16:07:39 ERROR: syslinux was skipped: incompatible with host arm-poky-linux-gnueabi (not in COMPATIBLE_HOST) Jun 06 16:07:39 ERROR: Required build target 'core-image-minimal' has no buildable providers. Jun 06 16:07:39 Missing or unbuildable dependency chain was: ['core-image-minimal', 'syslinux'] Jun 06 16:09:38 kergoth , rburton: how can i add gcc into core-image-minimal ? Jun 06 16:10:20 add "gcc" to IMAGE_INSTALL Jun 06 16:10:23 the live images are only supported on archs that support syslinux, that's correct Jun 06 16:10:30 this is in the documentation under "adding packages to images" Jun 06 16:10:44 or grub-efi or gummiboot, i think, for efi systems Jun 06 16:11:00 i have added "gcc" to IMAGE_INSTALL_APPEND Jun 06 16:11:10 IMAGE_INSTALL_append =" psplash example complexyocto sudo python gcc" Jun 06 16:11:11 if you actually want a working toolchain then add tools-sdk to IMAGE_FEATURES Jun 06 16:11:40 note, compilers are versioned unless you also install the symlink package, so its gcc-5.2 or whatever Jun 06 16:11:56 (you can tell that by looking at the contents of the gcc package, using oe-pkgdata-util) Jun 06 16:12:31 do you mean by adding "tools-sdk" to image_features , i will have a gcc Jun 06 16:13:10 well "gcc" gives you gcc-[version] which isn't a problem, and there's another package that installs the symlinks for default versions. Jun 06 16:13:16 but i guess you'll also want a linker Jun 06 16:13:28 so its best to just use tools-sdk Jun 06 16:13:33 ok Jun 06 16:17:03 kergoth,rburton: how can i get my core-image-minimal to support syslinux ? Jun 06 16:17:12 you can't magically make syslinux work for arm Jun 06 16:17:13 currently i am building against ARM processors Jun 06 16:17:20 oh Jun 06 16:17:38 so you mean , if i made it x86 machine or x64 it shall work ? Jun 06 16:18:44 the current live image code needs syslinux, you can port it to something else to make it work on other hardware, or build for x86 if that's acceptable for testing Jun 06 16:18:48 or don't use live images Jun 06 16:19:10 ok , i will follow you , so , basically , no live image for arm processors Jun 06 16:19:16 so this raises two questions Jun 06 16:19:35 1. if i want to deploy my linux into a hardware appliance that has arm processor , how can i get my linux installed there Jun 06 16:19:49 i'm not sure what good you'd expect a live cd to do you on an arm machine, most of which don't support booting from a cd even if they had a drive connected, which most don't Jun 06 16:20:02 that depends on the hardware Jun 06 16:20:14 2.if i changed my configuration in local.conf to map to qemux86-64 and specified "live" , will it work ? Jun 06 16:21:14 so how can i deploy my core-image-minimal into a board that has arm ? Jun 06 16:21:21 through flash memory or something ? Jun 06 16:21:27 as i just said, that depends on the hardware Jun 06 16:21:46 update/flash/boot methods vary Jun 06 16:27:19 from where can i read more about update /flash/boot methods Jun 06 16:27:28 do you have any online references kergoth ? Jun 06 16:27:55 as i just said, it varies. read up about whatever hardware you're trying to work on Jun 06 16:34:19 snouto: typically with ARM platforms, u-boot is your friend. You can use u-boot to download a kernel and rootfs image then program them into local NAND flash on the board or to an SD-card. You can also use u-boot to configure the board to load kernel image via tftp and mount rootfs via NFS for testing purposes (if your board has Ethernet available). Other alternatives, if SD-card is available is to use tools on your development system to copy files to SD car Jun 06 16:37:17 snouto: if your hardware does not come with u-boot pre-installed, then you need to read up on built-in first/second stage bootloader for your h/w on how to load u-boot over network, usb or serial and flash into NAND. Although some h/w will also load direct from SD card, if present, so you can put second stage loader, u-boot, kernel and rootfs all on SD card. As kergoth said, it really depends on what your hardware supports. Jun 06 16:41:48 billr, Thank you for this expert opinion , i will have to check with the h/w company for this Jun 06 16:42:35 billr, can i read about this "You can use u-boot to download a kernel and rootfs image then program them into local NAND flash on the board or to an SD-card" in u-boot documentation ? Jun 06 16:43:02 snoutu: yes, that is in the u-boot documentation Jun 06 16:43:56 actually , the h/w company already provided me an intel atom processor as a prototype Jun 06 16:44:02 and it is a soc chip Jun 06 16:44:18 atom isn't arm. i think your'e a bit confused :) Jun 06 16:44:24 i told them it is ok for a prototype , but for production appliances , i will prefer an intel xeon Jun 06 16:44:29 i knew Jun 06 16:44:34 atom is intel Jun 06 16:45:02 why do you care about deploying to an arm board if what you're getting is x86 anyway? Jun 06 16:45:02 i started arm because i read about yocto from a book and i followed the examples , the book was targetting arm Jun 06 16:45:06 so i choosed arm Jun 06 16:45:12 so pick a different machine and move on Jun 06 16:45:25 qemu isn't a board anyway, it's emulation Jun 06 16:45:56 because qemuarm image i am building is for testing purposes , i am checking how can i install required recipes , scratch my head around it , then i will oe-init a complete different environment for the OS later Jun 06 16:46:52 kergoth: qemuarm is just a testing image to get experience in yocto Jun 06 16:47:35 i am still learning it piece by piece and because i am not a h/w guy , that is why i feel with a bit difficulty in these variations between h/w and processors Jun 06 16:48:28 snouto: if you just picked arm for demo, to learn about installing packages, then pick something closer to your final h/w, like qemux86 then do an actual build for the atom and load onto your initial h/w Jun 06 16:48:57 billr: exactly , that is what i am doing right now , i changed into qemx86_64 Jun 06 16:49:16 and poky is now building it from scratch , i will stick to this because it is the closer to the target board Jun 06 16:49:32 when i started , i didn't even know what h/w i will target Jun 06 16:49:46 snouto: good idea Jun 06 18:05:03 Hello! Using poky 2.1 with meta-openembedded, I get a bunch of deprecation warnings like this one: Jun 06 18:05:21 NOTE: build/../meta-openembedded/meta-networking/recipes-support/stunnel/stunnel_5.28.bb: base_contains is deprecated, please use bb.utils.contains instead. Jun 06 18:06:02 should I open a bug for that? Jun 06 18:06:24 meta-openembedded doesn't have a bug tracking system, last i checked, so not sure where you'd plan to do that Jun 06 18:06:27 is your meta-networking up to date? I know the maintainer fixed a bunch of those within the last wk or two. Jun 06 18:25:41 paulg, kergoth: my meta-openembedded directory was stalled, yeah indeed updating solved the issue, sorry for the noise Jun 06 18:29:21 np Jun 06 20:29:32 RP: WARNING: libevdev-1.5.1-r0 do_fetch: Couldn't load checksums from donestamp /scratch/yocto-new/poison-ldflags/build.nodistro/downloads/libevdev-1.5.1.tar.xz.done: ValueError (msg: unsupported pickle protocol: 4) Jun 06 20:29:57 looks like it's no longer happy to share downloads amongst numerous yocto releases Jun 06 20:30:28 we really shouldn't be using pickle to begin with for persistence, it's known to have lots of issues. should look into switching to another text or binary format Jun 06 20:30:52 * kergoth ponders Jun 06 20:31:56 so the python3 we generate for builld-appliance doesn't have the "multiprocessing" module. Looking at other distros, it lives in libpython3-stdlib (ubu) Jun 06 20:32:41 and we can't get off the ground in bitbake w/o that module; not seeing where our equivalent would be just yet... Jun 06 20:33:03 check the manifest .inc Jun 06 20:33:14 either that or use oe-pkgdata-util Jun 06 20:33:31 hmm, why is gcc-runtime-external gettng a taskbase hash mismatch Jun 06 20:36:19 tmp/deploy/rpm/core2_64/python3-multiprocessing-3.5.1-r1.0.core2_64.rpm Jun 06 20:36:25 looks promising. Jun 06 20:36:29 * paulg installs Jun 06 20:36:54 Hmm.. wonder if I can rework bb.process in such a way that it retains compatibility with the *numerous* users of it, but still align much more closely with subprocess Jun 06 20:36:56 * kergoth pokes at it Jun 06 20:36:58 * paulg expects this to be a lather-rinse-repeat affair... Jun 06 20:37:30 wonder if there is a parent meta-package. Jun 06 20:42:46 ImportError: No module named 'sqlite3' Jun 06 20:43:01 ImportError: No module named 'pysqlite2' Jun 06 20:43:27 see this going on for a while.. Jun 06 20:44:52 meta/recipes-devtools/python/python-3.5-manifest.inc has it. Wonder why it didn't get installed. Jun 06 20:45:09 we don't already have a packagegroup for 'the bits bitbake needs to run'? Jun 06 20:45:10 odd Jun 06 20:45:40 that was the buildtools tarball wasn't it? Jun 06 20:45:47 I got 42 python3 pkgs installed. But clearly that wasn't enough... Jun 06 20:46:19 I'll stick with the manual mode for a bit just to see what else shakes loose after that. Jun 06 20:48:32 solution might be obvious to a seasoned bitbake person vs. a kernel guy flailing around learning as he goes. :) Jun 06 20:51:46 if you had buildtools installed before you need to rebuild it and reinstall it Jun 06 20:51:59 since it now has the python3 bits in it Jun 06 20:59:13 * paulg builds buildtools-tarball Jun 06 21:00:13 I'm not stuck with my builder not being able to build itself ; I've got a 2nd machine with a bog std ubu install that builds ok after I fixed meta-overc and meta-cloud-services Jun 06 21:00:40 so I was copying rpms off of that and onto the one w/o the right modules installed... Jun 06 21:00:57 until it wanted pdb module, and we didn't have an rpm for that. :-/ Jun 06 21:01:15 maybe building buildtools will generate the missing ones. Jun 06 21:06:28 yay, buildtools fails on binutils cross SDK | configure.ac:33: error: Please use exactly Autoconf 2.64 instead of 2.69. Jun 06 21:06:45 * paulg goes off to order an "I hate autoconf" T-shirt Jun 06 21:20:53 tmp/deploy/rpm/core2_64/python3-debugger-3.5.1-r1.0.core2_64.rpm Jun 06 21:20:59 ...makes sense Jun 06 21:21:04 * paulg installs Jun 06 21:46:11 * RP dreads to think what paulg is doing. Taking a buildtools-tarball from somewhere else (like our AB) and using that would probably work Jun 06 21:55:10 RP, meta-overc, which was basically a 64 bit build appliance with kernel and grub so you could use it for real dev. Jun 06 21:55:30 (for purpose of this discussion) -- making it work again after all the python3 fallout. Jun 06 21:56:01 paulg: I'm told we had buildtools-tarball working so I'm just surprised the work its involving :/ Jun 06 21:56:25 maybe if I use a 32 bit config... Jun 06 21:57:36 I've got all the pyton3 modules on it now and I'm fighting with this... Jun 06 21:57:39 Please use a locale setting which supports utf-8. Jun 06 21:57:39 Python can't change the filesystem locale after loading so we need a utf-8 when python starts or things won't work. Jun 06 21:58:00 paulg: We also fixed buildtools-tarball for that Jun 06 21:58:05 I had the locale stuff satisifed prior to the py2 --> py3 update but now it appears more strict. Jun 06 21:58:29 paulg: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=479780d790cc4f6e93564bfd849824e9a7f9160c Jun 06 21:58:32 let me look into the changes for buildtools-tarball ; prior to today I didn't know it even existed. Jun 06 21:58:40 thanks for the commit ; save me digging. Jun 06 22:00:50 hrrm. will have to see what is in nativesdk-locale-base-en-us ; if it is a giant thing, zeddii_sweden will start hurling crap over the wall at me. Jun 06 22:01:16 (well, maybe not from sweeden...) Jun 06 22:04:37 on a semi related note, it seems py3 gets generated with a crap PYTHONHOME default ; I had to symlink /usr/lib64 py3 into /usr/lib as a temp. workaround. Jun 06 22:04:51 of course that needs a proper fix too. Jun 06 22:17:27 holy crap, I think I may have the builder building itself Jun 06 22:18:00 it is at least passed parsing and is cleaning out the obsolete cruft from the sysroot. Jun 06 22:20:38 need to tidy up all the issue workarounds etc. but I think there is light at the end of the tunnel. Jun 06 22:21:13 Currently 5 running tasks (1121 of 7463): Jun 06 22:21:27 good a time as any to walk away and find food. Jun 06 23:09:14 RP: know of a good way to diagnose taskbase hash mismatches? **** ENDING LOGGING AT Tue Jun 07 02:59:58 2016