Friday, 2018-12-14

*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto00:01
*** nishant_ <nishant_!6040dcfd@gateway/web/freenode/ip.> has joined #yocto00:11
nishant_inet_pton(AF_INET, "99||SDKTD[0", &(addr.sin_addr))00:12
nishant_This API is returning 1 (that means succesfull)00:13
nishant_Linux cb4f0b42-30a5-e162-dbb0-cbe8577b0c28 4.10.17-yocto-standard #14 SMP PREEMPT Thu Nov 8 19:44:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux00:13
nishant_Where should I file bug for this00:14
nishant_inet_aton() works fine00:14
*** KevinK <KevinK!~Kevinkk@> has quit IRC00:36
*** KevinK <KevinK!~Kevinkk@> has joined #yocto00:36
*** suy <suy!> has quit IRC00:42
*** suy <suy!> has joined #yocto00:42
*** pepijndevos <pepijndevos!~pepijndev@> has quit IRC01:04
*** pepijndevos <pepijndevos!~pepijndev@> has joined #yocto01:06
*** nishant_ <nishant_!6040dcfd@gateway/web/freenode/ip.> has quit IRC01:06
*** KevinK <KevinK!~Kevinkk@> has quit IRC01:25
*** rburton <rburton!> has quit IRC01:29
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC02:38
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto02:43
*** otavio_ <otavio_!> has quit IRC03:37
*** otavio_ <otavio_!> has joined #yocto03:46
*** learningc <learningc!> has joined #yocto03:59
*** learningc <learningc!> has quit IRC04:25
*** learningc <learningc!> has joined #yocto04:26
yoctiNew news from stackoverflow: Yocto core-image-* (minimal) networking <>05:11
*** learningc <learningc!> has quit IRC05:25
*** learningc <learningc!> has joined #yocto05:27
*** learningc <learningc!> has quit IRC05:28
*** learningc <learningc!> has joined #yocto05:30
*** hamis <hamis!~irfan@> has joined #yocto05:54
yoctiNew news from stackoverflow: requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC <>06:11
*** AndersD <AndersD!> has joined #yocto06:12
*** AndersD <AndersD!> has quit IRC06:15
*** AndersD <AndersD!~AndersD@> has joined #yocto06:15
*** kaspter <kaspter!~Instantbi@> has quit IRC06:18
*** kaspter <kaspter!~Instantbi@> has joined #yocto06:18
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC06:24
*** learningc <learningc!> has quit IRC06:25
*** learningc <learningc!> has joined #yocto06:26
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC06:38
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto06:39
yoctiNew news from stackoverflow: PHP odbc driver as shared extension <>06:42
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto06:58
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto07:01
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC07:09
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto07:11
*** mihais <mihais!~mihaiserb@> has joined #yocto07:13
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC07:15
*** Bunio_FH <Bunio_FH!> has joined #yocto07:20
*** ant_home <ant_home!> has quit IRC07:21
*** learningc <learningc!> has quit IRC07:26
*** learningc <learningc!> has joined #yocto07:27
*** cvasilak <cvasilak!> has joined #yocto07:27
*** tprrt <tprrt!~tprrt@> has joined #yocto07:36
*** jmiehe <jmiehe!> has joined #yocto07:44
*** TobSnyder <TobSnyder!> has joined #yocto08:07
*** erbo <erbo!> has joined #yocto08:14
erboIs 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)08:15
LetoThe2nderbo: 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.08:19
*** sagner <sagner!~ags@> has joined #yocto08:19
erboLetoThe2nd: Right, the runqemu part was easy. Just add extra qemu params as you said.08:21
LetoThe2ndfor the testimage no idea, sorry.08:23
*** learningc <learningc!> has quit IRC08:25
*** learningc <learningc!> has joined #yocto08:26
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto08:29
*** diego_r <diego_r!~diego@> has joined #yocto08:32
*** lucaceresoli <lucaceresoli!> has joined #yocto08:33
*** varjag <varjag!> has joined #yocto08:39
*** diego_r <diego_r!~diego@> has quit IRC08:47
*** yoctopus <yoctopus!c19e5dd3@gateway/web/freenode/ip.> has joined #yocto08:59
*** yann <yann!> has quit IRC09:00
yoctopushello ! 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 ?09:01
LetoThe2ndyoctopus: as usual on irc: don't ask to ask, just ask. preferable as precisely as possible - so when somebody knows, he/she will answer09:02
*** diego_r <diego_r!~diego@> has joined #yocto09:02
*** ant_home <ant_home!> has joined #yocto09:04
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC09:06
yoctopusoh sorry... Anyway. I have a custom image recipe (folder hierarchy based on freescale layers) in meta-mylayer/imx/meta-sdk/recipes-myrecipes/images/ . 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 to09:06
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto09:06
LetoThe2ndyoctopus: you mea, you expect a parsing error becasue you intentionally mistyped IMAGE_INSTALL to IMAGE_IsnTALL09:08
LetoThe2ndin 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 error09:09
LetoThe2ndremoving one of the quotation marks on the other hand would be an error, as it violates the syntax09:11
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC09:11
*** diego_r <diego_r!~diego@> has quit IRC09:14
*** diego_r <diego_r!~diego@> has joined #yocto09:15
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:17
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto09:17
yoctopusLetoThe2nd: 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 image09:20
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:21
LetoThe2ndyoctopus: hm. that might maybe happen if you modify an extension to a known variable, like IMAGE_INSTALL_rmooov... but just guessing here09:23
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC09:23
LetoThe2ndyoctopus: 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.09:24
*** learningc <learningc!> has quit IRC09:25
*** learningc <learningc!> has joined #yocto09:26
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:c4f9:280c:be4b:6b66> has joined #yocto09:29
yoctopusLetoThe2nd: yeah makes complete sense, somehow didn't consider initially09:30
LetoThe2ndnp :-)09:31
LetoThe2ndthats why i'm explaining it09:31
LetoThe2ndyoctopus: 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.09:32
yoctopusLetoThe2nd: Thank you (:09:35
*** diego_r <diego_r!~diego@> has quit IRC09:39
ak77what I need to do to get audio in qemu86-64? (host is linux)09:40
* LetoThe2nd guesses "a sledgehammer"09:43
LetoThe2nddid i just say that? </SCNR>09:44
LetoThe2ndak77: on a more serious note, googling suggests to inspect qemu-system-x86_64 -soundhw help09:45
*** egavin <egavin!> has joined #yocto09:46
[Sno]RP: I didn't see any feedback or merge attempt for perl update to 5.28.0 - neither for Alexanders proposal nor mine09:49
[Sno]RP: I just sent an update for 5.28.1 and a fixed quirk from rdepends generator09:50
[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 :(09:51
ak77LetoThe2nd: did that before asking, but got no precise answer as to which kernel CONFIGs to enable with which qemu option09:52
LetoThe2ndak77: ah, i see. sorry, no idea09:53
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto09:53
*** yann <yann!> has joined #yocto09:57
ak77LetoThe2nd: but, upon further googlin'
ak77LetoThe2nd: no luck, something else is missing10:13
*** Bunio_FH <Bunio_FH!> has quit IRC10:14
*** yoctopus <yoctopus!c19e5dd3@gateway/web/freenode/ip.> has quit IRC10:15
*** Bunio_FH <Bunio_FH!> has joined #yocto10:15
*** didile <didile!b07ff51a@gateway/web/freenode/ip.> has joined #yocto10:23
*** rburton <rburton!> has joined #yocto10:25
*** learningc <learningc!> has quit IRC10:25
*** learningc <learningc!> has joined #yocto10:26
didileI've an error at populate_sdk10:27
didile"package openssh-dev-7.6p1-r0.cortexa9hf-neon requires openssh = 7.6p1-r0, but none of the providers can be installed"10:27
didilesolution: "do not ask to install a package providing dropbear-dev"10:28
didilehow should I do that?10:28
LetoThe2ndfind out what installs dropbear-dev10:29
*** berton <berton!~berton@> has joined #yocto10:30
LetoThe2ndso you pull in dropbear, and something else wants openssh? sounds likely to clash :)10:31
rburtonLetoThe2nd is on the mark10:32
rburtondropbear and openssh conflict10:32
rburtonwhat ssh server do you want?10:32
rburtonas you're installing two right now10:32
LetoThe2ndrburton: "the best one, ofc!"10:32
didileI used to use dropbear10:32
didileand I had no issue with morty10:33
didilenow I'm on sumo10:33
rburtondidile: are you by any chance using the openssh sftp module with dropbear?10:33
*** sararussell8875 <sararussell8875!~sararusse@> has joined #yocto10:33
sararussell8875∕!\ ᎪTTN: Thіs ⅽһаnneⅼ һaѕ mοⅴed tⲟ іrc.freenode.ᥒet #osirіslɑb /!⧹10:33
*** sararussell8875 <sararussell8875!~sararusse@> has quit IRC10:34
*** didile_ <didile_!b07ff51a@gateway/web/freenode/ip.> has joined #yocto10:34
didile_I use openssh-sftp-server to push binaries with Qt Creator10:35
didile_you made a point10:35
*** berton <berton!~berton@> has quit IRC10:37
*** berton <berton!~berton@> has joined #yocto10:37
*** cvasilak <cvasilak!> has quit IRC10:37
*** didile <didile!b07ff51a@gateway/web/freenode/ip.> has quit IRC10:37
*** cvasilak <cvasilak!> has joined #yocto10:38
rburtondidile_: and you have dev-pkgs enabled?10:46
rburtoni think we fixed this ...10:46
didile_rburton: no10:47
rburtonso what is pulling in openssh-dev then10:47
didile_I added INHIBIT_PACKAGE_DEBUG_SPLIT = "1" and INHIBIT_PACKAGE_STRIP = "1" to my local.conf file10:47
LetoThe2ndrburton: isn't that implicit on populate_sdk?10:48
didile_but -dev packages are still created10:48
rburtonoh yeah, sdk, yes10:48
didile_I had the same issue on morty10:48
rburtonof course you get dev packages then10:48
didile_I removed openssh-sftp-server from the image then10:48
RP[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 you10:50
rburtondidile_: you can probably force it out of the sdk if you want to keep it on target images10:51
*** rburton <rburton!> has quit IRC10:51
*** rburton <rburton!> has joined #yocto10:51
kanavin_RP: I have put that on hold for now, there are a few things to rework10:52
didile_rburton: I don't remember why I had to use dropbear and openssh-sftp server on the same image10:52
didile_rburton: but this is definitely for the SDK only10:52
kanavin_if [Sno]'s patchset passes the AB, I don't mind that merging, even though it's still not very maintainable10:52
rburtondidile_: because dropbear doesn't have a sftp module but can use openssh's10:53
RPrburton: the test_maintainers change works for MACHINE=qemux86 but not qemux86-64. Due to the handling of _64 in overrides10:53
rburtonso you can install dropbear + openssh-sftp10:53
* RP is contemplating a small tweak to fix that in bitbake10:53
*** hrkrx <hrkrx!> has joined #yocto10:54
didile_rburton: oh yes I remember but ssh-server-dropbear and openssh-sftp-server conflict10:55
rburtonyes, the servers do10:55
rburtonin normal images that's not a problem10:55
rburtonbecause you install dropbear + openssh-sftp10:55
[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 framework10:56
rburtonbut in a SDK you get all corresponding dev-pkgs, which means openssh-sftp -> openssh-dev -> openssh10:56
[Sno]RP: and I seriously would prefer that10:56
didile_so is there a way to make it work in normal image and for populate_sdk too?10:56
didile_should I remove dropbear or openssh-sftp from the image .bb file before a populate_sdk?10:57
*** florian_kc is now known as florian10:58
RPrburton: have we tried that perl patch on the AB?10:58
hrkrxDo i have to do something specific to crosscompile glibc? (i get the error: missing __attribute__ ((constructor)) support??)10:58
rburtonRP: alexs?  last i saw it did break some bits.11:00
RPrburton: [Sno]'s11:00
rburtonah, no.11:00
rburtondidile_: try setting PACKAGE_EXCLUDE in the image recipe to openssh or openssh-dev11:01
rburtondidile_: yeah i *think* PACKAGE_EXCLUDE="openssh-dev" should work in the image11:01
RPrburton: I might fire a build now...11:01
rburtonRP: just master + perl?11:02
RPrburton: I was going to put my bitbake datastore/maintainer fix in and use -next11:04
*** cvasilak <cvasilak!> has quit IRC11:08
*** hrkrx <hrkrx!> has left #yocto11:09
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC11:11
*** hrkrx <hrkrx!> has joined #yocto11:12
*** hrkrx <hrkrx!> has left #yocto11:12
didile_rburton: it's working11:20
rburtondidile_: great11:20
rburtonat least there's a workaround11:20
*** learningc <learningc!> has quit IRC11:26
*** learningc <learningc!> has joined #yocto11:26
RP[Sno]: you can follow
*** dmoseley <dmoseley!> has quit IRC11:37
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto11:41
RP[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)11:50
*** sagner <sagner!~ags@> has quit IRC11:51
*** sagner <sagner!~ags@> has joined #yocto11:53
[Sno]RP: the QA warnings were already on 5.24 - don't know if it's probably from the structure of the recipe11:56
[Sno]for musl I have to look, I don't have an appropriate setup here11:56
RP[Sno]: With current master perl builds cleanly with no warnings11:57
[Sno]I take a closer look at afternood and come back with questions then ;)11:59
RP[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 them12:00
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC12:02
[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 warnings12:02
RP[Sno]: usually these checks were added as they highlight problems so suppressing them might not be the right answer12:03
[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.2412:04
[Sno]rburton: unsure ;) preferred, fix - but the RDEPENDS vs. DEPENDS is likely unreasonable to be fixed12:05
*** muppe <muppe!> has joined #yocto12:09
*** niro22 <niro22!> has joined #yocto12:10
*** comptroller <comptroller!> has quit IRC12:19
*** comptroller <comptroller!> has joined #yocto12:19
*** kristoiv <kristoiv!~kristoiv@> has joined #yocto12:21
*** learningc <learningc!> has quit IRC12:26
*** learningc <learningc!> has joined #yocto12:26
*** niro22 <niro22!> has quit IRC12:28
*** jmiehe <jmiehe!> has quit IRC12:31
*** AndersD <AndersD!~AndersD@> has quit IRC12:36
*** AndersD <AndersD!> has joined #yocto12:38
*** fsdun <fsdun!> has quit IRC12:42
*** marka <marka!~masselst@> has joined #yocto12:51
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC13:10
*** gtristan <gtristan!~tristanva@> has joined #yocto13:11
*** marble_visions <marble_visions!~user@> has quit IRC13:11
*** marble_visions <marble_visions!~user@> has joined #yocto13:12
*** learningc <learningc!> has quit IRC13:18
*** fsdun <fsdun!> has joined #yocto13:18
*** fsdun <fsdun!> has quit IRC13:28
*** fsdun <fsdun!> has joined #yocto13:32
*** OpenSorceress <OpenSorceress!> has joined #yocto13:36
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto13:36
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC13:39
*** varjag <varjag!> has quit IRC13:49
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto13:58
yoctiNew news from stackoverflow: missing __attribute__ ((constructor)) support when building glibc for aarch64 <>14:13
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto14:18
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto14:18
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC14:30
*** hamis <hamis!~irfan@> has quit IRC14:43
*** kristoiv <kristoiv!~kristoiv@> has quit IRC14:52
*** jofr <jofr!~jofr@> has left #yocto14:58
*** waldhar <waldhar!> has joined #yocto14:59
*** eduardas_m__ <eduardas_m__!~Eduardas@> has joined #yocto15:00
*** eduardas_m <eduardas_m!~Eduardas@> has joined #yocto15:00
*** AndersD <AndersD!> has quit IRC15:03
*** eduardas_m___ <eduardas_m___!~Eduardas@> has joined #yocto15:08
*** eduardas_m <eduardas_m!~Eduardas@> has quit IRC15:08
*** eduardas_m__ <eduardas_m__!~Eduardas@> has quit IRC15:08
*** eduardas_m___ <eduardas_m___!~Eduardas@> has quit IRC15:08
*** eduardas_m <eduardas_m!~Eduardas@> has joined #yocto15:08
*** ant_home <ant_home!> has quit IRC15:12
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto15:14
RPrburton: - ahhrg :/15:16
*** AndersD <AndersD!~AndersD@> has joined #yocto15:21
*** tprrt <tprrt!~tprrt@> has quit IRC15:24
*** AndersD <AndersD!~AndersD@> has quit IRC15:24
*** AndersD <AndersD!~AndersD@> has joined #yocto15:26
RPhmm, its sitting in socket.connect()15:28
frayout of resources and a rety is missing?15:30
*** AndersD <AndersD!~AndersD@> has quit IRC15:32
RPfray: no timeout set so it hangs indefinitely15:34
RPfray: logged into that AB worker and its still there now, the builddir was even deleted15:34
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC15:34
*** fsdun <fsdun!> has quit IRC15:34
*** TobSnyder <TobSnyder!> has quit IRC15:35
RPfray: we'll try setting a timeout15:35
*** cdgarren <cdgarren!~cdgarren@> has joined #yocto15:36
cdgarrenHow 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.15:38
cdgarrenWould it sense for me to append do_fetch to only get the subdirectory I care about?15:39
cdgarrens/sense/make sense15:39
frayHow odd.. even w/o a timeout, I'd hav expected a failure code if something 'went wrong'15:39
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto15:41
*** eduardas_m <eduardas_m!~Eduardas@> has quit IRC15:45
*** armpit <armpit!~armpit@2601:202:4180:c33:1cde:ec36:ad31:c07e> has quit IRC15:53
rburtoncdgarren: see autotools.bbclass. AUTOTOOLS_SCRIPT_PATH ?= "${S}"  CONFIGURE_SCRIPT ?= "${AUTOTOOLS_SCRIPT_PATH}/configure"15:57
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has left #yocto15:57
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto15:57
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto15:57
rburtoncdgarren: if you literally only care about one directory then you can just set S to that subdirectory15:57
*** Bunio_FH <Bunio_FH!> has quit IRC15:57
cdgarrenrburton: 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?16:00
rburtoncdgarren: unpack just untars whatever its told, S tells everything else where that is16:01
rburtonbecause typically, a tarball contains a top-level directory16:01
cdgarrenrburton: got it, thanks for your help16:01
rburtonfwiw, the fetcher unpacks to WORKDIR16:02
*** prabhakarlad <prabhakarlad!~prabhakar@> has left #yocto16:02
rburtonand the assumption is that foo-1.2.tar.gz unpacks to a directory called foo-1.2, so S=WORKDIR/PN-PV16:02
*** sagner <sagner!~ags@> has quit IRC16:05
*** armpit <armpit!~armpit@2601:202:4180:c33:89fb:1aae:c674:da2b> has joined #yocto16:05
*** sagner <sagner!~ags@> has joined #yocto16:06
*** lusus <lusus!~lusus@> has quit IRC16:09
*** JaMa <JaMa!~martin@> has quit IRC16:10
*** maudat <maudat!~moda@> has joined #yocto16:15
*** eduardas_m <eduardas_m!~eduardas@> has joined #yocto16:19
kanavin_RP: cheers, AUH patch looks good to me16:23
RPkanavin_: cool, hopefully we can get rid of these csv files as I think its the last user! :)16:24
RPkanavin_: want me to merge it?16:24
kanavin_RP: I think distrodata oe-selftest is still using them?16:24
eduardas_mhello, how do I generate an u-boot image compatible with NXP's new "UUU" manufacturing tool via yocto?16:25
RPkanavin_: 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 code16:25
kanavin_RP: for determining which packages have no maintainers16:25
eduardas_mif I try to boot my current u-boot with it, I get "can't get rom info"16:25
kanavin_RP: I still use the csv to get a quick overview of what needs updating, and which packages have broken upstream check though16:26
RPkanavin_: I'm hoping we can create a script to do this instead of that class16:26
RPkanavin_: I can't read that class code without wanting to cry :/16:27
kanavin_RP: yes, it's rather awful :) paul's patch looks good as well16:28
RPkanavin_: combine Paul's code and my AUH bits and you have the script to check upstream status16:28
kanavin_RP: I guess we can teach AUH to write out the info to stdout as a --dry-run kind of option16:32
RPkanavin_: that would be a way to do it, or perhaps put this as a function into lib/oe16:33
kanavin_RP: yes! that bit to create a list of packages together with their update status should be in lib/oe16:35
kanavin_RP: I just don't want to lose the way to quickly get what packages have broken upstream checks16:36
kanavin_RP: so don't merge the AUH patch yet please, let's have a generic lib/oe function for this16:38
*** ant_home <ant_home!> has joined #yocto16:41
RPkanavin_: 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 :)16:41
*** kristoiv <kristoiv!> has joined #yocto16:46
*** sagner <sagner!~ags@> has quit IRC16:47
kanavin_RP: cheers16:48
*** didile_ <didile_!b07ff51a@gateway/web/freenode/ip.> has quit IRC16:49
*** mihais <mihais!~mihaiserb@> has quit IRC16:52
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC16:53
*** egavin <egavin!> has quit IRC17:01
*** kristoiv <kristoiv!> has quit IRC17:02
kanavin_rburton: sadly virgl in qemu is an uphill struggle. I got it to fully boot but it displays a blank screen :/17:03
kanavin_everything did start, including X (the gl-based server, forgot the name) and matchbox17:04
kanavin_yet qemu shows a blank window17:04
rburtontrue zero copy17:04
rburtonsounds like job done to me! ;)17:05
kanavin_I suspect we might have better luck using gtk instead of sdl with qemu, but that would pull in a ton of native deps17:05
rburtonworth a go to see, at least then we can tell qemu that it works in one but not other17:06
kanavin_rburton: I even got 600 fps score from glxgears!17:07
*** tprrt <tprrt!> has joined #yocto17:08
*** eduardas_m <eduardas_m!~eduardas@> has quit IRC17:08
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC17:12
yoctiNew news from stackoverflow: yocto open embedded recipe using host perl install <>17:14
*** grma <grma!~gruberm@> has quit IRC17:49
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC18:11
*** yann <yann!> has quit IRC18:35
JPEWkavavin_: 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 while18:38
kanavin_homeJPEW: yes, exactly.18:39
kanavin_homeJPEW: I tried first with SDL (as that is what qemu-native currently uses) and it's a total bug-o-rama18:40
JPEWhmm... what version of qemu do we build in qemu native?18:40
kanavin_home3.0.0 I think18:41
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC18:41
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto18:42
JPEWkanavin_home: FWIW, my system fedore qemu works great with SDL: QEMU emulator version 3.0.0 (qemu-3.0.0-2.fc29)18:42
kanavin_homeJPEW: ultimately the experience also depends on what mesa drivers are available vs. host hardware18:43
kanavin_homewe can't instruct mesa-native to build everything, as that will also pull in llvm-native18:43
JPEWYa, I would believe that.... All I did was add PACKAGECONFIG_append_pn-mesa = " gallium" && GALLIUMDRIVERS_append_pn-mesa = ",virgl" to my machine.conf18:44
JPEW(On thud)18:45
kanavin_homeI'm tempted to teach runqemu to use the host's qemu, and keep qemu-native 'crippled' somewhat18:45
kanavin_home(optionally use, that is)18:45
kanavin_homeJPEW: what about the virtiogpu module for the guest kernel?18:46
JPEWOh, right.... let me check....18:46
kanavin_homeand what does glxinfo say in the guest?18:46
JPEWI don't build with X; our application directly interacts with the kernel DRM/gbm/mesa (and it is accelerated)18:47
JPEWI've ran kmscube and weston successfully18:47
kanavin_homebut do you see this?18:48
kanavin_home# dmesg | grep '\[drm\]'18:48
kanavin_home[drm] virgl 3d acceleration enabled18:48
JPEWHere is the config fragment I used with yocto-linux:
JPEWerr, linux-yocto :)18:49
kanavin_homeright, I patched yocto-linux-cache directly, to enable it across the board :)18:49
JPEWThat will be nice18:50
kanavin_homethere's a fragment that contains all of those virtio entries, that looked a natural place to add the gpu as well18:50
JPEWmakes sense18:50
kanavin_homeanyway. I have no idea what's wrong, the system boots, there are no error indications anywhere, all processes start, yet the qemu window is blank18:51
JPEWweird. What command line arguments do you pass to qemu?18:51
kanavin_homethat said, maybe enabling virgl in qemu-native is indeed too much hassle, and we should outsource the job to desktop distributions18:52
kanavin_home-display sdl,gl=on -vga virtio18:52
kanavin_homeotherwise same as runqemu18:52
kanavin_homein fact, I run runqemu with those patched in18:52
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:c4f9:280c:be4b:6b66> has quit IRC18:52
JPEWI use: -kvm -device virtio-vga,virgl=on -display sdl,gl=on18:52
kanavin_homeyeah, kvm as well of course18:53
JPEWI figured :)18:53
kanavin_homenot sure if virtio-vga vs -vga virtio matters18:56
JPEWI tried your options on mine and it worked just fine18:56
kanavin_homeJPEW: I'd be tempted to ask you to test my branch, as I am really out of ideas19:01
JPEWJust to make sure the kernel/mesa config is correct?19:02
kanavin_homeyeah, and have a second pair of eyes19:02
JPEWI might be able to take a look next week.... whats the branch?19:03
kanavin_homenote that it has a fair bit of tweaks that may not be necessary, and were done out of desperation :)19:04
JPEWeww, we build mesa-native?19:05
kanavin_homewell, I wanted to not rely on host for anything :)19:06
JPEWkanavin_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)19:08
*** thaytan <thaytan!> has quit IRC19:10
*** cag_ss <cag_ss!~chris@> has quit IRC19:23
rburtonJPEW: you should blog or something about how you made it work19:35
JPEWhmm, too bad our internal wiki page doesn't count ;)19:36
rburtonyeah that's not an answer :)19:36
kanavin_homerburton: I think the short answer is that JPEW used qemu provided by fedora distro?19:36
rburtonthat'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 everything19:38
kanavin_homerburton: 'our mesa' approach is problematic19:39
*** marka <marka!~masselst@> has quit IRC19:39
kanavin_homewe can't afford to compile all the drivers, particularly llvm-based swrast, which is a *much* better fallback when hardware support is not available19:40
kanavin_homealso, I can imagine people wanting to use nvidia's proprietary driver19:41
kanavin_homelike I said, it's tempting to outsource qemu to desktop distros altogether for GL acceleration use case19:42
rburtonif its easier then that's definitely a fine starting point19:48
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:00
*** berton <berton!~berton@> has quit IRC20:10
kanavin_homeI just tried host qemu on my opensuse20:15
kanavin_homeusing sdl does not work in exactly same way as qemu-native does not work (blank screen)20:15
kanavin_homebut using gtk works!20:15
rburtonoh yay20:15
kanavin_homeand there are handy menus and stuff :)20:15
rburtontime to mine the fedora packages for version upgrades/patches?20:16
kanavin_homeI checked if they patch sdl, and seem that they do not20:16
*** dv_ <dv_!~dv@> has quit IRC20:23
*** Carton__ <Carton__!~jo@2a02:120b:2c3c:3bf0:5838:4b8d:c006:b420> has joined #yocto20:28
kanavin_homebah, ubuntu's qemu comes without virgl support :(20:33
*** marka <marka!~masselst@> has joined #yocto20:36
*** dv_ <dv_!~dv@> has joined #yocto20:37
*** tgoodwin <tgoodwin!> has quit IRC20:43
*** yann <yann!> has joined #yocto20:46
JPEWAh, thats too bad20:54
kanavin_homeJPEW: hardly surprising, given that Red Hat's business model relies on full-featured qemu among other things :)
kanavin_homeexcuse me, IBM's !21:03
JPEWWell.... perhaps we can compile our own qemu, but rely on host mesa/sdl/virglrendering ?21:04
JPEWOr some combination thereof21:04
kanavin_homethat's what I thought, yes. probably host mesa, but native other things (gtk/virgl).21:05
kanavin_homehost 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 all21:06
JPEWYa, that seems to make sense21:06
JPEWWould that be as simple as ASSUME_PROVIDED += "mesa-native" ?21:07
kanavin_homeJPEW:  ASSUME_PROVIDED += "virtual/libgl"21:09
*** micka_ <micka_!> has quit IRC21:09
*** micka <micka!> has joined #yocto21:11
kanavin_homeI 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.21:11
kanavin_homemaybe it could be subject to "gl-in-qemu" DISTRO_FEATURE21:12
rburtonkanavin_home: hahaha it's huge21:42
rburtonthough making it opt-in means we can disable it by default i guess21:43
kanavin_homerburton: maybe gtk's 'worst' dependency is mesa, which we can shortcut to the host21:46
kanavin_homerburton: disabled-by-default == untested :(21:46
rburtonsure, we can have the AB do the builds in one of the extended build runs21:47
*** Carton__ <Carton__!~jo@2a02:120b:2c3c:3bf0:5838:4b8d:c006:b420> has quit IRC21:59
*** rburton <rburton!> has quit IRC21:59
*** marka <marka!~masselst@> has quit IRC22:02
yoctiNew news from stackoverflow: How to use '&' character in Yocto SRC_URI svn:// <>22:15
*** Crofton_ <Crofton_!~Crofton@2601:5c0:c100:b84:4075:a01f:16e7:a914> has quit IRC22:23
*** maudat <maudat!~moda@> has quit IRC22:23
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC22:34
*** Crofton_ <Crofton_!~Crofton@2601:5c0:c100:b84:5900:f55c:6c11:3ccf> has joined #yocto22:34
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto22:34
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC22:39
*** OpenSorceress <OpenSorceress!> has joined #yocto22:40
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto22:40
*** nate02 <nate02!> has joined #yocto22:46
*** nate0202 <nate0202!> has quit IRC22:49
*** tgraydon <tgraydon!textual@nat/intel/x-qnqxjqotsprnpcla> has joined #yocto23:30
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:31
*** tgraydon <tgraydon!textual@nat/intel/x-qnqxjqotsprnpcla> has quit IRC23:36
*** tgraydon <tgraydon!~textual@> has joined #yocto23:38
*** nate0202 <nate0202!> has joined #yocto23:39
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto23:40
*** nate02 <nate02!> has quit IRC23:42
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC23:42
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto23:51

Generated by 2.11.0 by Marius Gedminas - find it at!