**** BEGIN LOGGING AT Wed May 20 02:59:58 2020 May 20 03:28:41 * khem chases paulg May 20 03:29:57 * paulg drops a box of thumb tacks May 20 03:30:26 stole 'em along with my red stapler! May 20 03:41:16 Don't make me use my paper clips. May 20 05:49:55 Hi May 20 05:59:40 Hi ykrons May 20 07:13:58 I would like to add a specific partition to an image (that remains after an update) and I would like that different applications store their settings in that partition. What's the right way to go? At that time the partition is added by a dedicated recipe, but I wonder if it should not be part of distro features. And I plan to customize this recipe for each application but I found it weird to have a bbappend for another recipe in the folder of a recipe. May 20 07:21:29 look into wic partitioning schemes May 20 07:22:01 partitions are added by image builder not by recipes May 20 07:35:51 Hi guys! May 20 07:42:29 vNistelroot: hi May 20 07:44:22 I´m new using yocto project, is there any way/script such as Linis or Linenum for GNU\Linux to check for the health/files/packages of a Yocto Linux from a security perspective? I have only SSH access May 20 07:57:39 Hi, I have recently used OpenVAS on a Yocto system May 20 07:59:19 But I think there is also cve-check.bbclass that should do nearly the same from package analysis, but never use it May 20 07:59:51 (I'm also a bit new to yocto world so ..) May 20 08:01:12 yep! Ive read about cve-check, but it sounds is more like for devs prior to releasing the build, but ill check again now! May 20 08:13:43 openvas is probably a good option so. You have to install it (was easy with ubuntu 20.04 ), update CVE database and then it is just a matter of giving SSH credentials and IP to the tool. 20min later you have a report with potential vulnerabilities May 20 08:41:07 ykrons: thank you! Ill try that way May 20 08:58:27 Uhm. I'm confused: I added DISTRO_FEATURES_remove = "ldconfig", and did not add it to DISTRO_FEATURES_BACKFILL_CONSIDERED. It still seems like "ldconfig" has been removed from DISTRO_FEATURES. May 20 08:59:15 But I see the featurebackfill code in base.bbclass is still active, so what gives.. May 20 09:01:52 I guess _remove's are applied after that code runs May 20 09:02:43 so then what is the point of having *_CONSIDERED ? why not just use _remove's ? May 20 09:05:49 kroon: i think _considered predates _remove May 20 09:15:58 rburton, right. _considered introduced 2012 in oe-core commit 738658d9d5ddef026d2929188744aa225324bf26. _remove operator added 2013 in bitbake commit 9c91948e10df278dad4832487fa56888cd58d187 May 20 09:19:01 I'd like to get rid of it May 20 09:32:42 patches welcome May 20 09:33:05 ykrons: I just installed openvas, did you choose any specific family type when launching the credential scan over ssh? May 20 09:33:13 kroon: but do you understand the purpose of it? May 20 09:34:14 rburton, not entirely May 20 09:37:30 how is a default time set (before NTP kicks in) in the recipe? May 20 09:38:00 I only see posts about timezone, not the date itself May 20 09:38:17 imagine that you have certificates and stuff and the date is 1970 May 20 09:41:32 Ad0: systemd or sysvinit? May 20 09:42:01 hm you mean making a oneshot service setting the date? May 20 09:42:26 no, i mean are you using systemd or sysvinit, because how the default time is set is different for each one May 20 09:42:56 both will detect if the time is basically 1970 and reset it to something newer May 20 09:43:22 ok May 20 09:43:34 I have systemd on my image but without internet it stays at 1970 May 20 09:43:35 rburton, it sounds to me like its a mechanism for introducing new "default" values to DISTRO_FEATURES, without breaking existing distro conf's that I'm guessing sets DISTRO_FEATURES with the "="-operator May 20 09:44:00 kroon: basically, yes. eg sysvinit wasn't a feature, then was. if it wasn't backfilled then upgraders would suddenly lose the init May 20 09:45:20 rburton, I see. I'd say that nowadays distro conf's should use _append/_remove, and not set it with '='-operator, right ? May 20 09:45:37 kroon: not at all. if you're writing your own distro then feel free to control the values May 20 09:45:57 just remember to look at changes to the default when upgrading May 20 09:54:56 rburton, so if we assume upgraders remember to look at changes to the default value, then we don't need the _backfill magic May 20 09:55:39 rburton, if they use _append_remove they don't need to check at all May 20 10:31:55 I vaguely remember there should be some kind of packagegroup or something for including all licenses in a rootfs, can't find it quickly in the docs. Did I dream of it or is my search skills that bad? May 20 11:33:43 qschulz: its not a packagegroup but a variable. COPY_LICSOMETHING May 20 11:33:49 the manual knows. May 20 12:03:24 Letothe2nd: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#providing-license-text May 20 12:03:27 the almighty doc May 20 12:03:32 thx May 20 12:07:47 qschulz: have fun May 20 12:10:07 Letothe2nd: I was just curious :) not going to need it :) (was just trying to justify why would one want to add their license to LICENSE_PATH May 20 12:14:57 :) May 20 12:28:06 RP: just saw the pub-enlightenment remark in the backlog. ++! May 20 12:29:35 vNistelroot, I just pick the default scan options. It can be customized but the default will already give a quick overview May 20 12:33:15 hello, I am using poky-atmel to build Linux kernel for my atmel SAMA5D27 board. I build core-image-minimal kernel. I want to know how can I verify that some features have been build into my kernel ? for example I want to know if TCP/IP is existing in my kernel May 20 12:34:00 gaston53: by looking at the kernel config, probably. May 20 12:34:26 Letothe2nd a file ? May 20 12:34:31 gaston53: bitbake virtual/kernel -c menuconfig May 20 12:35:50 qschulz menuconfig and look for the checked features ? May 20 12:36:28 note, that the example(?) is badly chosen, because a kernel configuration without tcp/ip support is extremely rare these days, especially on a vendor-based kernel for a board that has ethernet connectivity. May 20 12:37:46 Letothe2nd I have just made an example. besides, it's a minimal image. That's why I am hesitated May 20 12:38:20 I need to verify RS232 communications, gpios, ethernet May 20 12:38:25 hello. i am using a "SRC_URI_append =" in a bbappend, to get some additional files, i was expecting files from this second SRC_URI are "merged" to the first git folder, while, i see a total replacement. Is it possible to have such additional files from bbappend SRC_URI just "added" to the build folder ? May 20 12:39:16 gaston53: yup. Beware that modifying the kernel config with menuconfig from yocto isn't completely straightforward but that was not what you were asking (yet :) ) May 20 12:39:58 gaston53: i actually would rather suggest to look at the device tree and supplied configuration of the atmel bso layer that you are probably using. May 20 12:41:36 qschulz sorry but what you mean is that when I , for example , check or uncheck a feature from the menuconfig and re-build the kernel, no modifications will take place ? May 20 12:41:37 angelo__: files in SRC_URI are copied to $WORKSPACE expect if there is something weird going on. That's it, if there's nothing more done, the files are just there (and if they are patches, they are applied on S afterwards) May 20 12:42:49 Letothe2nd I think that there is a file with list of " feature = y " and " feature = n " some where ? May 20 12:42:52 qschulz, thanks. mm well, current issues is that i get just some .sh files, and bitbake claims about missing makefile May 20 12:43:23 gaston53: not exactly, but basically. May 20 12:43:58 gaston53: but there are more than enought documentation examples and tutorials on configuring a linux kernel out there that i really don't feel like repeating. May 20 12:43:59 angelo__: files in SRC_URI are copied to $WORKSPACE expect if there is something weird going on. That's it, if there's nothing more done, the files are just there (and if they are patches, they are applied on S afterwards) May 20 12:44:42 gaston53: it might, until you modify the recipe or clean your tmpdir, then the result of your menuconfig is lost May 20 12:44:51 it's really temporary May 20 12:45:10 angelo__: sorry, blip in my ssh connection and it sent the message again :) May 20 12:45:52 Letothe2nd maybe you mean yocto mega manual May 20 12:46:20 qschulz I think that I will face this problem soon .. May 20 12:46:36 gaston53: and the file might be in the git repo and not in yocto layer. And there might be conditional fragments... the only 100% success rate method is using menuconfig (or looking into the .config in the tmpdir of the recipe after configure has been done) May 20 12:46:51 gaston53: no, proper linux kernel documentation. May 20 12:49:38 qschulz please can you take a look here : https://www.linux4sam.org/bin/view/Linux4SAM/Sama5d27Som1EKMainPage#Build_Kernel_from_sources May 20 12:50:03 qschulz I am following this to build my kernel May 20 12:51:12 qschulz make ARCH=arm sama5_defconfig May 20 12:51:32 ## configuration written to .config May 20 12:52:08 At this step, you can modify default configuration using the menuconfig$ make ARCH=arm menuconfigNow, in the menuconfig dialog, you can easily add or remove some features. Once done, Move to with arrows and press this button hitting the Enter key to exit from this screen. May 20 12:54:17 qschulz sama5_defconfig is the default configuration , isn't it ? May 20 12:58:02 gaston53: well... who knows :) May 20 12:58:23 i would guess that its the default configuration for sama5 :) May 20 12:58:24 the defconfig can be passed directly to the recipe, or in the machine, can have additional config fragments May 20 12:58:47 so... default from the kernel repository yes. Is it the one used for your kernel in Yocto /me shrugs May 20 13:00:33 So after running " make ARCH=arm sama5_defconfig " and after opening the menuconfig and make changes and before building the kernel with " make ARCH=arm " command, what should I do in a certain way to make my modifications take place please ? May 20 13:05:22 autobuilder is locked up again :( May 20 13:06:09 gaston53: you're not using Yocto anymore right? make ARCH=arm ; make ARCH=arm menuconfig (save before leaving); make ARCH=arm savedefconfig (optional, if youw ant to save the defconfig); make ARCH=arm CROSS_COMPILE=arm-linux0gnueabihf -j`nproc` (to compile). But that's not a discussion to have on #yocto :) May 20 13:07:02 if you want to persist the config it's bit longer... I regret I haven't written this tutorial yet.. There are a few ways to do it and only a handful work for each kernel recipe May 20 13:22:49 paulg, zeddii: Are either of you any good with fs kernel D state hangs? May 20 13:25:19 sysrq to get a backtrace ? there is a specific sysrq for hung tasks, I forget the letter.... May 20 13:25:29 paulg: w, have that May 20 13:26:20 paulg: https://paste.debian.net/1147869/ May 20 13:26:48 paulg: its a git clone from an NFS share using clone by reference :/ May 20 13:27:15 paulg: this process isn't using any locks though, that is the parent which is waiting on it. So I don't think its NFS lock related May 20 13:27:54 paulg: I'm at a loss to figure out which file its struggling with May 20 13:28:06 (or why) May 20 13:29:16 hmm, I can look at /proc/XXX/maps and try and copy the files it has open on NFS May 20 13:29:54 which locks up May 20 13:30:58 Now I have two D state processes :) May 20 13:34:16 so we have an NFS file which hasn't changed recently which one worker can't cp but another can just fine May 20 13:35:39 that is the nice thing about D state turds, you can stack 'em up like cordwood. :-P May 20 13:37:13 * RP isn't sure what else can be done with this :/ May 20 13:38:44 All those 'Lock reclaim failed!' msgs aren't particularly encouraging. May 20 13:39:17 Is this a typical big distro build host kernel we are looking at? May 20 13:39:31 paulg: no, not figured out what the -254 means either. Its NFS "not supported" but *what* isn't supported, who knows :/ May 20 13:39:57 paulg: this is an suse tumbleweed but fedora31 has the same messges and issue May 20 13:41:32 use samba May 20 13:43:25 * Letothe2nd prefers tango. May 20 13:44:21 waltz May 20 13:44:44 zeddii: slow waltz is ok. vienna waltz, nope. May 20 13:44:59 * zeddii nods wisely May 20 13:45:14 I would think walts would be safer for Letothe2nd with his wallet chain whipping about May 20 13:45:15 * Letothe2nd was actually a relatively competent ballroom dance a couple of years ago. sadly out of practise, these days. May 20 13:47:17 Letothe2nd, did you have dancing boots? May 20 13:48:00 does anybody have any ideas on nfs debugging? :/ May 20 13:48:26 armpit: believe it or not, i did do quite a lot of classic ballroom dancing, and for my own wedding in snakeskin boots. May 20 13:48:44 nice May 20 13:49:14 snakeskin is formal enough May 20 13:49:18 RP: I can't say that I've ever debugged NFS hangs like that sucessfully, and ended up rebooting. but I assume these are consistently coming back through reboots ? May 20 13:49:27 armpit: yup. May 20 13:49:46 armpit: if i remember i shall show you some pictures. May 20 13:50:54 zeddii: yes, it keeps happening May 20 13:50:57 READ: May 20 13:50:57 632014263 ops (62%) 629809108 errors (99%) May 20 13:51:07 that does not look good May 20 14:00:18 hmm May 20 14:00:29 Looking at wireshark, "NFS4.1 client with NetApp NFS server encounters READ / NFS4ERR_BAD_STATEID loop" sounds like what I see May 20 14:00:36 Can't see the redhat solutions though May 20 14:05:51 zeddii: its sitting saying "read: no, error NFS4ERR_BAD_STATEID", "read: no, error NFS4ERR_BAD_STATEID" :/ May 20 14:06:33 did you say what kernel version the distro kernel is ? May 20 14:06:38 * zeddii scrolls May 20 14:07:00 zeddii: Linux version 5.6.11-1-default (geeko@buildhost) (gcc version 9.3.1 20200406 [revision 6db837a5288ee3ca5ec504fbd5a765817e556ac2] (SUSE Linux)) #1 SMP Wed May 6 10:42:09 UTC 2020 (91c024a) May 20 14:08:23 there's 6 NFS patches in the .14 5.6 -stable queue. hmm. May 20 14:08:51 zeddii: do you have a pointer? May 20 14:08:56 doesnt help you, but it does mean that there were quite a few NFS issues. May 20 14:09:26 sec. yes. May 20 14:09:52 zeddii: the fedora workers with the issue are also 5.6.11 :/ May 20 14:09:56 https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/ May 20 14:10:17 and here's the summary email: https://www.spinics.net/lists/stable/msg387100.html May 20 14:10:45 three fscache fixes, wonder if those could lead to the bad state. May 20 14:11:26 https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/releases/5.6.14 <--- for the ones zeddii mentioned May 20 14:18:14 no NFS issues here on 2.6.18-238.el5 but that doesn't mean our fileserver is better in any way :) May 20 14:20:20 zeddii: they don't look quite right but who knows :/ May 20 14:35:09 When building an image with machine qemuarm, i can not chroot into the rootfs because I get "Illegal instruction". Is qemuarm not usable on a real ARM system? May 20 14:37:05 sstiller: depends on the real machine and the tune. May 20 14:37:23 sstiller: Are you trying to run qemu on an ARM host? Or boot the qemu image on a physical ARM target? May 20 14:37:41 RP, have you tried nfsvers=3 as a workaround? May 20 14:37:57 paulg: no, not yet May 20 14:42:38 paulbarker: I built a rootfs with MACHINE = "qemuarm", extracted it on the real ARM device and tried to chroot into it. Other binaries in the image also lead to "Illegal instruction" May 20 14:42:56 CPU is ARMv7 May 20 14:43:20 sstiller: That's not expected to work, I'd recommend looking for a BSP for your target device May 20 14:44:05 sstiller: a simple reason might be different fpu tunes, for example. just as paulbarker said, this is not expected to work. May 20 14:48:04 paulg, zeddii: it looks like its calling TEST_STATEID and getting the reply NFS4ERR_NOTSUPP which the spec says it shouldn't :/ May 20 14:48:05 just armv7 is not enough for ISA compatibility for qemuarm we use cortex-a15 ISA so if you are using something like cortex-a8 based CPU implementatition it might not have certain instructions e.g. virtual extentions etc May 20 14:48:16 Its a 4.1 extension so using 4.0 would avoid it... May 20 14:48:41 RP: so some sort of mismatch between the nfs client and server ? May 20 14:48:56 zeddii: perhaps May 20 14:49:08 paulbarker, Letothe2nd: OK, I'll try to use a special machine of the processor vendor. I thought, there are some general ARM machines that can be used on different real processors with chroot or docker. May 20 14:50:03 qschulz after doing some researches I found this : https://stackoverflow.com/a/61290625/11406249 May 20 14:50:34 sstiller: It'd be good to have some generic ARMv7 target the same way we have `genericx86` and `genericx86-64` in meta-intel but I don't think we have those right now. Maybe something to go in the new meta-arm layer. Patches welcome :) May 20 14:51:17 paulbarker: its not that easy for arm as it is for x86 May 20 14:51:39 and since our build host is most of time x86 too helps the case too May 20 14:52:14 khem: No, not trivial, but a general armv7 tune and a kernel built with the `multi_v7_defconfig` should be possible May 20 14:52:37 for long we stuck to using armv5te ISA and year or so ago switch to using armv7+ May 20 14:53:07 thats not enough, you need machine implementation in Qemu as well, otherwise its of lesser use May 20 14:53:26 See for example Alpine Linux which has "Generic ARM" images for armv7 and aarch64. I don't know exactly what goes in there but they seem useful May 20 14:53:27 and qemu does not implement every arm CPU May 20 14:53:53 ok.. maybe you all can answer, easiest way to building a X86_64 IMAGE FOR A VM ? saw raw or qcow2? im having fits getting an iso installer out of intel-corei7-64 May 20 14:54:21 and obviously a vm cant install from the usb genned wic May 20 14:56:01 paulbarker: ubuntu and debian have too, for example. i also think it should be doable, basically it should just be restricting the tune to armv7a without any optionals May 20 14:56:30 I'm just thinking aloud as it's not something I'd have time to work on right now May 20 14:56:53 OutBackDingo: Maybe look at how AGL generates VMDK images May 20 14:57:44 paulbarker: for armv8 there is sanity and can be achieved to have a armv8 base ISA images and they will work on newer armv8 revisions for ARM32 bit its not that easy, look at what raspian does, they still tune for armv6+thumb1 and run those on rpi4 today May 20 14:58:07 jonmason and I talked about just such a thing in the context of reference binaries. It's in our Lyon presentation, but we haven't gotten back to it yet. May 20 14:58:45 gaston53: yup, that's one way. Your recipe should support config fragments though (usually a recipe that inherits linux-yocto or kernl-yocto or some class named like this) May 20 15:00:41 zeddii: there will be one custom CPU implementation which will break it, ARM is not east May 20 15:00:43 easy May 20 15:01:03 I'm aware ;) May 20 15:01:47 khem: zeddii: cue https://youtu.be/ZpUYjpKg9KY May 20 15:01:59 so somewhere you have to draw the line May 20 15:02:26 that's just what jon and I talked about, we just haven't been back to it, pandemics and all interrupted our flow. May 20 15:02:39 Letothe2nd, :D May 20 15:04:06 zeddii: though concerning the pure destructive aspect, https://youtu.be/HCBPmxiVMKk holds more wisdom. May 20 15:04:57 chainsaws and baseball bats. how can you go wrong!? May 20 15:05:12 :) May 20 15:07:30 zeddii: "lets just dress up as stupid as humanly possible". May 20 15:12:58 arm32 might not be easy, but arm64 should be May 20 15:13:48 Also, I think I have my debian system building again. PITA May 20 15:15:53 paulbarker: hrmmm interesting thought... and ive used AGL before..... ill have a look May 20 15:23:49 jonmason: yeah, and all desktop/server distros are doing that, I usually get a deb and run it if needed May 20 15:30:13 * OutBackDingo starts to hate on wic May 20 15:44:18 I simply created a machine which includes conf/machine/include/tune-cortexa8.inc And my test rootfs now works on am335x and i.mx6. No special BSP versions needed, I think :) May 20 15:46:54 sstiller: yeah as I said baseline for qemu is armv7ve not armv7-a which is what you are using May 20 15:47:04 so illegal instructions are explained May 20 15:51:03 zeddii: around? May 20 15:52:03 zeddii: this https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/?id=a1e3f5c92cdee7c4259b7be643bd829ce7c1efa3 doesn't seem to work, configure.ac does: AC_CHECK_PROG(PYTHON_CHECK,python,yes) May 20 15:52:07 if test x"$PYTHON_CHECK" != x"yes" ; then AC_MSG_ERROR([Please install python before installing.]) May 20 15:52:56 so with python3native it just shows that you should install python (as python3native does provide only python3 and "python" from host was already removed from HOSTTOOLS a while ago May 20 15:54:27 Hi guys, could I use cve-check in an already built yocto system? May 20 15:56:20 Just got "500 Internal error, please try again later." trying to email the meta-arm list. Anyone else having mailing list issues? May 20 15:58:22 zeddii: http://paste.ubuntu.com/p/VgyCqyXykC/ allows it to build, but I am wondering how it built for you before, you have tested your change, didn't you? :) May 20 16:01:52 vNistelroot: cve-check just looks at recipes/patches, it doesn't need to build at all May 20 16:02:23 vNistelroot: it needs to run in bitbake though, its not something that runs on target May 20 16:04:25 JaMa, if you see the list archives, I said when I did that bulk migration that it was to pass parse only May 20 16:04:37 and that people using the recipes needed to chip in fixes. May 20 16:04:56 * zeddii shrugs May 20 16:08:00 JaMa: if you have meta-python then python binary will be plugged in May 20 16:08:19 zeddii: hmm May 20 16:08:57 zeddii: ok, I'll send patch May 20 16:09:20 vNistelroot: https://hub.mender.io/t/how-to-run-cve-checks-using-the-yocto-project/1142 May 20 16:10:05 khem: through HOSTTOOLS? I don't see it in either meta-python nor meta-python2 May 20 16:10:18 ok. cool. I was going to blacklist it. but if you have something, I won't. May 20 16:10:51 https://github.com/shr-project/meta-webosose/commit/431cf34f1d9926919828c78892b7549e3d431581 May 20 16:10:58 just need to move this to meta-virtualization May 20 16:11:48 I’ll ping the original submitter as well, to see if they are going to uprev it, otherwise, I’ll add it to my todo. May 20 16:12:22 but yes, I’ll gladly take the patch, or if you want, I can cherry pick it from your repo and massage it into meta-virt. May 20 16:14:50 I'll test it first then send May 20 16:17:50 JaMa: nm I missed the context a bit but now I see it May 20 16:18:43 khem: OK May 20 16:24:44 anyone working on https://launchpadlibrarian.net/479890562/bind9_1%3A9.16.1-0ubuntu2_1%3A9.16.1-0ubuntu2.1.diff.gz for 3.1 ? May 20 16:58:17 I forget who was asking on yesterday's call, but Arm does provide a binary toolchain for building on Arm HW. https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads May 20 16:58:29 of course, there is no recipe May 20 17:02:57 jonmason: are those native or cross? May 20 17:04:48 native, but should "cross" for armv7 May 20 17:05:55 denix: do you have arm64 build servers? May 20 17:06:12 jonmason: nope May 20 17:06:45 I need get get my local one up and running May 20 17:24:09 jonmason: I worked on a project quite a ways back that used one of those. I did eventually get bored and prove to myself I could at least reproduce it by hand May 20 17:48:43 jonmason: i wonder if i could use an nvidia nano running yocto for a yocto build server :) May 20 17:48:55 probably be awful slow May 20 17:52:07 paulg, zeddii: https://marc.info/?l=linux-nfs&m=158999684930705&w=2 FWIW May 20 17:56:58 khem: please hold off using the autobuilder for now May 20 18:05:10 OutBackDingo: IIRc, YP can self host. So, go for it. Patches are welcome if you get the bin toolchain working :) May 20 18:06:52 We are upgrading the NAS to fix a blocking Autobuilder issue. There will be up to an hour outage for downloads.yoctoproject.org. May 20 19:01:41 RP, looks good - if only all bug/issue reports were that well detailed. :-/ May 20 19:02:27 (v.s. "shit doen borked. Can ane 1 hlp me plz?") May 20 19:05:11 RP, and I see Trond already replied with what amounts to STBU. May 20 19:05:43 Guess you are back to trying downrev on the nfsver.... May 20 19:06:40 Not sure I agree with his reply - goes against the old axiom of "be generous in what you accept, and conservative in what you send" -- or however it was worded. May 20 19:09:01 (in the context of networking and RFCs etc etc. - not about whether you get/put 10 quid with an xmas card) May 20 19:25:59 RP: or kanavin_home: I'm debugging atm why libbz2.so.1.0 (with .0) crept into my sstate built by a debian 10 machine although there is bzip2-native being build (which has only libbz2.so.1 and libbz2.so.1.0.6) thus leading to: May 20 19:26:00 rpmdeps: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory May 20 19:26:39 my current theory is that we build bzip2-native (providing bzip2-replacement-native) May 20 19:27:22 as requested by rpm-native May 20 19:33:29 but there is no EXTRANATIVEPATH += "bzip2-native" in rpm ... only ever see that in python-native_2.7.18 May 20 19:33:46 where it was introduced back in 3f05622ba May 20 19:34:34 so I wonder: how would rpm-native get the proper bzip2-native/libbz2.so May 20 19:35:31 ah, EXTRANATIVEPATH is only for 'PATH' aka executables May 20 19:35:33 hmm May 20 19:37:59 https://paste.debian.net/1147978/ May 20 19:42:07 RP: ok np May 20 20:54:29 paulg: I did reply pointing out that it could handle the situation a bit more gracefully but I am clearly an idiot user ;-) May 20 20:54:53 paulg: For us it should become a non-issue as we've upgraded the server to something which supports this May 20 20:55:12 paulg: shame about the next person to find it though :( May 20 20:55:22 khem: we're back up now May 20 21:07:36 RP, at least if someone googles for it now, they have a chance to find your post and Trond's answer.... May 20 21:31:37 paulg: right, that is something I guess May 21 00:10:00 kergoth: was bb already replaced by something after tinfoil2 changes in pyro? both https://github.com/kergoth/bb/issues/34 and last line of https://wiki.yoctoproject.org/wiki/Tinfoil2 look like it's (still) dead May 21 00:55:19 Can the sstate cache be shared between different builds like the downloads dir? May 21 01:03:31 aaronov:yes May 21 02:00:39 khem: It didn't seem to specify it was safe in the local.conf comments. If I have two different local.conf's - they can share the same sstate? May 21 02:26:03 aaronov: same machine type? and no distro feature changes? May 21 02:27:21 JaMa: honestly i just haven't gotten to it. certain functions have alternatives, such as oe-pkgdata-util, oe-depends-dot, etc. rburton fixed a subcommand or two on his fork May 21 02:27:56 JaMa: would like to fix it at some point, there's definitely still gaps, and i like the subcommand-based approach May 21 02:28:10 mranostay: there might be differences in those May 21 02:28:11 i haven't put much time into oe/yocto work outside of work hours in quite a while May 21 02:28:50 still enjoying it during work hours, so not completely burnt out, just have other focuses for that time May 21 02:29:03 maybe i can talk mentor into letting me fix it during work hours May 21 02:29:04 heh May 21 02:31:07 mranostay: yep, looks like we have different distro and machine type using the same sstate cache May 21 02:31:24 I assume this could cause some strange issues? May 21 02:31:40 aaronov: nothing wronng with that May 21 02:32:00 i use a single sstate cache for every build i do on my machine May 21 02:32:49 Ok. I was concerned as the comment in local.conf for download cache says "This directory is safe to share between multiple builds on the same machine too." May 21 02:32:59 But it does not have the same statement for sstate May 21 02:34:34 yeah, that doesn't mean anything, might be a good idea to open a bug suggesting it be made consistent to avoid confusion and clarify the usage **** ENDING LOGGING AT Thu May 21 02:59:57 2020