Friday, 2019-08-09

*** learningc <learningc!~learningc@> has joined #yocto00:01
*** learningc <learningc!~learningc@> has quit IRC00:05
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC00:39
*** vineela <vineela!vtummala@nat/intel/x-ztmbghnpfrsmytyw> has quit IRC00:41
*** learningc <learningc!> has joined #yocto00:51
*** Crofton <Crofton!~Crofton@2601:5c0:c100:b84:b9f6:9972:3db8:cd9f> has joined #yocto00:51
*** learningc <learningc!> has quit IRC00:53
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto00:53
*** learningc <learningc!> has joined #yocto00:54
yoctiNew news from stackoverflow: Change $TMPDIR in yocto <>02:04
*** armpit <armpit!~armpit@2601:202:4180:c33:850a:47c7:68f4:7b01> has quit IRC02:41
*** kaspter <kaspter!~Instantbi@> has quit IRC02:49
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:49
*** kaspter <kaspter!~Instantbi@> has quit IRC02:51
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:51
*** armpit <armpit!~armpit@2601:202:4180:c33:606f:67f:8951:122a> has joined #yocto02:53
yoctiNew news from stackoverflow: Convert a tar.xz into a tar.gz in the deb package <>03:04
*** yizhao <yizhao!~zhaoyi@> has quit IRC03:17
*** yizhao <yizhao!~zhaoyi@> has joined #yocto03:19
*** comptroller <comptroller!> has quit IRC03:22
*** comptroller <comptroller!> has joined #yocto03:24
*** kaspter <kaspter!~Instantbi@> has quit IRC03:40
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:46
*** khem <khem!~khem@unaffiliated/khem> has quit IRC04:04
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto04:17
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC05:15
*** fdav <fdav!~Thunderbi@> has joined #yocto05:20
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC05:25
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto05:26
*** kroon <kroon!~kroon@> has joined #yocto05:55
*** fdav <fdav!~Thunderbi@> has quit IRC06:04
*** fdav <fdav!~Thunderbi@> has joined #yocto06:05
*** alessioigor <alessioigor!~alessioig@> has quit IRC06:17
*** agust <agust!> has joined #yocto06:19
*** diego_r <diego_r!~diego@> has joined #yocto06:21
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:24
*** fdav <fdav!~Thunderbi@> has quit IRC06:26
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:36
*** alessioigor <alessioigor!~alessioig@> has quit IRC06:38
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:41
*** tprrt <tprrt!> has joined #yocto06:43
*** TobSnyder <TobSnyder!> has joined #yocto06:43
*** learningc <learningc!> has quit IRC07:02
*** learningc <learningc!> has joined #yocto07:03
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC07:04
*** learningc <learningc!> has joined #yocto07:04
*** yacar_ <yacar_!~yacar@> has joined #yocto07:14
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:21
Dvorkinkernel Kconfig meta problem: Why
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC07:23
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC07:27
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto07:27
*** yacar_ <yacar_!~yacar@> has quit IRC07:28
*** yacar_ <yacar_!~yacar@> has joined #yocto07:30
*** diego_r <diego_r!~diego@> has quit IRC07:31
*** diego_r <diego_r!~diego@> has joined #yocto07:35
*** goliath <goliath!> has joined #yocto07:35
*** yacar_ <yacar_!~yacar@> has quit IRC07:43
*** amaury_d <amaury_d!> has joined #yocto07:58
amaury_dhi everyone07:58
amaury_dI have a question, is it possible to force a recipe to be rebuild if the image rootfs is rebuild as well ?07:59
amaury_dto explain my need, when I do <bitbake my-image>, I want to rebuild os-release recipe if do_rootfs is executed08:00
amaury_dto have the DATETIME var in /etc/os-release of the rootfs08:00
LetoThe2ndamaury_d: that actually sounds more like you want a ROOTFS_POSTPROCESS_CMD, not an extended recipe.08:03
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:03
*** diego_r <diego_r!~diego@> has quit IRC08:03
amaury_dLetoThe2nd: yes I could do it via ROOTFS_POSTPROCESS_CMD08:04
amaury_dbut when I saw os-release recipe from poky/meta, I though it was designed for this use case08:04
*** leitao <leitao!~leitao@2620:10d:c092:200::1:2fb1> has joined #yocto08:05
LetoThe2ndamaury_d: it sepcifies the os_release, just like the name says. not the build date.08:05
amaury_dparticularly because of BUILD_ID ?= ${DATETIME}08:05
LetoThe2ndlet me have a look :)08:05
LetoThe2ndamaury_d: hm, maybe it would even be enough to remove the vardepsexclude on DATETIME08:08
*** jofr <jofr!~jofr@> has joined #yocto08:08
amaury_dbut in this case the image will be always rebuild ?08:09
amaury_dI try to find the optimal way, to avoid having rebuild image if everything is up to date if possible08:09
*** Tamis <Tamis!504e056f@> has joined #yocto08:09
amaury_delse, what is the syntax to remove DATETIME from vardepsexclude ?08:10
LetoThe2ndi can see what you want, but i don't think theres a neat way. just a postprocess cmd08:10
LetoThe2ndgood question.08:11
LetoThe2ndRP: can you enlighten us if theres magic for this?08:11
*** vineela <vineela!~vtummala@> has joined #yocto08:12
amaury_din the manual, its specified that _remove does not work for flag syntax08:12
amaury_dLetoThe2nd: I understand that this is a tricky problem :)08:12
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC08:12
amaury_dif not possible, never mind I will rebuild image on every bitbake invocation08:13
LetoThe2ndits a totally valid question, i just don't have a good answer besides what i already wrote, sorry.08:13
TamisIn sumo branch if I include lib32-glibc in an image I get the following warning:08:14
TamisWARNING: The postinstall intercept hook 'update_gio_module_cache-lib32' failed, details in /home/tamis/build_occe/tmp/work/intel_corei7_64-intel-linux/core-image-occe/1.0-r0/temp/log.do_rootfs08:14
Tamisvalid ELF image for this architecture08:14
Tamisany ideas of how to fix that?08:15
amaury_dLetoThe2nd: no problem, thank you for your help :)08:16
*** JaMa <JaMa!> has joined #yocto08:19
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC08:25
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto08:25
amaury_dLetoThe2nd: I tried with a ROOTFS_POSTPROCESS_CMD, but I got "basehash value changed from ... The metadata is not deterministic and this needs to be fixed"08:30
amaury_dmaybe I should use nostamp on os-release recipe...08:31
*** leitao <leitao!~leitao@2620:10d:c092:200::1:2fb1> has quit IRC08:33
*** vineela <vineela!~vtummala@> has quit IRC08:33
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:34
*** leitao <leitao!~leitao@2620:10d:c092:200::1:2fb1> has joined #yocto08:35
wooosaiiiI have built extensible SDK... I install it and should run devtool but it doesn't... however I have found out that every tool in eSDK/sysroots/x86_64/usr/bin depends on finding libraries in $SDKPATH (is set to /opt/...)08:39
wooosaiiithus if I then install the normal toolchain to /opt/...08:39
wooosaiiitools start to work...08:39
wooosaiiibut for example devtool fails due to not being able to find argparse module...08:40
amaury_dLetoThe2nd: I have decided to use do_compile[nostamp] = "1" in os-release08:40
amaury_dit seems overkill but at least I'm sure the datetime of build is correct08:40
LetoThe2ndamaury_d: if it does the trick for you, all is well08:40
LetoThe2ndthanks for reporting back08:40
amaury_dthank you for your help08:40
wooosaiiishould I set SDKPATH variable or will this break eSDK?08:40
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto08:52
*** Bunio_FH <Bunio_FH!> has joined #yocto08:54
*** Bunio_FH <Bunio_FH!> has quit IRC08:56
*** LocutusOfBorg is now known as mdelaus08:59
*** mdelaus is now known as Locutusofborg08:59
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:16
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:16
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:26
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:31
RPkanavin: around? One of the RDEPENDS changes seems to be making the g-i tests fail due to missing pkgutil :/09:34
RPkanavin: actually I don't think its your patches and I can probably test a guess at the fix...09:41
*** bentech <bentech!~bentech@unaffiliated/bentech> has joined #yocto09:52
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:52
*** learningc <learningc!> has quit IRC10:14
*** learningc <learningc!> has joined #yocto10:15
*** Chrusel <Chrusel!c1669b04@> has quit IRC10:20
*** learningc <learningc!> has quit IRC10:32
*** goliath <goliath!> has quit IRC10:35
*** micka <micka!> has quit IRC10:35
*** micka <micka!> has joined #yocto10:38
*** kroon_ <kroon_!~kroon@> has joined #yocto10:38
*** kroon <kroon!~kroon@> has quit IRC10:38
kanavinRP: cheers, I am looking at mingw failure meanwhile. We might have to add another ugly-ish _mingw32_remove :(10:43
LetoThe2ndkanavin: "the mingw failure"10:44
kanavingcc-cross-canadian has this to say: # Having anything auto depending on gcc-cross-sdk is a really bad idea...10:44
kanavinEXCLUDE_FROM_SHLIBS = "1"10:44
kanavinwhich doesn't exactly explain why10:45
LetoThe2ndkanavin: sorry, failed to transmit the tongue-in-cheek feeling over IRC10:45
RPkanavin: that sounds like it wants its libs to be private11:20
RPkanavin: "gcc-cross-sdk" is also a very very old term11:20
RPkanavin: it may not even be an issue now as I suspect cross-canadian doesn't build the libs it used to duplicate?11:21
kanavinRP: I am not sure about that, I went the mingw_remove route in the latest iteration of the patch. But we can drop the EXCLUDE_FROM_SHLIBS and see what happens too.11:45
kanavinbasically this line was added by you years ago, and 'really bad idea' bit discouraged me :)11:45
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto11:51
RPkanavin: I figured it might have been me. I'm tempted to try removing it11:54
RPkanavin: back then we didn't have rss and so on so it was a different world11:54
RPkanavin: the key bit in the phrase is "depending on" - we want to mask out its provides, not its depends11:56
kanavinRP: right, but that requires explicit listing of libraries in PRIVATE_LIBS, which is probably prone to breakage on version upgrades12:05
kanavinI did this in a couple of places though for ptest packages (dbus and recently elfutils)12:05
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC12:08
RPkanavin: I think we should add something to the code which just disables generating shlibs provides12:08
RPkanavin: I actually thought we had such a thing already12:09
kanavinRP: I looked at that part in package.bbclass, and couldn't find it. It would certainly be beneficial!12:09
RPkanavin: I also looked and couldn't see it. It would be useful12:10
*** kaspter <kaspter!~Instantbi@> has quit IRC12:13
*** pung_ <pung_!~BobPungar@> has joined #yocto12:20
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC12:24
*** goliath <goliath!> has joined #yocto12:27
*** WillMiles <WillMiles!> has joined #yocto12:56
*** gtchub <gtchub!> has joined #yocto12:57
*** leitao <leitao!~leitao@2620:10d:c092:200::1:2fb1> has quit IRC13:00
*** leitao <leitao!~leitao@2620:10d:c092:200::1:a6e9> has joined #yocto13:02
*** JPEW__ <JPEW__!~JPEW@2605:a601:21d1:5200:620a:c230:ada8:3135> has joined #yocto13:13
*** JPEW_ <JPEW_!~JPEW@2605:a601:21d1:5200:620a:c230:ada8:3135> has joined #yocto13:15
RPkanavin: I'm also seeing an odd perl-native problem. Sometimes there is a recipe-sysroot-native/usr/lib/perl5/5.30.0/ and sometimes not13:16
RPkanavin: tmp/work/x86_64-linux/perl-native/5.30.0-r0/temp$ grep 0/ log.do_ins* shows only about half the install logs install it13:17
RPkanavin: looks to correlate with do_compile log size:/13:19
RPah, and the reason I see weird determinism problems is the same sstate hash and manifest has different files in it at different times13:25
JPEW_RP, kanavin: I think I've seen a similar perl issued when I was looking at reproducibility (it was for the target packages though)13:30
*** leitao <leitao!~leitao@2620:10d:c092:200::1:a6e9> has quit IRC13:30
*** contrast <contrast!c037362a@> has joined #yocto13:31
*** kroon_ is now known as kroon13:32
*** leitao <leitao!~leitao@2620:10d:c092:200::1:2fb1> has joined #yocto13:33
RPJPEW_: I was trying to figure out why sstate was breaking but its an underlying determinism problem and sstate assuming things with the same hash are really the same :/13:33
*** comptroller <comptroller!> has quit IRC13:33
*** alessioigor <alessioigor!~alessioig@> has quit IRC13:34
JPEW_RP: perl wasn't producing the same sstate output each time for the same taskhash?13:34
RPJPEW_: correct13:36
*** contrast <contrast!c037362a@> has left #yocto13:37
RPJPEW_: from local rebuilds of it13:37
*** contrast <contrast!c037362a@> has joined #yocto13:37
*** Ded_Zerom <Ded_Zerom!~Ded_Zerom@unaffiliated/deda-zych/x-1167266> has quit IRC13:38
JPEW_RP: Matches what I saw. That was one of the reasons I was thinking the reproducible build test might have to do 2 clean builds13:39
*** alessioigor <alessioigor!~alessioig@> has joined #yocto13:40
*** Ded_Zerom <Ded_Zerom!~Ded_Zerom@unaffiliated/deda-zych/x-1167266> has joined #yocto13:42
JPEW_RP: The hashequiv issue where do_populate_sysroot_setscene skips do_configure is ironic(?) because that is the example I was planning on using in devday presentation13:44
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC13:44
jofrI have a recipe that depends on ruby-native, and a particular gem. Since there is no meta-ruby anymore, how can I define my dependency?13:48
*** comptroller <comptroller!> has joined #yocto13:50
kanavinRP: I suspect the Storable issue might be in do_compile where that thing could be 'generated' (or not)13:51
kanavinjofr, you take over the maintenance of meta-ruby and place your gem in it:)13:52
kanavingenerally there has not been a lot of interest in ruby, the version in oe-core hasn't been updated in years13:52
jofrkanavin: Yay!13:52
contrastjofr: I see a ruby recipe in the openembedded layer index:
jofrcontrast: Yes. It has Ruby. But there used to be a "bundler" that could install gems13:53
jofrI just keep falling more and more in love with this home-grown build-system that we have here (written in Ruby).  *sigh*13:54
RPJPEW_: It can skip configure *if and only if* all the pieces come some sstate14:00
*** leitao <leitao!~leitao@2620:10d:c092:200::1:2fb1> has quit IRC14:03
*** berton <berton!~berton@> has joined #yocto14:03
JPEW_RP: Ya I was wonder if that was the bug.... it was removing do_configure to aggressively when it discovered do_populate_sysroot, but there were still some non-sstate tasks that need it to run?14:05
*** leitao <leitao!~leitao@2620:10d:c092:200::1:2fb1> has joined #yocto14:05
*** berton <berton!~berton@> has quit IRC14:08
*** kroon <kroon!~kroon@> has quit IRC14:08
RPJPEW_: I think so. Sadly I've been pulled into a uncontrolled funnel of other bugs :/14:08
*** vineela <vineela!~vtummala@> has joined #yocto14:17
*** diembed <diembed!> has joined #yocto14:20
*** bentech <bentech!~bentech@unaffiliated/bentech> has left #yocto14:23
*** bentech <bentech!~bentech@unaffiliated/bentech> has joined #yocto14:24
*** bentech <bentech!~bentech@unaffiliated/bentech> has left #yocto14:24
*** berton <berton!~berton@> has joined #yocto14:25
diembedHi all14:26
diembedIs there a way to deploy all locales (glibc-binary-localedata-*, glibc-charmap-*, glibc-gconv-*, glibc-localedata-*, locale-base-*), please ?14:26
diembedI already set GLIBC_GENERATE_LOCALES="en_GB.UTF-8 en_US.UTF-8 fr_FR.UTF-8 ru_RU.UTF-8 he_IL.UTF-8 sv_SE-UTF-8"; IMAGE_LINGUAS?="en-gb" but it still have to specify all combination for each packages)14:26
JPEW_Crofton|work: I'd really like to see your display of bugzilla bugs where each one is carefully pinned to a board and labeled with the scientific name14:28
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC14:47
*** TobSnyder <TobSnyder!> has quit IRC14:50
*** AndersD <AndersD!~AndersD@> has joined #yocto14:55
*** vineela <vineela!~vtummala@> has quit IRC14:56
nabokovglib-2.0 build for target is broken on master (poky and openembedded) for me... do you have the same issue there ?14:58
kanavinnabokov, nope. Do you have extra layers enabled?15:02
*** goliath <goliath!> has quit IRC15:05
yoctiNew news from stackoverflow: Enable root password verification while login with serial console in Yocto <> || Replace mosquitto.conf file with bbappend? <>15:05
*** AndersD <AndersD!~AndersD@> has quit IRC15:07
*** pung_ <pung_!~BobPungar@> has quit IRC15:20
*** learningc <learningc!~learningc@> has joined #yocto15:20
*** litb <litb!> has joined #yocto15:23
litbhello folks15:23
litbIf I build from an external source using externalsrc, and start building the package, press C-cc (interrupt twice). Then change sources, and build again. Does it continue the build where it stopped (i.e if the pacakge's 'do_compile' doesn't do anything special like cleaning). or will yocto clear the build folder with every build?15:25
kergothit'll continue. do_compile doesn't wipe the build dir. if it did, builds would break, as do_configure touches the build dir too15:25
*** elGamal <elGamal!~elg@> has quit IRC15:33
*** goliath <goliath!> has joined #yocto15:40
*** elGamal <elGamal!~elg@> has joined #yocto15:42
*** learningc <learningc!~learningc@> has quit IRC15:42
*** tgamblin__ is now known as tgamblin15:43
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC15:53
*** diembed <diembed!> has quit IRC15:59
nabokov@ kanavin yes I do (meta-raspberrypi) but they do not override anything in build system or glib-2.016:16
nabokov@kanavin  "do_configure" fails indeed16:17 ERROR: Unknown compiler(s)16:18
*** kukela_cd <kukela_cd!> has joined #yocto16:19
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC16:23
*** marler8997 <marler8997!> has joined #yocto16:25
marler8997So I want to make sure I understand the difference between "native", "nativesdk" and "cross"16:31
marler8997For "native", it just means that if someone DEPENDS on you (i.e. DEPENDS += "foo-native") means you're going to be available somewhere when that recipe is being built, but doesn't mean you're going to be installed into the SDK right?16:32
dl9pfwarrior 2.7.1: tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/curses/", line 13, in <module>16:33
dl9pf    from _curses import *16:33
dl9pfModuleNotFoundError: No module named '_curses'16:33
dl9pf^^^ does this ring a bell ? anyone ?16:33
marler8997If a recipe DEPENDS on a native package...does that mean the "foo-native-dev" package will be installed to the SDK or no?16:34
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC16:34
dl9pfdo_rootfs can't exec dnf due to _curses not being found16:34
Tamisat sumo branch: qemu.bbclass at the end returns qemu-" + target_arch which is x86_64 for 64 multilib image.  But what it you want to add in that image lib32-glibc qemu-i383 needs to run.16:35
TamisHow you can do that?16:35
Tamisqemu-i386* in order to execute the lib32-executable16:35
*** Tamis <Tamis!504e056f@> has quit IRC16:44
*** nrossi <nrossi!nrossimatr@gateway/shell/> has quit IRC16:45
*** wak-work <wak-work!wak-workma@gateway/shell/> has quit IRC16:45
*** kayterina <kayterina!kayterina-@gateway/shell/> has quit IRC16:45
*** bachp <bachp!bachpmatri@gateway/shell/> has quit IRC16:45
*** JPEW_ <JPEW_!~JPEW@2605:a601:21d1:5200:620a:c230:ada8:3135> has quit IRC16:46
kergothmarler8997: native == built *on* this machine, *for* this machine, completely independent of the target machine/board. cross == built *on* this machine, *for* the target, it's bound to both the host and the target, and is how we build our cross-compiler. nativesdk == built *on* this machine, *for* the SDKMACHINE, targeting the SDKMACHINE. that is, it builds binaries for the sdk which run on the machine that installs the sdk, and are independnet of the16:47
kergoth target. build tools, in other words. nativesdk == a packaged version of native, but meant to run on the sdkmachine, not the current machine (you can build an sdk intended for 64-bit hosts even if you're builidng it on a 32-bit host)16:47
*** mrpelotazo <mrpelotazo!> has quit IRC16:48
*** la_croix <la_croix!> has quit IRC16:48
marler8997ok that helps16:49
marler8997so for a cross-compiler recipe meant to be used as an EXTERNAL_TOOLCHAIN to build everything in yocto, I definitely want cross16:51
*** la_croix <la_croix!> has joined #yocto16:51
marler8997and if I needed a compiler in the sdk, I would want crosssdk16:51
*** mrpelotazo <mrpelotazo!> has joined #yocto16:51
kergothactually do16:52
kergothcrosssdk, despite the misleading name, is the toolchain that *targets* sdkmachine16:52
kergothif you're building a 64-bit sdk on a 32-bit x86 host, crosssdk is what builds the nativesdk packages for 64-bit x8616:53
kergothi.e. crosssdk == cross but targeting sdkmachine, not machine16:53
*** bachp <bachp!bachpmatri@gateway/shell/> has joined #yocto16:53
kergothit's *cross-canadian* that uses crosssdk to build a toolchain that runs on sdkmachine but targeting machine16:53
kergothfirst it builds crosssdk toolchain, then it uses that to build the nativesdk and cross-canadian packages16:54
kergothcross-canadian should really get renamed, it sounds like it'd be used to build a cross-canadian toolchain to run on the target, but it's actually specific to the sdk, dspite not having sdk in its name16:54
marler8997one more question...I get confused about install locations for each type of recipe and which install function to override16:55
kergothcross canadian is a generic term. from wikipedia: "The Canadian Cross is a technique for building cross compilers for other machines. Given three machines A, B, and C, one uses machine A (e.g. running Windows XP on an IA-32 processor) to build a cross compiler that runs on machine B (e.g. running Mac OS X on an x86-64 processor) to create executables for machine C (e.g. running Android on an ARM processor)."16:55
marler8997For my cross compiler, do I override do_install_cross then?  And install it to ${D}...and does it just not do the packaging steps or what?16:55
kergothyou don't need to do anything special16:55
kergothjust install to ${D} in do_install and the bbclasses will do the rest for you16:56
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC16:59
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto17:02
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC17:07
*** leitao <leitao!~leitao@2620:10d:c092:200::1:2fb1> has quit IRC17:08
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:10
*** nrossi <nrossi!nrossimatr@gateway/shell/> has joined #yocto17:10
*** learningc <learningc!~learningc@> has joined #yocto17:10
*** kayterina <kayterina!kayterina-@gateway/shell/> has joined #yocto17:22
*** tprrt <tprrt!> has quit IRC17:23
kayterinaI get the "Nothing PROVIDES..." error for my recipe  "/mylayer/recipes-core/systemd_service/". "mylayer" is added to bbconf. I am missing something obvious,which is...?17:26
*** learningc <learningc!~learningc@> has quit IRC17:30
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC17:32
*** jacques <jacques!~jacques@nslu2-linux/jacques> has joined #yocto17:34
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:35
*** goliath <goliath!> has quit IRC17:37
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto17:40
*** jacques <jacques!~jacques@nslu2-linux/jacques> has quit IRC17:41
kukela_cdHello I have a question about opkg package signatures. I have enabled opkg package signature, and asc files are generated. When i try to run opkg update though, it fails because i do not have a package.sig file. How do i generate a package.sig file?17:44
*** vineela <vineela!~vtummala@> has joined #yocto17:53
*** jacques2 <jacques2!~jacques@nslu2-linux/jacques> has joined #yocto17:55
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC17:56
*** tgamblin <tgamblin!~tgamblin@> has quit IRC18:04
*** goliath <goliath!> has joined #yocto18:09
*** litb <litb!> has quit IRC18:29
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto18:31
*** jacques2 <jacques2!~jacques@nslu2-linux/jacques> has quit IRC18:33
*** contrast <contrast!c037362a@> has quit IRC18:49
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto18:59
*** marler8997 <marler8997!> has quit IRC19:02
*** kroon <kroon!> has joined #yocto19:09
*** vineela <vineela!~vtummala@> has quit IRC19:24
*** kroon <kroon!> has quit IRC19:24
*** vineela <vineela!~vtummala@> has joined #yocto19:46
*** kukela_cd <kukela_cd!> has quit IRC20:00
*** khem <khem!~khem@unaffiliated/khem> has quit IRC20:12
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto20:17
*** learningc <learningc!~learningc@> has joined #yocto20:25
*** learningc <learningc!~learningc@> has quit IRC20:29
*** tijko <tijko!~tijko@unaffiliated/tijko> has quit IRC20:47
*** berton <berton!~berton@> has quit IRC21:15
*** WillMiles <WillMiles!> has quit IRC21:20
stefandxmis there a recipe for yocto with systemd?21:21
khemstefandxm:its a distro option21:22
stefandxmoh ok21:22
stefandxmiam really new to yocto21:22
stefandxmie, i dont know a shit21:22
stefandxmbut its possible?21:23
stefandxmill read up thank you :)21:23
stefandxmive been kicked in to yocto21:24
stefandxmi didnt really want to21:24
stefandxmtbh i want some 'standard' arm distro based solution21:25
khemif you are new then start with getting started kind of docs
stefandxmi did21:25
stefandxmbut i got lost21:25
stefandxmis it ok if i ask you why i should use yocto isntead of debian arm?21:25
khemmay be start with Yocto Project Quick Build21:25
stefandxmyeah ill play with both. iam just a bit at lost why i am doing yocto in the first place21:26
stefandxmbasically using a device with a yocto "sdk" ?21:27
stefandxmand i dont really want it. i just want to crosscompile to it and run a systemd environment or similar21:27
khemits a cross build environment so that will help I guess with your cross-compile needs21:28
stefandxmyeah i figured that much21:28
stefandxmand i managed to cross compile and put the binaries and run them on the host itself21:29
stefandxmso i have a rough idea whats happening after yocto21:29
stefandxmjust not sure why i need yocto instead of a standard linux distro for arm basically21:29
kergothyocto eases maintenance of your own distro, makes it easier to customize how things are built, use non-standard libcs, things not supported by debian, integrate your own software projects, build custom filesystem images, etc21:30
kergothat the cost of a steeper learning curve21:30
kergothreally depends on your needs21:30
stefandxmi think you nailed it :)21:30
khemkergoth: not non-standard but alternate :)21:31
stefandxmwe are targetting a bit higher level i think yocto should not be needed for our stuff but ill look into it anyhow :)21:31
stefandxmjust so you understand: iam not against yocto at all. just was hoping for a higher level of this boards distro21:31
khemstefandxm:if you are doing apps, then Yocto SDKs will help21:31
kergothkhem: indeed, well put21:31
stefandxmthe sdk seem to have the bit and pieces21:32
stefandxmi just need to learn how to pull out the libs and build it all without the eclipse crap that my board supplier want me to use21:32
kergothstefandxm: of course. not every project works for every set of requirements. there are a lot of tools available, some are better for some things and worse for others. there are things that just aren't possible with a desktop distro, but simple stuff can be done with either21:32
khemstefandxm: you can get anything you want into SDK as kergoth said its customizable21:33
stefandxmmy problem is i come from the "other side"21:33
stefandxmtrying to use a boards yocto stuff21:33
stefandxmie mangoh red stuff21:33
khemstefandxm:I know its easier to do native development21:33
stefandxmtheyve built this legato stuff on top21:33
stefandxmi just want pure c++21:33
stefandxmbut iam happy to learn21:34
khemthat attitude will take you long way21:34
kergothkhem: semi-OT, but is pretty interesting. with an image builder to convert a docker image to a wic image or something, you could construct semi-customized embedded disk images using a dockerfile instead of an image recipe, based on any number of container distros. i didn't realize you could do that with qemu+multiarch21:35
stefandxmbut for me yocto seems a bit too proprietary niched for what i want but.. ill try :)21:35
stefandxmi got this mangoh red card and it has a base set of yocto etc. ill have to abuse it to see if it works :)21:35
stefandxmits worth a go21:35
stefandxmso is yocto primarly focusing a bit lower/niched hardware that cannot run say debian?21:36
khemstefandxm: you can build images for anything infact, it does not limit itself to any hardwaree21:36
stefandxmyeah i read about that21:37
stefandxmits really cool21:37
kergothnot really. it's more about the level of customization, the ability to cross-build, and the ability to rebuild everything from source, which usually isn't an option with a desktop distro unless you're running gentoo :)21:37
khemkergoth:interesting I will read more on it21:37
stefandxmjust trying to sort the yocto vs build an arm board suitable for debian21:37
khemstefandxm: you can use something like rpi4 for native arm development21:38
khemunless buildtimes start eating into your days21:38
stefandxmas i said iam targetting a rather big board anyhow so i was thinking more along the raspery design21:38
stefandxmwell  i can patch specific software/libs anyhow21:38
stefandxmbut ill dig it through21:39
stefandxmbut iam very glad for the comments. it makes it easier to understand the docs :)21:40
stefandxmthis is not really my domain =)21:40
stefandxmiam more of a server-side c++ guy21:40
khemkergoth:qemu usermode is quite interesting21:40
khemstefandxm: yeah I think with yocto you will become a full stack guy21:41
khemand also devops21:41
stefandxmlol i dont need more stacks ;)21:41
stefandxmbut i figured i could help port some c++ code of mine to a yocto -using device :)21:42
khemwith yocto you can build a lean and mean image for your platform, then you can generate an image SDK which you can use to build apps21:42
khemyou will get power of x86 build systems to do the builds21:42
stefandxmi'd rather compile the "apps" myself as usually with a cross compiler21:43
stefandxmyeah, ive done this all the time in the past21:43
stefandxmehrm "past"21:43
khemyeah sure, thats where the SDK is going to help you21:43
stefandxmyeah it gives me an abi-compatible compiler right?21:43
*** dv_ <dv_!~dv@> has quit IRC21:43
khemsince the SDK will represent the dev and tuntime env of your target in cross env21:43
khemand any dependencies your app has on other opensource you can add to SDK21:44
khemso your app is not bundling stuff21:44
stefandxmwell it might anyhow but we will see :)21:44
stefandxmi dont like the idea of "apps"21:45
stefandxmiam a unix guy hehe21:45
stefandxmbut it should all be the same21:46
khemkergoth: its all using qemu-user-static thats what I thought see
*** JaMa <JaMa!> has quit IRC21:58
* kergoth nods21:58
khemmy problem is someone has to be able to build those docker images21:59
khemits not a solution when you ship products that you want to support and maintain for years21:59
kergothaye, there's always the issue of bootstrapping21:59
khembut for development its not a bad thing at all21:59
khemso maybe we need a combinations of both approaches ie. OE which maybe used used build docker images and a dev env which could then use these docker images22:01
kergothi was mulling over the idea of using dockerfiles to customize yocto images (after building the baselines with the current mechanisms) and then burn them with wic after yanking out the needed bootloader bits from it, as a development tool. folks are already familiar with dockerfile in container environments.22:01
kergothyeah. not sure how much value it'd add, just a way to leverage existing expertise in some fashion22:01
*** dv_ <dv_!~dv@> has joined #yocto22:01
kergothbut it's *fast* since it has the image layering and caching of the binary artifacts22:01
khemmost of devs do native development22:01
khemso it will help them to write stuff for embedded systems easily22:02
kergothvery true. scratchbox leveraged binfmt like this iirc. it'd be interesting to improve our native development story before the dev moves onto recipe creation and deployment for the longer term22:02
khemyeah  recipe creation then should be like writing a spec file or debian rules file22:04
khemkergoth:creating dockerfiles for such devenv seems interesting, but wont you need apt-get blah :)22:06
khemgto customize the images22:06
kergothtrue. and it'd be binary based, so you'd ideally have a feed like angstrom for that workflow22:08
khemyeah I think we are at a disadvanrage to not have a strong binary feed based distro except angstrom22:16
*** wak-work <wak-work!wak-workma@gateway/shell/> has joined #yocto22:18
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC22:43
*** vmeson <vmeson!> has quit IRC22:43
*** marka <marka!~marka@> has quit IRC22:43
*** goliath <goliath!> has quit IRC22:55
*** vineela <vineela!~vtummala@> has quit IRC23:35

Generated by 2.11.0 by Marius Gedminas - find it at!