**** BEGIN LOGGING AT Fri Dec 14 03:00:02 2018 Dec 14 05:11:46 New news from stackoverflow: Yocto core-image-* (minimal) networking Dec 14 06:11:57 New news from stackoverflow: requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC Dec 14 06:42:02 New news from stackoverflow: PHP odbc driver as shared extension Dec 14 08:15:49 Is there a way to increase the amount of RAM when running qemu? Both in the context of runqemu and bitbake -c testimage (with qemu backend) Dec 14 08:19:04 erbo: runqemu without any parameters should give you the help. theres either a switch for it per se, or you pass an additional argument for appending to the qemu command line. Dec 14 08:21:15 LetoThe2nd: Right, the runqemu part was easy. Just add extra qemu params as you said. Dec 14 08:21:20 Thanks Dec 14 08:23:01 for the testimage no idea, sorry. Dec 14 09:01:21 hello ! Anyone here ? If there is someone kind enough to free me from my yocto induced slide into the depths of insanity, can i ask something ? Dec 14 09:02:38 yoctopus: as usual on irc: don't ask to ask, just ask. preferable as precisely as possible - so when somebody knows, he/she will answer Dec 14 09:06:08 oh sorry... Anyway. I have a custom image recipe (folder hierarchy based on freescale layers) in meta-mylayer/imx/meta-sdk/recipes-myrecipes/images/imagename-base.bb . I change IMAGE_INSTALL_remove = "... " variable to IMAGE_IsnTALL_remove = "..." and expect to see a parsing error, however when i do bitbake imagebase-name, bitbake just goes on and build the image. Checked for typos - everything seems ok. Some sort of cache i need to Dec 14 09:08:36 yoctopus: you mea, you expect a parsing error becasue you intentionally mistyped IMAGE_INSTALL to IMAGE_IsnTALL Dec 14 09:08:39 ? Dec 14 09:09:41 in that case, no. bitbake happily evaluates your recipe. this is not a parsing error per se, but jsut a new variable name. one without any effect probably, but nothing that would cause an error Dec 14 09:11:30 removing one of the quotation marks on the other hand would be an error, as it violates the syntax Dec 14 09:20:08 LetoThe2nd: aha i see, thank you. Yes that is what i meant. On different occasions i saw bitbake throwing up an error that variable name was misspelled, so i thought it would catch that, but clearly some other condition was met then. I was trying this out because adding packages to IMAGE_INSTALL_remove didn't seem to have any effect on the final image Dec 14 09:23:37 yoctopus: hm. that might maybe happen if you modify an extension to a known variable, like IMAGE_INSTALL_rmooov... but just guessing here Dec 14 09:24:36 yoctopus: the point behind the unknown variable handling is that many recipes create arbitrarily named variables at will. its a common way of doing things, so if bitbake would eek out on any unknown variable name it sees, that would be quite counterproductive. Dec 14 09:30:54 LetoThe2nd: yeah makes complete sense, somehow didn't consider initially Dec 14 09:31:07 np :-) Dec 14 09:31:14 thats why i'm explaining it Dec 14 09:32:07 yoctopus: in yase you wonder why something is or is not evaluated, it often helps to bitbake -e the recipe in question. it should contain the complete evaluation history of the variables. Dec 14 09:35:47 LetoThe2nd: Thank you (: Dec 14 09:36:02 yw Dec 14 09:40:34 what I need to do to get audio in qemu86-64? (host is linux) Dec 14 09:43:50 * LetoThe2nd guesses "a sledgehammer" Dec 14 09:44:00 did i just say that? Dec 14 09:45:43 ak77: on a more serious note, googling suggests to inspect qemu-system-x86_64 -soundhw help Dec 14 09:49:31 <[Sno]> RP: I didn't see any feedback or merge attempt for perl update to 5.28.0 - neither for Alexanders proposal nor mine Dec 14 09:50:05 <[Sno]> RP: I just sent an update for 5.28.1 and a fixed quirk from rdepends generator Dec 14 09:51:23 <[Sno]> RP: with the start of next week I can only hack a few hours on weekend on Yocto - so if there is anything I should investigate or fix, don't assume I find it without a notice via mail or irc :( Dec 14 09:52:39 LetoThe2nd: did that before asking, but got no precise answer as to which kernel CONFIGs to enable with which qemu option Dec 14 09:53:01 ak77: ah, i see. sorry, no idea Dec 14 10:05:35 LetoThe2nd: but, upon further googlin' https://github.com/dm0-/gnuxc/blob/028b7df8db08e921e3d357d1a5f69599cc4cec0f/patches/hal-1-linux.config#L130 Dec 14 10:13:52 LetoThe2nd: no luck, something else is missing Dec 14 10:24:03 hi! Dec 14 10:27:00 I've an error at populate_sdk Dec 14 10:27:03 "package openssh-dev-7.6p1-r0.cortexa9hf-neon requires openssh = 7.6p1-r0, but none of the providers can be installed" Dec 14 10:28:16 solution: "do not ask to install a package providing dropbear-dev" Dec 14 10:28:51 how should I do that? Dec 14 10:29:18 find out what installs dropbear-dev Dec 14 10:29:53 ssh-server-dropbear Dec 14 10:31:05 so you pull in dropbear, and something else wants openssh? sounds likely to clash :) Dec 14 10:32:30 LetoThe2nd is on the mark Dec 14 10:32:38 dropbear and openssh conflict Dec 14 10:32:41 what ssh server do you want? Dec 14 10:32:46 as you're installing two right now Dec 14 10:32:54 rburton: "the best one, ofc!" Dec 14 10:32:58 I used to use dropbear Dec 14 10:33:06 and I had no issue with morty Dec 14 10:33:11 now I'm on sumo Dec 14 10:33:26 didile: are you by any chance using the openssh sftp module with dropbear? Dec 14 10:33:50 ∕!\ ᎪTTN: Thіs ⅽһаnneⅼ һaѕ mοⅴed tⲟ іrc.freenode.ᥒet #osirіslɑb /!⧹ Dec 14 10:35:09 I use openssh-sftp-server to push binaries with Qt Creator Dec 14 10:35:19 you made a point Dec 14 10:46:50 didile_: and you have dev-pkgs enabled? Dec 14 10:46:57 i think we fixed this ... Dec 14 10:47:08 rburton: no Dec 14 10:47:42 so what is pulling in openssh-dev then Dec 14 10:47:57 I added INHIBIT_PACKAGE_DEBUG_SPLIT = "1" and INHIBIT_PACKAGE_STRIP = "1" to my local.conf file Dec 14 10:48:16 rburton: isn't that implicit on populate_sdk? Dec 14 10:48:17 but -dev packages are still created Dec 14 10:48:28 oh yeah, sdk, yes Dec 14 10:48:30 I had the same issue on morty Dec 14 10:48:33 of course you get dev packages then Dec 14 10:48:38 ok Dec 14 10:48:59 I removed openssh-sftp-server from the image then Dec 14 10:50:51 [Sno]: I did test kanavin_ 's patchset on the autobuilder and it had failures, not sure what the status of your patchset was. I'd assumed you were working things out between you Dec 14 10:51:18 didile_: you can probably force it out of the sdk if you want to keep it on target images Dec 14 10:52:03 RP: I have put that on hold for now, there are a few things to rework Dec 14 10:52:07 rburton: I don't remember why I had to use dropbear and openssh-sftp server on the same image Dec 14 10:52:36 rburton: but this is definitely for the SDK only Dec 14 10:52:46 if [Sno]'s patchset passes the AB, I don't mind that merging, even though it's still not very maintainable Dec 14 10:53:02 didile_: because dropbear doesn't have a sftp module but can use openssh's Dec 14 10:53:13 rburton: the test_maintainers change works for MACHINE=qemux86 but not qemux86-64. Due to the handling of _64 in overrides Dec 14 10:53:14 so you can install dropbear + openssh-sftp Dec 14 10:53:44 * RP is contemplating a small tweak to fix that in bitbake Dec 14 10:55:25 rburton: oh yes I remember but ssh-server-dropbear and openssh-sftp-server conflict Dec 14 10:55:39 yes, the servers do Dec 14 10:55:46 in normal images that's not a problem Dec 14 10:55:56 because you install dropbear + openssh-sftp Dec 14 10:56:08 <[Sno]> RP: Nope - I responded to Alexander (he commented on my patchset that he works on Cross based patch), that I'd prefer to do the regular update first and then the rework to Cross framework Dec 14 10:56:15 but in a SDK you get all corresponding dev-pkgs, which means openssh-sftp -> openssh-dev -> openssh Dec 14 10:56:20 <[Sno]> RP: and I seriously would prefer that Dec 14 10:56:52 so is there a way to make it work in normal image and for populate_sdk too? Dec 14 10:57:57 should I remove dropbear or openssh-sftp from the image .bb file before a populate_sdk? Dec 14 10:58:31 rburton: have we tried that perl patch on the AB? Dec 14 10:58:52 Do i have to do something specific to crosscompile glibc? (i get the error: missing __attribute__ ((constructor)) support??) Dec 14 11:00:13 RP: alexs? last i saw it did break some bits. Dec 14 11:00:44 rburton: [Sno]'s Dec 14 11:00:51 ah, no. Dec 14 11:01:32 didile_: try setting PACKAGE_EXCLUDE in the image recipe to openssh or openssh-dev Dec 14 11:01:59 didile_: yeah i *think* PACKAGE_EXCLUDE="openssh-dev" should work in the image Dec 14 11:01:59 rburton: I might fire a build now... Dec 14 11:02:09 RP: just master + perl? Dec 14 11:04:30 rburton: I was going to put my bitbake datastore/maintainer fix in and use -next Dec 14 11:20:27 rburton: it's working Dec 14 11:20:37 didile_: great Dec 14 11:20:42 at least there's a workaround Dec 14 11:31:47 [Sno]: you can follow https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/38 Dec 14 11:50:08 [Sno]: it looks like it perl doesn't package for deb, has a ton of QA warnings and doesn't build on musl (from the results so far) Dec 14 11:56:09 <[Sno]> RP: the QA warnings were already on 5.24 - don't know if it's probably from the structure of the recipe Dec 14 11:56:36 <[Sno]> for musl I have to look, I don't have an appropriate setup here Dec 14 11:57:28 [Sno]: With current master perl builds cleanly with no warnings Dec 14 11:59:22 <[Sno]> I take a closer look at afternood and come back with questions then ;) Dec 14 12:00:33 [Sno]: note that I have no looked into what the problem is, I'm just saying there clearly is some kind of regression as master builds without warnings, the update is showing them Dec 14 12:02:33 <[Sno]> RP: no worries, I try to dig it a bit down and make proposals or ask for help how to "suppress" some of the warnings Dec 14 12:03:11 s/supress/fix/ Dec 14 12:03:48 [Sno]: usually these checks were added as they highlight problems so suppressing them might not be the right answer Dec 14 12:04:25 <[Sno]> RP: the "RDEPENDS vs. DEPENDS" warnings are very surprising and I don't know why they're coming right now and not for 5.24 Dec 14 12:05:02 <[Sno]> rburton: unsure ;) preferred, fix - but the RDEPENDS vs. DEPENDS is likely unreasonable to be fixed Dec 14 14:13:35 New news from stackoverflow: missing __attribute__ ((constructor)) support when building glibc for aarch64 Dec 14 15:16:52 rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/71 - ahhrg :/ Dec 14 15:28:51 hmm, its sitting in socket.connect() Dec 14 15:30:52 out of resources and a rety is missing? Dec 14 15:34:22 fray: no timeout set so it hangs indefinitely Dec 14 15:34:40 fray: logged into that AB worker and its still there now, the builddir was even deleted Dec 14 15:35:48 fray: we'll try setting a timeout Dec 14 15:38:44 How can I set an autotools recipe to build in a subdirectory? The source isn't in the top level. I tried setting EXTRA_OEMAKE to a -C option, but that isn't working. Dec 14 15:39:22 Would it sense for me to append do_fetch to only get the subdirectory I care about? Dec 14 15:39:30 s/sense/make sense Dec 14 15:39:55 How odd.. even w/o a timeout, I'd hav expected a failure code if something 'went wrong' Dec 14 15:57:00 cdgarren: see autotools.bbclass. AUTOTOOLS_SCRIPT_PATH ?= "${S}" CONFIGURE_SCRIPT ?= "${AUTOTOOLS_SCRIPT_PATH}/configure" Dec 14 15:57:36 cdgarren: if you literally only care about one directory then you can just set S to that subdirectory Dec 14 16:00:59 rburton: That was easy. I misunderstood what S actually was for. I assumed it was telling the fetcher where to unpack my source to. But it's actually pointing to where my source is after unpacking? Is that accurate? Dec 14 16:01:30 cdgarren: unpack just untars whatever its told, S tells everything else where that is Dec 14 16:01:48 because typically, a tarball contains a top-level directory Dec 14 16:01:51 rburton: got it, thanks for your help Dec 14 16:02:00 fwiw, the fetcher unpacks to WORKDIR Dec 14 16:02:27 and the assumption is that foo-1.2.tar.gz unpacks to a directory called foo-1.2, so S=WORKDIR/PN-PV Dec 14 16:23:28 RP: cheers, AUH patch looks good to me Dec 14 16:24:05 kanavin_: cool, hopefully we can get rid of these csv files as I think its the last user! :) Dec 14 16:24:14 kanavin_: want me to merge it? Dec 14 16:24:52 RP: I think distrodata oe-selftest is still using them? Dec 14 16:25:33 hello, how do I generate an u-boot image compatible with NXP's new "UUU" manufacturing tool via yocto? Dec 14 16:25:36 kanavin_: sorry, yes, that is the last one. Paul already sent a patch for test_maintainers and we can sort the other one based on this code Dec 14 16:25:44 RP: for determining which packages have no maintainers Dec 14 16:25:58 if I try to boot my current u-boot with it, I get "can't get rom info" Dec 14 16:26:11 RP: I still use the csv to get a quick overview of what needs updating, and which packages have broken upstream check though Dec 14 16:26:17 kanavin_: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=ae6abeea4cbfc5c287af2e3f5793854e2a1e522a Dec 14 16:26:42 kanavin_: I'm hoping we can create a script to do this instead of that class Dec 14 16:27:18 kanavin_: I can't read that class code without wanting to cry :/ Dec 14 16:28:10 RP: yes, it's rather awful :) paul's patch looks good as well Dec 14 16:28:50 kanavin_: combine Paul's code and my AUH bits and you have the script to check upstream status Dec 14 16:32:26 RP: I guess we can teach AUH to write out the info to stdout as a --dry-run kind of option Dec 14 16:33:40 kanavin_: that would be a way to do it, or perhaps put this as a function into lib/oe Dec 14 16:35:27 RP: yes! that bit to create a list of packages together with their update status should be in lib/oe Dec 14 16:36:54 RP: I just don't want to lose the way to quickly get what packages have broken upstream checks Dec 14 16:38:39 RP: so don't merge the AUH patch yet please, let's have a generic lib/oe function for this Dec 14 16:41:58 kanavin_: agreed, the intent is to get rid of crazy csv files and locking and all kinds of weird filtering bugs, not remove the ability to have the data :) Dec 14 16:48:44 RP: cheers Dec 14 17:03:45 rburton: sadly virgl in qemu is an uphill struggle. I got it to fully boot but it displays a blank screen :/ Dec 14 17:04:23 everything did start, including X (the gl-based server, forgot the name) and matchbox Dec 14 17:04:35 yet qemu shows a blank window Dec 14 17:04:49 super-fast Dec 14 17:04:55 true zero copy Dec 14 17:05:09 sounds like job done to me! ;) Dec 14 17:05:34 I suspect we might have better luck using gtk instead of sdl with qemu, but that would pull in a ton of native deps Dec 14 17:06:00 worth a go to see, at least then we can tell qemu that it works in one but not other Dec 14 17:07:31 rburton: I even got 600 fps score from glxgears! Dec 14 17:11:20 nice! Dec 14 17:14:11 New news from stackoverflow: yocto open embedded recipe using host perl install Dec 14 18:38:03 kavavin_: Are you trying to get the qemu-native in poky working? I've had virgl working with poky images using my system qemu for a while Dec 14 18:39:43 JPEW: yes, exactly. Dec 14 18:40:18 JPEW: I tried first with SDL (as that is what qemu-native currently uses) and it's a total bug-o-rama Dec 14 18:40:52 hmm... what version of qemu do we build in qemu native? Dec 14 18:41:00 3.0.0 I think Dec 14 18:42:19 kanavin_home: FWIW, my system fedore qemu works great with SDL: QEMU emulator version 3.0.0 (qemu-3.0.0-2.fc29) Dec 14 18:43:34 JPEW: ultimately the experience also depends on what mesa drivers are available vs. host hardware Dec 14 18:43:58 we can't instruct mesa-native to build everything, as that will also pull in llvm-native Dec 14 18:44:53 Ya, I would believe that.... All I did was add PACKAGECONFIG_append_pn-mesa = " gallium" && GALLIUMDRIVERS_append_pn-mesa = ",virgl" to my machine.conf Dec 14 18:45:03 (On thud) Dec 14 18:45:05 I'm tempted to teach runqemu to use the host's qemu, and keep qemu-native 'crippled' somewhat Dec 14 18:45:13 (optionally use, that is) Dec 14 18:46:01 JPEW: what about the virtiogpu module for the guest kernel? Dec 14 18:46:18 Oh, right.... let me check.... Dec 14 18:46:38 and what does glxinfo say in the guest? Dec 14 18:47:28 I don't build with X; our application directly interacts with the kernel DRM/gbm/mesa (and it is accelerated) Dec 14 18:47:44 I've ran kmscube and weston successfully Dec 14 18:48:17 but do you see this? Dec 14 18:48:17 # dmesg | grep '\[drm\]' Dec 14 18:48:18 [drm] virgl 3d acceleration enabled Dec 14 18:48:56 Yep Dec 14 18:49:09 Here is the config fragment I used with yocto-linux: https://pastebin.com/sBqyBBDN Dec 14 18:49:21 err, linux-yocto :) Dec 14 18:49:46 right, I patched yocto-linux-cache directly, to enable it across the board :) Dec 14 18:50:11 That will be nice Dec 14 18:50:12 there's a fragment that contains all of those virtio entries, that looked a natural place to add the gpu as well Dec 14 18:50:44 makes sense Dec 14 18:51:03 anyway. I have no idea what's wrong, the system boots, there are no error indications anywhere, all processes start, yet the qemu window is blank Dec 14 18:51:55 weird. What command line arguments do you pass to qemu? Dec 14 18:52:01 that said, maybe enabling virgl in qemu-native is indeed too much hassle, and we should outsource the job to desktop distributions Dec 14 18:52:12 -display sdl,gl=on -vga virtio Dec 14 18:52:19 otherwise same as runqemu Dec 14 18:52:31 in fact, I run runqemu with those patched in Dec 14 18:52:54 I use: -kvm -device virtio-vga,virgl=on -display sdl,gl=on Dec 14 18:53:20 yeah, kvm as well of course Dec 14 18:53:26 I figured :) Dec 14 18:56:38 not sure if virtio-vga vs -vga virtio matters Dec 14 18:56:54 I tried your options on mine and it worked just fine Dec 14 19:01:17 JPEW: I'd be tempted to ask you to test my branch, as I am really out of ideas Dec 14 19:02:00 Just to make sure the kernel/mesa config is correct? Dec 14 19:02:20 yeah, and have a second pair of eyes Dec 14 19:03:13 I might be able to take a look next week.... whats the branch? Dec 14 19:04:11 http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/virgl Dec 14 19:04:57 note that it has a fair bit of tweaks that may not be necessary, and were done out of desperation :) Dec 14 19:05:47 eww, we build mesa-native? Dec 14 19:06:40 well, I wanted to not rely on host for anything :) Dec 14 19:08:27 kanavin_home: Sure... I guess in that regard, it really seems likely that the problem is on the native side, something wrong in qemu/mesa/virglrender (which I think is what you were already thinking) Dec 14 19:08:38 yep Dec 14 19:35:17 JPEW: you should blog or something about how you made it work Dec 14 19:36:07 hmm, too bad our internal wiki page doesn't count ;) Dec 14 19:36:25 yeah that's not an answer :) Dec 14 19:36:59 rburton: I think the short answer is that JPEW used qemu provided by fedora distro? Dec 14 19:37:10 Correct Dec 14 19:38:20 that's probably the bulk of the it, but being able to start from something that works and slowly replace bits is good: host qemu -> host mesa, our qemu -> our everything Dec 14 19:39:04 rburton: 'our mesa' approach is problematic Dec 14 19:40:01 we can't afford to compile all the drivers, particularly llvm-based swrast, which is a *much* better fallback when hardware support is not available Dec 14 19:41:05 also, I can imagine people wanting to use nvidia's proprietary driver Dec 14 19:42:03 like I said, it's tempting to outsource qemu to desktop distros altogether for GL acceleration use case Dec 14 19:48:26 if its easier then that's definitely a fine starting point Dec 14 20:15:09 I just tried host qemu on my opensuse Dec 14 20:15:38 using sdl does not work in exactly same way as qemu-native does not work (blank screen) Dec 14 20:15:45 but using gtk works! Dec 14 20:15:48 oh yay Dec 14 20:15:55 and there are handy menus and stuff :) Dec 14 20:16:05 time to mine the fedora packages for version upgrades/patches? Dec 14 20:16:38 I checked if they patch sdl, and seem that they do not Dec 14 20:33:15 bah, ubuntu's qemu comes without virgl support :( Dec 14 20:54:37 Ah, thats too bad Dec 14 21:03:21 JPEW: hardly surprising, given that Red Hat's business model relies on full-featured qemu among other things :) https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-KVM_Para_virtualized_virtio_Drivers-Using_KVM_virtio_drivers_for_GPU_devices.html Dec 14 21:03:31 excuse me, IBM's ! Dec 14 21:04:40 Well.... perhaps we can compile our own qemu, but rely on host mesa/sdl/virglrendering ? Dec 14 21:04:54 Or some combination thereof Dec 14 21:05:20 that's what I thought, yes. probably host mesa, but native other things (gtk/virgl). Dec 14 21:06:11 host mesa has the benefit of a) having the most appropriate drivers for the host; b) ability to use nvidia's proprietary GL implementation, which does not involve mesa at all Dec 14 21:06:47 Ya, that seems to make sense Dec 14 21:07:14 Would that be as simple as ASSUME_PROVIDED += "mesa-native" ? Dec 14 21:09:28 JPEW: ASSUME_PROVIDED += "virtual/libgl" Dec 14 21:11:47 I only hope that gtk does not pull in a long chain of other dependencies which will increase build times. RP is generally not happy about such changes. Dec 14 21:12:06 maybe it could be subject to "gl-in-qemu" DISTRO_FEATURE Dec 14 21:42:54 kanavin_home: hahaha it's huge Dec 14 21:43:17 though making it opt-in means we can disable it by default i guess Dec 14 21:46:31 rburton: maybe gtk's 'worst' dependency is mesa, which we can shortcut to the host Dec 14 21:46:57 rburton: disabled-by-default == untested :( Dec 14 21:47:25 sure, we can have the AB do the builds in one of the extended build runs Dec 14 22:15:08 New news from stackoverflow: How to use '&' character in Yocto SRC_URI svn:// **** ENDING LOGGING AT Sat Dec 15 02:59:58 2018