**** BEGIN LOGGING AT Tue Mar 24 02:59:57 2020 Mar 24 03:18:55 New news from stackoverflow: Need to use 'tuned' in yocto Mar 24 07:22:22 * kroon decides to try this "devtool" Mar 24 07:23:03 Is there devtool documentation on how to add create and add a patch to an existing recipe ? Mar 24 07:23:18 s/add create/create Mar 24 07:30:28 some day I will too :) Mar 24 07:32:03 devtool modify ; ; devtool update-recipe Mar 24 07:32:40 but it got a little confused with additional bbappends from other layers Mar 24 07:33:38 still, definetly better than my old workflow of devshell:ing and quilt:ing Mar 24 08:00:49 I'm devshell'ing and creating patches manually everywhere, though devshell may be tricky with multiple yocto versions.. Mar 24 08:13:46 derRichard: where are you setting your PREFERRED_PROVIDER? This can only be set in local.conf, distro.conf or machnie.conf because recipe data is local and an image recipe IS a recipe. Mar 24 08:15:28 qschulz: problem solved, after some sleep, i realized that yocto is smarter than i thought and cached the compile result of foo for both PREFERRED_PROVIDER variants :-) Mar 24 08:15:36 therefore i didn't see the rebuild Mar 24 08:16:01 sstate-cache "magic" :) Mar 24 08:16:17 but for real, where do you set PREFERRED_PROVIDER? Mar 24 08:17:01 in my local.conf Mar 24 08:18:04 at one point you might want to introduce your own distro.conf. (basically when you're starting to tell people to copy your local.conf, it's usually a good tell :D) Mar 24 08:20:16 qschulz: but then i change my disto from "myimage" to "myimage-debug" just to get a different PREFERRED_PROVIDER, doesn't that trigger a *full* rebuild of everything? Mar 24 08:20:19 *when Mar 24 08:21:57 it does, but once, then you have your sstate-cache Mar 24 08:23:51 that's not an option Mar 24 08:24:18 (since rebuild takes for ever) Mar 24 08:24:38 we have chomeium and other horros Mar 24 08:31:50 qschulz: hmm, it does not rebuild that much. good. :-) Mar 24 08:32:04 i thought it reuilds every single package Mar 24 08:35:20 derRichard: mmmm, I thought DISTRO was part of the hash of sstate-cache entries Mar 24 08:35:29 derRichard: which YP release are you using? Mar 24 08:38:52 qschulz: i'm on sumo Mar 24 08:39:03 qschulz: its not as simple as that Mar 24 08:39:26 qschulz: the configuration for a given recipe is included in its hash, not DISTRO specifically Mar 24 08:44:30 RP: mmmmm that is very interesting. so any distro actually benefits from the general sstate-cache Mar 24 08:44:56 I should have checked with bitbake-dumpsig before assuming :/ Mar 24 08:50:32 qschulz: yes. Its clever enough that even where distro_features are referenced, it will cache whether feature X is enabled or not instead of the full distro_features string Mar 24 08:50:53 where it it can anyway Mar 24 08:51:27 RP: that might actually be something I could leverage here. Many thanks for chiming in :) Mar 24 08:57:38 qschulz: its why you should access DISTRO_FEATURES with bb.uttils.contains() Mar 24 08:58:41 qschulz: I appreciate you helping out here :) Mar 24 08:59:47 RP: taking that into account, i think i really should try and do a session the sigs. Mar 24 08:59:59 hmm, why can't i set IMAGE_FEATURES in my disto.conf? Mar 24 09:00:27 derRichard: because its image specific? Mar 24 09:00:44 LetoThe2nd: yes! Mar 24 09:00:49 LetoThe2nd: I think people would greatly benefit from a multi part series on how to debug your recipe/whatever Yocto Mar 24 09:01:45 like, devtool, bitbake -e, bitbake-dumpsigs, -diffsigs, where the log.do_ are, that you can edit run.do_ and run them manually to debug, etc... Mar 24 09:01:56 derRichard: you can, but it makes only sense with IMAGE_FEATURES_append Mar 24 09:02:39 LetoThe2nd, derRichard: IMAGE_FEATURES_pn-my-image-recipe may work too Mar 24 09:02:51 RP: once my upcoming absence is passed i might look into that. Mar 24 09:03:00 RP: good point. Mar 24 09:03:09 LetoThe2nd: yes, do a session on sigs etc! Mar 24 09:03:21 LetoThe2nd: upcoming absence? Mar 24 09:03:32 thx. let me check that out Mar 24 09:09:53 hello. i build an image for zc702 xilinx board (custom serie of zedboard) and i added meta-xilinx-tools layers and necessary stuff for building fsbl and etc and the image worked by uart and i see the image booted and everything was ok but now i added ethe in board and connections are assured but i got an error below Mar 24 09:10:25 Invalid bus 0 (err=-19) Mar 24 09:13:15 the error i searched and related to qspi i know this problem may not ordinary and if you faced that plz help me :) Mar 24 09:13:50 mamadeus: If it's not build related, I'm afraid you should contact the kernel community for you board (or your vendor). It's unlikely yocto has some responsibility in this error Mar 24 09:14:31 mamadeus: FWIW, -19 is -ENODEV Mar 24 09:20:07 New news from stackoverflow: yocto bitbake core-image-sato Mar 24 09:28:53 Hello qschulz, sorry to ping to ping you directly but I have read your article on u-boot secure-boot and I would like to know if this feature is avaible inside Yocto ? Thx :) Mar 24 09:29:32 Ninic0c0: Mar 24 09:30:08 qschulz :P Mar 24 09:30:30 Ninic0c0: I honestly don't know. I don't know if and how the signing is implemented for U-Boot recipe. Mar 24 09:31:24 qschulz Ok no problem i was sure that the name on diapo and the chat :P I will take a look :) Mar 24 09:31:25 Ninic0c0: I also know that if you want the whole chain, it's going to require a bit of fiddling. See my slide on issues with YP. Mar 24 09:31:40 especially the dm-verity part Mar 24 09:31:48 it's being discussed recently on the mailing list though Mar 24 09:32:41 look for threads started by Bartosz Golaszewski Mar 24 09:33:00 i think there are three (two RFC implementations and one global question iirc) Mar 24 09:33:04 all this mont Mar 24 09:33:06 h Mar 24 09:34:04 he's working at baylibre, a consulting company, iirc. so if you're looking for some help under contract, that's a possibility (other companies as well, not linking them specifically) Mar 24 09:35:23 Not sure to understand but on my side I have a compressed rootfs, so if use the key to encrypt the u-boot config (kern+dtb+rootf) sould be enough and no need to use dm-verity part. I will check the mailing list thx Mar 24 09:36:21 thank u qschulz Mar 24 09:36:48 Ninic0c0: rootfs is an initramfs? Mar 24 09:36:56 no persistent data? Mar 24 09:38:24 mamadeus: when contacting communities, please be a bit more specific. What are you trying to do, what have you done so far, what is the issue you're encountering. When it's kernel specific, try to include a few lines after and before the message you think is the issue, and you might need to send a full boot log at one point, sometimes the error lies ahead of yours (in kernel dev, the rule is, fix the first Mar 24 09:38:30 issue that appears in the bootlog) Mar 24 09:39:15 qschulz no persistent data :) Mar 24 09:40:34 Ninic0c0: if the rootfs isn't too big or if your boot time isn't important, yes, that seems like a good solution Mar 24 09:40:57 Ninic0c0: so just figure out the signing process :) Mar 24 09:41:13 hint: kernel-fitimage.bbclass I think is a good place to have a look Mar 24 09:41:41 I have already follow your slides and all works like a charm. Now I have to integrate that inside my Yocto conf :) Mar 24 09:42:11 maybe you even want an embedded initramfs (in the kernel) and that might solve some circular dependency that could happen in Yocto (don't remember exactly when/how it happens) Mar 24 09:42:19 qschulz In fact I have already made one by myself because I didn't find this one before :S Mar 24 09:42:56 Ninic0c0: take the upstream one if you can, less maintenance :) Mar 24 09:42:59 As I have already a class to build a FIT image should be simple to add an other classe no ? Mar 24 09:43:21 just replace it, you most likely don't need yours Mar 24 09:43:45 Replace my FIT classe with what ? Mar 24 09:45:08 kernel-fitimage? Mar 24 09:46:25 qschulz after taking a look inside kernel-fitimage I will keep mine, juste because I have to integrate some bitstream and firmwares :S Mar 24 09:47:46 qschulz I will follow your advice inside slides "wrote a new image and class to work around this issue Mar 24 09:48:27 qschulz As I don't want the kernel inside the rootfs sould be okay. I keep in touch Thx for your support (again :) ) Mar 24 09:48:50 Ninic0c0: I was talking about the opposite, the initramfs inside the kernel. Mar 24 09:49:56 Ninic0c0: don't forget to set the correct dependencies on the recipe creating your fitimage. Most likely you're taking files from the deploy dir? then you need to add do_create_fitimage[depends] += "bitstreamrecipe:do_deploy" or something Mar 24 09:50:07 otherwise you might encounter some race :) Mar 24 09:50:56 qschulz haha i have spend 2 days to find that :S I should before for the next time ^^ Mar 24 09:54:11 Ninic0c0: hehe, been there done that :) Mar 24 09:54:56 qschulz is it better to Update dependencies during parsing, i mean inside anonymous python function ? Mar 24 09:55:31 Ninic0c0: I don't get your question, what are you trying to do and how? Mar 24 09:56:17 specifically how do you plan to detect the dependencies yourself? Mar 24 09:58:15 Hi, i always get "nothing provides ..." error Mar 24 09:59:08 I created a meta layer, which is found by yocto. Then i add a directory and inside that one application.bb file. But if i try bitbake application i get the nothing provides error Mar 24 10:00:36 GeneralS1upid: what's the path to your application.bb? Mar 24 10:00:52 GeneralS1upid: theres a high chance that you messed up the meta-*/recipes-*/*/*.bb pattern. Mar 24 10:01:26 LetoThe2nd: i tried it in the console and it displayed my bb file Mar 24 10:01:33 ? Mar 24 10:01:55 path is meta-.../recipes-application/application/application.bb Mar 24 10:02:11 LetoThe2nd: i copied that pattern out of the conf file and tried it with ls Mar 24 10:02:13 GeneralS1upid: what did you try in the console? Mar 24 10:02:27 ls *meta-...... Mar 24 10:02:38 GeneralS1upid: are you sure your layer is found by yocto? Mar 24 10:02:41 how do you know Mar 24 10:02:55 bitbake-layers shw Mar 24 10:02:59 show-layers Mar 24 10:03:00 GeneralS1upid: bitbake-layers show-recipes Mar 24 10:04:40 ok, i guess i did something stupid :) the recipe had an underscore in its name Mar 24 10:04:48 GeneralS1upid: hehe, classic :) Mar 24 10:04:50 and that will be parsed as version :) Mar 24 10:04:57 Thanks for your help Mar 24 10:05:09 no underscore, no weird char, no uppercase letter and you're good Mar 24 10:06:03 i think i learned this lesson ;) Mar 24 10:06:54 GeneralS1upid: you're lucky, because the uppercase letter issue is not fun to debug :) Mar 24 10:07:21 Whats the issue with uppercases? Mar 24 10:10:37 I don't remember, was ages ago for a recipe. But for the name of machines, it breaks the override mechanism: i.e., SRC_URI_Mymachine does not work iirc. SRC_URI_append_Mymachine does though, but SRC_URI_Mymachine_append does not :) Mar 24 10:10:47 qschulz Okay i'm going to tell you all the story :) I have made a classe to create fitimage, my image recipe inherit this class. I have set some variable list to set what i want inside the FIT ( kern, dtb, firmware, bitstream ...) i have use d.getVar to parse variables and call d.setVar("DEPENDS", depends) inside python __anonymous() Mar 24 10:23:10 ndec: too bad you've been cancelled :( Mar 24 10:27:45 Postponed, not cancelled.. not sure what’s going on.. hopefully it will be rescheduled soon! Mar 24 10:28:30 ndec: yeah got that. Mar 24 10:29:05 ndec: i actually found it one of the upsides of the current situation that i can "join" ltd without travel this year. Mar 24 10:30:06 Hehe... Mar 24 10:35:00 Ninic0c0: and I guess this variable list is set in the machine conf file? Have you made your fitimage recipe machine specific? Mar 24 10:35:32 that does not look too bad to me so admitedly it feels hackish Mar 24 10:36:37 but what you're asking should be possible, something like setVarFlags for the recipe Mar 24 10:36:42 s/recipe/task/ Mar 24 10:37:38 Yes each machine provide the list of what we want to put inside the FIT, i will add the secure part today on the same pattern because that seems do the job. After that i will probably paste.bin if you want to take a look :P Mar 24 10:40:07 Ninic0c0: don't forget PACKAGE_ARCH = ${MACHINE_ARCH} Mar 24 10:40:44 Ninic0c0: d.appendVarFlag('do_create_fitimage', 'depends', deps) from a quick grep in pocky Mar 24 10:42:15 PACKAGE_ARCH = ${MACHINE_ARCH} inside a class file ? Mar 24 10:42:37 d.appendVarFlag('do_create_fitimage', 'depends', deps) sounds interesting I have to double check that :) Mar 24 10:45:21 Ninic0c0: a class is nothing in itself. It's meant to be inherited. When a recipe inherits a class, IIUC its content is basically inserted in place in the recipe (more or less, there's some variable expanding done). Mar 24 10:45:35 your class is inherited by which recipe? Mar 24 10:55:51 qschulz by the image recipe Mar 24 10:56:27 Ninic0c0: why does the image DEPENDS on package recipes? Mar 24 10:57:50 the big issue with what you're trying to do is you're making an image machine specific and my gut feeling tells me that's not the best idea Mar 24 11:02:03 Are you sure ? Inside my image recipe I have just --- require recipes-core/images/core-image-minimal.bb ---- and inherit fitimage Mar 24 11:03:36 quick question guys: how do I set the image hostname to depend on the machine name? Mar 24 11:04:08 so, from the append file, hostname="myhostname" sets the hostnbame to a static value Mar 24 11:04:20 but if I want to make it dynamic? Mar 24 11:04:31 cjdc2: ${MACHINE}? Mar 24 11:04:32 cjdc2 maybe a bbappend on base-file recipe Mar 24 11:05:25 Ninic0c0: why do you have DEPENDS in your fitimage class? Mar 24 11:05:49 qschulz so, hostname="myhostname-${MACHINE}" Mar 24 11:06:31 cjdc2: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#usingpoky-extend-customimage-image-name Mar 24 11:07:05 yes that's exactly where I am Mar 24 11:07:14 so the default should be the machine already Mar 24 11:07:46 just want ot be sure that the variable MACHINE is available from the append file Mar 24 11:07:54 y but I need a prefix Mar 24 11:08:57 then follow whatever they say there and use ${MACHINE} Mar 24 11:09:17 ok trying now , ty Mar 24 11:20:35 New news from stackoverflow: how to reduce packages size for reducing rootfs size in yocto? [closed] Mar 24 11:25:02 when i write this into my distro.conf: IMAGE_FEATURES_append = " tools-debug" Mar 24 11:25:03 i get: Mar 24 11:25:09 'tools-debug' in IMAGE_FEATURES is not a valid image feature Mar 24 11:25:24 but tools-debug is an image feature, i'm confused Mar 24 11:26:08 ahh, stupid me Mar 24 11:26:21 there is a different image which does not inherit core-image Mar 24 11:26:25 hm Mar 24 11:34:46 hi, im using this linter here for bitbake https://github.com/priv-kweihmann/oelint-adv . its pretty good, but there's been a rule that has recently been added that me and my work colleagues are questioning. `oelint.vars.appendop - Use '_append' instead of ' += '`, for what seems to be all cases, even when you intend to have a space, would there be Mar 24 11:34:46 a valid reason for this, or could this be a bug or personal preference? Mar 24 11:39:06 FrazerClews: _append and += are different things Mar 24 11:39:38 += can override ?= ??= if it's parsed before the latter("s") Mar 24 11:40:05 _append does not and is expanded after all the += =+ .= =. ?= ??= = are expanded Mar 24 11:40:57 So there are usecases for each, but I feel like _append is usually safer (if one does not forget when to add the space and where) Mar 24 11:42:57 thanks for the info qschulz Mar 24 12:16:15 So another problem. i use rm and other commands in the Makefile but yocto says "command not found" i Mar 24 12:18:37 GeneralS1upid: check your CC or CXX in your makefile, you should have a bit more than gcc in there (--sysroot), I think that's how the staging_bindir_native is passed to recipes but am not sure Mar 24 12:20:46 qschulz: is there an environment variable which is set by yocto? Mar 24 12:21:08 because right now the Makefile is using the path to the yocto SDK... Mar 24 12:26:30 GeneralS1upid: yes... CC and CXX variables and CFLAFS and CXXFLAGS and LDFLAGS and plenty other things :) Mar 24 12:27:01 you should set all those variables (and more?) in your makefile with ?= at best, no :=, no = Mar 24 12:28:15 qschulz: there is one makefile which calls other makefiles :) Mar 24 12:28:37 This is an important from an older project and it starts to sound like a lot of work Mar 24 12:28:49 GeneralS1upid: patch the sources Mar 24 12:29:58 or use EXTRA_OEMAKE = "-e 'CC=${CC}'" and other variables. I think that's how you force the use of env variables over ones defined in makefiles, but that might apply only to the first makefile) Mar 24 12:30:16 badly written code always takes time to adjust :) Mar 24 12:30:42 yes that makefiles should be rewritten or at least modified... Mar 24 12:30:59 kanavin_home: gtk3 has GSETTINGS_PACKAGE_class-native = "" via you, should that just be in the gsettings class do you think? Mar 24 12:31:36 GeneralS1upid: has anyone said not to use bare makefiles yet? :) Mar 24 12:31:51 RP: Sorry, haven't had time to analyse and comment on the AUTOREV problem. I'll see if I can get to it today... Mar 24 13:20:21 Whats the env variable for the HOST CC ? Mar 24 13:20:59 New news from stackoverflow: can't open "/dev/mcelog" No such file or directory Mar 24 13:26:14 GeneralS1upid: BUILD_CC ? Mar 24 13:27:41 GeneralS1upid: if you have more or less an idea where the file should be, you can always look for it in bitbake -e myrecipe and see where it is put. Sometimes a few variables are defined in WORKDIR/temp/run.do_ Mar 24 14:56:53 YPTM: Jan-Simon on. Mar 24 14:59:04 YPTM: Scott Murray on Mar 24 15:05:58 YPTM: Denys is on Mar 24 15:12:05 YPTM: Alejandro joiner Mar 24 15:12:11 joined* Mar 24 15:19:52 RP: You mentioned that there was a bug on centos7 builds. Do you have the number or mail, I don't see it. Mar 24 15:20:48 jpuhlman: its the fact it doesn't warn you to install buildtools Mar 24 15:21:20 jpuhlman: http://bugzilla.yoctoproject.org/show_bug.cgi?id=13832 Mar 24 15:21:23 Bug 13832: normal, High, 3.1 M4, timothy.t.orling, ACCEPTED , Add script to setup buildtools-extended-tarball Mar 24 15:22:39 Saur: I will probably merge the revert as the change wasn't correct. We do need better test coverage Mar 24 15:23:09 RP: Yeah, I understand. Seems your use case is different from mine... Mar 24 15:23:34 Hi, I recently send some patches to oe-core, but I had to superseed them with v2. I guess something went wrong, only 1/5 was superseeded, is there anything I can do to fix this ? https://patchwork.openembedded.org/project/oe-core/patches/?submitter=13375&state=* Mar 24 15:24:15 RP: Would a new choice for BB_SRCREV_POLICY be an option (if I can come up with a suitable name for it)? Mar 24 15:24:47 Saur: isn't your usecase already there as clear ? Mar 24 15:24:51 RP: Ah okay. Thank you. Mar 24 15:25:21 Saur: sorry if I'm not making sense. The tinfoil dataconnector change is getting to me Mar 24 15:26:24 I'm curious about how the new policy would differ from clear too Mar 24 15:28:51 RP: No. We configure BB_SRCREV_POLICY = "cache" since most of our own recipes are configured to use SRCREV = "", but we do not want it to do git ls-remote every time we build since our tags are not supposed to move around. We also do not allow ${AUTOREV} to be used in the recipes that are part of our platform. However, for individual developers and development teams, some want to use ${AUTOREV} while they are working on some new Mar 24 15:28:51 feature. Mar 24 15:30:24 RP: Typically they have started with setting SRCREV = "" and either found it doesn't work as they expect, or I have told them to use ${AUTOREV} instead. That was until I realized that didn't work any more after we changed BB_SRCREV_POLICY. Mar 24 15:30:59 Saur: I see. That "cache" was simply never designed to avoid the ls-remote calls like that Mar 24 15:31:28 kergoth: I assume it would match what cache does now, with my fix, i.e., as before but ${AUTOREV} can be used and will update as if BB_SRCREV_POLICY = "clear". Mar 24 15:31:32 Saur: I think I'm going to require more tests Mar 24 15:32:28 sorry for bursting in, but I'm trying to get my head around features and packages. Is this line of thought right? : got a project -> added the meta-virtualization layer -> added that layer to bblayers.conf and appended virtualization to DISTRO_FEATURES -> build Mar 24 15:33:18 now, nothing is installed, so if I just want docker, I: append docker to IMAGE_INSTALL Mar 24 15:33:55 cjdc2: basically right, only addition is: please start with a custom image instead of cramming everything into local.conf. Mar 24 15:34:11 hmm, oe-selftest -r tinfoil fails but only on debian10 Mar 24 15:34:49 not sure I want to know why Mar 24 15:35:31 LetoThe2nd what if Docker has a dependency? will the recipe resolve it automatically? . You say "evertything" into a custom image...but is that really worth just for one appended package? Mar 24 15:36:03 cjdc2: then, yes, yes. Mar 24 15:36:19 (answers in order of your questions) Mar 24 15:36:33 :p thanks Mar 24 15:38:04 I have a two-file cpython extension module; one c file of hello-world complexity, and a setup.py file. On my PC, I would run "python3 setup.py build_ext --inplace" to build this module and make it importable by a python interpreter. Mar 24 15:38:04 RP: http://sprunge.us/qFUJwG these are ptest fails I see regulaly on x86_64/glibc Mar 24 15:38:11 hi, need to install some files in ${D}/usr/ but do_install is triggering some quality issues Mar 24 15:38:43 I would like to include this extension module in the embedded image that I'm building with bitbake. Mar 24 15:40:29 LetoThe2nd where in the docs are the instructions for these custom images usage? Mar 24 15:43:56 cjdc2: just copy over the image recipe that you would use into your own layer, rename it and thats it. an example is also in the live coding sessions. Mar 24 15:44:20 ok solved using FILES_${PN} += Mar 24 15:45:14 but then I'm pretty much forking from that repo and losing upstream updates Mar 24 15:45:16 I am having trouble putting together a recipe that builds my package. I used other python-package recipes as a starting point. I have inspected in my work directory. There is so much inheritance and redirection that I can't find the line of code that is actually calling "setup.py" for all the other python extension modules (although it must be getting called!) Mar 24 15:45:51 cjdc2: ? Mar 24 15:45:58 cjdc2: upstream updates to an image recipe? Mar 24 15:46:33 cjdc2: the image recipe defines what your specific usecase needs, there hopefully ain't no upstream for it besides yourself. Mar 24 15:46:34 LetoThe2nd maybe I'm confusing image recipe with recipe? Mar 24 15:46:44 maybe. Mar 24 15:47:06 have i already pointed out that watching the videos would really explain a lot of those things? Mar 24 15:48:52 Hi folks. I have a huge tarball which content will be used by multiple recipes. I would like it to *not* be extracted in every recipe workdir, but somehow shared among them to save space. Is it possible? Thank you. Mar 24 15:49:14 yes I already went over the bazillion lines of docs at https://www.yoctoproject.org/docs/3.0.2/dev-manual/dev-manual.html Mar 24 15:49:33 creating image recipes is not covered in detail there Mar 24 15:49:39 cjdc2: that's not even the biggest doc we have :) Mar 24 15:49:48 :p Mar 24 15:49:54 looking forward then Mar 24 15:50:20 google for "yocto mega manual" Mar 24 15:50:39 cjdc2: also, this is a manual, LetoThe2nd was talking about the Youtube/Twitch videos Mar 24 15:51:21 and I second what he suggested, there's a lot covered for beginners and it helps get through one's first step in using YP Mar 24 15:51:26 y also started watching them, finished the 1st one, but figured out the docs would be a better start Mar 24 15:51:53 sashko: i've seen this be done and i do *not* recommend it Mar 24 15:52:13 Hi, i still have some trouble with yocto and Makefiles. Mar 24 15:52:20 I get Mar 24 15:52:24 sashko: instead you should install that package as you would do normally and then specify it as a compike-time dependency for the other recipes Mar 24 15:52:43 "whoami" command not found. If i use full paths i will get undefined variable errors Mar 24 15:52:47 cjdc2: you could try the shared workdir setup that is used for gcc and the kernel source, look for do_shared_workdir in the reference manual Mar 24 15:53:43 Guest5299: "whoami" is not in HOSTTOOLS or HOSTTOOLS_NONFATAL. Mar 24 15:53:44 milloni: it's still duplicated in the sysroot, and all sources of a recipe don't actually make it to the sysroot.. Mar 24 15:54:17 qschulz: yes, is that a problem? Mar 24 15:54:33 milloni: could you please elaborate why on why it's not recommended? Mar 24 15:54:37 Guest5299: Why do you need "whoami" in the Makefile? Mar 24 15:54:53 milloni: "I would like it to *not* be extracted in every recipe workdir, but somehow shared among them to save space." Mar 24 15:55:07 Saur just for some useless informations. I did not write that but i will try in HOSTTOOLS Mar 24 15:55:08 qschulz: fair enough Mar 24 15:55:50 Guest5299: you know it's going to be root all the time right? Mar 24 15:56:04 (IIUC pseudo/fakeroot) Mar 24 15:56:10 sashko: perhaps there's a way to do this properly, the only way i saw this done is this: they pulled and extracted the source code using one tool (outside of yocto), and then pointed yocto to the path of the extracted source code Mar 24 15:56:23 and it caused a lot of problem Mar 24 15:56:31 it seems to me that mixing multiple tools is a bad idea Mar 24 15:56:37 qschulz no -.- i didnt know that Mar 24 15:56:47 qschulz: not if whoami is invoked during compile, then its the user doing the build Mar 24 15:56:49 if someone knows a proper way to do it, go for it Mar 24 15:56:54 The cpython module I'm trying to build into poky: https://pastebin.com/00prKHkn Mar 24 15:57:09 qschulz: which is why we don't put it in the hosttools, information leakage and reproducibility reasons Mar 24 15:57:10 I have a basic recipe to build it based on python3-dbus Mar 24 15:57:26 sashko, milloni, qschulz: Sharing it via a common recipe and the sysroot shouldmean it is copied to each recipe sysroot using hard links, so there should not be any duplication between the recipes. Mar 24 15:57:37 rburton: ok, when is this fakeroot/psuedo used then? correct assumption to say under fakeroot/pseudo it's root the user (i think that's the whole point of the tool right?) Mar 24 15:58:04 Saur: nice thanks! Mar 24 15:58:16 The only appropriate code was 'inherit distutils3-base' Mar 24 15:58:41 Plus a SRC_URI to point to the two files I need, setup.py and cfifo.c Mar 24 15:58:45 qschulz: pseudo is acctive during, e.g., do_install Mar 24 15:59:06 I can see these two files in the work directory. Mar 24 15:59:06 sashko: smurray highlighted the wrong person so cp again: you could try the shared workdir setup that is used for gcc and the kernel source, look for do_shared_workdir in the reference manual Mar 24 15:59:50 Saur: qschul: thank you for the suggestions; I will take a look. Mar 24 16:00:01 qschulz: as saur said, during install/package for most recipes. images are done entirely in pseudo. Mar 24 16:00:02 tmp/work/aarch64-poky-linux/python3-cfifo/0.0.1-r0/cfifo contains both setup.py and cfifo.c Mar 24 16:00:24 qschulz: oops, thanks Mar 24 16:00:26 rm into HOSTTOOLS does not fix it Mar 24 16:00:48 So I know that my recipe is pointing to them adequately. But I can't tell that setup.py is getting invoked. Mar 24 16:00:59 rm is already in hosttools Mar 24 16:01:02 Guest5299: ^ Mar 24 16:01:21 ok but then, why do i get rm: command not found? :/ Mar 24 16:01:25 Guest5299: how about you share the actual error and the actual makefile fragment? Mar 24 16:01:36 I added a print statement to it to print a 16-character unique token Mar 24 16:01:44 I do not see this token anywhere in the logs Mar 24 16:01:53 So it looks like it's not getting run. Mar 24 16:02:03 https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/python/python3-dbus_1.2.16.bb Mar 24 16:02:14 ecdhe: you can manually run WORKDIR/temp/run.do_ and add your debug statements there Mar 24 16:02:22 obviously ONLY for debugging purposes Mar 24 16:02:47 qschulz: If you are in a devshell... Mar 24 16:03:12 qschulz: do I just run it from bash, or do I need to invoke bitbake? Mar 24 16:03:39 Saur: I'm not using devshell? but admittedly might have always called it from the terminal where I sourced the poky init script Mar 24 16:03:58 rburton http://dpaste.com/26ZRPHH Mar 24 16:04:07 ecdhe: Run "bitbake -c devshell ", then you can run the run.do_* files to repeat what they did when bitbake ran the task origiinally. Mar 24 16:04:18 Guest5299: and the definition of RM? Mar 24 16:04:30 Saur: how come I never had to do that? Mar 24 16:04:50 (on thud if that matters) Mar 24 16:05:04 Guest5299: presumably this is closed source stuff yuo can't share Mar 24 16:05:06 rburton it is just Mar 24 16:05:07 rm Mar 24 16:05:09 Guest5299: basically rm is in $PATH Mar 24 16:05:15 but i have no idea where its defined Mar 24 16:05:24 so your makefile or recipe is dong something weird Mar 24 16:05:36 most likely -.- Mar 24 16:07:29 qschulz: The difference if you do not run it in a devshell is that you run the tasks as yourself, which makes a difference if you run, e.g., run.do_install Mar 24 16:07:59 rburton if i replace the $(RM) with plain rm it is still not working Mar 24 16:08:15 is the makefile poking at $PATH? Mar 24 16:09:09 yes it appends /usr/bin ... Mar 24 16:09:17 a bit ugly Mar 24 16:09:26 we need a collection box into which everybody having troubles with hand-crafted makefiles has to put at least 5€ Mar 24 16:09:57 LetoThe2nd: We'd be rich in no time... ;) Mar 24 16:10:22 i had a discussion with the guy who wrote that file. He told me thats much better then cmake Mar 24 16:10:28 Saur: thats why we need it. Mar 24 16:10:40 Guest5299: so we can bill that guy, because he knows $BETTER? Mar 24 16:10:44 I get a feeling that he likes 'dirty but worky' solutions Mar 24 16:10:55 of cause you can bill him :) Mar 24 16:11:15 everybody, i have written proof ^^^^^ Mar 24 16:11:18 invoice address, please. Mar 24 16:11:25 Guest5299: most people don't know shit about what they're saying (that includes me :) ). Don't believe them :) Mar 24 16:11:34 always triple check Mar 24 16:12:05 Saur: /o\ indeed. I never used it for anything else than configure or compile. thx! Mar 24 16:14:52 i believe a lot. But actually these makefiles call other makefiles... Its not really debugable Mar 24 16:15:34 Guest5299: rule of thumb is: whenever a makefile hardcodes something, it is buggy. Mar 24 16:15:37 no joke. without that stupid PATH its compiling. But i cant find my executable Mar 24 16:15:56 this whole thing is hardcoded Mar 24 16:16:02 Guest5299: as you've already said, it hardcodes an appendix to PATH, which gave you troubles. QED. Mar 24 16:16:41 we really need to change that way of coding . I dont like that Mar 24 16:18:00 Guest5299: and then you fall on some stupid SW which does not work if you compile it with anything else than -O0... SW are full of surprises :) Mar 24 16:18:33 i had these kind of trouble at my old job a lot. but that was more or less baremetal with good OCD Mar 24 16:25:15 ok now i need to define BUILDSPEC? So if i use write_rpm, do i still need to copy my files into the system root? or will yocto install that rpm ? Mar 24 16:25:33 I have been operating under the assumption that yocto project already contains recipes that know how to build cpython extensions and package them. Mar 24 16:26:00 But I am just about ready to give up on that and write my own do_compile, do_install Mar 24 16:26:15 Guest5299: no need to take care of packaging, just make sure you've got proper do_install and FILES_ Mar 24 16:26:46 gah, tinfoil issue is a race Mar 24 16:27:07 LetoThe2nd so i should delete that task ? Mar 24 16:27:09 Guest5299: everything will be installed automagically upon image creation, for the packages in the dependency tree formed by IMAGE_INSTALL Mar 24 16:27:34 Guest5299: unless you have very, very, *VERY* specific needs to manipulate the resulting rpm manually, delete it. Mar 24 16:28:21 just because i get this : ERROR: Function failed: BUILDSPEC Mar 24 16:29:29 Guest5299: *sigh* is your makefile trying to manually build an rpm, or what? Mar 24 16:29:53 Guest5299: in that case, please leave your desktop now and give that guy who knows $BETTER a good beating. Mar 24 16:30:06 no no. its 'just' creating one binary Mar 24 16:30:32 Guest5299: then what gave you the idea you need that task? Mar 24 16:30:58 hm i dont added that manually Mar 24 16:31:05 it was in automatical Mar 24 16:31:17 Guest5299: which task is failing? Have you overriden/appended/prepend to this task? if yes, what? in all cases, please send the whole line/log Mar 24 16:31:18 maybe because i use oe_runmake ? Mar 24 16:31:40 Guest5299: i doubt that. Mar 24 16:31:51 share the recipe please Mar 24 16:31:58 yes, recipe please. Mar 24 16:31:59 so hard to debug via shadows Mar 24 16:32:15 and the *full* log that breaks Mar 24 16:33:36 http://dpaste.com/0XX3NM0 Mar 24 16:35:54 http://dpaste.com/19524XQ Mar 24 16:36:40 no do_install, hence nothing in package, hence fails. my geuss. Mar 24 16:36:54 ahhh Mar 24 16:37:17 ok anyway i think there is still something fucked up in my makefile. I cant find the executable Mar 24 16:37:33 zeddii, khem: do I merge the kernel revs or wait? Mar 24 16:38:14 my next ones will be incremental, so I'd suggest merging them. I'll follow up with more in a few hours. Mar 24 16:38:28 zeddii: right, that is what I suspected, thanks Mar 24 16:39:31 LetoThe2nd: I'm surprised, I'd have thought the do_install from the base class would have oe_runmake install in it Mar 24 16:39:58 (spoiler: I checked, it does not) Mar 24 16:40:12 qschulz maybe but this makefile does not have an install target Mar 24 16:40:16 so even if... Mar 24 16:40:32 qschulz: only autotools.bbclass does that Mar 24 16:40:36 qschulz: 'make install DESTDIR=$D' isn't reliable enough Mar 24 16:40:47 that's basically autotools-ism Mar 24 16:41:06 * LetoThe2nd points at the 5€-Makefile-Box Mar 24 16:41:23 :) Mar 24 16:43:04 i see all the objects but no binary.... Mar 24 16:45:16 * LetoThe2nd calls ita day then, proud of all his recipes that instantly worked with just inherit cmake. Mar 24 16:45:30 LetoThe2nd bye :) Mar 24 16:45:53 Guest5299: i endorse meson when you finally flip out over makefiles Mar 24 16:46:30 AHhh Mar 24 16:46:35 cannot find /lib/ld-linux-armhf.so.3 Mar 24 16:46:58 Guest5299: just go see your dude... take the hammer with you Mar 24 16:47:04 we'll not tell Mar 24 16:47:12 we are not allowed at the moment :) Mar 24 16:47:34 Guest5299: anthrax by post you're welcome Mar 24 16:48:03 Guest5299: but for real... anything that is hardcoded path, flamethrower on it Mar 24 16:48:08 actually thats good to know, he is really fast in finding and fixing stuff, now i know why Mar 24 16:49:25 we've one very respected engineer here, barely readable code, no commit log, but "it works" TM until it does not and you cna't fix it yourself Mar 24 16:49:44 qschulz thats him! Mar 24 16:50:00 he dont want code reviews, he dont want git... Mar 24 16:50:13 i found it, the LD PATH is hardcoded to the one the SDK uses Mar 24 16:50:47 what is the yocto variable for the so path Mar 24 16:53:25 LDFLAGS Mar 24 16:53:34 so... Mar 24 16:53:46 if i change := to ?+ Mar 24 16:53:49 ?= Mar 24 16:53:54 it will work /. Mar 24 16:54:04 sorry, new keyboard :) Mar 24 16:54:25 wait, no the path to ld is LD accordin to mega-manual if I read correctly Mar 24 16:54:34 https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-LD Mar 24 16:54:42 it should yes Mar 24 16:55:02 (told you, anything :=, get rid of it) Mar 24 16:55:19 I mean, hopefully it works, but you know if it does not, it's still the makefile's fault :D Mar 24 16:55:37 yeah just fix the makefile Mar 24 16:55:43 this isn't really the most appropriate place for this question but what's the replacement for `iwpriv` in `iw`? Mar 24 16:56:00 asking here because you guys removed iwpriv saying iw is a replacement for it Mar 24 17:01:29 are there similiar macros for the sdk? Mar 24 17:03:31 never compiled the sdk, but I'd assume the content of the variables change but not the actual name of the variable (otherwise you'd need to patch the sources depending on if you're building target or sdk). Was that your question? Mar 24 17:04:02 this is the LDLIB Mar 24 17:04:20 -L/opt/fslc-framebuffer/2.6.4/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/usr/lib/ -ldl - lstdc++ -lpthread -lrt -lc -lm -lutil Mar 24 17:04:35 so ome of them are still needed Mar 24 17:16:26 ok i will call it a day :) see you and thanks a lot Mar 24 17:20:29 RP: An alternative to reverting all of ba093a38 in bitbake would be to just revert the change in get_autorev() (but please keep the updated comment). That way ${AUTOREV} would behave as before when BB_SRCREV_POLICY = "cache" unless you also set BB_DONT_CACHE = "1" in the recipe, in which case you get the behaviour I want. And I'd argue that if you do set BB_DONT_CACHE = "1" in a recipe, then you do not want the SRCREVs cached, regardless Mar 24 17:20:29 of BB_SRCREV_POLICY... Mar 24 17:36:05 Saur: I'm leaning towards a revert and then clear patches for new functionality with tests Mar 24 17:36:24 tests are the only way we'll document and maintain this Mar 24 17:40:24 RP: Fair enough. But what do you think of allowing BB_DONT_CACHE to override BB_SRCREV_POLICY = "cache"? I think it makes sense. Then I think a new policy is still a good idea, to make using ${AUTOREV} simple for the developers. Mar 24 17:45:09 RP: Btw, unrelated to this, but something I noticed while testing ${AUTOREV}: if I set BB_SERVER_TIMEOUT to anything (even ""), the bitbake server stays behind and refuses to die. `bitbake -m` will say "NOTE: Terminated bitbake server." but the server still remains. Only kill -9 works... Mar 24 17:47:48 Saur: That is worth a bug report and debugging as clearly that is bad Mar 24 17:48:25 RP: It's the same with Zeus for me at least... Mar 24 17:48:31 Saur: I'm not sure the API is very discoverable compared to a specific policy setting Mar 24 17:48:50 RP: How do you mean? Mar 24 17:49:08 Saur: I don't think many users would "find" it Mar 24 17:49:21 Saur: its not obvious Mar 24 17:49:41 RP: You mean that you can set BB_DONT_CACHE to override BB_SRCREV_POLICY = "cache"? Mar 24 17:49:52 Saur: the system has a ton of usability issues but we try to improve that, not make it worse Mar 24 17:51:23 RP: My plan was actually to update the manual with information on how BB_DONT_CACHE, BB_SRCREV_POLICY, AUTOREV and even BB_SERVER_TIMEOUT affects each other. Mar 24 17:52:23 RP: I.e., it's not obvious that if you set BB_SERVER_TIMEOUT, ${AUTOREV} will not take effect (with BB_SRCREV_POLICY = "clear") unless the bitbake server is restarted. Mar 24 17:54:15 Saur: with policy clear, a new connection should reset a resident server so that is a bug Mar 24 17:56:56 RP: Hmm, ok. Will have to run now, but I'll get back to this. Mar 24 18:01:08 Saur: its not surprising as we've just not thought through the implications but that would be the correct behaviour Mar 24 18:41:56 I have a bitbake "Worker" process stuck using 100% cpu. Anything I can do to debug this ? Mar 24 18:42:46 kroon: attach gdb with python extensions and get a backtrace? Mar 24 18:43:52 RP, ok, let me see if I can this. Using master bitbake/oe-core, my tmpdisk ran out of space, so bitbake sent SIGTERM to the remaining task, but the worker gets stuck Mar 24 18:52:11 New news from stackoverflow: How can I skip steps in bitbake compilation procedure? Mar 24 18:52:55 RP, you know if there is special package in fedora I need to install in order to get the gdb python extensions ? Mar 24 18:53:50 erhm Mar 24 18:55:20 kroon, what version of bitbake Mar 24 18:55:32 armpit, master Mar 24 18:55:43 oh Mar 24 19:04:29 Hi all, I have a recipe compiling a c library which builds fine when invoking bitbake to build only that recipe. But when I add this recipe as a dependency to an image configuration of mine and try to build that it seems to somehow inject a new dependency to dnf which crashes with the following exception: `do_rootfs: Could not invoke dnf.` Mar 24 19:05:06 do you have a clue where this extra dependency might come from? I'm pretty clueless Mar 24 19:11:53 emrius: I'm pretty sure the error does not limit to dnf, look again, there should be additional info, if I recall correctly Mar 24 19:12:47 Maybe another previous error slipped away Mar 24 19:14:20 hmm probably Mar 24 19:15:56 I was fumbling with the `TARGET_FPU` (since a couple of days) trying to compile another library which caused a bunch of other issues. Maybe something is conflicting there. I undid a few changes and it's rebuilding right now. Let me see how this turns out... Mar 24 19:16:29 The initial problem was actually this one: https://stackoverflow.com/questions/60772241/recipe-compilation-fails-due-to-floating-point-unit-compatibility-issue-i-assum Mar 24 19:16:57 So, feel free to have a peek and drop a comment if you have any hint on that issue \O/ Mar 24 19:21:05 RP, I've filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=13843 Mar 24 19:21:06 Bug 13843: normal, Undecided, ---, richard.purdie, NEW , bitbake worker stuck using 100% cpu on aborted build Mar 24 19:56:20 rburton: I honestly don't remember anything about that Mar 24 20:00:29 kroon: cool on getting a backtrace! Mar 24 20:03:57 RP, yeah I just needed to "dnf debuginfo-install python3" in Fedora, then "py-bt" was available in gdb. pretty neat. Mar 24 20:31:21 qschulz: caught up on scrollback, I also debug things by running the run.do_* scripts. devshell is more about setting things up so you can e.g. go into the build directory and invoke make by hand Mar 24 20:36:00 smurray, qschulz, I thought one were supposed to run the run.do_* scripts from a devshell. sounds like I can run them in a regular shell ? Mar 24 20:37:17 kroon: it's always worked for me Mar 24 20:37:52 kroon: though it's usually configure and compile that I've done it with Mar 24 20:38:12 hmm whatabout the environment pruning that bitbake does Mar 24 20:40:33 well, seems like devshell doesn't do that either Mar 24 20:42:16 kroon: heh Mar 24 20:44:58 kroon: I believe you can run e.g. 'bitbake -c compile foo' while down inside the WORKDIR, but people do complain about bitbake startup time Mar 24 21:05:59 is anyone still receiving e-mail notifications from git hook? I haven't received one in last few days (might be since migration to groups.io) and today I've noticed that there were some new commits Mar 24 21:32:07 RP: should probably merge and expect another pull from zeddii Mar 24 21:37:29 RP: I sent patches for gdk-pixbuf and quilt ptests Mar 24 21:37:41 RP: I have to warn though, I did not test them :D but they should do the trick Mar 24 21:38:19 (basically because building ptest images on the NUC is not feasible) Mar 24 21:45:04 kanavin_home: how was patch-wrapper giving intermittent results? Mar 24 21:45:24 kanavin_home: and you mean 2G right? Mar 24 21:46:31 RP: no, I mean 2.5G, as 2G is too close to the image size (1.9G) Mar 24 21:47:02 RP: I do not have the answer to the patch-wrapper intermittent results mystery :( Mar 24 21:47:09 kanavin_home: I don't understand, we're not living in a ramdisk are we? Mar 24 21:47:38 oh wait, I confused the units! Mar 24 21:47:43 grrrrr Mar 24 21:47:47 kanavin_home: I don't like intermittent mysteries, they tend to come back :/ Mar 24 21:47:50 ignore me :) Mar 24 21:49:49 "Bail out! GLib-FATAL-ERROR: ../glib-2.62.4/glib/gmem.c:105: failed to allocate 1987968 bytes " Mar 24 21:49:50 Erg, I just found target recipes (aarch64) that put compiled host binaries (x86) into $DEPLOYDIR... this breaks sstate because the interpreter doesn't get corrected to the new uninative path Mar 24 21:49:56 that's 2M, not 2G :) Mar 24 21:50:58 kanavin_home: was i always fast that was failing? I note that has a much lower ram limit Mar 24 21:51:19 kanavin_home: are we filling a tmpfs again I wonder? Mar 24 21:51:28 RP: -fast is 1G, -slow is 2G Mar 24 21:51:48 and I can't remember if it is -fast or -slow specific Mar 24 21:51:55 and I can't run local experiments :( Mar 24 21:52:13 just wanted to look into it by 'static code inspection' :) Mar 24 21:52:30 kanavin_home: I still have http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=b2283ce1521177ec17a90a3bc9ffc54c76acbf6a lying around from the last time we had a problem... Mar 24 21:52:50 kanavin_home: we could run that on the AB on a branch Mar 24 21:53:11 RP: yes that's useful, but I think it was mostly mdadm filling the disk and we have now dropped it Mar 24 21:53:18 kanavin_home: or turn it into a proper patch and warn if there is more than X difference Mar 24 21:53:57 kanavin_home: kind of thinking out loud Mar 24 22:03:49 kanavin_home: both failures were fast, different arches Mar 24 22:13:28 RP: I am looking at what the gdk-pixbuf test is actually doing: it's setting the heap limit to 100M and looks like the test might be hitting that intermittently? https://github.com/GNOME/gdk-pixbuf/blob/mainline/tests/pixbuf-randomly-modified.c#L100 Mar 24 22:14:28 again just a guess, but probably closer to the truth Mar 24 22:16:46 kanavin_home: seems possible although 100M seems like a high limit :/ Mar 24 22:17:29 RP: note that jp2 is jpeg2000 and unpacked that may well be hitting that Mar 24 22:17:53 RP: also note that it's doing random writes to the data, which means the limit may or may not be triggered Mar 24 22:18:09 kanavin_home: hmm, good points Mar 24 22:18:38 kanavin_home: is there debug we could put into the test to see how close to the limit it is? Mar 24 22:18:56 kanavin_home: such a fix may be upstreamable if we can show its close Mar 24 22:20:23 RP: I think there is, wait a moment Mar 24 22:20:54 https://gitlab.gnome.org/GNOME/glib/blob/master/glib/gmem.c#L96 Mar 24 22:21:04 TRACE in there should be print what we need? Mar 24 22:21:16 if that can be turned on for that specific test Mar 24 22:22:15 RP: as for quilt, you're right, the intermittent nature of the failure may mean there is a deeper issue than just the test that's not supposed to be run Mar 24 22:25:51 RP: https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/146 Mar 24 22:25:57 really should've checked that first Mar 24 22:31:31 kanavin_home: we should point ross at this tomorrow Mar 24 22:35:57 RP: I think we can simply drop the offending image file from the ptest package for now. The test should gracefully skip. Upstream bug exists, I don't think we're qualified to fix it. Mar 24 22:37:51 kanavin_home: lets give ross a chance to comment tomorrow Mar 24 22:38:02 kanavin_home: we have a lot more info now which helps massively Mar 24 22:38:23 kanavin_home: we have friends who we might lean on ;-) Mar 24 22:38:35 "On kfreebsd, I see the tests being killed with "out of swap space" on a VM with 16G of ram" ----> this means in the absence of setrlimit corrupted data may cause gdk-pxibuf to swell to over 16G somehow? :-/ Mar 24 22:38:53 (I thought of raising the limit, but now I think it's better to just drop the problematic file) Mar 24 22:39:10 kanavin_home: freebsd doesn't have setrlimit ? Mar 24 22:39:31 RP: I have no idea, but that comment implies it doesnt? Mar 24 22:40:14 kanavin_home: if freebsd has setrlimit it probably means the author of the bug may just not have spotted it Mar 24 22:40:26 so it was just hitting the 100M, same as us Mar 24 22:41:27 "Checking for function "setrlimit" : YES " - yes it does Mar 24 22:41:33 https://buildd.debian.org/status/fetch.php?pkg=gdk-pixbuf&arch=kfreebsd-amd64&ver=2.40.0%2Bdfsg-2&stamp=1582013991&raw=0 Mar 24 22:42:07 kanavin_home: might be worth spelling this out in the bug and suggesting raising the limit? Mar 24 22:42:51 RP: I did just that? Mar 24 22:42:51 "Note that it fails when loading and randomly modifying the jp2 image, which in rare cases hits the 100M data limit the test sets for itself: https://github.com/GNOME/gdk-pixbuf/blob/mainline/tests/pixbuf-randomly-modified.c#L100" Mar 24 22:43:02 RP: should I add something else? Mar 24 22:43:07 https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/146 Mar 24 22:43:28 kanavin_home: that the kfreebsd failure would also run into the same 100M limit regardless of the 16GB VM Mar 24 22:44:18 yeah, just commented about that Mar 24 22:44:33 cool Mar 24 22:44:49 I am not sure how this happens though, as the jp2 loader is not even enabled for us Mar 24 22:45:13 maybe the corruption somehow triggers some other large allocation Mar 24 22:47:47 RP: going to bed :) Mar 24 22:47:59 I like working from home, but dont want to mess up the sleep Mar 24 22:49:50 (or in rare cases the corruption turns jp2 into plain jpeg and kaboom - no idea really :) Mar 24 22:53:03 New news from stackoverflow: Yocto Bitbake Recipe for Custom Python Script and PyTest Mar 24 22:58:16 kanavin_home: get some sleep, I'd like to talk to ross tomorrow Mar 24 23:01:45 build passed. sending the kernel pull request. Mar 24 23:14:27 just run into the same issue on zeus: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950551 Mar 24 23:15:01 cryptsetup starts multiple threads for argon2i and crashes badly because libgcc_s.so is missing ;-\ Mar 24 23:16:02 khem: you maintain that? is this a known issue? Mar 24 23:16:45 add it as rdep then Mar 24 23:19:22 so i'm the first one that runs cryptsetup on a smp machine with zeus? :) Mar 24 23:36:12 perghaps maybe Mar 24 23:36:56 hehe :-) **** ENDING LOGGING AT Wed Mar 25 02:59:57 2020