Friday, 2019-11-29

bluelightningtlwoerner: presumably that path is being encoded into a file that gets installed by PackageA, and PackageB's configure step picks it up00:03
tlwoernerbluelightning: let me check...00:04
*** agust <agust!> has quit IRC00:06
tlwoernerbluelightning: yes! found it00:08
tlwoernerthis doesn't *appear* to be a mistake in the recipe, but rather something that's part of cmake (or maybe how we're using cmake?)00:10
*** behanw <behanw!uid110099@gateway/web/> has quit IRC00:30
*** tgamblin <tgamblin!> has quit IRC00:56
*** DvorkinDmitry <DvorkinDmitry!> has joined #yocto01:26
*** nrossi <nrossi!uid193926@gateway/web/> has joined #yocto04:20
*** kaspter <kaspter!~Instantbi@> has quit IRC04:42
*** kaspter <kaspter!~Instantbi@> has joined #yocto04:43
yoctiNew news from stackoverflow: Bitbake Server does not start on Windows Subsystem for Linux <>04:44
*** kaspter <kaspter!~Instantbi@> has quit IRC04:45
*** kaspter <kaspter!~Instantbi@> has joined #yocto04:46
*** hyper_dave <hyper_dave!~quassel@> has quit IRC05:28
*** kaspter <kaspter!~Instantbi@> has quit IRC05:38
*** kaspter <kaspter!~Instantbi@> has joined #yocto05:39
*** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has quit IRC05:53
DvorkinDmitryb'/disk2/build.23/tmp/work/x86_64-nativesdk-tpssdk-linux/nativesdk-cmake/3.14.1-r0/package/opt/tps/2.7-20191129/sysroots/x86_64-tpssdk-linux/usr/bin/cpack: RPATH=/disk2/build.23/tmp/work/x86_64-nativesdk-tpssdk-linux/nativesdk-cmake/3.14.1-r0/recipe-sysroot-native/usr/lib\n'b"new rpath '$ORIGIN/../../../../../../../disk2/build.23/tmp/work/x86_64-nativesdk-tpssdk-linux/nativesdk-cmake/3.14.1-r0/rec05:58
*** camus <camus!~Instantbi@> has joined #yocto05:58
*** kaspter <kaspter!~Instantbi@> has quit IRC06:01
*** camus is now known as kaspter06:01
*** ThomasD13 <ThomasD13!> has joined #yocto06:10
*** AndersD <AndersD!> has joined #yocto06:36
*** pohly <pohly!> has joined #yocto06:58
*** agust <agust!> has joined #yocto07:05
*** guerinoni <guerinoni!> has joined #yocto07:10
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:38
*** mckoan|away is now known as mckoan08:14
*** diego_r <diego_r!> has joined #yocto08:18
*** yann|work <yann|work!> has quit IRC08:29
wertigonAllright, so after a lot of cursing, sweat and tears, I finally narrowed down why my mingw sdk refuse to compile08:34
wertigonIt is due to the layers meta-browser and it in turn inherits meta-clan08:35
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:35
wertigonNow, I do not need these layers at all for the SDK; so I wish to have them excluded from the SDK build chain and only the SDK build chain08:37
wertigonCan this be done?08:37
wertigone.g. when I type bitbake my-image -c populate_sdk it should ignore those two layers completely08:41
LetoThe2ndnope, i don't think so08:41
LetoThe2ndthis contradicts pretty much the whole layer model08:41
LetoThe2ndi mean, do the layers break the build by their pure inclusion in bblayers.conf? without any recipes being pulled in, no configuration being selected and all?08:42
wertigonWell, the meta-browser layer is supposed to be only an extra application, we don't need any libraries from it, and same with meta-clang08:43
RPwertigon: You could try setting TOOLCHAIN = "gcc" in the problematic recipes?08:43
LetoThe2ndbecause if a layer break the build just by its pure inclusion, then it is buggy.08:43
LetoThe2ndbut if you actively select something from the layer and it breaks, well, then fix the recipe08:44
RPwertigon: shows the kind of thing I mean, its necessary for some bits of the system08:44
wertigonLetoThe2nd: Yes, from what I can understand; if I remove meta-browser dependencies from meta-arago-extras, but include it in bblayers.conf, it still builds08:44
*** TobSnyder <TobSnyder!> has joined #yocto08:45
LetoThe2ndwertigon: then the layer is probably wellbehaved and the recipes need fixing.08:45
wertigonRP: Ah, that might help; do I put that recipy in my own layer then? :)08:45
LetoThe2ndRP: can i try again and pester you for some multiconfig things?08:45
wertigonI'll try it after my coffee break starting now ^^08:46
RPLetoThe2nd: it sounds like I missed something previous but yes, you can ask08:46
LetoThe2ndbasically this:1) build an image that depends on another mc-image. 2) change something in a recipe that affects the mc-image, to something that is already in sstate cache 3) bitbake image. effect is: the mc-image gets rebuilt, but not image. then rerun bibtake image: mc-image doesn't get rebuit, image does08:46
RPwertigon: you can set it in certain recipes directly to force a particular toolchain or set it with the pn-XXX override in local.conf08:46
LetoThe2ndRP: like, struggling with dependency propagation when sstate is involved.08:47
RPLetoThe2nd: that sounds wrong :/ Is a nostamp involved on any of the images?08:48
*** camus <camus!~Instantbi@> has joined #yocto08:48
*** kaspter <kaspter!~Instantbi@> has quit IRC08:48
*** camus is now known as kaspter08:48
LetoThe2ndRP: no. setting a nostamp on the fetch of the recipe that pulls in the image from the mc dependency solves them problem practically, but it feels like a sledge hammer08:49
RPLetoThe2nd: right, it is and you shouldn't have to do that08:50
RPLetoThe2nd: could be a bug :(08:51
LetoThe2ndRP: FWIW it only shows the behaviour if a recipe is modified so diffsigs triggers, but the new state of the recipe is something that already was built earlier and therefore can be pulled from sstate08:51
RPLetoThe2nd: its good to have it isolated to a specific case like that08:52
RPLetoThe2nd: probably a case of filing a bug and waiting/hoping someone has a chance to debug it08:52
LetoThe2ndRP: want me to file?08:52
RPLetoThe2nd: please08:52
LetoThe2ndRP: ok08:53
RPLetoThe2nd: an automated test reproducing the problem would probably help too08:53
RPsounds like it could be something quite simple to reproduce, maybe even two recipes rather than full images08:53
RPLetoThe2nd: basically the easier it is to reproduce, the faster someone will probably look at it08:54
LetoThe2ndRP: one additional minor question. referring to something from a speicifc multiconfig is clear, with the :multiconfig: syntax. but how to refer to something from the standard config, e.g. local.conf?08:54
LetoThe2ndRP: we'll see if we can provide a test case.08:55
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:55
RPLetoThe2nd: normal is a multiconfig of ''08:56
LetoThe2ndRP: so ::, basically?08:57
RPLetoThe2nd: I think so08:57
LetoThe2ndRP: thanks!08:57
LetoThe2ndRP: ok, $coworker who actually works on this (i'm just the guys supposed to be good with people here) agrees to provide a bugreport some time soon.09:01
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto09:06
*** fitzsim <fitzsim!> has quit IRC09:06
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9a0f> has joined #yocto09:10
*** rburton <rburton!> has joined #yocto09:11
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:18
RPLetoThe2nd: ok, thanks09:20
LetoThe2ndme being stupid. whats the trick if a source tarball unpacks to a non-canonical path?09:21
LetoThe2ndi think there was soomething to set the extraction directory? or just do S=...?09:22
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC09:22
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:23
*** farnerup <farnerup!> has joined #yocto09:30
*** yann|work <yann|work!~yann@> has joined #yocto09:32
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9a0f> has quit IRC09:54
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9a0f> has joined #yocto09:55
*** Bunio_FH <Bunio_FH!> has joined #yocto09:57
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9a0f> has joined #yocto09:57
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC09:59
*** goliath <goliath!> has joined #yocto10:12
mcfriskhmm, a nativesdk recipe must set variables with FOO_class-nativesdk to override defaults from a bbclass. Plain FOO = "bar" will not work even if the bbclass sets defaults with FOO ??= "zoo"10:19
rburtonproper example?10:22
LetoThe2ndRP: concerning the python2 thing from yesterday, rebuilding the container did the trick. no idea what went wrong there.10:24
mcfriskthe bbclass also sets defaults for FOO_class-nativesdk ??= "". Seems like that overrides the FOO = "bar" from recipe, but FOO_class-nativesdk = "bar" again overrides the FOO_class-nativesdk ??= ""10:24
mcfriskso that works. I wonder how many bugs I have because of this...10:25
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9a0f> has quit IRC10:25
*** leitao <leitao!~leitao@2620:10d:c092:200::1:c2b> has joined #yocto10:27
RPmcfrisk: think "right to left" with variables. ??= sets the thing with that value (which includes the overide). Override expansion happens later10:28
RPFOO_x ??= "y" sets a default value of "y", FOO_x = "z" changes its value to z. Overrides only come later10:29
mcfriskRP: thanks. Not sure if I should use ?= or ??= in the bbclass though.10:29
RPmcfrisk: it depends on the behaviour you want I guess10:35
rburtonWARNING: core-image-minimal-1.0-r0 do_rootfs: Manifest /home/pokybuild/yocto-worker/oe-selftest/build/build-st-14235/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-mdadm.package_write_rpm not found in qemux86_64 core2-64 x86_64 allarch x86_64_x86_64-nativesdk (variant '')?10:46
rburtonERROR: core-image-minimal-1.0-r0 do_rootfs: No manifest generated from: mdadm in /home/pokybuild/yocto-worker/oe-selftest/build/meta/recipes-extended/mdadm/mdadm_4.1.bb10:46
rburtonRP: ^^ is that one of the known problems?10:46
rburtonor something fun and exciting in my next branch10:46
RPrburton: not seen it before10:47
rburtondropped the gcc patch from my next10:50
rburtonhm devtool selftest does a mdadm cleansstate10:52
rburtoncould that be breaking the other tests?10:52
RPrburton: is that one where it sets its own sstate directory?10:53
RPrburton: there are some tests which do run clean* but they should have their own sstate dir10:54
rburtonah yes, okay, devtoolbase sets sstate_dir10:55
ThomasD13I've created a eSDK for my raspberrypi 4. Now I changed the kernel source and wanted to rebuild the image with "devtool build-image core-image-base". However, bitbake reports "skipping recipe linux-raspberrypi-rt as it doesn't produce a package with the same name"10:57
ThomasD13I don't know if that will affect me, or how to fix it ?10:58
*** anujm <anujm!anujm@nat/intel/x-qctufmovciodyzuu> has joined #yocto10:59
*** florian_kc is now known as florian11:02
LetoThe2ndis there a particular reason why runqemu always wants to get tun/tap up? what about a -nonet option?11:22
*** ThomasD13 <ThomasD13!> has quit IRC11:22
*** kaspter <kaspter!~Instantbi@> has quit IRC11:23
*** leitao <leitao!~leitao@2620:10d:c092:200::1:c2b> has quit IRC11:25
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9a0f> has joined #yocto11:34
*** berton <berton!~berton@> has joined #yocto11:43
*** berton <berton!~berton@> has quit IRC11:47
wertigon*le sigh*11:48
*** berton <berton!~berton@> has joined #yocto11:49
*** leitao <leitao!~leitao@2620:10d:c092:200::1:9a0f> has quit IRC11:58
*** jklare <jklare!~jklare@> has quit IRC11:58
*** jklare <jklare!~jklare@> has joined #yocto12:01
nrossiRP: are you sure that my gcc change was causing those reproducible errors? I was able to reproduce the errors, however both with and without the change. I did have to add tools-sdk to image features to get g++/etc. building though (which does not look like the default? on the AB)12:04
RPnrossi: I'm not 100% sure but I know the builds with that change in showed those reproducible test errors12:05
wertigonI might have been able to reproduce my troubles, building now to double check but:12:06
RPnrossi: I guess I could add just that change and run another test to 100% isolate it but it seemed fairly clear12:06
wertigonBasic problem - meta-browser and/or meta-clang breaks meta-toolchain12:06
wertigonSteps to reproduce: Download Poky, meta-browser, meta-clang, meta-mingw12:07
wertigonSorry, breaks meta-toolchain when trying to build on meta-mingw on Poky12:07
wertigonPoky-thud even12:08
nrossiRP: it does seem obvious why it might fail reproducible tests. The equivalent configargs.h might also be needed for non-cross (since "--with-build-sysroot" is embedded in the binaries), however it should be failing now regardless of my gcc change :|12:12
wertigonChange all branches to thud, add layers to bblayers.conf, specify the SDKMACHINE12:17
wertigonCompile, everything explodes in a fire12:17
RPnrossi: you can see why I was holding off blaming the patch, I don't quite understand it.12:22
RPnrossi: I guess we should fire a build with just this change in12:23
RP(compared to master)12:23
nrossiRP: probably a good idea, out of query do you know where/how tools-sdk or gcc/g++/etc. is added to core-image-minimal in yocto-autobuilder-helper?12:24
*** leitao <leitao!~leitao@2620:10d:c092:380::1:5d6c> has joined #yocto12:25
RPnrossi: I don't :/12:28
*** leitao <leitao!~leitao@2620:10d:c092:380::1:5d6c> has quit IRC12:30
RPnrossi: I've fired a couple of test builds with just that in12:30
nrossiRP: thanks, i will keep an eye on it. Will see if i can figure out why my local master build fails12:34
wertigonAnother strange inconsistency12:35
wertigonI get mingw gcc version 7.312:36
wertigonbut linux gcc version 8.212:36
wertigonfor sdk12:36
LetoThe2ndtrying to use yarn in a recipe do_compile, it gets annoyed over Error: EACCES: permission denied, open '/usr/local/share/.yarnrc'12:42
LetoThe2ndanybody run into this already?12:42
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto12:50
*** JaMa <JaMa!~martin@> has joined #yocto12:52
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:56
*** anujm <anujm!anujm@nat/intel/x-qctufmovciodyzuu> has quit IRC12:58
wertigonWhy isn't meta-mingw gcc same as linux-native gcc?13:22
*** yann|work is now known as yann13:24
mcfriskwould CFLAGS_append_x86_64 work for appending some optimizations for x86_64 targets only? is the variable TUNE_ARCH or some other thing?13:27
yannhow is it possible that a wic image tries to include my squashfs rootfs without building it first (in sumo) ?  The squashfs does get built as soon as I remove "wic" from IMAGE_FSTYPES, so it looks like some task dependency is missing ?13:36
wertigonOk, confirmed; meta-browser breaks meta-mingw on standard Yocto in the same way it breaks on meta-arago.13:56
wertigon(thud branch)13:56
rburtonand this is why we have the yocto project compatible scripts13:57
rburtonto detect layers that make changes without being asked13:57
wertigonrburton: Or might be mingw that breaks browser, but end result is the same :P13:57
rburtonwertigon: how does it explode?13:58
rburtonwertigon: meta-mingw does export RC, which might be upsetting the browser13:58
wertigonrburton: try the following layers: meta, meta-poky, meta-yocto-bsp, meta-openembedded/meta-oe, meta-clang, leta-browser, meta-mingw13:59
rburtonor, you can pastebin the failure and i can look at it14:00
wertigonPut all layers to thud except for meta-browser14:00
wertigonBuilding the failure right now14:00
wertigonBut I'll pastebin in about 5-10 min :)14:00
wertigon(meta-browser has no layers)14:00
wertigonAnd change SDKMACHINE14:01
wertigonAnd it'll explode in glorious flames14:01
wertigonIf you do bitbake meta-toolchain or populate_sdk14:01
*** rcrudo <rcrudo!> has quit IRC14:05
*** rcrudo <rcrudo!> has joined #yocto14:06
RPnrossi: figured it out. coreutils-ptest adds libmodule-build-perl which has a ptest RDEPENDing on gcc14:12
RPnrossi: so the coreutils change made it appear in the test14:12
RPtgamblin: ^^^14:12
tgamblinah, interesting14:12
tgamblinI'll check to see how that affects the ptest. I think it adds a failure without it but I'll have to confirm again14:13
RPtgamblin: its not that much of an issue but just an interesting part of the tangled web the ptests are causing14:14
tgamblinRP: things to remember when I eventually add more14:18
tgamblinAt some point I'd like to add one for libgcrypt14:18
RPtgamblin: I'm definitely keen to see more of them14:26
*** TobSnyder <TobSnyder!> has quit IRC14:31
*** AndersD <AndersD!> has quit IRC14:38
wertigonrburton: Sorry for it taking so long, clang-native takes a lot of time to compile, at 87% clang-native and 2109 tasks of 228714:40
wertigondoing a -k bitbake in order to catch most errors14:40
*** jij <jij!jonashg@nat/axis/x-bkhfwgluthwgyeqi> has quit IRC14:44
wertigonrburton: Here ya go!
GeneralStupidhi iam stucking at my custom Uboot config...14:55
GeneralStupidI want to have the boot config / environment in a different partition (and redundant but afair this is possible with altbootcmd)14:56
GeneralStupidBut for me it looks likt its hard compiled into include/configs/boardname.h  And NXP uses a lot of "custom" enviroment...14:56
wertigonWe have a separate boot partition that contains Linux kernel image, a squashed rootfs and boot parameters15:09
wertigonI don't think you can have kernel config and image separate, could be wrong15:09
wertigonWould otherwise suggest an overlayfs15:09
wertigonWe as in, my company, not yocto project as such. :P15:10
wertigon<-- Just another yocto "user" with noobish skills still15:10
wertigonAnyhow; boot configs cannot be put in a separate partition, but you can overlay and merge a separate filesystem that replaces all files in the first file system with ones defined in the second one15:17
wertigone.g. if your overlay only has /etc/network/interfaces only that file will be replaced in the unified root filesystem15:17
*** lfa_ <lfa_!~lfa@> has quit IRC15:20
*** kpo <kpo!> has quit IRC15:20
GeneralStupidwertigon: not kernel config, iam taling about uboot config / environment stuff15:21
*** jij <jij!jonashg@nat/axis/x-mgbkucqkcclnrpjh> has joined #yocto15:33
nrossiRP: interesting, good to know that the build passed with just the gcc patch though. I will separately look into the configargs.h for target gcc since noticing it contains build-sysroot paths, will help to make target gcc one step closer to reproducible ;)15:35
wertigonrburton: Ok, I think I have a theory of why I am seeing strange things with mingw[thud]:15:40
wertigonmingw[thud] does not support clang15:40
wertigonthis is since clang makes gcc compiler version 8.215:41
wertigonWhich mingw[thud] does not support15:41
wertigonAm waiting for a build to finish so I can confirm, but I have a pretty strong suspicion I'm right here :P15:42
*** diego_r <diego_r!> has quit IRC15:51
*** jklare <jklare!~jklare@> has quit IRC15:55
*** jklare <jklare!~jklare@> has joined #yocto15:59
wertigonYes, this is confirmed now - gcc is 8.2 if I include clang, 7.3 if I do not16:10
wertigonGreat, have a good weekend y'all!16:10
millonihi folks, not really strictly a yocto question but since there's a lot of people who have a lot of knowledge about this kind of stuff16:15
milloniwhy would my recipe require libtool .la files?16:16
millonishouldnt the same info already be in pkg-info?16:17
millonii've upgraded to a newer yocto and now it removes .la files during install by default16:17
millonii understand there's REMOVE_LIBTOOL_LA16:18
millonibut im trying to understand why it needs those files at all16:24
*** guerinoni <guerinoni!> has quit IRC16:24
millonithe recipe that fails to build looks just like a regular autotools project16:24
milloniit's using     PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.16, dummy=yes,16:25
millonii thought that would take everything it needs from the .pc file for glib16:26
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC16:37
*** Bunio_FH <Bunio_FH!> has quit IRC16:42
*** tgamblin <tgamblin!~tgamblin@> has quit IRC16:45
rcrudoI am creating a recipe for this sw: The license is some sort of modified BSD. what value should I use for LICENSE var?16:50
*** guerinoni <guerinoni!> has joined #yocto16:52
kergoththis is neither the usual 3-clause nor the usual 4-clause bsd, but something customized, i such a case we generally advise setting it to the name of the project16:56
*** alessioigor <alessioigor!> has quit IRC16:59
*** farnerup <farnerup!> has quit IRC17:10
*** hpsy <hpsy!~hpsy@> has quit IRC17:10
*** yann <yann!~yann@> has quit IRC17:23
rburtonmilloni: yes, but if you're rebuilding and it found a .la file before and you're not using a clean build dir and and and.  just use the remove-la class and do a clean build. .la files are EVIL.17:27
milloniin this particular case, it seems that glib (glib itself, unrelated to yocto) stopped producing .la files17:28
rburtonyes, it moved to meson17:29
RPnrossi: sorry for the false alarm, its sometimes hard to track down what is coming from where17:29
rburtonwhich doesn't use libtool17:29
rburtonso no .la files17:29
milloniand good for them :)17:29
millonibut i've got a project here that insists on building from .la files17:29
rburtonbut if something indirectly depends on glib and uses libtool and you were not blasting them from space, it will try to find the files17:29
millonii.e im getting a ".la file not found" error17:29
rburtondoes it break from a clean build?17:29
milloniclean build of the offending recipe? yes17:30
rburtonmaybe its actually hitting the .la files directly?17:30
millonihow so?17:30
rburtonspecifying them directly in the makefiles17:30
rburtonis this a public project or something private17:30
milloniunfortunately proprietary code :/17:31
rburtonso 1) check the makefiles are using pkgconfig properly, ie the variables from that PKG_CHECK_MODULES call and not anyhere17:31
rburton2) check that you don't have any implicit dependencies on modules that depend on glib, so wouldn't have rebuilt, but now embed references to the files17:32
rburtonthis is one of many reasons why we blast away all .la files by default17:32
rburtonRP: ross/next went green if you want to grab it17:35
RPrburton: cool, thanks17:36
millonithe only thing returned by `git grep '\.la'` is17:37
*** mckoan is now known as mckoan|away17:37
millonilib_LTLIBRARIES = libredacted.la17:37
milloniwhere "redacted" is the thing im trying to build17:37
RPrburton: did you find a problem with the gcc change or not?17:37
rburtonRP: i removed it as you had a hunch17:38
rburtonwe can fire that at selftest on its own17:38
RPrburton: ok, we've proven that one wrong, just checking I hadn't missed anything17:38
rburtonmilloni: can you not just use the remove-la class and rebuild the world?17:38
rburtonthe problem is most likely (2), .la files are incredibly contagious17:38
milloniisn't remove-la on by default now? (zeus)17:38
millonifor autotools.bbclass17:39
milloniit started removing .la files since we upgraded17:39
rburtonassuming you're using the default distro conf yes17:39
millonithat started breaking things17:39
milloniwhich we got around by using REMOVE_LIBTOOL_LA = 017:40
millonibut this proprietary recipe is insisting on using .la files17:40
millonieven though i cant find any references to them in the codebase17:40
milloniother than what i pased above17:41
rburtonso if you don't set REMOVE_LIBTOOL_LA=0 then what error do you get?17:41
milloniit built after i removed lib_LTLIBRARIES = libredacted.la17:42
milloniwe have REMOVE_LIBTOOL_LA = 0 for glib-2.017:42
millonii've not tried without setting it but i assume it doesnt make a difference17:43
rburtonhonestly, just stop disabling it for glib and fix the real problem17:43
*** Chrusel <Chrusel!c1669b04@> has quit IRC17:43
millonisince glib-2.0 doesnt produce .la files at all ever since they moved to meson17:43
rburtonremoving lib_LTLIBRARIES will mean it doesn't build libredacted.la17:43
rburtonwhich means it won't build the library at all17:43
milloni<rburton> honestly, just stop disabling it for glib and fix the real problem17:44
millonithat's what im trying to do now17:44
rburtonbefore i go, my recommendation is to undo anything you changed re libtool and do a build with a clean tmp17:44
milloniokay, i'll try that, thanks17:44
*** goliath <goliath!> has quit IRC17:48
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:54
*** wertigon <wertigon!8addfa13@> has quit IRC17:56
*** lucaceresoli <lucaceresoli!> has quit IRC18:00
*** yann <yann!> has joined #yocto18:27
*** hpsy <hpsy!~hpsy@> has joined #yocto18:29
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC18:38
*** goliath <goliath!> has joined #yocto18:48
*** Domin1k <Domin1k!c1669b04@> has quit IRC18:54
*** tgamblin <tgamblin!> has joined #yocto19:32
*** roussinm <roussinm!> has joined #yocto20:44
*** pohly <pohly!> has quit IRC20:51
*** mischief <mischief!~mischief@> has quit IRC20:51
*** guerinoni <guerinoni!> has quit IRC21:02
*** nrossi <nrossi!uid193926@gateway/web/> has quit IRC21:04
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto21:13
*** berton <berton!~berton@> has quit IRC21:13
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto21:16
*** sagner <sagner!~ags@> has quit IRC21:35
*** lexano <lexano!> has quit IRC21:47
*** falstaff <falstaff!~quassel@> has quit IRC22:01
*** falstaff <falstaff!~quassel@> has joined #yocto22:03
*** dv_ <dv_!> has quit IRC22:07
*** lexano <lexano!lexano@gateway/vpn/nordvpn/lexano> has joined #yocto22:09
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has quit IRC22:09
*** falstaff <falstaff!~quassel@> has quit IRC22:16
*** dv_ <dv_!> has joined #yocto22:20
*** tgamblin <tgamblin!> has quit IRC22:25
*** roussinm <roussinm!> has quit IRC22:38
*** lexano <lexano!lexano@gateway/vpn/nordvpn/lexano> has quit IRC22:50
*** anujm <anujm!~anujm@> has joined #yocto22:54
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC23:15
*** agust <agust!> has quit IRC23:15
*** lexano <lexano!lexano@gateway/vpn/nordvpn/lexano> has joined #yocto23:25
*** goliath <goliath!> has quit IRC23:30
*** champagneg <champagneg!> has quit IRC23:44
*** anujm <anujm!~anujm@> has quit IRC23:46
*** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has quit IRC23:46

Generated by 2.11.0 by Marius Gedminas - find it at!