Friday, 2019-09-06

*** rburton <rburton!> has quit IRC00:02
*** rburton <rburton!> has joined #yocto00:02
*** stephano <stephano!~stephano@2620:10d:c090:380::1:132d> has quit IRC00:33
*** goliath <goliath!> has quit IRC00:42
khemhalstead: pwclient is failing today to talk to patchwork ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:727)00:46
halsteadkhem, is the pwclient on your machine?00:47
halsteadkhem, The SSL cert is having issues. I'll hop right on it.00:47
halsteadkhem, The cert was already current but the webserver had the expired cert in memory. I'll make sure this doesn't happen again.00:51
khemyes pwclient is on my machine00:52
halsteadkhem, Should be repaired now.00:53
khemhalstead:ah working again thanks for resolving it00:53
halsteadThank you for reporting khem.00:53
khemrburton:.drone.yml is there on meta-clang00:53
*** jofr <jofr!~jofr@> has quit IRC01:10
*** jofr <jofr!~jofr@> has joined #yocto01:14
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has quit IRC01:27
*** anujm <anujm!~anujm@> has joined #yocto01:37
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:01
*** kaspter <kaspter!~Instantbi@> has quit IRC02:20
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:21
*** erakis <erakis!~erakis@> has quit IRC03:02
*** rburton <rburton!> has quit IRC03:30
*** rburton <rburton!> has joined #yocto03:31
*** kroon <kroon!> has joined #yocto03:46
*** gabrbedd <gabrbedd!> has quit IRC03:57
*** kroon <kroon!> has quit IRC03:58
*** anujm <anujm!~anujm@> has quit IRC04:34
*** kroon <kroon!~kroon@> has joined #yocto05:04
*** AndersD <AndersD!> has joined #yocto05:34
*** rburton <rburton!> has quit IRC05:36
*** rburton_ <rburton_!> has joined #yocto05:36
*** agust <agust!> has joined #yocto05:37
yoctiNew news from stackoverflow: Linux booting stop at Starting kernel when using Yocto build image with SD card <>05:48
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto05:51
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC06:00
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto06:21
*** tprrt <tprrt!~tprrt@> has joined #yocto06:36
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has quit IRC06:38
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has joined #yocto06:43
*** anujm <anujm!~anujm@> has joined #yocto06:43
iceawayLetoThe2nd: I haven't seen the fifth installment of the live coding yet, but if you have not talked about wic yet, that would be an interesting topic.06:45
LetoThe2ndiceaway: yeah i totally have wic on my to-do list. problem is rather that i'd have to learn it myself first :(06:48
iceawayI am creating a custom distro/image (based on poky/core-image-minimal) for our product. Would the recommended approach be to put everything that should end up in the production image in the distro/image settings, and keep local.conf only for things to customize for the developer/development session?06:52
LetoThe2ndiceaway: absolutely06:57
*** jmiehe <jmiehe!> has joined #yocto06:57
*** mckoan|away is now known as mckoan06:57
LetoThe2ndin a perfect world, local.conf sets MACHINE and DISTRO, besides that only things that affect the build process but not build content06:57
mckoangood morning, TGIF06:57
LetoThe2ndmckoan: heh yeah06:58
alessioigormckoan, LetoThe2nd: Good morning07:12
iceawayLetoThe2nd: great, then I have my bearings sortof correct :)07:15
LetoThe2ndalessioigor: i fail to agree on the "good" part, sorry.07:18
*** diego_r <diego_r!> has joined #yocto07:26
*** yacar_ <yacar_!> has joined #yocto07:33
nrossiRP: so if you hadn't already solved the concurrency ptestresults issue. I think i might have a solution. experimentation commit here:
nrossiRP: execution output here:
RPnrossi:  I'm only just starting to think about that so its good timimg!07:50
RPnrossi: good news is the still going autobuilder run is quite green after 17 hours :)07:52
RPnrossi: i.e. the keepalive works07:52
RPand we've addressed most of the failures07:52
RPkernel upgrades also look under control so things are starting to calm down a bit07:52
nrossiRP: nice to know :), I have to afk for a little while will be back in <1h07:52
RPnrossi: np, I appreciate all the help!07:53
RPnrossi: should that be self.successes.append((test, details)) ?08:02
RPnrossi: think I'm missing something with that commit but its in the right area...08:05
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC08:17
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto08:19
*** tprrt <tprrt!~tprrt@> has quit IRC08:21
*** tprrt <tprrt!~tprrt@> has joined #yocto08:21
rburton_khem: thanks08:24
wooosaiiiiHi guys... I have an image that I built with yocto... I deployed that image to my device... after some time I get some bug reports about that image... how can I link that image to layer commit ids?08:45
wooosaiiiiis there a "standard" way of doing this?08:45
wooosaiiiilike some yocto image tracebility?08:45
LetoThe2ndwooosaiiii: by making sure you know how you built the image that you handed out08:45
LetoThe2ndwooosaiiii: common approaches include repo or kas for layer setup, or git submodules as a combined distro08:46
wooosaiiiiI checked /etc/version timestamp -> this can be linked to images in deploy folder08:46
LetoThe2ndwooosaiiii: sounds very, very fragile08:46
wooosaiiiiLetoThe2nd: :)08:46
LetoThe2ndwooosaiiii: anything that depends on anything in tmp is to be considered a bad practise. the name "tmp" alone should already tell you these files are only temporary.08:47
wooosaiiiiLetoThe2nd: ok...08:47
LetoThe2ndwooosaiiii: a means of total emergency could be to look at the output of bitbake starting up, it at least givesthe git state of layers in use. but that does not tell you anything about local modifications and such08:49
wooosaiiiiLetoThe2nd: exactly...08:49
LetoThe2ndwooosaiiii: in a nutshell, never ever hand out something that hasn't been created through a reproductible build pipeline (CI!)08:49
wooosaiiiiLetoThe2nd: ok... Just wanted to hear if there is any "standard" way of doing so...08:50
wooosaiiiiLetoThe2nd: but is there any mechanism in place to link image on the device to repo layer commits?08:51
LetoThe2ndwooosaiiii: the standard way is making sure you know what you handed out, and i named the commonly used approaches.08:51
rburton_wooosaiiii: the image-buildinfo class can write the layer SHAs to the image for you08:51
wooosaiiiiLetoThe2nd: I thought about buildhistory + /etc/version on the device08:52
wooosaiiiirburton_: thanks for info... will try it out...08:53
nrossiRP: oh sorry should have been clearer, that commit is just about solving the cross process transfer of extraresults08:53
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:54
alessioigorHow handle in-kernel config fragments for defconfig generation in Yocto? KBUILD_DEFCONFIG seems looking for a physical file and not for the generated ones...08:58
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:59
*** yann <yann!~yann@> has joined #yocto09:01
*** JaMa <JaMa!> has joined #yocto09:19
RPnrossi: are you saying that should fix the problem?09:31
RPnrossi: are you sure that is the right commit?09:31
nrossiRP: its just a proof of concept. Aka passing the extraresults via the testresult class, which is handled by subunit to pass through the protocol stream to the parent processes testresults class09:32
nrossiRP: the other step is to take that dictionary and update the testcontext object from the testresults class09:32
RPnrossi: I think I need to stare at the code a bit as I'm not quite understanding! :)09:33
RPnrossi: ah, this is probably related to the way addSucess has compat fallbacks?09:33
nrossiRP: dw, its was complex at first. But the subunit module handles a kwarg called details that it will encode/decode across processes09:34
nrossiRP: compat fallbacks?09:34
RPnrossi: ignore me :)09:34
RPnrossi: that does make sense09:34
RPnrossi: I guess since you're close I'll let you figure this out?09:34
nrossiRP: i can finish it up of course and make sure it works locally. Not 100% sure it scales perfectly since it is passing the large json objects between processes09:35
RPnrossi: Hopefully we won't hit that...09:36
nrossiRP: i will make sure its only trying to do the passing for tests that have the extraresults09:37
RPnrossi: The other data probably isn't significant anyway09:38
nrossiRP: not sure, have not dug that deep yet ;)09:39
RPnrossi: I think I'm going to merge some of the base recipes but not the oeqa pieces yet09:44
RPnrossi: just to make the queues a bit more managable09:44
RPrburton_: ok with you?09:45
*** ball-hayden <ball-hayden!> has joined #yocto09:48
ball-haydenG'day. Hopefully a quick question - is it possible to run a QA step after wic image creation?09:49
RPnrossi: also cc'd you on a discussion with JPEW on how we might want to think about log processing in due course09:49
RPball-hayden: addtask qacheck after do_image_wic ?09:49
RPball-hayden: probably after do_image_complete actually09:50
RPball-hayden: in short, yes09:50
ball-haydenHuh. That simple. (sorry - still fairly new to this game)09:50
ball-haydenWould it be easy enough to get hold of the partitions from there?09:50
ball-haydenSpecifically, I'm wanting to run fsk09:51
ball-hayden(we've managed to generate images with FAT errors, and I'd quite like to know earlier next time...)09:51
ball-haydenI'll give that a go though - thanks :-)09:51
*** anujm <anujm!~anujm@> has quit IRC10:10
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC10:15
yoctiNew news from stackoverflow: How to create a yocto recipe that installs only the libraries to the target machine rootfs and all headers and libraries to the sdk host rootfs? <>10:19
jwesselRP: - ping on that patch, since it is has been over two weeks.10:30
jwesselI'd like to cross that off my list since it is a regression.10:30
RPjwessel: it had slipped the net, I'll queue it10:31
jwesselI wasn't sure if there was a problem in general with it or not.  No worries. :-)10:31
RPjwessel: just drowning in problems tm10:32
jwesselDo the OE minutes cover say what major problems are still left to go?  I had been out of the office all week, traveling back home today.10:34
kanavin_RP: if there's something I could help with let me know10:34
jwesselOr is it the typical dying the death of a 1000 cuts from small stuff.10:34
jwesselI had the same concern as kanavin_.  I can take a peak at something if I can download it before I get a on plane :-)10:35
RPjwessel: we've been struggling with the 5.2 kernel but that is now hopefully all resolved10:35
jwesselIndeed.  Hopefully that is set.   We have our test/bsp folks chewing away at it.10:36
RPjwessel, kanavin_: right now the pain points left are hashequiv problems and  getting the toolchain testsuite pieces integrated into the autobuilder10:36
RPI also need to test adding systemd to altcfg and see what that does on the autobuilder. I should sechedule that now10:37
RPjwessel:  it was systemtap that turned into a major pain but I think we're past that now10:38
*** goliath <goliath!> has joined #yocto10:38
RPkanavin_: I appreciate the offer, just not sure how to break up anything else left10:38
RPnrossi: are you ok with the testsuite pieces you have left on your plate?10:39
jwesselThanks for the update RP.10:40
nrossiRP: yes, assuming that is of course that the remaining issues are concurrency-ptestresults and selftest -t/-T arg changes10:41
RPnrossi: I think so (along with then sorting out the autobuild ptest log extraction but that is M4)10:45
nrossiRP: sure can look at that later, have not completely read and understood what that is about though :)10:46
RPnrossi: right, its a "for later" thing10:47
RPnrossi: there was one other thing I remembered11:09
RPnrossi: the parallelism in oeqa is done per class. If we split some of the tests into more classes, they'll run in parallel11:09
RPnrossi: might be worth considering since they're independent?11:09
nrossiRP: should I setup e.g. "GccSelfTest" as a base class and make gcc, libatomic... super classes?11:10
RPnrossi: I'm thinking yes as we'll get parallelism wins11:11
RPnrossi: this is what the numbers in the likes of mean11:11
RPnrossi: the X/6 means there are 6 parallel sets of tests running with X/21 being the total number of tests.11:12
RPnrossi: the X: at the start tells you which thread was reporting11:12
nrossiRP: there wont be much win on the system emulation classes though.... qemu is just slow for those :(11:13
*** goliath <goliath!> has quit IRC11:14
RPnrossi: executing in parallel compared to serial is still a win11:14
nrossiRP: sure, but its only really going to split off libstdcxx tests from check-gcc ones in terms of parallel tasks as the other lib* ones are alot faster11:15
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto11:17
rburton_RP: sounds sensible (merging bits)11:31
*** berton <berton!~berton@> has joined #yocto11:39
rburton_oh god another ota updater https://www.fullmetalupdate.io11:39
rburton_can people please stop writing new ones and start consolidating11:40
qschulzrburton_: it's a "big" French company behind11:41
rburton_qschulz: was wondering who made it, never easy to identify11:41
qschulzrburton_: Witekio, previously Adeneo Embedded IIRC11:42
kanavin_meh, just rocko/thud11:42
rburton_kanavin_: was  'allow shell-style wildcards in PRIVATE_LIBS' a repost or a v2?11:43
kanavin_rburton_, repost11:43
rburton_cool, its in mut already11:43
kanavin_and the virgl bits are the same too, I'm not sure whether they'll be picked up for 3.0, but posted them once more just in case11:44
rburton_yeah i wanted to give those a play11:44
kanavin_yeah, somewhere on the way, SDL started working11:45
rburton_not entirely sure i like how something in there needs mesa-dev installed to use the .pc files11:45
kanavin_rburton_, only for egl-headless11:45
kanavin_sdl/gtk frontends don't need them11:45
kanavin_sdl/gtk work through libepoxy which falls through to the host mesa11:46
kanavin_but egl-headless loads native mesa directly, and so we need to (mis)guide it to use host drivers11:46
kanavin_because building a useful set in mesa-native would simply be way too much11:46
rburton_any reason why it can't use libepoxy too i wonder11:47
kanavin_just the way it's written in qemu11:47
kroonJust to be sure, commit message in 6b8e0077339a89cb01aa40c1b367a4e41a638892 in current master states that the commit perhaps shouldn't be merged.11:48
kroonoe-core repo that is11:48
kroonJPEW, RP: ^^^11:48
RPnrossi: FWIW I'm leaning towards tagging the tests as "toolchain-user", "toolchain-system" and "toolchain-ypab" and then from the autobuilder we just run "toolchain-ypab"11:48
RPkroon: It was intentional, I'd just not realised the commit said it was a test11:49
kroonRP, cool11:49
RPrburton_: -next looks a little more trim11:50
RPnrossi: I guess that still means conditional tags though :/11:51
nrossiRP: i assume that would mean for qemux86-64 you would run all "toolchain-ypab" and "toolchain-system" tags, but only "toolchain-ypab" for the others?11:51
RPnrossi: right, toolchain-ypab doesn';t help us does it :/11:51
RPnrossi: we'd just have to override the template for x86/x86-6411:52
nrossiRP: yer, maybe its best to keep it simple for now :)11:53
RPnrossi: still haven;t figured out how to trigger things conditionally properly for quick/full11:53
RPI guess that is my next job11:53
*** ric96 <ric96!sid234506@gateway/web/> has quit IRC11:54
rburton_RP: repushed mut with revised patches for meson/weston from the contributors instead of my fixup patches on top. if the ab goes green you should be good to pull the lot into next11:55
*** vmeson <vmeson!> has quit IRC11:55
*** ric96 <ric96!sid234506@gateway/web/> has joined #yocto11:55
*** vdehors <vdehors!> has quit IRC11:58
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:00
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC12:01
*** kroon <kroon!~kroon@> has quit IRC12:04
*** berton <berton!~berton@> has quit IRC12:13
*** berton <berton!~berton@> has joined #yocto12:14
fullstopin local.conf, does the order of IMAGE_INSTALL_append matter?12:29
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto12:35
*** kroon <kroon!~kroon@> has joined #yocto12:37
JaMahmm, it's not possible to include another .bbappend from .bbappend? It fails with "u-boot_2019.01.bbappend: not a BitBake file"12:37
*** vmeson <vmeson!~rmacleod@> has joined #yocto12:38
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC12:40
qschulzJaMa: what's the use case?12:43
RPrburton_: into next or straight to master?12:44
RPJaMa: not sure that is something we've ever tried or supported12:44
*** anujm <anujm!~anujm@> has joined #yocto12:46
JaMaRP: probably not useful in most cases, I was just surprised12:49
RPJaMa: you could certainly include an inc from both12:50
JaMaRP: yes, that's what I did now12:50
qschulzJaMa: ah, interesting problem indeed :)12:50
*** alessioigor <alessioigor!~alessioig@> has quit IRC12:57
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto13:05
RPrburton_: any idea why qaextras step 4b is so slow?13:17
*** diego_r <diego_r!> has quit IRC13:23
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC13:26
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has quit IRC13:28
rburton_fullstop: no13:30
rburton_RP: what does 4b do :)13:30
rburton_we need to start renaming those13:30
RPrburton_: not sure we can do that easily13:31
RPrburton_:  "SDK_EXT_TYPE = 'full'"13:32
rburton_why can't we just change the string from step2 to 'api documetation build"13:32
RPrburton_: I wonder if we have some performance regresion with that13:32
rburton_maybe we do13:32
rburton_surely that just changes the build of the sdk itself13:32
RPrburton_: you have no idea what magic is behind these strings :(13:32
fullstoprburton_: thanks!13:33
*** jmiehe <jmiehe!> has quit IRC13:33
rburton_RP: locked signatures test failed in mut again13:34
rburton_ive seen that happen occasionally and a rebuild makes it go away :/13:34
RPrburton_: I wonder if the issue is slow NAS13:34
RP(for 4b)13:34
*** AndersD <AndersD!> has quit IRC13:34
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto13:35
RPrburton_: AssertionError: unexpectedly None : Didn't find the expected warning message. Output: Loading cache...done.13:35
RP        # Verify you get the warning and that the real task *isn't* run (i.e. the locked signature has worked)13:36
RP        patt = r'WARNING: The %s:do_package sig is computed to be \S+, but the sig is locked to \S+ in SIGGEN_LOCKEDSIGS\S+' % test_recipe13:36
RPrburton_: wonder if that test races and something else can wipe self.testlayer_path ?13:37
RPnrossi: FWIW I think I've untangled the autobuilder piece of this ready13:38
JPEWkroon, RP: Hah, I guess I should be more clear with my commit messages :)13:39
JPEWrburton: I see you are still using the reprodcible_build_simple... is that just for sato? The AB is using reproducible_build currently, so I think it should be working?13:41
*** goliath <goliath!> has joined #yocto13:41
* Crofton|work missed a reproducible build meetup at camp :(13:42
RPCrofton|work: I just noticed that in the news bulletin13:42
Crofton|workI follow them on twitter now13:43
RPCrofton|work: what's twitter?13:43
Crofton|workhow I get all my news13:43
Crofton|workApparently you have MP's resigning to spend less time with their families13:44
RPrburton_: going to merge the systemd by default for poky-altcfg since that went green (and call that good for systemd by default in 3.0)13:44
RPCrofton|work: yes, understandably :/13:45
rburton_Crofton|work: what an original joke i've never heard that one before13:45
RPrburton_: we call mut green and merge?13:46
rburton_RP: yeah13:46
rburton_RP: i do wonder if this is racing with something else wiping out the bbappend13:46
rburton_the bbappend creation should be in a per-test path so they don't conflict13:47
rburton_like the devtool workspace is in build dir13:47
RPthat layer path is per test?13:47
Crofton|workrburton_, it took me a while before I understood the underlying news story13:48
rburton_RP: is it? looks like it ends up in get_test_layer which is just the first layer called meta-selftest13:48
rburton_so dropping a bbappend in there impacts all running tests13:49
yoctiNew news from stackoverflow: cannot su to new user added in yocto build <>13:49
RPrburton_: which is bad and we shouldn't be doing that13:53
RPrburton_: I can drop the X: prefix from the pango uprev?13:53
rburton_RP: yeah thats a reminder that i need to post the patch13:56
rburton_so please strip and post13:56
* rburton_ needs to get the kids now13:56
*** kroon <kroon!~kroon@> has quit IRC14:00
*** kaspter <kaspter!~Instantbi@> has quit IRC14:03
ykronsHi all14:05
*** rcw <rcw!~rcw@> has joined #yocto14:08
ykronsI would like to enable  the libdns-sd support in avahi. To do so, I had a look to avahi recipe in master and try to "backport it" to my rocko version as a bbappend, but it seems I missunderstood how packages are created from recipes because to expect library are missing in the final image14:08
ykronsI have customized PACKAGECONFIG with PACKAGECONFIG[libdns_sd] = "--enable-compat-libdns_sd," and then declare that the recipe generates the package if option is set with PACKAGES =+ "${@bb.utils.contains("PACKAGECONFIG", "libdns_sd", "libavahi-compat-libdnssd", "", d)}"14:10
*** WillMiles <WillMiles!> has joined #yocto14:10
ykronsand finally just add generated files to the package with FILES_libavahi-compat-libdnssd = "${libdir}/*".  But if I do a bitbake libavahi-compat-libdnssd, I get error: Nothing PROVIDES 'libavahi-compat-libdnssd'. What did I missed?14:13
qschulzykrons: you bitbake a recipe, always14:13
qschulzso bitbake avahi and then look in the deploy/deb or rpm or ipk for libavahi-compat-libdnssd package14:14
RPrburton_: sorted, thanks for looking at that patchset14:15
* RP has another load in -next to test14:15
qschulzPACKAGES is for RPROVIDES. You can use recipes for DEPENDS only, and packages for RDEPENDS. It happens that most of the time, there is a package named after the recipe so it is confusing14:15
RPnrossi: mips64 and ppc are still going after 24 hours on the toolchain testsuite! :)14:15
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto14:19
ykronsqschulz, thanks for clarification. I will rebuild to check but think I will not have th eipk for libavahi-compat-libnsssd14:20
ykronsqschulz, nthe ipk has not been generated, but other libavahi-xxxx have been14:21
ykronsI'm doing a cleanall of avahi and a rebuild to be sure14:26
*** anujm <anujm!~anujm@> has quit IRC14:34
qschulzykrons: what is the value of the PACKAGECONFIG for avahi?14:40
qschulzalso, why don't you put ${libdir}/* in the default avahi package?14:41
yoctiNew news from stackoverflow: cannot su to new user added in yocto build [on hold] <>14:50
*** pebenito_ <pebenito_!~pebenito@unaffiliated/pebenito> has joined #yocto14:51
rburton_ykrons: all you need to do is add libdns_sd to PACKAGECONFIG for avahi14:55
ykronsrburton_, it has been done just before setting PACKAGECONFIG[libdns_sd]14:58
rburton_ykrons: then you bitbake a *recipe*, so bitbake avahi14:59
ykronsbitbake avahi is on going (after a cleanall), I tell you the result in few minutes15:01
rburton_cleanall is very rarely ever needed15:02
rburton_especially as it deletes *all* sstate (slow) and the source tarballs (why?)15:02
rburton_just bitbake avahi, it will rebuild15:02
ykronsI have changed the recipe in different ways and want to be sure to have something clean to troubleshoot, but I agree, it is probably not needed but I expect avahi not to be to long to fully rebuild15:04
ykronsqschulz, rburton_ : build finished and no libavahi-compat-libdnssd package found in deploy15:17
ykronsTo clarify here is my avahi_%.bbappend:15:17
ykronsPACKAGECONFIG = "dbus ${AVAHI_GTK} libdns_sd"15:18
ykronsPACKAGECONFIG[libdns_sd] = "--enable-compat-libdns_sd,"15:18
ykronsPACKAGES =+ "${@bb.utils.contains("PACKAGECONFIG", "libdns_sd", "libavahi-compat-libdnssd", "", d)}"15:18
ykronsFILES_libavahi-compat-libdnssd = "${libdir}/*"15:18
JPEWykrons: It won't generate a packages called libavahi-compat-libdnssd because of the so renaming15:19
*** fitzsim is now known as fitzsim_`15:19
*** fitzsim <fitzsim!> has joined #yocto15:19
JPEWykrons: It will should be called "libdns_sd<something>" (sorry, I don't remember the exact rules for the renaming)15:19
yoctiNew news from stackoverflow: create symbolic link in bitbake recipe <>15:20
*** fitzsim_` <fitzsim_`!> has quit IRC15:20
ykronsJPEW, you're right I have libdns_sd1... package with the expected libs15:21
ykronsbut what is the "so renaming" ?15:21
JPEWykrons: Basically, if a package contains only a library (.so), it gets renamed to a specially formatted name based on that library15:22
ykronsOk, I don't know that point! Thanks15:25
JPEWykrons: This allows the packaging code to look at the linktime libraries an ELF executable requires and automatically add the correct dependencies as runtime dependencies... this is why you usually don't have to add linktime library dependencies as RDEPENDS, but they still get picked up15:25
JPEWLetoThe2nd: Is library packaging (and so package renaming) on your list? I feel like I explain it a lot :)15:26
ykronsIn the original recipe from master, there is also RPROVIDES_libavahi-compat-libdnssd = "libdns-sd" that I have commented, it is a way to create an "aliases" from libavahi_compat_libdnssd to libdns-sd ?15:27
JPEWykrons: The RPROVIDES should do that?15:29
ykronsSorry, it was a question, what is doing this RPROVIDES?15:30
*** cpo <cpo!> has quit IRC15:36
*** weltling <weltling!> has quit IRC15:37
*** milloni <milloni!> has quit IRC15:37
ykronsI have to leave sorry, but thanks it seems my problem is solved now.15:37
JPEWykwrons: Ok15:37
*** Crofton|mini <Crofton|mini!~Crofton@2601:5c0:c100:b84:3d3f:64d6:2ba1:780b> has quit IRC15:37
*** Crofton|mini <Crofton|mini!~Crofton@2601:5c0:c100:b84:3d3f:64d6:2ba1:780b> has joined #yocto15:37
*** milloni <milloni!> has joined #yocto15:37
*** falk0n <falk0n!> has quit IRC15:37
rburton_JPEW: the renaming isnt needed for that, the magic deps work if you turn off debian renaming15:38
rburton_the renaming is because early oe wanted to be like debian15:38
JPEWrburton_: Huh. I figured they were related.... it must be able to look at the RPROVIDES to determine the dependencies then?15:39
rburton_do_package of libraries writes a map of sonames to package names15:39
*** cpo <cpo!> has joined #yocto15:41
JPEWrburton_: The .list files in ${SHLIBSWORKDIR}?15:42
*** lucaceresoli <lucaceresoli!> has quit IRC15:43
rburton_JPEW: right15:44
JPEWrburton_: Ah. Thanks!15:44
*** lucaceresoli <lucaceresoli!> has joined #yocto15:46
*** lucaceresoli <lucaceresoli!> has quit IRC15:55
*** lucaceresoli <lucaceresoli!> has joined #yocto15:56
*** tprrt <tprrt!~tprrt@> has quit IRC16:06
*** yann <yann!~yann@> has quit IRC16:09
*** yacar_ <yacar_!> has quit IRC16:10
*** nrossi <nrossi!nrossimatr@gateway/shell/> has quit IRC16:21
*** MarcWe <MarcWe!hmwmatrixo@gateway/shell/> has quit IRC16:21
*** bachp <bachp!bachpmatri@gateway/shell/> has quit IRC16:21
*** silviof <silviof!silv-iomat@gateway/shell/> has quit IRC16:21
*** kayterina <kayterina!kayterina-@gateway/shell/> has quit IRC16:21
*** Bunio_FH <Bunio_FH!> has joined #yocto16:24
*** mckoan is now known as mckoan|away16:26
*** falk0n <falk0n!> has joined #yocto16:26
*** Bunio_FH <Bunio_FH!> has quit IRC16:28
*** bachp <bachp!bachpmatri@gateway/shell/> has joined #yocto16:32
*** Bunio_FH <Bunio_FH!> has joined #yocto16:38
*** nrossi <nrossi!nrossimatr@gateway/shell/> has joined #yocto16:48
*** silviof <silviof!silv-iomat@gateway/shell/> has joined #yocto16:48
RPnrossi: - not merged but ready and hopefully should work with the changes you're working on16:56
RPmoto-timo: I did figure out that autobuilder nfs patch and merged it16:57
khemRP: do we have a writeup to run toolchain tests16:57
RPkhem: "oe-selftest -t toolchain-user | toolchain-system" will be the end result16:58
RPkhem: right now with master-next its -t machine16:59
*** lucaceresoli <lucaceresoli!> has quit IRC17:00
RP26 hours to run the ppc toolchain tests17:03
khemno wonder17:10
khemyou chose the best case17:10
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has joined #yocto17:22
millonidoes yocto support shallow cloning git repos?17:26
millonithere was some work on that here
kergothshallow clones are not supported, use of shallow mirror tarballs are. that is, *someone* has to do a full clone to populate a mirror, but everyone using the mirror could pull down shallow tarballs to speed things up17:27
kergothwe can't do a shallow clone because our fetcher supports fetching an arbitrary revision, while clone with shallow requires that you specify a branch and depth, and we don't know how many commits separate SRCREV and the specified branch until we've cloned it17:28
*** yacar_ <yacar_!> has joined #yocto17:28
kergothwe *could* support shallow only when using AUTOREV, but that hasn't been done17:28
kergoths/tarballs are/tarballs is/17:28
milloniso you can pull a tarball from a git remote? is that a standard git feature?17:29
kergothno, you can pull a tarball from an oe/yocto mirror using our mirror support17:29
kergothdoesn't use get for that part at all17:30
milloniah okay17:30
kergoththe fetcher can fetch an upstream git url, convert it to shallow, tar that up, and put the tarball in your DL_DIR, then you can use that to populate a mirror to be used in PREMIRRORS17:30
millonioh, thats news to me17:30
*** rizzitello <rizzitello!~quassel@> has joined #yocto17:31
kergothstill worthwhile IMO since it's nicer for the rest of the team to download a 150mb kernel tarball than a gig git repo, even if it doesn't help the person or CI job populating the mirror in the first place17:31 kind of like a "download cache"?17:31
millonihm, an example scenario: assuming i have set up a mirror that has a git revision A of project X tar'ed up17:33
milloniand i've got a bitbake recipe that fetches from that mirror17:34
*** rizzitello <rizzitello!~quassel@> has quit IRC17:34
milloniassuming i want to change the revision to fetch to B17:34
millonican i do that quickly and without too much effort?17:34
kergothyou jus tmodify the recipe to change SRCREV to the new revision. when you do a new build or —runall=fetch, it'll download the new/updated git repo locally, if you set BB_GENERATE_MIRROR_TARBALLS=1, it'll also create a new git tarball, and you could rsync your local DL_DIR to the remote mirror directory to get the updated tarball there17:36
kergothshallow works similarly, just it creates smaller shallow tarballs instead, and the user has to enable it to use them instead of the full git mirror tarball17:36
milloniokay that sounds good, i'll read the docs, thanks17:36
*** Bunio_FH <Bunio_FH!> has quit IRC17:47
*** Bunio_FH <Bunio_FH!> has joined #yocto17:48
*** fitzsim is now known as fitzsim_17:54
*** fitzsim <fitzsim!> has joined #yocto17:54
*** Bunio_FH <Bunio_FH!> has quit IRC17:55
*** yacar_ <yacar_!> has quit IRC18:08
*** Bunio_FH <Bunio_FH!> has joined #yocto18:14
*** fitzsim <fitzsim!> has quit IRC18:28
LetoThe2ndJPEW: i have already done a session on packaging and package splitting. i won't be going more in depth there in the near future probably, sorry18:50
JPEWLetoThe2nd: Cool, I must have missed that one. I'll look through the archives18:50
LetoThe2ndJPEW: i think it #318:54
LetoThe2ndJPEW: if you want to witness me making a total fool of myself, tune in on tuesday :)18:58
Crofton|workLetoThe2nd, we are all fools19:00
Crofton|workjust less foolish than others19:00
LetoThe2ndi'll be talking about *gasp* kernel things!19:00
* Crofton|work shivers19:02
*** gnac <gnac!> has quit IRC19:23
markamust be Fri afternoon, sorry about that folks19:42
*** vmeson <vmeson!~rmacleod@> has quit IRC20:30
*** rburton_ <rburton_!> has quit IRC20:31
*** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto20:38
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has quit IRC20:39
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC20:40
*** aidanh_ is now known as aidanh20:40
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has quit IRC20:46
fullstopHow can I make a change to something in sysroot before a package configures?20:47
fullstopthere is a header file which was renamed and I need to either copy or symlink it for compatibility with a particular package.20:48
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has joined #yocto20:48
fullstopdo_configure_prepend looks interesting20:49
neverpanicwhy not just patch the include in the sources of the package?20:50
neverpanicModifying the sysroot is kinda asking for trouble. You might now get away with it since Yocto now has separate sysroots per recipe, but back when it didn't, you'd have modified the build env for all other packages, too.20:51
fullstopI'll consider it20:52
neverpanicWith the obvious unexpected side-effects of race conditions and so on, which is why it's best not to touch the sysroot.20:52
fullstopthe source package is some binary doo-dad from nvidia20:52
neverpanicif it's a binary, why does it care about the name of a header file?20:52
neverpanicIf you really need the header file back, bbappend the recipe that provides the header file and modify what it puts into the sysroot.20:52
fullstopit's a library with a header file20:53
fullstopanyway, I'll look at those options20:54
neverpanicright, but if it's a header file, you can patch it ;-)20:54
*** falk0n <falk0n!> has quit IRC20:55
fullstopwell, it's a renamed header20:55
fullstopbut yes20:55
neverpanicMaybe I'm misunderstanding you… I'm suggesting to patch the source that uses the renamed header, not patching the header itself.20:57
fullstopthat gets into cmake and I don't like that area.. :-)20:58
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has quit IRC20:59
*** rcw <rcw!~rcw@> has quit IRC21:01
*** gnac <gnac!> has joined #yocto21:04
fullstopthat may not have been that bad. thanks, neverpanic.21:05
fullstopokay, that worked.. onto the next problem21:06
*** Bunio_FH <Bunio_FH!> has quit IRC21:08
RPgah, here had to be a single failure in -next. Now I get to play guess the patch21:10
* RP powers the build machine back21:10
*** berton <berton!~berton@> has quit IRC21:15
*** rubdos <rubdos!~rubdos@> has joined #yocto21:17
*** rubdos <rubdos!~rubdos@> has quit IRC21:23
*** pebenito_ <pebenito_!~pebenito@unaffiliated/pebenito> has quit IRC21:24
*** rubdos <rubdos!~rubdos@> has joined #yocto21:25
*** WillMiles <WillMiles!> has quit IRC21:27
*** falk0n <falk0n!> has joined #yocto21:36
*** dv_ <dv_!> has quit IRC21:45
*** dv_ <dv_!~dv@> has joined #yocto22:03
*** rubdos <rubdos!~rubdos@> has quit IRC22:14
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC22:33
*** agust <agust!> has quit IRC22:38
*** fatalhalt <fatalhalt!> has joined #yocto22:44
*** Willy-- <Willy--!~william@> has quit IRC23:05
*** JaMa <JaMa!> has quit IRC23:09
*** fitzsim <fitzsim!> has joined #yocto23:26
* armpit has flash back to the power twins23:41
*** goliath <goliath!> has quit IRC23:54

Generated by 2.11.0 by Marius Gedminas - find it at!