**** BEGIN LOGGING AT Mon May 17 02:59:57 2021 May 17 03:02:02 nothing suspicious about that... May 17 07:27:39 good morning May 17 09:19:00 JPEW: No PR over the (long) weekend for me for two reasons: 1) shellcheck does not support zsh /me sad 2) zsh seems to support == (which is just an alias for compatibility purposes to =) according to the documentation. It does not work on my three PCs running zsh (with ohmyzsh too, so might be coming from it). I'll spin an alpine container to see with a freshly installed zsh if == is valid or not May 17 09:21:09 Hello guys May 17 09:21:23 I have a custom recipe fetching sources from a git repo May 17 09:21:42 in the src_uri i have added both branch=X and rev=Y May 17 09:22:24 bitbaking the recipe always results is do_fetch: Fetcher failure: Unable to find revision Y in branch X even from upstream May 17 09:23:27 but cloning manually the repository and running git checkout Y gives no error at all May 17 09:23:37 So I am pretty confused May 17 09:25:36 thekappe: why not using SRCREV="Y" outside of SRC_URI instead of rev=Y in SRC_URI? May 17 09:28:15 same resutl May 17 09:34:16 thekappe: git branch --contains Y May 17 09:34:33 thekappe: does this return a branch named X? May 17 09:41:41 JPEW: can confirm on a fresh zsh install in Alpine that == does not work... /me sighs May 17 09:45:15 JPEW: https://unix.stackexchange.com/a/255483 well... let's go for [[ ]] conditionals then I guess :) The issue is that shellcheck won't probably ever fail on [ ] conditionals when we want [[ ]] :/ May 17 09:45:59 qschulz, yes May 17 09:47:16 wait May 17 09:50:36 found a typo May 17 09:50:53 sorry guys May 17 09:56:20 thekappe: the good old typo :D May 17 09:57:11 thekappe: don't worry, I lost half a day trying to figure out why I couldn't boot a hand crafted entry in GRUB2 to find out that I named the initrmafs initrd-fc34.img instead of initramfs-fc34.img 👌 May 17 10:48:14 hi all. I encountered some technical problem and would like to ask for advice. I need to apply a patch to Linux kernel but it needs to be applied to all kernels we use in our top-level meta-layer. May 17 10:51:00 I wonder if there is any canonical method to achieve that. Nothing comes to my mind but seems like something that at least one person should have encountered before me. May 17 10:55:44 zbodek: use a .inc file which adds your patch to SRC_URI? May 17 10:57:02 qschulz: You mean create .inc file and include it in each and every kernel recipe/bbappend? May 17 11:19:52 zbodek: yes? May 17 11:50:27 <_dleppich> Hi, I'm currently compiling chromium for an embedded device. The compilation is really slow (takes about 3 hours to complete). When I make a modification to the recipe, it recompiles everything and takes another three hours. Chromium makes use of meta-clang to use its native clang compiler. Do you know of any way to speed up the compilation process? I'm quite sure most of the files won't need to be May 17 11:50:43 <_dleppich> recompiled every time.. May 17 11:57:09 _dleppich: maybe you can try by adding ccache to this recipe? May 17 11:57:27 `inherit ccache` should be enough for starters May 17 11:59:11 <_dleppich> qschulz: Thanks, I'll try that once the current compile run finishes :) May 17 12:03:55 Is Freenode in danger to go away? https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409 May 17 12:48:26 qschulz: thanks for advice. I was hoping there is some way to create one thingy that will affect all kernel recipes. One thingy to rule them all May 17 12:53:48 RobertBerger: doesn't sound like it May 17 12:55:10 @Crofton|cloud: let's hope so ;) May 17 13:33:38 zbodek: not that I'm aware of no. Except if all your kernel recipes are named the same (in which case, only the version of the recipe changes), then you can use kernel-recipe_%.bbappend and that will apply to all kernel recipes named kernel-recipe, whatever their version number is May 17 13:45:49 qschulz: thanks, unfortunately that is not the case for us at the moment. Will go with .inc May 17 13:49:34 zbodek: are all your kernel recipes in the same directory? May 17 13:50:54 if not, you need the FILESEXTRAPATHS_prepend := "${THISDIR}/files" trick you can find in bbappends May 17 13:59:19 qschulz: no, they are not in the same directory, in addition they are in the separate layers now May 17 14:00:54 zbodek: honestly, I'm not too sure this is a great idea :/ It'd surprise me if you actually manage to get all recipes to use the same patch May 17 14:01:47 i'm running a yocto build for a new architecture, csky, and am getting this ERROR: Unknown CPU family csky, see https://wiki.yoctoproject.org/wiki/Meson/UnknownCPU for directions. May 17 14:01:53 i don't understand why meson knows or cares about cpu architecture - can someone please explain? May 17 14:03:18 because meson needs to know about cpu architecture May 17 14:03:21 easily fixed May 17 14:03:27 same reason autoconf needs to know May 17 14:03:39 and there's a slew of tables in oe-core you need to fill in May 17 14:04:59 rburton: gnumake doesn't need to know about cpu architecture - why would meson? May 17 14:05:08 autoconf does though May 17 14:05:27 yes, but then that would be an autoconf issue, right? May 17 14:05:34 right May 17 14:05:38 and this is a meson issue May 17 14:05:49 new architectures mean telling both May 17 14:05:50 qschulz: hmm, thanks for the tip. I will try it out and if the solution will not be accepted I guess I will fall back to using per-recipe patch May 17 14:05:55 by "solution" are you referring to this: https://wiki.yoctoproject.org/wiki/Meson/UnknownCPU May 17 14:05:59 What is csky? May 17 14:06:16 it is a relatively new cpu architecture. May 17 14:06:46 yates: yes, that wiki page i wrote tells you exactly what to do. specifically, the last line. May 17 14:07:32 ok May 17 14:08:55 do https://git.savannah.gnu.org/gitweb/?p=config.git;a=tree too, the good news is that we update every autoconf-using recipe with the latest files we have so you patch once instead of every recipe May 17 14:09:31 Crofton|cloud: https://c-sky.github.io/ May 17 14:09:44 * Crofton|cloud smiles, Yes just found that May 17 14:09:59 So very interesting, glad to see someone working on support May 17 14:10:12 nothing since 2019 in google May 17 14:10:19 so... its mostly dead? May 17 14:10:53 rburton: yes, until you help me fix this meson issue... :) May 17 14:11:03 well it told you what to do :) May 17 14:11:10 even wrote a wiki page explaining the steps May 17 14:11:14 i'm typing as fast as i can... :) May 17 14:13:04 https://git.savannah.gnu.org/gitweb/?p=config.git;a=commitdiff;h=63b4ce2e8c28aee6a32133e400436e4ca885215a was the gnu fix May 17 14:13:38 qschulz: I think changing it from == to = is fine; I beleive you that it doesn't work and is more compatible :) May 17 14:14:05 qschulz: Thanks for trying to track it down more precisely though May 17 14:16:46 JPEW: I'll work on a shellcheck GH action anyway in addition of this patch, so pyrex follows best practices for at least bash May 17 14:18:42 Cool, thanks! May 17 14:35:03 rburton: i don't understand that "gnu fix" link at all. i don't know what repository that is, and i don't know what config.git does. May 17 14:35:32 but i submitted the meson bug report May 17 14:35:44 https://github.com/mesonbuild/meson/issues/8770 May 17 14:45:06 config is where config.guess and config.sub come from, the arch/os detection logic in autoconf May 17 14:46:09 yates: you can send a patch, its trivial May 17 15:06:31 hello, I am trying to derive a QEMU machine from qemux86-64, but something is wrong May 17 15:06:48 ERROR: linux-yocto-5.10.16+gitAUTOINC+8f72218572_98eda36c96-r0 do_kernel_metadata: Could not locate BSP definition for qemux86-64-derived/standard and no defconfig was provided May 17 15:09:05 eduardas: you are missing a MACHINEOVERRIDES =. "qemux86-64:" before the first include in your machine configuration file May 17 15:09:13 eduardas: wild guess of course :) May 17 15:12:18 qschulz: I've already had it. does not help May 17 15:12:56 qschulz: https://pastebin.com/Xtn0Pxcr May 17 15:13:03 here is the machine configuration May 17 15:13:24 is it perhaps wrong to just include qemux86-64.conf? May 17 15:32:47 qschulz: setting KMACHINE = "qemux86-64" in my machine configuration seems to have helped May 17 15:40:58 eduardas: That's what I had to do when I derived a machine from qemux86, so it sounds correct May 17 15:42:21 JPEW: good to know because I had my doubts whether that is appropriate May 17 15:43:00 I *also* added the MACHINEOVERRIDES as qschulz suggested, so you may need both depending on what behavior you're looking for May 17 15:45:37 JPEW: yes, I have both May 17 15:56:27 hi, i'm seeing a conflict where resolvconf and dhcp-client (using dunfell) both provide /etc/dhcp; the things each install under there don't actually conflict though and i'm not quite sure how to resolve that May 17 16:03:57 opello: Is that a directory or a file? May 17 16:05:34 JPEW: it's a directory despite what the error during the image recipe build claims :) May 17 16:07:14 Not sure. If it truly is a directory, it shouldn't conflict if both recipes provide it May 17 16:07:35 Hey! Can someone help me understand classes a bit? May 17 16:07:50 The following defined a package called "virtualenv" https://dpaste.com/EEMKPL4MW May 17 16:08:28 It inherits pypi, which inherits this bbclass. https://github.com/openembedded/openembedded-core/blob/master/meta/classes/pypi.bbclass May 17 16:08:30 JPEW: yeah :/ https://pastebin.com/PTFpqz7a May 17 16:08:53 opello: Sorry, pastebin is blocked for me :/ May 17 16:09:19 virtualenv, as far as I can tell, has python-six as a runtime dependency. A lot of other source based distributions have six being a dependency of virtualenv anyway. May 17 16:09:19 JPEW: d'oh, alternative? May 17 16:09:37 github gist? May 17 16:09:37 Why is it that I cannot find `python-six` declared anywhere in openembedded, or as the runtime dep for a bunch of python packages? May 17 16:09:43 opello: Ya, that's fine May 17 16:09:51 Sorry... it's a stupid policy May 17 16:10:04 python3-six is in oe-core, python-six is in meta-python2 May 17 16:10:29 For example, in the following Nix package, it is simply declared that `six` is a propogatedBuildInput (runtime dependency) of the python package known as 'virtualenv' https://github.com/NixOS/nixpkgs/blob/nixos-20.09/pkgs/development/python-modules/virtualenv/default.nix#L35 May 17 16:10:31 JPEW: https://gist.github.com/opello/453d092d70e952556c577ac23ee104cb May 17 16:10:58 Where in Yocto/OE is six declared as a runtime dependency, anywhere? Is something "impure" happening where it's figured out later and ends up in the output of a given recipe, despite not being written down? May 17 16:11:14 opello: Hmm, perhaps they are both trying to create the directory with different permissions? May 17 16:11:27 I'm really interested in this behavior, since it has been the one thing I've not understood about yocto, the fact that some things are just magic. May 17 16:11:40 opello: I've never come across that before, but it could be that OE checks that May 17 16:11:51 matthewcroughan: there's no magic detection for python imports, no May 17 16:12:11 So how does `six` end up being built as part of virtualenv? May 17 16:12:17 Or doesn't it? And if so, why? May 17 16:12:30 is meson pulled and built within yocto? May 17 16:13:01 yates: meson-native is depended upon by meson recipes by meson.bbclass May 17 16:13:24 i just submitted a pull request to add csky to mesonbuild: https://github.com/mesonbuild/meson/pull/8771 May 17 16:13:26 JPEW: sure, and g+s is set (maybe leaked through in a copyFiles type thing, i had to do that across my environment for other complicated reasons) May 17 16:13:36 JPEW: (but only for resolvconf, heh) May 17 16:13:41 thanks for the hint May 17 16:13:52 RP: so will that automatically pull the new meson once my pull request is merged? May 17 16:13:56 opello: Sure. Hopefully that's the cause of the problem May 17 16:14:17 rburton: other distros like gentoo/nix/guix have six, filelock, distlib, appdirs, other python packages written as runtime dependencies of virtualenv. So how do these dependencies end up being included in the virtualenv recipe despite not being written? May 17 16:14:18 https://layers.openembedded.org/layerindex/recipe/118314/ May 17 16:14:44 Like I don't see `six` anywhere here. Or in the recipe/include. May 17 16:14:48 yates: you can patch the meson recipe to use it now May 17 16:14:54 In fact, the include claims it only needs dateutil! https://git.yoctoproject.org/cgit/cgit.cgi/meta-cloud-services/tree/meta-openstack/recipes-devtools/python/python-virtualenv.inc?h=master May 17 16:14:57 yates: you'd have to update the meson recipe May 17 16:15:23 matthewcroughan: where are you seeing six as a dependency? May 17 16:15:30 rburton: other distributions May 17 16:16:35 matthewcroughan: are you saying that the virtualenv recipe is missing the dependency and six is in fact needed? May 17 16:16:46 well, based on other distributions, I guess so :D May 17 16:16:50 maybe it's just the case that it's missing. May 17 16:16:59 I wonder what the runtime behavior of virtualenv is then. May 17 16:17:13 "So how do these dependencies end up being included in the virtualenv recipe despite not being written?" reads "how does virtualenv depend on six when its not in the recipe" May 17 16:17:21 Anyone know how to get `pip` to list the deps of a given package without destroying your filesystem? May 17 16:17:42 rburton: Yes, that's a better way of saying it. I'm confused, thanks for the patience. May 17 16:17:50 if there are missing rdepends, send a patch May 17 16:18:08 Well, I just assumed OE was perfect, because it has a lot of money in it. That was my problem. May 17 16:18:27 I assumed that it was the reference and that a package like virtualenv couldn't be done wrong. May 17 16:19:02 ha! May 17 16:19:08 lots of money May 17 16:19:09 hahahaha May 17 16:19:45 Well I did see this. So maybe I poorly judged https://lists.yoctoproject.org/g/yocto/message/53438 May 17 16:20:25 point (c) is "give us money" May 17 16:20:48 no distro is perfect May 17 16:21:01 missing rdepends are trivial to fix, so please send a patch May 17 16:21:02 Well the problem with me is environment. I'm running Nix and I've been spolied. May 17 16:22:13 There's no way I can just `bitbake github:openembedded/openembedded#python3-virtualenv` is there? I can do that with Nix, on any distro. So my capacity to have actually tested that before asking here was reduced. May 17 16:22:38 bitbake-layers will fetch a layer for you May 17 16:22:49 With Nix, I can just `nix build github:nixos/nixpkgs/master#python3Packages.virtualenv` and it would have build it locally and I'd be testing it. May 17 16:23:25 But with Yocto, I first have to be running Ubuntu, or do some very complex installation procedure, right? There is no tool I can use to do this that is distro-agnostic? May 17 16:23:30 erm no May 17 16:23:42 the installation process is git clone May 17 16:24:07 you need a compiler and a few other tools, as we're not mad enough to bootstrap from dd or something May 17 16:24:09 My host needs an environment though? May 17 16:24:43 yocto is distro-agnostic May 17 16:25:34 I just haven't found that to be the case, maybe the poky based distribution I'm building is just too complicated. May 17 16:26:19 rburton: https://dpaste.com/FUQBEDZ57.txt May 17 16:26:25 Here's the deps from the instructions I'm given, for example :D May 17 16:26:29 erm May 17 16:26:30 yeah May 17 16:26:33 as i said you need a compiler May 17 16:26:43 half of those are not core yocto deps May 17 16:26:45 and a bunch of python3 stuff, and a very esoteric bsd utility May 17 16:26:58 those are either wrong, or the recipes that you're being told to use are very broken May 17 16:27:15 well there you go, it's not that simple is it? May 17 16:27:28 The project you're working on can ruin it and make it non-distro-agnostic. May 17 16:27:32 gasp! May 17 16:27:37 OE on its own, you're probably right. And yes, I'm wrong about that. May 17 16:27:42 people doing wrong things make things wrong May 17 16:28:07 also tell whoever gave you the distro that they shouldn't be using poky May 17 16:28:11 again, doing it wrong May 17 16:28:14 rburton: Well, with Nix, it's not really possible to end up in a position where you add a dependency and effect people's ability to compile it based on their host system, because Nix actually sets up that env. May 17 16:28:28 Bitbake is not like that, is what I'm saying. So I need to construct my own environment, by hand. May 17 16:28:58 correct, bitbake is not nix May 17 16:29:04 can we get back to something on topic? May 17 16:29:08 rburton: Sorry, I'm using poky to refer to whatever the latest release is, it's just a bad habit of mine. May 17 16:29:30 Point is, I can't test these things easily because of the tooling, which is why I have to apologise for wasting your time :P May 17 16:30:18 Going to test venv on OE now, hopefully the only deps I need are gcc and git. May 17 17:55:26 Hmmm.....Is there a way to overwrite distro env variables so that they take effect before let's say the kernel bitbake recipe is evaluated? May 17 17:57:31 I am asking because the kernel bitbake file uses things like: ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'file://selinux.cfg', '', d)}, and I would like to control that in my recipe, and leave the distro.conf as is May 17 18:31:22 RP, I'm going to experiment with zstd for rpm (de)compression. It's being hyped as much faster than anything else, I'd like to see if that applies to package_write_rpm and do_rootfs/do_populate_sdk :) May 17 18:31:26 rburton, ^^^ May 17 18:32:15 kanavin: If you really want speed, lz4 is awesome May 17 18:32:58 kanavin: Ah, it looks like zstd is more tunable though for speed/compression though May 17 18:40:44 nevermind, threaded zstd is only supported in rpm 4.17.0-alpha :) May 17 18:41:00 whenever the final comes May 17 19:02:41 rburton: https://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html#brief-compatible-distro May 17 19:02:50 Does this line up with what you were saying earlier? May 17 19:03:20 The apt-get install advice I gave you via dpaste is actually just a copy-paste of the poky docs, I didn't realise. May 17 19:04:33 Is it fair to say "Yocto is not distro-agnostic" and "OE is distro-agnostic" ? May 17 19:08:02 Also someone helped me figure out why python-six is not declared in python-virtualenv. It's because of inheritance via the runtime dep, python-dateutil includes python-six. I don't like that, but at least I understand it now. May 17 19:08:45 https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/virtualenv/virtualenv-20.4.6.ebuild May 17 19:09:05 Gentoo by comparison is very explicit about deps so that you can actually read it and have a hope of tracing things back without having to use dot. May 17 19:09:07 matthewcroughan: You need a few host dependencies in order to build (mostly, compiler, git, python, etc.). You can probably get it to build on just about any distro as long as you satisfy the required dependencies. YP can't test on every single distro, but they do test on the more popular ones, and those become the "supported distro", but you can turn that check off if you want to run on something else (just realize, it's May 17 19:09:07 not tested by YP) May 17 19:09:38 JPEW: Is that in reference to Yocto, or OE? May 17 19:09:43 Yocto May 17 19:09:56 Well, I just gave you a link to the docs, it's actually a large amount of deps. May 17 19:10:12 It's not just a compiler, git, python. It's actually a very large list. May 17 19:11:28 Realistically, you have to be on Ubuntu or Fedora. May 17 19:12:02 matthewcroughan: I'm pretty sure that not all of those are required for all use cases.... but's it's easuer to give users a single list up front than say "these are for building, these are for running selftest, these are so you can run the emulator, etc." May 17 19:13:01 matthewcroughan: I have heard of people running on things other than Ubuntu or Fedora; but ya, that's mostly what YP tests with May 17 19:14:09 JPEW: it was totally permissions :) May 17 19:14:27 opello: Excellent. Hopefully that's an easy fix! May 17 19:15:11 heh, well, maybe :) it points to permissions of the layer checkout directory leaking into the image which seems maybe suboptimal May 17 19:15:42 opello: Oh, that. That's outright host contamination, which is a bug :) May 17 19:17:25 * zeddii chuckles May 17 19:18:58 JPEW: yeah, i worried about that ... i had it for the postinst_intercept helper too, where g+s across the checkout seemed like a reasonable fix because of bb.utils.copyFile(?) checking owner/mode on both sides of the copy operation May 17 19:19:57 opello: I'm not _exaclty_ sure what you are trying to do, but there are some tips for installing files.... May 17 19:20:02 * JPEW looks in the manual May 17 19:21:14 opello: https://docs.yoctoproject.org/ref-manual/tasks.html#ref-tasks-install May 17 19:21:34 heh sorry, just remarking that this latest issue is a product of working around something else, maybe it was unnecessary detail, but in the best case it might prompt a further response :) May 17 19:21:53 opello: Ah, got it. May 17 19:37:25 it just took me three tries to start an AB run. May 17 19:37:28 must be monday May 17 20:11:30 * armpit Poky on Apple M1.. who will be the first?? May 17 20:12:58 matthewcroughan: Is it fair to say "Yocto is not distro-agnostic" and "OE is distro-agnostic" ? <-- no. it has host requirements (gcc, make, etc). the documentation gives you example commands for the list of *supported* (but not the list of working) distros. May 17 20:13:18 note that eg arch is not supported (because it changes daily) but many people use it because it typically works and they prefer it May 17 20:13:47 rburton: The doc I linked uses an apt command and lists dependencies beyond gcc, make. May 17 20:14:03 It is not just gcc or make. It depends on latex for example, I'm not sure I'm understanding. May 17 20:27:58 armpit if someone would figure out storage, I'd be tempted to buy an M1 mac mini and do that May 17 20:38:52 rburton: tell me again how trivial it is to modify meson? http://paste.ubuntu.com/p/MnZHgRXB4N/ May 17 20:55:22 nm, i made a patch manually - seems to be working May 17 20:59:44 rburton: you developed sato?!? May 17 21:22:24 JPEW: I think I found the issue with the tests not failing with zsh, the ci/test.py is explicitly running command with the bash shell. I would like to find a way to use the login shell used by the user (the one selected via chsh) without actually mentioning it explicitly. But /bin/sh still redirects to /bin/bash on my Fedora. May 17 21:23:48 qschulz: Hmm, this isn't doing what I expect then: https://github.com/garmin/pyrex/blob/master/.github/workflows/main.yml#L48 ? May 17 21:24:39 qschulz: Hah, so it isn't! May 17 21:24:45 Good catch May 17 21:29:13 qschulz: Perhaps test.py should do os.environ.get('SHELL', '/bin/bash') and the CI can explicitly set SHELL with export SHELL=${{ matix.sh }} May 17 21:29:49 JPEW: I don't know tbh May 17 21:30:29 The only issue is with the script that gets sourced, otherwise since the shebang is /bin/bash for all the scripts, i guess it'll just use bash as the interpreter by default anyway May 17 21:30:50 Basically, I don't know how far we want to push the use of non-bash shells May 17 21:31:18 I think it boils down to "do we want to require bash to always be installed on the system?" May 17 21:31:39 and just make the pyrex-init-env script zsh or even POSIX compliant May 17 21:31:51 if the answer to the question is yes May 17 21:32:30 (might not make a lot of sense, pretty late here :) ) May 17 21:33:27 The intention is that pyrex works with shells other than bash, and I *thought* we were testing zsh, but it's actually broken May 17 21:33:58 ok, then passing it as part of the environment is one way indeed May 17 21:38:11 or have an additional argument to ci/test.py? May 17 21:38:39 anyway, gotta go now, bed's calling me :) have a nice day, I'll read whatever you write tmrw morning :) May 17 21:55:38 kanavin: The numbers I saw said slower compression, faster decompression. I also read there were issues supporting multithreaded compression? May 17 21:55:55 kanavin: getting rid if mklibs looks sane to me, probably about time May 17 21:57:05 how do i build perl without gdbm May 17 21:57:32 i tried removing it from the packageconfig but then it fails file-rdeps.. May 17 21:57:34 RP: zstd has a parameter that sets that tradeoff. Multithreaded compression support zstd was added to rpm, so someone is using it. That's something I wanted to experiment with but has to wait until rpm 4.17 I guess. May 17 21:57:40 "ERROR: perl-5.30.1-r0 do_package_qa: QA Issue: /usr/lib/perl5/5.30.1/arm-linux/auto/GDBM_File/GDBM_File.so contained in package perl-module-gdbm-file requires libgdbm.so.6, but no providers found in RDEPENDS_perl-module-gdbm-file? [file-rdeps]" May 17 21:58:08 kanavin: fair enough. We do have a problem with rpm and xz right now May 17 21:58:28 RP: what prompted me to look into it is that dnf saturates a single CPU core when uncompressing large rpms, very inefficient :( We could potentially gain a lot in things like populate_sdk and do_rootfs. May 17 21:58:32 alternatively, how do i remove perl from my image entirely? May 17 21:58:40 i have no idea what depends on it May 17 21:59:22 RP: last time I tried to get rid of mklibs, a certain Khem shoot it down with the talk of 'someone might be interested in it' :) May 17 21:59:31 kanavin: fair enough. If you wanted to help with an autobuilder pressing issue, I'm worried that http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/commit/?id=19b4e74b3960174238acc79fd112f55706bc7385 doesn't affect the rpm building and is going to cause problems on the autobuilder May 17 22:00:04 kanavin: We're seeing xz using crazy amounts of memory/threads :/ May 17 22:00:48 RP: where are those parameters picked up? May 17 22:01:06 RP: rpm's xz threads are set elsewhere, let me check.... May 17 22:01:53 kanavin: those options do feed into package_write_ipk but not sure about rpm/dev May 17 22:01:55 deb May 17 22:02:48 RP: ipk probably calls out to xz executable? rpm does not do that, and links to liblzma directly. But there is a way to set the threads there as well, hold. May 17 22:04:17 RP: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/package_rpm.bbclass#n687 May 17 22:04:45 w6T means 'compression level 6, multithreaded compression using all cpu cores' May 17 22:05:13 kanavin: can you tell what rpm does for memory limiting? May 17 22:05:17 you can set it to something like w6T8 (I think), or better make it configurable May 17 22:05:45 RP: for memory we have this patch which I do not like at all, because I have no idea what it does... hold May 17 22:06:15 RP: this http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/rpm/files/0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch May 17 22:09:01 kanavin: I'd be fine with about 6 threads May 17 22:09:11 kanavin: or yes, we could configure it May 17 22:09:53 kanavin: hmm, we never set virtual memory limits so I suspect that patch does nothing :/ May 17 22:10:02 unless rpm itself sets them May 17 22:10:26 most of our systems (that are setup by IT) have vm limits set.. sucks, cause it breaks often May 17 22:10:40 RP: rpmio.c is where all (de)compressor-specific things happen I think May 17 22:45:33 qschulz: https://github.com/garmin/pyrex/pull/62 I think I got the @ mention correct for your github account. Let me know if that is incorrect. May 18 00:12:45 kanavin: in small systems it is useful and we were trying to squeeze everything we could but we have since abandoned pushing yocto into small profiles as they need to be really small and its a constant battle. so I am not too bothered anymore if this stays or not May 18 00:20:50 khem: I think it is that broken people can't have been using it May 18 00:21:13 probably, May 18 00:21:44 I was more referring to when removal was proposed last time than now, May 18 00:26:50 and we were on older releases, and I was trying to keep it in master at that time, so if we used it then atleast we will have upstream support, it would have been bad if we started to use a feature which was then removed from master thats why I was worried at that time but thanksfully we did not need it May 18 01:20:27 khem: I'm on swat duty this week. I'm seeing lots of cancelled meta-oe builds without any obvious errors. Am I missing something or are they fine to dismiss? May 18 02:15:51 jonmason: I am beating the builders for changes May 18 02:17:01 usually its not the case but sometimes when oe-core changes in a way which results in full build of meta-oe can take long May 18 02:17:34 btw. thanks for keeping an eye on meta-oe builds, its kind of neglected job on AB, May 18 02:18:48 I'm a clean plate kind of guy :) **** ENDING LOGGING AT Tue May 18 02:59:56 2021