**** BEGIN LOGGING AT Tue May 19 02:59:57 2020 May 19 04:14:29 is there any way to un-inherit a class from bbappend? May 19 04:46:34 heh no May 19 06:17:54 does anyone know how to build a python package with a built time dependency on a module such as python3-jinja2, I have tried adding the module to RDEPENDS and DEPENDS but it still does not work May 19 06:18:46 dggonz: given the assumption that there is a recipe providing this, you would DEPEND += "python3-jinja2-native" May 19 06:19:48 dggonz: in a nutshell: "if you need it at build time, it has to be -native" May 19 06:46:08 thanks! I am going to give that a try May 19 06:58:10 Hello all, i'm refactoring an old project (based on Krogoth) but i'm stuck on an issue strange issue, inside the image.cpio.gz /init is empty o.0 I don't what is appening ... any help will be greatly appreciated :) Thx! May 19 06:59:37 Ninic0c0: without any more details, one can probably only say "it seems to be broken" May 19 07:08:09 Letothe2nd Of course but i' don't where the trouble come from (so i'm searching here some clues). During boot I got Failed to execute /init (error -13), I have open the cpio to take a llok init is empty, same issue after clean build. SO the trouble is in my conf :S May 19 07:09:28 Ninic0c0: well the closest idea would probably be to look at the recipe that shall provide /init and find out why it doesn't May 19 07:09:42 Ninic0c0: you can also try and build parts for qemu May 19 07:12:53 Letothe2nd thank you, i'm taking a look to image_types.bbclass, it's strange because the file exists but it's an empty file May 19 07:13:18 Ninic0c0: maybe its just a link? May 19 07:21:12 Letothe2nd after double check it's an empty file, not a link inside tmp/work I can find "1.0-r0/cpio_append/init May 19 07:22:10 Ninic0c0: is this a highly custom image type? what happens if you build an ext4, for example` May 19 07:24:14 Ninic0c0: well, for starters error -13 says permission denied May 19 07:24:30 Letothe2nd no it's a really basic image for testing based on core-image-minimal May 19 07:25:02 in fact should be really simple but i don't know if it's a kernel misconfiguration or something else May 19 07:25:24 Ninic0c0: we do need more details but the cpio image usually is used for the one loaded to ram May 19 07:25:49 alejandrohs feel free to ask i'm not Yocto expert :S May 19 07:26:17 alejandrohs I'm using the cpio to build basic FIT image May 19 07:26:30 hmm May 19 07:27:01 the FIT image includes both the kernel and rootfs May 19 07:27:29 yes but my cpio is boggus so the FIT also ... May 19 07:29:02 Ninic0c0: Id be interested in knowing what some variables are defined to May 19 07:29:20 INITAMFS_IMAGE May 19 07:29:44 KERNEL_IMAGETYPES May 19 07:31:21 bitbake -e | grep INITAMFS_IMAGE May 19 07:31:29 would tell you whats defined to May 19 07:31:37 and where that definition is coming from May 19 07:33:59 alejandrohs thank you for advice i'm doing that May 19 07:34:34 alejandrohs KERNEL_IMAGETYPES=" zImage" May 19 07:35:55 but INITAMFS_IMAGE is empty May 19 07:38:45 Ninic0c0: well that s your first very good clue May 19 07:39:09 Ninic0c0: sadly Im about to go to bed, but that should be defined May 19 07:39:37 Ninic0c0: If you look at the kernel-fiimage class May 19 07:39:56 you can see that it will be looking for an image defined in INITAMFS_IMAGE May 19 07:40:05 to prepare the FITimage itsel May 19 07:40:08 itself May 19 07:40:13 alejandrohs Thank you for pointing me that. I will check this part. Thanks for your time, have a nice night ! May 19 07:41:06 you can also look at the work directory oof the image and look at the log of the assemble_fitimage task May 19 07:41:23 to see how its being assembled and what its looking for May 19 07:42:48 Ninic0c0: also look at the do_assemble_fitimage_initramfs task May 19 07:42:57 alejandrohs i will :) May 19 07:43:04 it really depends on what yure trying to achieve what the class itself will do May 19 07:43:22 its likely youre just missing some definitions and you can get it working that way May 19 07:43:25 night! May 19 09:52:01 hello all, I'm still stuck on /init issue, after tracking inside Yocto I have found something strange. I'm using zeus branch and meta-xilinx (zynq and zynqMP board). from http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image_types.bbclass?h=zeus#n139 i can see the build process touch the init, so when I boot it's an empty file. Any May 19 09:52:01 idea ? May 19 10:03:28 in addition, someone here could tell me how tmp/work/../rootfs/sbin/init can be missing ? May 19 10:56:01 Dear all, I hope you are all fine and healthy. I have another stack overflow question and since it turned out to be efficient to discuss this here as well... well here I am :) May 19 10:56:14 To those who have a second: https://stackoverflow.com/questions/36595517/read-only-file-system-on-yocto May 19 10:56:46 ups wrong link May 19 10:56:59 here we go https://stackoverflow.com/questions/61889312/correct-handling-of-persistent-files-for-readonly-rootfs May 19 10:57:00 sorry May 19 10:58:41 emrius: we rather replace the volatile files with links to some filesystem that is rw (or can be made rw) May 19 10:59:58 Letothe2nd ok but I thought that e.g. passwd should be persistent, not volatile? I mean that was the whole point. To clarify `/data/etc/` will be the rw filesystem May 19 11:00:43 with persistent I mean that I survives reboots and can be altered by the system. May 19 11:01:10 emrius: volatile in the meaning of "not read only". May 19 11:01:26 not in the meaning of "transient" May 19 11:01:26 yes May 19 11:01:38 thats what i meant. May 19 11:01:49 ok, we are on the same page then :) May 19 11:02:01 probably, I used wrong semantics May 19 11:02:56 Am I guessing right, that the user `marius` (me) might be the issue here? May 19 11:03:03 emrius: its just that it is not going to work the way your imagine your recipe. this would basically be a recipe that alters the packages of n other recipes, which is not how the artifact flow works. May 19 11:04:00 Letothe2nd ok. What would be the correct way of finalizing the image? Or should this done on a 'per recipe level'? May 19 11:04:21 I mean finding the recipe that creates, e.g. passwd and write an 'do_install_append' there? May 19 11:05:02 emrius: that would probably work, yes. May 19 11:05:48 ok. Actually, that's what I did e.g. with the wifi configurations directory of NetworkManager and, yes, that work. May 19 11:05:50 But May 19 11:05:59 alternatively a postprocessing stage. it really depends a bit on the exact use case, and how the "volatile" data is meant to end up in the rw filesystem. think: updates? May 19 11:06:45 I thought it would be convenient to have this final modification of the filesystem in one single go May 19 11:06:59 updates? May 19 11:07:33 updates. like, how will your data behave if you roll out an update to the device? May 19 11:07:44 What other stage would you be thinking of? I attached this to `ROOTFS_POSTPROCESS_COMMAND += "move_to_persistent;"` May 19 11:07:50 Bad/wrong choice? May 19 11:08:03 11:05 < Letothe2nd> alternatively a postprocessing stage. May 19 11:08:14 but now, lünch May 19 11:08:27 I'm using an A/B updating service (mender) to roll out the entire partition May 19 11:09:28 This, I just need to ensure that a few files remain persistent over updates through a symbolic link into a persistent data storage (read/writeable by the system) May 19 11:10:01 then the persistent rw storage cannot be part of the update, right? May 19 11:10:05 think about it. May 19 11:10:22 ok. Guten Appetit :) May 19 11:10:47 hello May 19 11:10:52 I'll have a lunch break too and think about it then May 19 11:12:00 ah of course it can! I was probably mixing volatile, persistent semantics facts. Not only the wording. Ok thanks for now! May 19 11:13:36 was wondering if anyone can point me to where this timeout is set. thanks May 19 11:13:52 Please configure a few basic system settings: May 19 11:13:54 Started udev Coldplug all Devices. May 19 11:28:30 kukela_cd: this basically misses all context, even the question. May 19 11:28:44 thanks for your replay May 19 11:29:13 i was trying to get a new version of systemd working on rocko( systemd 241) May 19 11:29:30 i needed a feature only found in the new version May 19 11:29:57 i ported the 241 recipes from thud-next May 19 11:30:16 i have it mostly working but have an odd issue when i 1st boot the image May 19 11:30:40 it timeout on waiting for my boot partition when rebuilding the hardware database May 19 11:30:57 Please configure a few basic system settings: May 19 11:30:58 Started udev Coldplug all Devices. May 19 11:31:01 kanavin_home: https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/1046 another mesa issue :( May 19 11:31:01 Systems. May 19 11:31:08 this only happens on 1st boot though May 19 11:31:15 after that all seems well May 19 11:31:44 i was wondering if anyone knew how to change this timeout or had seen something similar in the past. May 19 11:31:55 kukela_cd: no idea me personally. neither my expertise nor do i actually care much for rocko :) May 19 11:31:56 zeddii: there is also a kheaders reproducibility issue in https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/1046 :( May 19 11:32:03 lol May 19 11:32:08 thanks May 19 11:32:50 i think it is just a dependency issue but cant find the right service files to tweak May 19 11:33:09 not much out there on google either May 19 11:33:28 kukela_cd: i'd go digging in the direction of systemd firstboot facilities, but again.. just guessing, no real knowledge. May 19 11:35:25 blast.... cant seem to conver intel-corei7-x64 wic image to iso May 19 11:35:51 thanks ill take a look there May 19 11:35:54 cant hut May 19 11:35:57 hurt May 19 11:55:33 RP: seems like could be tumbleweed specific? I'll take a look. May 19 11:57:19 RP: runqemu - ERROR - Could not determine the path to dri drivers on the host via pkg-config.Please install Mesa development files (particularly, dri.pc) on the host machine. May 19 11:57:32 seems like that host is missing a package May 19 11:57:57 so nothing major hopefully :) May 19 11:59:37 one more question letothe2nd May 19 12:00:09 do you know the name of the service that mounts file systems at boot May 19 12:00:52 i think i might just be a dependency issue May 19 12:01:17 kukela_cd: i do not, systemctl list-units and see if something looks like mount :) May 19 12:08:13 kanavin_home: hopefully. I guess we need to let Michael know whats missing May 19 12:08:16 and update the docs May 19 12:18:30 I'm really confused to ask again but i'm stuck on that from several days ... I have generated a Yocto image and the rootfs.cpio doesn't contain /sbin/init so i got error -13 during boot. I have tracked the issue until https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image_types.bbclass#n141 Some one could point me the direction to May 19 12:18:30 find what's append ? May 19 12:18:46 For info it's a really basic image based on core-image-minimal May 19 12:19:23 i'd look at what the difference is between your image and core-image-minimal May 19 12:19:41 specifically you probably ended up overwriting the default package list, removing systemd/sysvinit (which provide init) May 19 12:30:19 hey letothe2nd thanks for the help May 19 12:30:42 the 1st boot service had some new flags enabled that caused it to trigger May 19 13:03:22 RP: I can have a look later today if my backlog catchup goes well .. holidays and all that jazz just chew up time on the return. But obviously this is a different config than I tested on the AB before, is that popping up everytime now, but still passing on the quick build ? May 19 13:04:29 zeddii: its simply intermittent, I don't know why May 19 13:05:48 zeddii: best data we have is probably going to be from decompressing and comparing https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200519-3_asiv0_/packages/ May 19 13:06:09 hey! i have a question on multilib and RDEPENDS. if recipe foo RDEPENDS on daemon bar and i build lib32-foo, is it possible to build daemon foo still lib64? i'd like to minimize lib32 stuff on my system. so only shared libs foo uses should be lib32. this this possible? May 19 13:06:26 gotcha. I can start by grabbing the known fail and have a look. Some rogue timestamp. May 19 13:06:35 @rburton I have followed your advice, I have created a new image and add my stuff step by step to find where is the issue, and surprise I found it. The guy before use IMAGE_INSTALL_ += " some package" Yocto is agree with that ? because if this line is remove the link is made between /init and /sbin/init May 19 13:06:39 stange ... May 19 13:06:55 zeddii: I think we'll have to reverse engineer what happened, see what the difference is, then see if we can work out why that happened May 19 13:07:35 agreed. since I already hit the obvious build side fix, we’ll need to dig that way to get a hint. May 19 13:08:01 see. this is proof that Tuesday after a holiday Monday, is still a Monday! May 19 13:08:17 derRichard: how can it know if daemon is standalone or a lib? May 19 13:09:07 RP: i don't know, i thought maybe you have lib64-RDEPENDS variable or such May 19 13:10:26 derRichard: it works differently, if both 32 and 64 bit images pull some binary thing in, the primary one will wil May 19 13:10:43 derRichard: so it is possible you'd see what you're after May 19 13:11:42 RP: so, if pirmary is lib64, and lib32-foo REDEPENDS on say bash. lib32-bash and lib64-bash will get build but only lib64-bash will make it into the image? May 19 13:18:18 derRichard: right May 19 13:18:48 Ninic0c0, if is in OVERRIDES, it will override IMAGE_INSTALL. and I'm guessing IMAGE_INSTALL_ is empty to begin with, so it will just contain "some package" May 19 13:20:44 kroon ok is good to know Thx !! Do you the simple way to add specific package only for one specific board ? maybe Yocto doesn't agree with that ? May 19 13:20:47 Ninic0c0, you might want IMAGE_INSTALL_append_ = " some package" instead May 19 13:20:56 to add to what kroon just said, you most probably want IMAGE_INSTALL_append_ = " some_package" May 19 13:21:00 kroon: damn it May 19 13:21:32 qschulz @kroon thx guys is fixed now :D May 19 13:21:50 Ninic0c0: also... depending on which package we're talking and if it should be in any image built for the machine, the package might have its place in the machine configuration file in MACHINE_EXTRA_ESSENTIAL_RDEPENDS or RRECOMMENDS May 19 13:22:45 RP: very cool, i can work this that. thx! May 19 13:22:52 *with this May 19 13:25:29 qschulz always good advises Thx i will do that :) May 19 14:08:52 RP halstead I checked - Mesa-dri-devel package is needed on tumbleweed May 19 14:20:06 So I resolved that postgresql issue I was having yesterday. Just wondering how I might be able to run the setup command `postgresql-setup initdb -D /var/lib/postgresql/data` after it's been installed. Tried it in ROOTFS_POSTPROCESS_COMMAND but got an exit code. Thoughts? May 19 14:21:25 bsmerbeck: depends on where it needs to be run? in-target on first boot, or at build time? in that case you would need a -native dependency and should rther extend the do_install stage. May 19 14:22:59 Letothe2nd: I've had it work when I run the command manually at first boot, but I'm trying to get it all situated at build time. I'll take a look at the extension and see if that gives me something May 19 14:23:46 bsmerbeck: in that case i probably would go the route through a recipe that depends on -native and runs things on do_install. May 19 14:31:22 Looks like there was already an attempt at running it in a setup-script, lovely May 19 14:31:53 :) May 19 14:32:01 https://pastebin.com/m3S8bki0 May 19 14:32:07 now to just find out why it's not working :D May 19 14:32:11 * armpit too early to start working May 19 14:52:29 denix, khem: FYI using "-mno-outline-atomics" fixed optee. I sent a patch upstream May 19 14:56:43 what is yocto trying to tell me? http://paste.debian.net/plainh/4446b1c6 May 19 14:56:59 i run "bitbake my-image" May 19 14:57:19 and my-image being multilib depends some lib32-recipes May 19 14:57:26 building lib32-my-image works fine May 19 14:57:37 YPTM: armpit is on May 19 14:59:01 YPTM: Joshua Watt on May 19 14:59:25 YPTM: Scott Murray is on May 19 15:01:42 YPTM: Jan-Simon Möller is on May 19 15:24:11 kanavin_home, Mesa-dri-devel is installed on all the Suse workers now. May 19 15:24:55 JPEW: also see if it works with gcc < 10 May 19 15:26:14 kanavin_home, Do we need to list it at https://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#opensuse-packages or this is specific to the AB? May 19 15:32:57 Dear all, after posting this question: https://stackoverflow.com/questions/61889312/correct-handling-of-persistent-files-for-readonly-rootfs May 19 15:33:58 [grrr. I'm always forgetting that shift + return doesnt start a new line. Anyway...] May 19 15:35:37 halstead: this is needed only for a specific non-default option to runqemu, which is tested with oe-selftest. May 19 15:35:59 Thanks kanavin_home. May 19 15:36:23 halstead: but later on (when support for that option is enabled by default), the manuals should be updated. May 19 15:37:29 I found out that e.g. passwd is explicitly compiled not to follow symbolic links. At the same time files such as `/etc/passwd` need to be writable for the system. Thus, when I make rootfs readonly, I have to put `/etc/passwd` somewhere else, right? Does this mean, I have to patch the compilation of `passwd` to remove the flag that avoids following May 19 15:37:30 symbolic links? This seems odd to me from a security perspective and given that readonly rootfs is a pretty standard thing (I think) I was wondering if I'm missing something obvious here. May 19 15:38:01 I mean put /etc/passwd somewhere else and symlink it back to /etc/passwd May 19 15:43:00 So, I've now tried several different means of getting postgresql installed and running on a built minimal image. The `postgres` user is added, and the relevant binary files are accessible. Yet, it seems that the data directory isn't being initialized. The command to do so, which works when executed manually on first boot is `sudo May 19 15:43:01 /usr/bin/postgresql-setup initdb -D /var/lib/postgresql/data`. Trying to start the service returns the following error: `directory "/var/lib/postgresql/data" is not a database cluster`. This is, supposedly, handled in the setup script `postgresql-setup`. This is `postgresql` supplied by meta-oe/recipes-dbs and I'm running the dunfell branch. Any May 19 15:43:01 thoughts on how to debug this or fix it? Thanks in advance May 19 15:48:42 If a package can be built succesfully but dnf complains there are no providers in do_rootfs where is a good place to start looking? May 19 16:08:07 jrdn: we have issues in thud with packages in BAD_RECOMMENDATIONS but are RDEPENDS, that's one hint. Ohterwise I think it would make sense to share a bit more logs/context :) May 19 16:12:00 qshulz: I'm on the warrior branch having issues with a freescale xorg driver: 'xf86-video-imx-vivante'. bitbaking the recipe works and the package output looks fine but in do_rootfs I get a nothing provides error for 'xf86-video-imx-vivante' May 19 16:12:37 RP: can you push a 'v2.4.0' tag here please? would fix the broken version check nicely. May 19 16:12:44 http://git.yoctoproject.org/cgit/cgit.cgi/ptest-runner2/log/ May 19 16:16:36 jonmason: Congrats on the first release branch of meta-arm! May be worth reposting to yocto-announce May 19 16:17:26 I've joined the meta-arm list now so I'll try to structure my toolchain rant into some constructive comments :) May 19 16:20:40 khem: It passed on the optee-os CI, which uses an older GCC May 19 16:23:59 Trying to execute the postgresql-setup initdb in rootfs_postprocess_command seems to just throw a bunch of permission denied errors. Tried running as su as well as postgres May 19 16:35:51 paulbarker: if your toolchain rant is BINARY TOOLCHAINS SHOULD ALL DIE then i'll +1 you straight away May 19 16:37:43 rburton: It was along the lines of, if they do exist and I'm forced to use them they should at least not break the archiver, SDK generation, etc, etc May 19 16:38:10 wuss May 19 16:38:26 haha May 19 17:17:39 paulbarker: I tried to email announce, but got an error. I was going to hassle halstead, but took lunch instead :) May 19 17:19:04 jonmason: Taking lunch is always the correct option May 19 17:19:57 I think you need a moderator to post the announcement to yocto-announce. I'll need to look at this for the SanCloud BSP release which should be happening soon May 19 17:19:59 paulbarker: don't encourage rburton May 19 17:23:34 paulbarker: I've heard you got to spar with Bill again today... :) May 19 17:23:58 paulbarker: it is good I wasn't in the middle of it :D May 19 17:27:27 denix: I was sticking up for you. "There are good people at TI" May 19 17:27:42 khem: TCLIBC=musl build: ERROR: Task do_install in poky/meta/recipes-core/glibc/glibc-locale_2.31.bb depends upon non-existent task do_stash_locale in poky/meta/recipes-core/musl/musl_git.bb May 19 17:28:08 looks like I'm one of those poor debian souls who are seeing the qemu build problems May 19 17:28:48 paulbarker: btw, for TI stuff you are not forced to specific toolchain. meta-ti BSP doesn't care about toolchain at all. meta-arago Distro uses prebuilt by default as that's what gets tested and used by customers, but I actually support both, so one can easily do TOOLCHAIN_TYPE=internal May 19 17:29:05 Is this issue described on the mailing list? I can try to get the Arm Debian guy to fix it for us May 19 17:29:10 jonmason: ha! May 19 17:32:28 jonmason: does tf-a packaging fix qualify for dunfell backport? May 19 17:33:10 denix: the noackages patch? May 19 17:38:38 jonmason: yeah, that one May 19 17:39:13 denix: if you have a need for it in dunfell, then sure. May 19 17:39:33 I probably need a way of specifying the branch May 19 17:39:54 though, it is probably not going to be frequent May 19 17:42:30 jonmason: yeah, understood May 19 17:43:23 push to dunfell branch too May 19 17:43:28 everything should be up to date now May 19 17:44:51 jonmason: oh, thanks a lot! May 19 17:45:22 JPEW: are you still interested in having the qemu secureboot in meta-arm? May 19 17:50:32 damnit, gcc 10 broke my imx build, more getauxval fallout May 19 17:52:47 30 built attempts later...this stupid database is going to drive me insane May 19 17:58:27 denix: With my Yocto hat on I'm happy to use TI layers without the external toolchain. But with the customer hat on I need to use what TI has tested and what the FAEs and support engineers will actually be able to help with. The customer needs to not be up a particular creek if I disappear under a bus. May 19 17:59:51 If anyone wants to lend a hand, it would be appreciated. I know it's probably trivial to solve but I've run out of ideas May 19 17:59:56 For Sancloud we now support two configs: Poky distro with meta-ti & the internal toolchain and Arago distro with meta-ti, meta-arago & the external toolchain May 19 18:06:28 dl9pf: that dependency is not expected so trace it why glibc-locale is being pulled into a musl build May 19 18:07:07 paulbarker: sounds good. yeah, I also have to support both configs. just wanted to make sure people are aware there's an option of Arago with internal toolchain with a single switch May 19 18:09:53 denix: TI supports binary toolchains for end users with support contracts etc. ? e.g. if there is a gcc bug found by end user then how do you handle it May 19 18:10:43 khem: actually ARM provides that contract. and used to be Linaro before May 19 18:11:24 khem: that's the whole reason for TI to stick to those prebuilt toolchains - Yocto doesn't provide toolchain support contracts May 19 18:12:14 yeah I see, so a shoulder to cry on :) May 19 18:12:24 heh :) May 19 18:14:59 On that subject, I just got a failure running `bitbake tisdk-base-image -c populate_sdk` on dunfell May 19 18:15:14 Is SDK generation tested for Arago? May 19 18:26:39 jonmason: Ya, I need to update the patchset based on feedback from denix May 19 18:28:12 JPEW: I'm willing to pull it in. I jsut verified with management that it is okay May 19 18:29:33 jonmason: Cool... It might take me a bit to get the patches updated May 19 18:30:16 jonmason: I think there is also a lot of interest in moving TF-A and optee to oe-core, but we can rehash that later May 19 18:30:23 paulbarker: yeah, the old meta-toolchain style - there's some extra sause in meta-toolchain-arago to support some legacy workflows, as people are scared of yocto and demand their old code to be preserved :) I keep un-breaking -c populate_sdk, but it's not constantly tested May 19 18:30:52 paulbarker: send me logs for the error and I'll take a look May 19 18:31:17 denix: I might have a patch instead let me see what happens May 19 18:32:43 denix: The error was `nothing provides libatomic-dev needed by packagegroup-core-standalone-sdk-target-1.0-r8.armv7at2hf-neon`. The external-arm-toolchain recipe in meta-arm should have that in PROVIDES (as it does build a `libatomic-dev` package) but it didn't May 19 18:33:17 It's now rebuilding the whole world since I changed the toolchain recipe though May 19 18:33:49 JPEW: huh, where does this newfound interest in moving tf-a and optee to OE-Core come from??? May 19 18:37:04 jonmason: what you dont have NIH syndrome at ARM ? May 19 18:39:13 denix: that comes from me :) May 19 18:43:31 Khem: ha! May 19 18:44:40 So obviously this IRC isn't the place to ask for help. What mailing list/channel would you recommend for issues regarding your builds using OE layers/recipes? Spent two days asking here and don't want to waste mine or anyone else's time with constant messaging. Building an image for the Jetson Nano Dev Kit by NVIDIA (using meta-tegra by madisongh) May 19 18:44:41 - if it matters. May 19 18:52:14 khem: where were you back when I proposed it originally to get it into oe-core? everyone was like no-no-no, it should go into meta-arm! May 19 19:01:41 bsmerbeck: Are you using a pre-packaged set of layers from a vendor? May 19 19:07:21 paulbarker: From a vendor? I wouldn't say so. Just using the layers available through openembedded's layer-search to gain access to the packages used on the device before trying to go the custom image route. The only layer not from the primary open-source ones is my custom layer simply defining the image I'd like to build. It's basically just May 19 19:07:21 `core-image` with `meta-tegra` to define the BSP. Everything's gone great, but the `postgresql` recipe available through `meta-openembedded/meta-oe` is not too happy and has constant errors. It has init and setup script included to initialize the database cluster on intstall, yet it's not initialized on first boot. I've tried putting the command May 19 19:07:22 into a rootfs-postprocess function but that gave similar errors. Should be able to have the psql database initialized and running on first boot but there's not been someone having a similar problem through my two days of searching online. May 19 19:08:12 bsmerbeck: Can you reproduce the postgresql failure without meta-tegra or your custom layer? May 19 19:08:24 Likely, I'll run that build now May 19 19:08:59 bsmerbeck: That's the direction I'd go. If it's reproducible with a minimal set of layers look at the README for the layer containing the postgresql recipe May 19 19:09:22 If it's only reproducible with meta-tegra then blame your BSP and see what their support or mailing list address is May 19 19:12:01 paulbarker: will do. Thanks for the direction May 19 19:13:54 * paulbarker swears incoherently about pre-built toolchains May 19 19:16:27 denix: `/opt/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/lib` contains libatomic.so and libatomic.a but it doesn't get copied into the external-arm-toolchain packages. SDK generation fails as packagegroup-core-standalone-sdk-target requires `libatomic-dev` which doesn't get created as the files are missing May 19 19:16:47 paulbarker: TI would never steer you wrong ;-) May 19 19:17:13 jonmason: I think the issue is in the toolchain recipe not anything TI related :p May 19 19:17:40 It's a poor workman that blames his tool(chain)s May 19 19:18:19 I need to provide an SDK to our supplier this week so they can help debug some hardware so I'll see if I can fix the recipe May 19 19:18:47 oh, so this is extra relevant for you then. Sorry for teasing May 19 19:19:05 Yes, patches are very welcome May 19 19:19:27 denix has done a good job of fixing them up from what they were when I got them May 19 19:24:20 denix: you perhaps did no explain it well back then May 19 19:24:34 jonmason: and I've done it again and again when they were at meta-linaro - it's a constant battle May 19 19:25:01 khem: heh, sure :) May 19 19:26:27 denix: if you associated it well wih qemuarm64, I think it would have been better May 19 19:27:31 its better for us to test common boot scenarious and if tf-a +optee is common and can be tested in qemu then core could be a place for it May 19 19:27:46 khem: it's more generic to aarch64, but sure, qemuarm64 is a selling ticket... :) May 19 19:30:21 right, e.g. sbc for riscv is in same type of things where the qemu boot is using it and real h/w too so its a good test to use it in qemu May 19 19:41:13 denix: What's the purpose of the `external-arm-toolchain.bbappend` files in meta-arago? It all looks like things which should be upstream May 19 19:42:06 * paulg stops spamming zeddii with preempt-rt updates May 19 19:42:07 paulbarker: I've been upstreaming as much as possible May 19 19:46:01 denix: So these are mostly local fixes to issues with the external-arm-toolchain recipe? Plus using TI kernel headers? May 19 19:46:10 If I'm understanding correctly May 19 19:46:46 paulbarker: it got much-much better since moving upstream to meta-arm (I guess because of clean slate?), but there may be couple more smaller items to rework and upstream - I just had to switch to other things for the release May 19 19:47:02 denix: Understood May 19 19:47:55 I don't envy your job supporting this but it does look like things are moving in the right direction May 19 19:49:21 paulbarker: thanks! May 19 19:50:10 TI should be giving you hazard pay for having to look at it May 19 19:51:24 lol :) May 19 19:53:02 paulbarker: https://i.kym-cdn.com/photos/images/newsfeed/000/021/347/1248075250110.jpg May 19 19:57:23 moto-timo: https://github.com/garmin/pyrex/pull/47 May 19 20:57:33 denix wears a hazmat costume while working on it May 19 20:58:07 JPEW: nice. I might still need to change system defaults. I'll try again May 19 20:58:14 khem: the goggles do nothing! May 19 22:02:32 what the fuck. rsync just scp'd down my wic image, etcher flashes it and says it fails. i *know* this card is fine. and now it's bitching about alignment or something May 19 22:02:35 :( May 19 22:02:39 it's just one thing after another for me today May 19 22:03:13 * kergoth wipes tmp to rebuild it yet again just in case.. May 19 22:03:22 kergoth, that sounds like a "walk away and crack a beer" moment. May 19 22:03:39 else you risk cracking a keyboard or u-SD card. May 19 22:04:17 ugh, yes. i've been trying to do something as simple as some basic runtime testing on this dev board for like a week, previously banging my head into the wall tryingi to get fitimage happy with me, now it's just fucking up left and right May 19 22:04:42 before this etcher problem i had it booting, was great, realized i was missing a driver for usb wifi. went back, enabled it, rebuilt, scp, flash, no serial output trying to boot the card at all. nothing. May 19 22:04:52 enabling one damn driver should not have somehow hosed u-boot May 19 22:04:59 particularly since i didn't touch u-boot at all May 19 22:05:03 * kergoth sighs May 19 22:05:05 it's like Monday round two :) May 19 22:05:13 and yeah, i think you may have a good idea there May 19 22:05:14 kergoth: not that its any consolation but this is me and the autobuilder atm :/ May 19 22:05:54 misery loves company, eh? :) May 19 22:06:31 getting away from it might not be a bad idea. common mistake to keep stubbornly trying to progress and wasting time when a 5 minute walk might make the answer pop into my head May 19 22:06:43 kergoth: its a good plan May 19 22:06:52 Virtual monday in Kanuckistan ; yesterday was a holiday. May 19 22:06:53 * RP will head to bed in a minute May 19 22:06:54 used to make that mistake a lot when i was younger. common issue amongst inexperienced coders i think May 19 22:07:07 stay up late banging my head into the wall and fix it in 5 minutes in the morning :) May 19 22:07:21 still manage to make it once in a while now though.. May 19 22:07:28 ha, I guess my advice reveals me as an old fart. May 19 22:07:33 haha May 19 22:09:10 kergoth: there is the opposite effect where you get home from the pub on a Friday night and realise how to fix runqueue :) May 19 22:09:27 * RP hasn't done that in a while, perhaps that is the problem May 19 22:09:51 next morning the code works but you don't know how/why :) May 19 22:10:27 I'm sure 2am post-pub commit logs explain everything.... May 19 22:11:36 "I;ve alllwayz hated allz these crap and shoulda rewoten it 2 years zzaogo. Now times loke the pserent." May 19 22:12:52 :) May 19 22:16:04 does git have a breathalyzer plugin? :) May 19 22:16:36 and block all that inspired content!?! May 19 22:17:29 https://xkcd.com/323/ comes to mind.. May 19 22:19:55 added a handy little script to my dotfiles. wait-for-build == lsof +r -f -- "$builddir/bitbake.lock" >/dev/null 2>&1 May 19 22:20:26 spins waiting on my build to complete, or returns immediately if it's not running. combine that with a local scp/rsync and can immediately kick off a script to rsync the image down for flashing form a remote build server before its done May 19 22:20:35 downside, have to point it at a specific builddir, but.. May 19 22:21:17 who let mranostay in? May 19 22:31:08 ask mranostay ? May 19 22:40:55 argh! it wasn't my microsd card, it was my microsd to sd adapter that was hosed May 19 22:40:59 i'm glad i had spares May 19 22:52:50 doesn't everybody have like 10+ excess of those from 5y ago? Do you still get one when buying a u-SD card? May 19 22:53:43 I don't think there is any logic in them ; just a pin mapping? So if it fails, it is 'cause it is soaked in peanut butter and coffee, and cigarette butts? May 19 23:03:48 no clue, it's completely clean, unbent, but the resulting image checksum doesn't match May 19 23:11:30 oh good, makes more sense now. i thought i had it isolated, but no, it's just intermittent. probably a problem with the built in reader on the work laptop. lovely. May 20 01:30:53 Centos 8 pretty much ignores all attempts to change ulimit... something is clobbering the normal advice... perhaps systemd May 20 01:32:28 for once it doesn't appear to be pam May 20 01:34:29 * paulg would have blamed systemd May 20 01:51:37 the ONLY thing that works is /etc/systemd/system.conf setting DefaultNOLIMIT= and rebooting May 20 01:51:41 grrr May 20 01:59:33 replace systemd with sysV-init? May 20 01:59:42 * paulg runs **** ENDING LOGGING AT Wed May 20 02:59:58 2020