| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 00:16 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 00:39 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.139.93> has quit IRC | 00:41 | |
| *** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has quit IRC | 01:05 | |
| *** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has quit IRC | 01:07 | |
| *** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has joined #yocto | 01:08 | |
| *** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has quit IRC | 01:10 | |
| *** kaspter <kaspter!~Instantbi@2409:8928:66c:b82:8078:23da:9db1:7d7b> has joined #yocto | 01:12 | |
| *** Bryanstein <Bryanstein!~Bryanstei@shellium/admin/bryanstein> has joined #yocto | 01:25 | |
| *** tgraydon <tgraydon!~tgraydon@134.134.139.77> has quit IRC | 01:40 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has quit IRC | 02:00 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has joined #yocto | 02:00 | |
| *** kaspter <kaspter!~Instantbi@2409:8928:66c:b82:8078:23da:9db1:7d7b> has quit IRC | 02:14 | |
| *** kaspter <kaspter!~Instantbi@183.128.237.44> has joined #yocto | 02:34 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has quit IRC | 03:07 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has joined #yocto | 03:09 | |
| *** FailDev <FailDev!18d83107@24.216.49.7> has quit IRC | 03:57 | |
| *** chinhuat6479 <chinhuat6479!~chinhuat@192.198.146.173> has joined #yocto | 04:02 | |
| *** chinhuat647 <chinhuat647!~chinhuat@192.198.146.173> has quit IRC | 04:04 | |
| *** anujm <anujm!~anujm@134.134.139.76> has joined #yocto | 04:15 | |
| *** anujm <anujm!~anujm@134.134.139.76> has joined #yocto | 04:21 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 04:22 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 04:26 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 04:27 | |
| iceaway | I have created a small test application for the sake of learning how to create a custom recipe. The test application is using CMake. When I build this recipe in bitbake I get the error message: "do_package: QA Issue: anpr-test: Files/directories were installed but not shipped in any package:". Could this be because the install dir in the CMake description does not use the default "bin" directory, but | 04:30 |
|---|---|---|
| iceaway | rather a custom directory under /? | 04:30 |
| kroon | iceaway, sounds likely | 04:32 |
| kroon | iceaway, unusual files like that need to be explicitly listed in FILES_* | 04:33 |
| kroon | iceaway, but you can use wildcards when listing | 04:33 |
| iceaway | Ok great, thanks. | 04:34 |
| nrossi | RP: just started looking at the autobuilder runs with the toolchain test patches... I realised its running everything :| aka both gcc/glibc with user and system qemu. That will take awhile :| | 04:37 |
| zeddii | RP: finally I have the systemtap issue reproduced on my mips64 image. it’s 12:40 am here, so I’ll pick it up in the morning. I assume that your uprev in master-next didn’t sort it out. | 04:40 |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 04:43 | |
| *** anujm <anujm!~anujm@134.134.139.76> has quit IRC | 04:45 | |
| iceaway | I'm trying to use wic to create a custom partitioning scheme for my image. I have setup two partitions / and /anpr. But when I try to create the image I get an error message: "ERROR: Nothing PROVIDES '${IMAGE_ROOTFS}/anpr'". I can see that /anpr is present in the tar.gz version of the rootfs in my deploy/images directory. Any ideas? | 04:56 |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 05:07 | |
| yocti | New news from stackoverflow: bitbake failed with ExpansionError <https://stackoverflow.com/questions/41992449/bitbake-failed-with-expansionerror> | 05:08 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:18 | |
| yocti | New news from stackoverflow: OpenBMC with Raspberry Pi (2 or 3) and build bmcweb? <https://stackoverflow.com/questions/57103268/openbmc-with-raspberry-pi-2-or-3-and-build-bmcweb> | 05:38 |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto | 05:50 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 06:07 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 06:16 | |
| *** alessioigor <alessioigor!~alessioig@140.105.207.227> has quit IRC | 06:36 | |
| *** chinhuat64799 <chinhuat64799!~chinhuat@192.198.146.173> has joined #yocto | 06:39 | |
| *** chinhuat6479 <chinhuat6479!~chinhuat@192.198.146.173> has quit IRC | 06:40 | |
| *** feilz <feilz!d4328f74@212-50-143-116.co.dnainternet.fi> has joined #yocto | 06:48 | |
| feilz | Hello, I stumbled upon something strange with the bitbake build system. | 06:48 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 06:49 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 06:50 | |
| feilz | in my project at work, it seems that when I have two packages, and the first package has a dependency on the second package. If i update the second package, rebuilding the first package doesn't automatically update the cached dependency | 06:50 |
| feilz | meaning that I might rebuild the first package, using the old version of the second package, even though the second package has been updated | 06:51 |
| MarcWe | do you have SRCREV = "${AUTOREV}" ? | 06:52 |
| *** frsc <frsc!~frsc@200116b824140f00f7f86fd7ac845ea5.dip.versatel-1u1.de> has joined #yocto | 06:52 | |
| feilz | no. They are two local packages | 06:52 |
| feilz | as both packages are fairly small | 06:52 |
| *** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto | 06:53 | |
| feilz | so far only way I found that solves this issue is by manually deleting the cache of the first package | 06:54 |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has joined #yocto | 06:54 | |
| MarcWe | bitbake is not rebuilding if it is sees that the bb file is not changed | 06:54 |
| feilz | ahaa... then that would be the cause, even if the compiled package is different | 06:55 |
| MarcWe | do you have your package in a git repo ( on your local machine ) ? | 06:55 |
| feilz | both packages are in the same git repo on my local machine | 06:56 |
| *** alessioigor <alessioigor!~alessioig@140.105.207.227> has joined #yocto | 06:56 | |
| MarcWe | you can do a git init an somthing like SRC_URI = git:///Data/Development/Qt/package1;protocol=file;branch=${BRANCH} | 06:56 |
| MarcWe | SRCREV = "${AUTOREV} | 06:57 |
| feilz | i feel like you are not exactly following the problem I'm describing, as this is not related to git (as far as I know). | 06:57 |
| MarcWe | how do you store the local package? | 06:58 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 06:58 | |
| *** anujm <anujm!~anujm@134.134.139.77> has joined #yocto | 06:58 | |
| feilz | in my companys git repository, both inside the same layer | 06:59 |
| qschulz | how do you "update the second package" ? | 07:00 |
| feilz | "bitbake -c compile second-package-name" | 07:01 |
| MarcWe | o wait, do you have ${SRCREV} in your PV var this will trigger rebuild if the git repo is updated | 07:02 |
| feilz | @MarcWe I have taken advantage of that when it's linking two different git repos together in the same layer. However, in this situation that is not the case. | 07:03 |
| qschulz | feilz: you've done something before that which is requiring you to run do_configure. What? | 07:03 |
| qschulz | do_compile* | 07:03 |
| feilz | modifying the source files | 07:04 |
| qschulz | modified the source code? modified the recipe? what did you do? | 07:04 |
| qschulz | from where? | 07:04 |
| qschulz | I mean, where did you operate the changes for the source code? in the workdir? how do you fetch the sources? | 07:04 |
| feilz | uhh... inside the folder where the second package .bb directory | 07:04 |
| qschulz | feilz: are you adding directories in SRC_URI by any chance? | 07:05 |
| qschulz | RP: FYI, plain text version of "Yocto Project Status WW36’19" mail I received is unreadable. It's missing new lines (at least). | 07:07 |
| *** feilz <feilz!d4328f74@212-50-143-116.co.dnainternet.fi> has quit IRC | 07:09 | |
| qschulz | feilz you shouldn't have to run compile for the package, the dependency should be pulled because there's been a change in one the source file. So something makes Yocto think the source files were not updated (or somethng is saying to avoid rebuilding) | 07:10 |
| *** feilz <feilz!d4328f74@212-50-143-116.co.dnainternet.fi> has joined #yocto | 07:10 | |
| RP | qschulz: hmm, it was entered as html as that is what stephen normally does so something went wrong. You can also read it on the wiki | 07:11 |
| feilz | sorry, crash on my end. qschulz we use SRC_URI = "file://*" to include all files | 07:11 |
| MarcWe | feilz: that way bitbake is not seeing change to the bb file content so it not rebuilding ( if you change things in "file://*" ) | 07:13 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 07:14 | |
| feilz | if I included all files manulally such as SRC_URI = "file://files/filename1.c \ file://files/filename2.c", the change would be seen? | 07:14 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:16 | |
| *** S54 <S54!2eeb996e@46.235.153.110> has joined #yocto | 07:16 | |
| MarcWe | feilz: im not shure about that. but sins * is not working i think it is not getting picked up | 07:19 |
| S54 | hello | 07:19 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 07:21 | |
| *** feilz <feilz!d4328f74@212-50-143-116.co.dnainternet.fi> has quit IRC | 07:21 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:22 | |
| S54 | I'm facing "file /lib/systemd conflicts between attempted installs of" while doing a rootfs, can't figure out why but it happens whereas i'm installing different files from different packages. Could this also apply on directories? | 07:24 |
| *** feilz <feilz!~feil@212-50-143-116.co.dnainternet.fi> has joined #yocto | 07:26 | |
| *** kaspter <kaspter!~Instantbi@183.128.237.44> has quit IRC | 07:26 | |
| *** kaspter <kaspter!~Instantbi@183.128.237.44> has joined #yocto | 07:26 | |
| feilz | @qschulz the browser based irc client kept crashing on me... switched to command line. probably missed any questions / messages that came after my last comment | 07:27 |
| feilz | basically i know the reason why rebuilding the first package failed, as the .bb file didn't change of the dependency. | 07:30 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 07:30 | |
| feilz | one suggestion for implementing to bitbake would be an option to force rebuild dependency packages of the package im building, to avoid having to manually delete the cache | 07:30 |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has joined #yocto | 07:31 | |
| feilz | would perhaps be cool as well if it would be incorporated to "bitbake -c cleanall packagename" as well | 07:31 |
| LetoThe2nd | feilz: i guess you rather need to look at PR/PV in depth | 07:31 |
| *** yann <yann!~yann@85.118.38.73> has joined #yocto | 07:31 | |
| LetoThe2nd | feilz: because bitbake intentionally rebuild when it gets told that has been a change, and does not rebuild when not being told | 07:32 |
| feilz | aaaa... now i remember reading about that... | 07:32 |
| feilz | okay. | 07:33 |
| *** likewise <likewise!~leon@213.34.54.210> has joined #yocto | 07:33 | |
| qschulz | LetoThe2nd: I also have the same issue. When using directories with SRC_URI, if you change the content of the files, Yocto does not detect the changes and do not rebuild | 07:33 |
| *** learningc <learningc!~learningc@mti-37-145.tm.net.my> has quit IRC | 07:34 | |
| LetoThe2nd | feilz: as well as rethinking the recipe/source structure. because if you have one source repo building several packgaes, it might be helpful to actually pour it into one recipe that provides additional packages. | 07:34 |
| LetoThe2nd | qschulz: directories, as "something local on your disk"? | 07:34 |
| qschulz | LetoThe2nd: meta/recipes-foo/foo/foo.bb SRC_URI = "file://bar" and then meta/recipes-foo/foo/bar/main.cpp | 07:35 |
| qschulz | change main.cpp, nothing gets rebuilt | 07:35 |
| feilz | LettoThe2nd: rethinking the recipe/source structure won't be necessary in this situation. The problem I describe is what qschulz now highlights (apparently much better than I managed to do) | 07:36 |
| LetoThe2nd | i see what you mean, but in my opinion sticking source into the layers is a super bad practise anyways, and those who do it deserve to be punished :-P | 07:36 |
| feilz | if I use PV="0.1" and then bump that number, that should force a rebuild of main.cpp | 07:37 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 07:37 | |
| qschulz | feilz: maybe even PR IIRC | 07:37 |
| qschulz | but not great | 07:37 |
| qschulz | LetoThe2nd: well, it does not have to be specific to code actually | 07:38 |
| qschulz | I can have configuration files there | 07:38 |
| feilz | especially when doing some minor fixes, having to bump for every character change or minor bugfix does seem excessive | 07:38 |
| *** yacar_ <yacar_!~yacar@80.215.168.65> has joined #yocto | 07:38 | |
| LetoThe2nd | qschulz: sure, i know what you mean. taking me overly serious is a bad practise too :) | 07:38 |
| qschulz | feilz: -c cleanall for the package you're modifying | 07:38 |
| qschulz | LetoThe2nd: well, I don't like it myself as well but ATM, things are how they are | 07:38 |
| feilz | oh... that's how it's solved | 07:39 |
| qschulz | feilz: no, worked around :) | 07:39 |
| feilz | true | 07:39 |
| qschulz | sorry, -c cleansstate is enough IIRC | 07:39 |
| feilz | yeah. | 07:40 |
| feilz | anyways, hope I managed to bring this issue to light... glad we managed to find a workaround. Took me a day of bughunting yesterday to notice this :) | 07:40 |
| *** S54 <S54!2eeb996e@46.235.153.110> has quit IRC | 07:40 | |
| qschulz | LetoThe2nd: do you have more input on why it is working that way? It seems to be a known "issue". Is there a reason for not fixing it? | 07:40 |
| qschulz | feilz: been there :) | 07:41 |
| qschulz | LetoThe2nd: which could well be "nobody took time to send a patch". But maybe there was something already posted and got rejected for a reason. | 07:41 |
| LetoThe2nd | qschulz: in a nutshell it is like this: "bitbake decides what do based on looking at the recipe". so if it looks at the recipe, nothing changed, then nothing is to be done | 07:42 |
| LetoThe2nd | qschulz: it can be forced to behave differently by applying stuff like externalsrc, but thats the main reasoning. | 07:42 |
| qschulz | LetoThe2nd: well... it knows when a file from SRC_URI is changed | 07:42 |
| qschulz | so can't we have a glob there of the content of directories? | 07:43 |
| qschulz | I guess there is something like the hash of the files in SRC_URI in the sstate-cache to know if it's changed/ | 07:43 |
| *** S54 <S54!94401315@148.64.19.21> has joined #yocto | 07:44 | |
| tprrt | Hello, I have a question about the ccache bbclass which has been reworked, but the mega-manual seems not to be up to date and advises against using it, is this advice still valid? | 07:46 |
| LetoThe2nd | no, it does not | 07:46 |
| LetoThe2nd | AFAIK it does *not* look at the files mentionend in SRC_URI, only at SRC_URI itself | 07:47 |
| LetoThe2nd | but there are others you can explain siggen way better than me. | 07:47 |
| S54 | can't find what DIRFILES does in the mega manual, am I missing sth? | 07:48 |
| qschulz | LetoThe2nd: that's something I haven't looked at yet and I'm eager to know about it a bit more :) so if anyone has pointers... | 07:48 |
| LetoThe2nd | qschulz: hand over beer to RP :) | 07:49 |
| LetoThe2nd | i think theres also a tool like bitbake-diffsigs or such | 07:50 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 07:55 | |
| qschulz | RP: thanks, I just wanted to give a headsup as previous mails (last week's was broken as well IIRC though) were readable. Nothing to worry about, I still can open the html version, but you know.. one more key press :D | 07:57 |
| RP | qschulz: FWIW a glob of files should correctly notice when they change | 07:59 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 08:04 | |
| RP | qschulz: you can understand a bit about it by doing bitbake-dumpsig on tmp/stamps/XXX/YY.do_fetch.sigdata | 08:04 |
| RP | That will tell you what makes up the data bitbake uses on that task | 08:05 |
| *** S54 <S54!94401315@148.64.19.21> has quit IRC | 08:07 | |
| *** ms_k <ms_k!~mauro@host72-92-static.3-79-b.business.telecomitalia.it> has joined #yocto | 08:15 | |
| MarcWe | Im trying to do some app development for my target using qt creator but im getting the error: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by | 08:17 |
| RP | MarcWe: on target or using native tools on the host? | 08:19 |
| MarcWe | on the target | 08:19 |
| RP | that sounds like trying to run newer binaries on a older target toolchain | 08:19 |
| RP | gcc and glibc aren't matched up | 08:20 |
| MarcWe | yes but im shure that i loaded up the correct tool chain | 08:20 |
| RP | MarcWe: that error says otherwise, it looks like glibc is probably too old | 08:21 |
| *** Proffalken <Proffalken!uid388181@gateway/web/irccloud.com/x-ttjguoyjxjbzupmj> has quit IRC | 08:25 | |
| *** Bunio_FH <Bunio_FH!~bunio@84.red-213-0-2.staticip.rima-tde.net> has joined #yocto | 08:32 | |
| RP | nrossi: happen to be around? | 08:36 |
| yocti | New news from stackoverflow: Description of files that are in image files folder in Yocto project and the boot sequence of Yocto linux <https://stackoverflow.com/questions/57784490/description-of-files-that-are-in-image-files-folder-in-yocto-project-and-the-boo> | 08:39 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 08:42 | |
| *** kaspter <kaspter!~Instantbi@183.128.237.44> has quit IRC | 08:46 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 08:47 | |
| *** kaspter <kaspter!~Instantbi@183.128.237.44> has joined #yocto | 08:48 | |
| *** Bunio_FH <Bunio_FH!~bunio@84.red-213-0-2.staticip.rima-tde.net> has quit IRC | 08:54 | |
| *** Bunio_FH <Bunio_FH!~bunio@84.red-213-0-2.staticip.rima-tde.net> has joined #yocto | 08:55 | |
| nrossi | RP: i am now | 09:00 |
| RP | nrossi: I've run the series on the autobuilder and the gcc tests are going crazy. I've locally tracked it down to all the headers in gcc/include/*.h containing just the word "timestamp" | 09:01 |
| *** Bunio_FH <Bunio_FH!~bunio@84.red-213-0-2.staticip.rima-tde.net> has quit IRC | 09:02 | |
| RP | nrossi: I had to add python3-pexect and python3-ptysomething to the build to make it work. We also need to add inherit nopackages to glibc-testsuite.inc | 09:02 |
| RP | nrossi: those python3 bits and the dejagnu are missing from maintainers.inc too | 09:02 |
| RP | nrossi: any idea why "timestamp" would end up in those headers? | 09:03 |
| nrossi | RP: for the gcc ones I thought that might be due to builddir issues due to the multiple processes running with selftest but I had not looked into it. Though you say you have reproduced it on a local build without rm_work? | 09:03 |
| RP | nrossi: right, I don't use rm_work, nor does the autobuilder | 09:04 |
| RP | nrossi: its appeared on both | 09:04 |
| nrossi | RP: for the python-pexpect, i saw that when looking at the autobuilder logs. I completely forgot to check those packages. They are only there to make a FAIL -> UNSUPPORTED, needs gdb to actually run the tests. I am looking at that atm | 09:04 |
| nrossi | RP: I will wipe away my sstate and see if i can reproduce. | 09:05 |
| RP | nrossi: this sounds like criticism, its not meant as such btw :) It is great to see this so close! | 09:05 |
| nrossi | RP: dont worry, I have not taken your words in that way. Getting this stuff working is lots of moving pieces and I expected issues :) | 09:07 |
| RP | nrossi: I'm struggling with too many issues which we're struggling to debug right now :/ | 09:08 |
| nrossi | RP: one question I did have seeing the builds running, is did you actually want to have all machines running all usermode and system emu tests? | 09:08 |
| nrossi | RP: I have been following, sorry if i'm taking too much of your time away from more important tasks | 09:09 |
| RP | nrossi: this is important! :) | 09:09 |
| RP | nrossi: I'm just mentioning this in case I seem a little distracted | 09:09 |
| RP | nrossi: no, we probably don't want both usermode and system | 09:10 |
| RP | nrossi: I think that was my naive way of running things | 09:10 |
| nrossi | RP: probably need a "manual" tag or similar to put on some of the tests. And possibly change the selftest -t to a "tags of test must match those in list of supplied tags" | 09:11 |
| RP | nrossi: not quite decided how to integrate into the autobuilder yet, this was just a quick hack to start testing | 09:11 |
| nrossi | RP: no problems, I was mostly focused on getting everything working with the v2 series with less emphasis on autobuilder setup | 09:12 |
| RP | nrossi: right, and I wanted to get something run so we could find any issues with that piece. I'll ponder the integration a bit more but you're right, we need to select between the user and system modes | 09:13 |
| RP | nrossi: it may be enough just to tag them differently and run machine,toolchain-system or machine,toolchain-user or something that simple | 09:13 |
| nrossi | RP: possibly, I was just thinking about having the system emulated glibc tests running for x86-64 by default though | 09:14 |
| feilz | schulz: lettoThe2nd: one possible solution that could solve the issue we talked about is to modify file checking to take chksum of all files included, and compare that to the new version. Think it could work? | 09:16 |
| RP | nrossi: it gets tricky as you'd want to do something different on an arm host :/ | 09:16 |
| *** sbach <sbach!~sbach@45.77.212.219> has quit IRC | 09:17 | |
| *** sbach <sbach!~sbach@45.77.212.219> has joined #yocto | 09:18 | |
| *** anujm <anujm!~anujm@134.134.139.77> has quit IRC | 09:19 | |
| nrossi | RP: I will have a bit of a think about it, see if there is a decent solution | 09:19 |
| RP | nrossi: ok. We do have a bit of time pressure now to get something ready for 3.0 even if its not perfect | 09:20 |
| nrossi | RP: of course, i meant think as in whilst sorting out some of the current issues :) | 09:21 |
| RP | nrossi: fair enough :) | 09:21 |
| nrossi | RP: also should I put the maintainers as those that already mantain said recipes, e.g. binutils, glibc? | 09:21 |
| RP | nrossi: yes, I think that is khem | 09:22 |
| qschulz | RP: I didn't know about those. Thanks :) | 09:22 |
| nrossi | RP: and for dejagnu who should I put? it is not a hard recipe to maintain so I am not against putting my name if nessecary | 09:22 |
| RP | nrossi: the python ones are trickier but even better if we don't need them | 09:22 |
| RP | nrossi: volunteers are very welcome to spread the load | 09:22 |
| nrossi | RP: if the gdb tests don't work anyways I think its probably just easier to drop them so they appear as "FAIL:" | 09:23 |
| qschulz | RP: well, the issue is that SRC_URI = "file://dir" does not add the files of this directory to the "This task depends on the checksums of files:" list. SRC_URI = "file://dir/*" as well. HOWEVER, SRC_URI = "file://dir/" does. | 09:23 |
| qschulz | feilz: ^ | 09:23 |
| qschulz | (well, both RP and feilz actually) | 09:23 |
| RP | qschulz: probably time to add a new selftest to the bitbake test suite and fix it... | 09:24 |
| RP | qschulz: it sounds a bit like a bug | 09:24 |
| feilz | i'm not a bitbake developer, started using bitbake about 2 months ago when i started at my current employer :) | 09:28 |
| qschulz | LetoThe2nd: see, there is a point in having people "misuse" Yocto, you get to find bugs :D | 09:29 |
| feilz | but glad that I could help the community :) | 09:29 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 09:29 | |
| qschulz | feilz: add everything in a subdir so that you can include SRC_URI = "file://subdir/" | 09:30 |
| feilz | and it does seem like the "misuse" of Yocto is a little more widespread, as I know at least 2 of the client companies that this company works for does the same setup | 09:30 |
| qschulz | also IIRC, we didn't see the issue when it was a simple * but a *.c for example | 09:30 |
| qschulz | feilz: don't forget the trailing slash | 09:31 |
| LetoThe2nd | qschulz: certainly! | 09:31 |
| RP | nrossi: I just reproduced the header thing again. cleansstate of gcc-cross-x86_64 and gcc-runtime | 09:31 |
| feilz | i'll give it a go. Let's see if this works as expected | 09:31 |
| RP | nrossi: inspected the headers in gcc-cross-x86-64's gcc stash builddir and they were fine. Build gcc-runtime, they're not | 09:31 |
| RP | nrossi: I'll dig a bit more | 09:32 |
| qschulz | feilz: my issue with Yocto is that the ramp up is long so it does not get much interest from people for which Yocto is the tool and not the goal. Also, it is pretty much possible to have something that works "good enough" you don't experience the issues before a long time (not writing in the sstate cache output dirs for example). Which results in people having bad Yocto layers "but it works" TM | 09:33 |
| feilz | yeah... I understand | 09:34 |
| LetoThe2nd | qschulz: s/"but it works"/"doesn't break enough for me to care"/ | 09:34 |
| RP | nrossi: gcc-cross-x86_64:do_install destroys the files | 09:35 |
| RP | nrossi: looks like a race where "make install" messes with the hardlinked files | 09:36 |
| qschulz | LetoThe2nd: the number of times I see people cleaning the whole build dir/sstate cache because there is an error in the build they don't understand/want to fix and a fuild rebuild/build fromsstate cache fix the issue. | 09:37 |
| nrossi | RP: but do_gcc_stash_builddir is supposed to be run before do_install :| | 09:37 |
| nrossi | RP: oh right, you mean onces the hardlinking is done but before the sstate part of the task? | 09:38 |
| yocti | New news from stackoverflow: GitLab CI Yocto Build - How to use SSTATE and DL_DIR <https://stackoverflow.com/questions/52095080/gitlab-ci-yocto-build-how-to-use-sstate-and-dl-dir> | 09:39 |
| kroon | qschulz, you should tell them to file bugs. I've not had any problems with reusing sstate-cache for ages | 09:41 |
| RP | nrossi: the hardlink is done before do_install, gcc messes up the hardlink | 09:42 |
| RP | nrossi: it will be this: Makefile:STAMP = echo timestamp > | 09:42 |
| feilz | @qschulz: tested out moving it into it's own directory, and when doing that make fails, due to no makefile found. | 09:42 |
| feilz | even though that makefile.am does exist in that folder. | 09:43 |
| qschulz | feilz: S = "${WORKDIR}/dir"? | 09:43 |
| feilz | oh | 09:43 |
| feilz | sec | 09:43 |
| *** yacar_ <yacar_!~yacar@80.215.168.65> has quit IRC | 09:44 | |
| RP | nrossi: the "move-if-change" stuff | 09:44 |
| nrossi | RP: ok, i'm not fully aware of how the sstate-inputdirs stuff works, but does it not store the content in sstate before the task is "complete"? or is the issue that the hardlinks are kept to populate the outputdirs immediately instead of from the sstate binary? | 09:44 |
| qschulz | kroon: my goal now is to get rid of as many warnings as possible so that we have a clean build. Then teach people to not ignore the warnings (except those I couldn't get rid of and explain why), either to report them or to fix them | 09:44 |
| qschulz | kroon: and in the end have them report anything that is not looking normal | 09:45 |
| kroon | qschulz, I apologize, I think I misread your sentence | 09:45 |
| qschulz | kroon: didn't see you misinterepreted it >< it matched both situations :D | 09:46 |
| kroon | qschulz, :-D | 09:46 |
| tprrt | The advise about the ccache.bbclass from the mega-manual, is this advice still valid on Warrior?" | 09:47 |
| qschulz | feilz: also... might be actually a good idea to have the code outside of the yocto layers and use externalsrc instead? | 09:47 |
| qschulz | if it's actually code, it's better to use externalsrc IMHO (if you can't/don't want to have it in a git repo) | 09:49 |
| qschulz | anything else, I find it okay to use in-layer files. but you know, IMO. I don't have extensive knowledge about best practices | 09:50 |
| feilz | qschulz: I do agree to that, but the project is too far in already to have them modify the project structure any longer. | 09:51 |
| feilz | I do agree with what you are saying, and the previous project I did in this company we had that. Was far easier to manage :) | 09:51 |
| feilz | but yeah, I'm getting forward, and that problem is long gone. Seems I still have other issues, but I'll work them out 1by1 :) | 09:52 |
| qschulz | feilz: :) | 09:53 |
| qschulz | RP: another issue with dirs in SRC_URI. If you have dir1/dir2/myfile and dir1/dir3/myfile (same hash for both). If you remove one, it does not recompile. | 09:54 |
| qschulz | if you have dir1/dir2/myfile and you add the same file to dir1/ for example. Does not retrigger the fetch | 09:54 |
| qschulz | my understanding of bitbake-dumpsig is that we store the name of the file and its hash and not the path to the file | 09:55 |
| qschulz | sorry, even worse, any file duplicated in SRC_URI, wherever it's from won't trigger a refetch. Again, my understanding of bitbake-dumpsig, happy to be told I'm wrong | 09:58 |
| *** griffinp <griffinp!griffinp@gateway/shell/linaro/x-otxlgrsgngkzwvxg> has joined #yocto | 10:00 | |
| RP | qschulz: I think you may be right. Could you file bug reports please so we don't lose the info and can investigate? | 10:01 |
| feilz | qschulz: hmm... actually I may have been wrong... doesn't seem like my issue got solved after all... running bitbake package-2-name passes just fine, and no issues anywhere. however bitbake package-1-name seems to still carry some extremely old version of package-2, that makes building of package-1 fail. | 10:03 |
| feilz | running cleanall in between doesn't seem to change anything | 10:05 |
| qschulz | feilz: how's the dependency on package-1 explicited in package-2? | 10:06 |
| feilz | DEPENDS = "package-1" | 10:07 |
| kroon | qschulz, SRC_URI = "file://dir" seems to work here.. | 10:10 |
| feilz | kroon: yeah, I noticed the same, and it seems to work for me as well. | 10:11 |
| *** User_ <User_!~learningc@mti-37-145.tm.net.my> has quit IRC | 10:12 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 10:13 | |
| kroon | qschulz, cleansstate for recipe, rebuild recipe, check with bitbake-dumpsigs | 10:14 |
| kroon | qschulz, SRC_URI = "file://dir/*" does not work, but not sure if that is a bug | 10:15 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 10:16 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 10:19 | |
| kroon | qschulz, found https://patchwork.openembedded.org/patch/8443/ which has some information | 10:22 |
| RP | nrossi: http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=5c514650478e5590bccdf4bba5d47385f092947f | 10:24 |
| nrossi | RP: makes sense, I did not realize that the sstate -> sysroot-components also used hardlinks as an optimization | 10:26 |
| nrossi | RP: even the sysroot-components -> builddir extraction might be problematic | 10:27 |
| RP | nrossi: we use a lot of hardlinks although most of our edit scripts do know to break them | 10:28 |
| RP | nrossi: queued http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=e2de3b769020f58d443139d65d58f877b7fd8a31 as well | 10:30 |
| RP | nrossi: also, we may need to think about the exit code of the toolchain tests. "fail" isn't going to help the autobuilder | 10:31 |
| RP | nrossi: I think we mark ptest as exepected fail or something :/ | 10:31 |
| nrossi | RP: yer, also the logging of the failed tests is not partically helpful when 150000 of them fail ;) | 10:31 |
| RP | nrossi: I'll rerun with those two fixes and see how that looks | 10:33 |
| *** learningc <learningc!~learningc@121.122.92.156> has joined #yocto | 10:36 | |
| RP | nrossi: output looks much better locally now! | 10:37 |
| yocti | New news from stackoverflow: How should the sstate-cache directory be deleted in Yocto? <https://stackoverflow.com/questions/45341760/how-should-the-sstate-cache-directory-be-deleted-in-yocto> | 10:39 |
| qschulz | kroon: define "SRC_URI = "file://dir" seems to work here.." ? | 10:43 |
| __angelo | can i build another recipe form a function added by addtask ? | 10:45 |
| nrossi | RP: ok cool. For the pexpect/gdb stuff, the tests do pass with gdb on target. But it requires configuring gdb with python enabled which is not default in oe. So ignoring the tests would probably be fine. Any opinions? | 10:45 |
| RP | nrossi: enabling python for target gdb probably isn't that bad of an idea | 10:46 |
| nrossi | RP: by default or just in the glibc test config? | 10:46 |
| nrossi | RP: glibc selftest* | 10:46 |
| RP | nrossi: maybe by default? | 10:47 |
| RP | rburton: any opinion ? | 10:47 |
| qschulz | __angelo: first, what are you trying to do? It seems wrong at first sight. | 10:48 |
| __angelo | qschulz, i am trying to have an initramfs image together with a rootfs image | 10:49 |
| __angelo | *build together | 10:49 |
| feilz | __angelo: I think the solution you are looking for is 'require otherRecipe' | 10:50 |
| feilz | not inside an addtask, but just inside the image recipe | 10:50 |
| qschulz | qschulz: we talked about it right? it didn't work what I suggested? | 10:51 |
| __angelo | feilz, thanks, but at least the only "require" is not triggering the image to build | 10:52 |
| __angelo | qschulz, no didn't worked | 10:52 |
| feilz | ahh, that's right | 10:54 |
| feilz | require adds everything from that other file into the location where you have require | 10:54 |
| feilz | but doesnt run it | 10:54 |
| *** learningc <learningc!~learningc@121.122.92.156> has quit IRC | 10:55 | |
| feilz | hence you have to make a call somewhere that activates the build sequence for the other image | 10:55 |
| kroon | qschulz, bitbake recipe, touch new-file-under-dir, bitbake recipe again, bitbake-dumpsigs says fetch depends on newly touched file | 10:55 |
| feilz | or solve it some other way | 10:55 |
| *** learningc <learningc!~learningc@121.122.92.156> has joined #yocto | 10:55 | |
| rburton | nrossi RP: struggling to have a strong opinion. the tests should definitely skip if python isn't enabled. if we're doing special builds for the gcc tests then its trivial enough to turn py on in that setup. | 10:58 |
| rburton | (skipping if py isn't present should be an upstreamable change) | 10:58 |
| rburton | RP: are we dropping gcc8.3 from master? | 10:59 |
| RP | rburton: very tempted to, nobody's objected yet | 11:00 |
| *** yacar_ <yacar_!~yacar@80.215.168.65> has joined #yocto | 11:03 | |
| nrossi | rburton: currently the tests fail if python or pexpect is not available, but mark unsupported if gdb is not present or if its missing python support in gdb. So its a query as to whether the addition of python-pexpect in oe-core and having to configure gdb with python is worth the test result. | 11:18 |
| *** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has quit IRC | 11:19 | |
| nrossi | RP: also, should I make these various changes as additional patches or v3 of the previous series? | 11:20 |
| *** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has joined #yocto | 11:20 | |
| *** jofr <jofr!~jofr@193.182.166.3> has quit IRC | 11:23 | |
| *** jofr <jofr!~jofr@193.182.166.3> has joined #yocto | 11:25 | |
| *** mads_andreasen <mads_andreasen!sid294408@gateway/web/irccloud.com/x-ecxvnxxjykkaoejc> has joined #yocto | 11:29 | |
| iceaway | After trying to solve my wic issue, i read on the internet that in order to use the ${IMAGE_ROOTFS} variable in the kickstarter file, it may need to end in .wks.in. If I rename my file to .wks.in, wic can no longer find it as an image type. | 11:30 |
| iceaway | i.e. with wic list images | 11:30 |
| rburton | nrossi: i'd be tempted to say lets not do that *now* but after the rest is merged. | 11:32 |
| nrossi | rburton: as in don't bring in the gdb/python-pexpect? and let the (its only 6 tests) fail | 11:35 |
| rburton | right | 11:35 |
| JaMa | RP: this fixes the issue with PRserv for me, hopefully doesn't break HashServe https://github.com/shr-distribution/bitbake/commit/57e41b66f5b28067f09973b028542f53c9d37712 | 11:38 |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:39 | |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 11:40 | |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:41 | |
| *** florian_kc is now known as florian | 11:42 | |
| RP | JaMa: that doesn't surprise me but not sure its the right fix | 11:58 |
| RP | nrossi: maybe additional patches at this point? | 11:59 |
| RP | nrossi: I can always squash | 11:59 |
| nrossi | RP: ok, looks like the gcc/includes/* is not the only directory touched by stamping | 11:59 |
| RP | nrossi: I saw the cs-*.h, s-* and stmp-* files but only the include ones seemed to change | 12:00 |
| *** mads_andreasen <mads_andreasen!sid294408@gateway/web/irccloud.com/x-ecxvnxxjykkaoejc> has quit IRC | 12:01 | |
| nrossi | RP: how can i tell what commit of oe-core the autobuilder is running against? | 12:01 |
| RP | nrossi: the build properties should show you, or look at the poky commit and it will show the oe-core hash | 12:02 |
| JaMa | RP: I'm not sure as well :/ | 12:03 |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 12:03 | |
| milloni | hi folks, i want to use selinux with a yocto build | 12:04 |
| milloni | it seems that yocto adds selinux labels on first boot | 12:04 |
| milloni | what do i do in a case where the filesystem is meant to be read-only? | 12:04 |
| *** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has quit IRC | 12:07 | |
| qschulz | kroon: ok, I'm building thud right now. so maybe this was fixed since then. ALSO, I've discovered this file://dir is actually a symlink to some other places (I hate it, but here it is atm). So maybe a corner case for symlinks... | 12:09 |
| erbo | iceaway: did you change WKS_FILE to point to the .wks.in file? | 12:18 |
| erbo | iceaway: hmm, I guess it should be listed under "wic list images" anyway though | 12:20 |
| iceaway | erbo: is that required? I thougt the .wks-file was found by name in the wic create <wic_image_name> -e <bitbake_image_name> | 12:25 |
| iceaway | I don't quite understand under which circumstances the WKS_FILE is required. Is it so that a wic image will be generated automatically with bitbake <image>? | 12:26 |
| erbo | I think so, if I have IMAGE_FSTYPES including "wic" for an image, and I do "bitbake that-image", then WKS_FILE need to point out the file to use. | 12:29 |
| iceaway | OKay, understood. Where would one put the WK_FILE? IN the distro/image .conf file? | 12:33 |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC | 12:35 | |
| *** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto | 12:36 | |
| *** anujm <anujm!~anujm@134.134.139.73> has joined #yocto | 12:37 | |
| nrossi | RP: do these changes look fine? https://github.com/nathanrossi/openembedded-core/compare/4fed8b1ca1a14ae3c88c30d0b1be09e7e49e0ca9...nrossi/gnu-test | 12:43 |
| nrossi | RP: also, im not sure what is causing the current failures with gcc tests on the autobuilder. Unfortunately I have not been able to reproduce the issues with do_install modifying hardlinks. I suspect it is a case of more of those files being modified | 12:44 |
| *** kroon_ <kroon_!~kroon@213.185.29.22> has joined #yocto | 12:47 | |
| *** kaspter <kaspter!~Instantbi@183.128.237.44> has quit IRC | 12:48 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 12:50 | |
| *** xtron <xtron!~xtron@110.93.212.98> has joined #yocto | 12:53 | |
| nrossi | RP: also i think i have a reasonable solution for the autobuilder config, qemu sys/usr execution. | 12:54 |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 12:55 | |
| nrossi | RP: gcc sys is tagged as machine and release, glibc sys is tagged as machine and qemu-slow. When running qemu* it is "selftest -t machine", when running qemux86-64 it is "selftest -t machine qemu-slow". When doing "release" testing it is always "selftest -t machine qemu-slow release". This means glibc tests are run with kvm, but otherwise not run unless release testing. | 12:56 |
| *** kroon_ <kroon_!~kroon@213.185.29.22> has quit IRC | 12:57 | |
| qschulz | kroon: ok, could reproduce with a symlink but not with dirs. So you're right SRC_URI = "file://dir" and SRC_URI = "file://dir/" work for dirs but not symlinks (only the later then). | 13:03 |
| *** feilz <feilz!~feil@212-50-143-116.co.dnainternet.fi> has quit IRC | 13:03 | |
| kroon | qschulz, ahh.. was just about to test on thud | 13:03 |
| erbo | iceaway: I guess WKS_FILE is usually set as part of machine configs | 13:04 |
| qschulz | kroon: now I'm interested by regex in SRC_URI, so going to test that :) | 13:05 |
| iceaway | erbo: Got it working. Apparantly using += on the IMAGE_FSTYPES variable did not work, I had to use _append. | 13:05 |
| qschulz | iceaway: bitbake -e and you can see who's setting IMAGE_FSTYPES and how | 13:06 |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 13:06 | |
| qschulz | I guess it was loosely set (?= or ??=) | 13:06 |
| qschulz | and when you use += you override those | 13:06 |
| qschulz | (IIRC) | 13:06 |
| xtron | how to add dependent layers with bitbake-layers add-layer <layer>? | 13:06 |
| kroon | qschulz, symlink - that was sneaky.. should definitely be a bug reported, either bitbake should handle it as expected or at least warn about it IMO | 13:07 |
| RP | nrossi: yes, they look good | 13:07 |
| RP | nrossi: how do we make the autobuilder do that though :/ Its to complex for it to handle :( | 13:08 |
| nrossi | RP: you mean for the "selftest" template? | 13:09 |
| yocti | New news from stackoverflow: Difference between devshell environment and bitbake task environment? <https://stackoverflow.com/questions/57788759/difference-between-devshell-environment-and-bitbake-task-environment> || Yocto change psplash image without rebuild the system <https://stackoverflow.com/questions/47769154/yocto-change-psplash-image-without-rebuild-the-system> | 13:10 |
| RP | nrossi: well, its currently in the arch-qemu template | 13:10 |
| RP | nrossi: obviously we can hardcode things into the autobuilder but we've managed to avoid much of that so far | 13:10 |
| RP | nrossi: it also needs to work with the older release branches | 13:10 |
| RP | nrossi: I also notice that resulttool is lumping sys and usr test results together | 13:11 |
| nrossi | RP: yes that was something I was going to ask, prefix/suffix them? | 13:12 |
| RP | nrossi: probably suffix then they'll sort next to each other | 13:12 |
| nrossi | RP: with the selftest args, are you suggesting that selftest itself should handle what is default? | 13:13 |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 13:13 | |
| RP | nrossi: I don't know what I'm suggesting. I just don't see how this release/qemu-slow tagging is going to get us to where we need to be | 13:14 |
| RP | nrossi: right now the tests would be triggered every build which is too often so we need to fix that. There is then the question of where in a full build they'd hook in | 13:15 |
| nrossi | RP: ok, but changing the autobuilder templates is undesirable? | 13:16 |
| iceaway | qschulz: bitbake -e is a life-saver :) | 13:16 |
| *** Proffalken__ <Proffalken__!~ec2-user@ec2-18-208-106-45.compute-1.amazonaws.com> has quit IRC | 13:17 | |
| RP | nrossi: no, we can change the templates | 13:17 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 13:18 | |
| nrossi | RP: for the sys/usr suffix. Should it suffix both or just usr (aka, gcc-user) | 13:20 |
| kroon | qschulz, if you wanna play around, I think its bitbake/lib/bb/checksum.py:get_checksums() that is the interesting one | 13:20 |
| RP | nrossi: just one, -user is probably fine | 13:21 |
| kroon | qschulz, see Bitbake commit 66dff37ebcd1dd14ebd6933d727df9cf0a641866 | 13:22 |
| *** anujm <anujm!~anujm@134.134.139.73> has quit IRC | 13:22 | |
| *** ricardocrudo <ricardocrudo!5387f440@i5387F440.versanet.de> has joined #yocto | 13:24 | |
| *** iceaway <iceaway!~pelle@37.233.78.69> has quit IRC | 13:25 | |
| ricardocrudo | I'm trying to update qt to version 5.12 (currently using 5.11) on my yocto project, but I'm having some trouble trying to find out how to do that. I don't see any tag or branch on the meta-qt5 repo. Anyone here perhaps can give me a hint on that? | 13:26 |
| qschulz | ricardocrudo: QT_MODULE_BRANCH in qt5-git? | 13:29 |
| qschulz | to be exact, QT_MODULE_BRANCH_PARAM but it is using QT_MODULE_BRANCH. | 13:32 |
| qschulz | bad news is that you'll have to have a bbappend for all qt recipes | 13:32 |
| qschulz | ricardocrudo: also, can't you just take the meta layer at the commit hash where they had qt 5.12? | 13:33 |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 13:34 | |
| qschulz | kroon: wow, big pandora box opened now | 13:37 |
| *** ricardocrudo <ricardocrudo!5387f440@i5387F440.versanet.de> has quit IRC | 13:37 | |
| qschulz | SRC_URI = "file://bar/*.txt" in recipes-foo/foo/foo.bb and then you have recipes-foo/foo/foo/bar/bar.txt recipes-foo/foo/foo/baz/baz.txt | 13:38 |
| qschulz | in WORKDIR: tmp/work/aarch64-poky-linux/foo/bar AND baz | 13:38 |
| *** sgw <sgw!sgw@nat/intel/x-scbjidavzahrvdgy> has joined #yocto | 13:38 | |
| kroon | qschulz, well.. not terrible | 13:39 |
| qschulz | uh? | 13:39 |
| RP | qschulz: some of that code is rather old :/ | 13:39 |
| kroon | qschulz, it includes baz.txt in the checksum by mistake. so you get unncesseray rebuilds, right ? | 13:40 |
| kroon | qschulz, still rebuilds if bar.txt is modified | 13:40 |
| qschulz | kroon: nope, not in the list of watched files | 13:40 |
| qschulz | so 1. it seems there is no support for regexp (at least `*`) in SRC_URI | 13:41 |
| qschulz | 2. why is it fetching baz as well? | 13:41 |
| *** ricardocrudo <ricardocrudo!5387f440@i5387F440.versanet.de> has joined #yocto | 13:41 | |
| kroon | qschulz, I thought you meant "bar AND baz" meant both was checksummed. So none of them are checksummed ? | 13:41 |
| RP | qschulz: it would be globbing, not regexp | 13:42 |
| qschulz | kroon: none of them are checksummed but both are fetched (visible in workdir) | 13:42 |
| ricardocrudo | Thanks (about qt5), that should do it | 13:42 |
| RP | qschulz: do they show up in unpack? file:// urls are odd in that we don't actually need to fetch them | 13:43 |
| *** zbooth <zbooth!cc4da337@204.77.163.55> has joined #yocto | 13:44 | |
| * kroon heads home | 13:46 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 13:46 | |
| qschulz | DEBUG: Searching for bar/*.txt in path: /media/qschulz/yocto/oe-dummy-project/recipes-foo/foo/foo/. | 13:54 |
| qschulz | NOTE: Unpacking /media/qschulz/yocto/oe-dummy-project/recipes-foo/foo/foo/. to /media/qschulz/build/tmp/work/aarch64-poky-linux/foo/1.0-r0/ | 13:54 |
| *** oz_rhett <oz_rhett!605fb46e@96-95-180-110-static.hfc.comcastbusiness.net> has joined #yocto | 13:54 | |
| qschulz | (from log.do_unpack) | 13:55 |
| *** LocutusOfBorg <LocutusOfBorg!LocutusOfB@ubuntu/member/locutusofborg> has quit IRC | 13:55 | |
| qschulz | RP: ^ | 13:55 |
| oz_rhett | Perhaps a simple question, but how can I remove all the old task log files ? Over time they accumulate and take a lot of disk space. Other than completely nuking my build directory tree, what other options are there ? I just don't need multiple (old) copies of every run.do_fetch.xxx, log.do_fetch.xxx, etc. wasting valuable disk space | 13:56 |
| RP | qschulz: right, I just wondered if the unpack sig had the file checksums rather than fetch | 13:56 |
| *** ricardocrudo <ricardocrudo!5387f440@i5387F440.versanet.de> has quit IRC | 13:57 | |
| qschulz | RP: nothing in sig for do_unpack | 13:59 |
| RP | qschulz: fair enough, just wondered | 13:59 |
| qschulz | sure np | 14:00 |
| qschulz | oh no sorry, it's worse /o\ bar and baz dirs are in a bar directory in workdir, it looks like this: WORKDIR/bar/{bar,baz}/{bar.txt,baz.txt} instead of the expected WORKDIR/bar/bar.txt | 14:05 |
| *** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has joined #yocto | 14:05 | |
| *** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC | 14:10 | |
| RP | qschulz: I think that is a legacy behaviour :/ | 14:10 |
| RP | qschulz: i.e. things rely on it | 14:11 |
| qschulz | RP: it does not look like it's from glob though, I quickly tested witha ptyhon3 interpreter and glob was working as expected | 14:13 |
| qschulz | RP: I'll try to ban the use of regular expression/glob in SRC_URI in our project then | 14:14 |
| nrossi | RP: going to send out these patches. Just checking again, I can respin them into the series if you would prefer? | 14:17 |
| RP | nrossi: it helps me just to stack them | 14:17 |
| RP | qschulz: It would help a lot to improve bitbake-selftest for this | 14:18 |
| nrossi | RP: ok, I will just send them as a stand alone series then :) | 14:19 |
| RP | nrossi: thanks | 14:19 |
| *** likewise <likewise!~leon@213.34.54.210> has quit IRC | 14:19 | |
| *** runde <runde!sid228344@gateway/web/irccloud.com/x-cteftqzspjumnuna> has quit IRC | 14:20 | |
| nrossi | RP: oh btw, you should drop the python-pexpect patch when you apply these. As it is no longer required | 14:20 |
| RP | nrossi: right, makes sense, thanks | 14:20 |
| *** runde <runde!sid228344@gateway/web/irccloud.com/x-yffivfkgootsppka> has joined #yocto | 14:20 | |
| RP | nrossi: realised binutils-cross-testsuite needs the nopackages fix to stop warnings too | 14:21 |
| nrossi | RP: want me to add that to this series for you? | 14:21 |
| *** yacar_ <yacar_!~yacar@80.215.168.65> has quit IRC | 14:22 | |
| RP | nrossi: its ok thanks, I have it locally | 14:22 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 14:23 | |
| nrossi | RP: np, series sent | 14:24 |
| RP | nrossi: added to -next, thanks! | 14:26 |
| oz_rhett | Does anyone have much experience with building recipes that use the Go language ? | 14:29 |
| oz_rhett | There doesn't seem to be a whole lot of documentation, just random web pages that I find using Google. | 14:29 |
| RP | ahrg, autobuilder is locked up on some kind of fetch nfs lock :( | 14:31 |
| nrossi | RP: anyways i managed to produce the "timestamp" issue locally, forcing install task after a clean run produced it, so I will see if i can look into the gcc failures that weren't fixed after your link breaking change. However its past midnight so I am off shortly | 14:32 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC | 14:32 | |
| RP | nrossi: which gcc failures weren't fixed? | 14:33 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 14:33 | |
| nrossi | RP: a number of gcc tests and gcc-runtime tests were failing on this run https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/996 which should have your fix | 14:34 |
| RP | nrossi: ah, right. Maybe arch specific headers :/ | 14:36 |
| RP | nrossi: I'd not spotted that yet :/ | 14:36 |
| *** frsc <frsc!~frsc@200116b824140f00f7f86fd7ac845ea5.dip.versatel-1u1.de> has quit IRC | 14:37 | |
| *** frsc <frsc!~frsc@i4DF677E4.static.tripleplugandplay.com> has joined #yocto | 14:38 | |
| armpit | zeddii, did you see the email about perf on older kernels? | 14:56 |
| RP | zeddii: With stap I got as far as seeing that runtime/linux/access_process_vm.h:#if defined(STAPCONF_LINUX_SCHED_HEADERS) is part of the problem | 15:00 |
| RP | zeddii: it seems STAPCONF_LINUX_SCHED_HEADERS should be defined but isn't. No idea why | 15:00 |
| RP | zeddii: I can change the error if I bypass that | 15:01 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 15:22 | |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto | 15:24 | |
| JPEW | RP: Using the BASEHASH in place of the TASKHASH for hash equivalence seems like it would work... except that the BASEHASH doesn't seem to include files (e.g. SRC_URI?) | 15:28 |
| RP | JPEW: right, those are added in later. Not sure that matters though? | 15:33 |
| RP | JPEW: ah, I do see what you mean | 15:33 |
| JPEW | RP: Unless the actual value of SRC_URI is included in the basehash... in which case any change to it would cover the sources actually changing | 15:34 |
| JPEW | presumably | 15:34 |
| RP | JPEW: a key use case is change a patch with whitespace/comment, rebuild and get the hash equiv | 15:35 |
| RP | JPEW: if the local file checksums aren't in basehash, that doesn't work | 15:35 |
| JPEW | RP: Correct. You wouldn't want different source to be detected as equivalent (at least with the default hash detection) | 15:36 |
| RP | JPEW: I don't think detecting different source as equivalent is a problem, that is inevitable | 15:36 |
| JPEW | Right, as long as the change to source doesn't affect the output? | 15:37 |
| RP | JPEW: exactly | 15:37 |
| *** zbooth <zbooth!cc4da337@204.77.163.55> has quit IRC | 15:37 | |
| *** oz_rhett <oz_rhett!605fb46e@96-95-180-110-static.hfc.comcastbusiness.net> has quit IRC | 15:37 | |
| RP | JPEW: I think we're going to have to change the code | 15:41 |
| JPEW | RP: For the basehash or something else? | 15:42 |
| RP | JPEW: Looking at the code, add in a "nodephash" which hashequiv would work off | 15:43 |
| __angelo | hi sorry if i repeat the help request, but getting crazy. Manual, mailing list etc says that putting DEPENDS += "recipe_2" inside recipe_1 will trig recipe_1 to be processed. It doesn't work for me at all. | 15:43 |
| RP | __angelo: what does bitbake recipe_1 -e show? | 15:44 |
| __angelo | i am wondering if may be connected my recipe_1 is an initramfs recipe | 15:44 |
| __angelo | RP, thank, trying | 15:44 |
| RP | __angelo: yes, since images don't have do_configure steps which is where DEPENDS get added | 15:45 |
| RP | __angelo: try do_sometask[depends] += "recipe_2:do_someothertask" | 15:45 |
| __angelo | bitbake recipe_1 -e shows an infinite python code output | 15:46 |
| RP | __angelo: add | grep DEPENDS.*=, I doubt its infinite | 15:46 |
| __angelo | ok in bitbake recipe_1 -e i see there is image_2 in the DEPENDS list | 15:56 |
| __angelo | i try now the do_sometask stuff | 15:57 |
| __angelo | RP, super thanks. Finally i solved | 16:03 |
| __angelo | i used do_rootfs[depends] = "my-initramfs-image:do_image" | 16:04 |
| __angelo | i think i tried before with "my-initramfs-image:do_rootfs" that was not working since probaly initramfs does not call that task | 16:05 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC | 16:07 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:07 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 16:10 | |
| *** frsc <frsc!~frsc@i4DF677E4.static.tripleplugandplay.com> has quit IRC | 16:15 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 16:16 | |
| *** ms_k <ms_k!~mauro@host72-92-static.3-79-b.business.telecomitalia.it> has left #yocto | 16:17 | |
| RP | zeddii: some progress. When stap is testing its definitions its not finding headers like spaces.h on mips | 16:34 |
| RP | zeddii: It has -I./arch/mips/include/asm/mach-generic missing from its search path | 16:34 |
| RP | zeddii: the rabbit hole beckons... | 16:35 |
| zeddii | hmm. I was just poking at how it generates defines, etc. but not much progress on it. | 16:35 |
| zeddii | did we lose our cisco guy that actually knows stap ? :D | 16:35 |
| zeddii | I could solve the problem with git rm :D | 16:35 |
| RP | zeddii: no, we should ask him | 16:35 |
| RP | zeddii: any luck with kprobes? | 16:36 |
| zeddii | I've never had that dmesg show up. | 16:36 |
| RP | zeddii: I'm burning a ton of time on this which is going to cost hashequiv :/ | 16:36 |
| zeddii | buildrun.cxx is kind of nasty in systemtap. we should try and offload that, and I can look at krpobes to try and trigger it here. | 16:37 |
| RP | zeddii: "kind of"? | 16:37 |
| zeddii | IIRC that's an arch where systemtap runs, and that triggers it. | 16:37 |
| zeddii | (the kprobes one) | 16:37 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 16:37 | |
| RP | zeddii: I ended up on the systemtap channel asking for help | 16:37 |
| zeddii | ah. | 16:38 |
| RP | zeddii: systemtap on 32bit arm and mips is not tested | 16:38 |
| RP | zeddii: but they welcome patches when we fix it | 16:38 |
| zeddii | for the 32 bit arches. I was going to suggest we just mark them incompatible. | 16:39 |
| RP | zeddii: don't tempt me | 16:39 |
| zeddii | when the one 32 bit systemtap user crawls out of a hole, we can tell them the same thing. patches accepted :D | 16:39 |
| *** mckoan is now known as mckoan|away | 16:40 | |
| *** armpit <armpit!~armpit@2601:202:4180:c33:7901:9fbe:6d35:e8ad> has quit IRC | 16:51 | |
| *** User_ <User_!~learningc@121.122.92.156> has joined #yocto | 17:00 | |
| *** cferssy <cferssy!b36fd503@179.111.213.3> has joined #yocto | 17:01 | |
| *** learningc <learningc!~learningc@121.122.92.156> has quit IRC | 17:04 | |
| cferssy | Hello guys! I am beginner at yocto project and I would like to know how can I to put my apps and webpage at the linux image? I'm working with legato mangoh. | 17:04 |
| *** cferssy <cferssy!b36fd503@179.111.213.3> has left #yocto | 17:04 | |
| *** cferssy <cferssy!b36fd503@179.111.213.3> has joined #yocto | 17:12 | |
| cferssy | Hello guys! I am beginner at yocto project and I would like to know how can I to put my apps and webpage at the linux image? I'm working with legato mangoh. | 17:12 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 17:20 | |
| *** learningc <learningc!~learningc@121.122.92.156> has joined #yocto | 17:25 | |
| RP | zeddii: _KBUILD_CFLAGS := $(call flags,KBUILD_CFLAGS) is what the stap Makefile does | 17:27 |
| RP | zeddii: KBUILD_CFLAGS has our flag, _KBUILD_CFLAGS is empty | 17:27 |
| RP | zeddii: is there an easy way to check if the flags filter was removed from the kernel or something? | 17:28 |
| *** User_ <User_!~learningc@121.122.92.156> has quit IRC | 17:28 | |
| zeddii | sec. let me check on that. | 17:31 |
| RP | zeddii: https://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commitdiff;h=e5976ba0af9b828dcc76b3937b5a98fe9c0f6cb8 | 17:31 |
| *** learningc <learningc!~learningc@121.122.92.156> has quit IRC | 17:31 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 17:34 | |
| *** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has joined #yocto | 17:35 | |
| zeddii | RP: not currently seeing a difference between 5.0 and 5.2 in that area. looking more. | 17:42 |
| RP | zeddii: I can't even tell what its meant to do. Commenting it out and using raw KBUILD_CFLAGS does seem better | 17:43 |
| zeddii | I thought it was just me that got lost in that routine. I read all the way to the bottom to see *how* that generated Makefile was used (I assume it is a generated makfile, given the “call” syntax). | 17:45 |
| RP | zeddii: Yes, there is a horrendous make command you end up with. I should write down my "stap debugging tips" and send you a copy | 17:47 |
| *** nabokov <nabokov!~armand@67.218.223.154> has quit IRC | 17:48 | |
| zeddii | I still haven’t found where the ‘call’ make macro is defined. kernel or stap. | 17:51 |
| * zeddii tries a new strategy | 17:51 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 18:05 | |
| RP | zeddii: kernel commit cdd750bfb1f76fe9be8cfb53cbe77b2e811081ab | 18:34 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 18:35 | |
| RP | zeddii: https://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commitdiff;h=7cfac6c0f8ba16c9a64c6799dd76ef61ef529f09 fix in systemtap to test | 18:38 |
| zeddii | well crap. I was limiting my git history foo to a different set of Makefiles. but I wonder why my #@$@#$ git grep "flags =" in the 5.0 kernel missed that. | 18:41 |
| zeddii | I'm switching to qemuarm64 and the kprobes message then. IIRC it is showing on there. | 18:42 |
| * zeddii finds that email | 18:42 | |
| zeddii | yup. will use arm64 | 18:43 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 18:47 | |
| RP | zeddii: My day is feeling like that :/ | 18:52 |
| *** armpit <armpit!~armpit@c-71-204-143-8.hsd1.ca.comcast.net> has joined #yocto | 18:54 | |
| fullstop | qschulz: I found my problem, btw. It was because of something I had in local.conf.. DEBUG_PREFIX_MAP="" | 18:55 |
| fullstop | I added it because setting that to "" avoids adding some compiler flags which gcc7 does not have. | 18:55 |
| *** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has joined #yocto | 19:04 | |
| *** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has quit IRC | 19:08 | |
| *** cferssy <cferssy!b36fd503@179.111.213.3> has quit IRC | 19:09 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 20:08 | |
| RP | zeddii: confirmed that systemtap master fixes qemumips stap | 20:12 |
| zeddii | nice | 20:15 |
| *** dfrey <dfrey!~dfrey@172.103.152.101> has quit IRC | 20:17 | |
| JPEW | RP: so nodephash would be an intermediate hash between basehash and taskhash that includes the files? | 20:17 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC | 20:17 | |
| RP | JPEW: yes | 20:18 |
| *** vmeson <vmeson!~rmacleod@128.224.252.2> has quit IRC | 20:28 | |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC | 20:57 | |
| rsalveti | khem: the update to 9.2 dropped the GLIBC_DYNAMIC_LINKER changes for risc-v again :-) | 21:02 |
| rsalveti | third time now :-) | 21:02 |
| kergoth | man am i looking forward to being able to move to master once hashequiv is polished off. waiting for a complete rebuild from scratch for no damn reason | 21:02 |
| * kergoth taps foot | 21:02 | |
| *** vmeson <vmeson!~rmacleod@24-52-238-240.cable.teksavvy.com> has joined #yocto | 21:07 | |
| JPEW | kergoth: Want to beta test :) | 21:12 |
| JPEW | kergoth: It's not ready yet though | 21:12 |
| kergoth | yeah, i know. been poking at it occasionally. even as is it's nice, just not ready to switch production over | 21:12 |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 21:14 | |
| *** Willy-- <Willy--!~william@142.166.62.112> has joined #yocto | 21:18 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC | 21:20 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.158.162> has joined #yocto | 21:21 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 21:21 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.158.162> has quit IRC | 21:22 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 21:26 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC | 21:29 | |
| RP | zeddii: still one qemuarm stap issue left: https://autobuilder.yoctoproject.org/typhoon/#/builders/38/builds/998/steps/8/logs/step1c - much simpler though | 21:30 |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 21:38 | |
| RP | zeddii: FWIW a straight boot of the qemuarm64 kernel here shows the kprobes message in dmesg | 21:38 |
| RP | zeddii: don't need any of the tests to trigger it | 21:39 |
| RP | zeddii: https://lkml.org/lkml/2019/8/24/107 | 21:40 |
| RP | zeddii: a fix? ^^^ | 21:40 |
| zeddii | root@qemuarm64:/tmp# dmesg |grep -i kpr | 21:44 |
| zeddii | [ 2.892795] kprobes: failed to populate blacklist: -22 | 21:44 |
| zeddii | [ 2.893110] Please take care of using kprobes. | 21:44 |
| zeddii | yah, was just looking at that. | 21:44 |
| zeddii | I can easily test that commit to see if it does address it. | 21:45 |
| zeddii | RP: that fix is queued for 5.2 -stable, which means it is likely the one and I've grabbed it from there. | 21:48 |
| RP | zeddii: cool. It reads like the right thing | 21:48 |
| zeddii | rebuilding and booting with it applied now. | 21:49 |
| RP | zeddii: so that leaves us stap broken on qemuarm | 21:49 |
| RP | and mips having highmen issues | 21:49 |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 21:49 | |
| RP | zeddii: 512 pushes mips into highmem range which is likely where the issues come from | 21:49 |
| zeddii | ah yes. | 21:50 |
| zeddii | I'll start a 32 bit arm build once I get the kprobes fix built. and then mips on my 2nd builder. | 21:50 |
| RP | zeddii: cool. I think I need to take a break (32 bit arm building as there is a toolchain testsuite issues there too) | 21:51 |
| zeddii | I'll get myself setup for those last two. | 21:51 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 21:58 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 22:04 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 22:05 | |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 22:19 | |
| zeddii | RP: kprobes message is gone here. testing systemtap and will send a SRCREV update later. | 22:49 |
| RP | zeddii: sounds good, thanks! | 22:49 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto | 22:55 | |
| *** anujm <anujm!~anujm@134.134.139.73> has joined #yocto | 22:56 | |
| *** CoRfr_ <CoRfr_!~CoRfr_@carmd-fwm01.sierrawireless.com> has joined #yocto | 23:00 | |
| *** CoRfr_ is now known as CoRfr | 23:00 | |
| *** anujm <anujm!~anujm@134.134.139.73> has quit IRC | 23:01 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 23:04 | |
| *** anujm <anujm!~anujm@134.134.139.77> has joined #yocto | 23:05 | |
| *** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has quit IRC | 23:05 | |
| *** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has joined #yocto | 23:11 | |
| aehs29 | best advice on adding something back after it was in _remove? | 23:23 |
| *** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC | 23:50 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!