**** BEGIN LOGGING AT Fri Feb 14 02:59:59 2020 Feb 14 03:56:54 Hello .. I am trying to use opkg package management in one of our products. I wanted to know if I compile a new application A , if there is any bitbake command to know the list of .ipk files which will be generated along with the dependent .ipk files which is required for installing the package on target without causing any dependency issues. Feb 14 03:59:23 sonuabraham: if you express the right dependencies then packager will do the right thing Feb 14 04:00:22 dependencies in .bb file that is, then there is a shlibs component which will automatically add deps on shared libs its linking to and add it to ipk metadata Feb 14 04:01:07 if it still misses then you can specify those using rdepends in .bb file to express what it needs during runtime Feb 14 04:05:15 perhaps you can use buildhistory to get that information where you build an image with buildhistory enabled and then add package A to IMAGE_INSTALL of image and build image again Feb 14 04:05:17 Thanks khem for the reponse .. my requirement is that when I create a new app , I want to move the newly created .ipk file for the app and all its dependent .ipk files to a new folder .. I want to know if there is a method to get the list of .ipk files and all the dependent ipk files which are generated newly Feb 14 04:05:38 then see buildhistory and it will record the new packages added to image Feb 14 04:06:07 right, I understand your usecase Feb 14 04:06:22 perhaps buildhistory route is something you can tool around Feb 14 04:06:44 We want to send only the newly created .ipk files and the dependent .ipk files to our customer Feb 14 04:07:17 will give a try using buildhistory .. Feb 14 04:07:35 yes ideally, opkg and other package management tools are tuned to use a feedserver mechanism Feb 14 04:07:47 ok Feb 14 04:07:52 to distribute s/w Feb 14 04:08:25 and that will be easy if you have a feedserver then you can just push the newly generated feeds into feedserver Feb 14 04:08:45 but then these feedserevers talk to devices directly, which might not be what your customers want Feb 14 04:09:45 yes exactly .. our customer wants all the updated files(.ipks) in a compressed format and our custom package manager will extract the compressed file and call opkg to install/upgrade the packages ... Feb 14 04:10:59 yeah Feb 14 04:12:33 Hello, I'm having an issue with my do_compile() for a recipe that relies on the cuda library. I have nvcc (the nvidia cuda compiler) in the path, but bitbake is throwing an error when I get to the do_compile() saying that nvcc is not found. Any ideas? Feb 14 04:12:46 I'm new to Yocto, so be gentle, thanks. Feb 14 04:13:27 Is there any bitbake command to get the list of dependent packages for a package.. I found thee following command [ bitbake -g image-name && cat pn-buildlist | grep -ve "native" | sort | uniq] to get the list of dependent packages for an image.. wast trying to find our if there is one for packages as well .. Feb 14 06:41:01 New news from stackoverflow: Yocto Package have unmet dependencies while installing deb file Feb 14 08:11:17 New news from stackoverflow: Jenkins setup to work with different projects managed with the repo tool Feb 14 09:05:52 erbo: hehe, awesome example to confirm my no-more-SO decision. Feb 14 09:07:58 LetoThe2nd: :D Feb 14 09:09:38 erbo: my condolences. Feb 14 09:14:54 LetoThe2nd: I just make sure I only answer/comment on SO when I'm relaxed enough to handle any type of questions. Feb 14 09:15:45 erbo: did you read my "article"? Feb 14 09:15:59 No, link please? :) Feb 14 09:16:23 the problem is the questions in itself. but the procedures that emerge specifically on SO Feb 14 09:16:26 erbo: https://www.linkedin.com/pulse/why-i-wont-answer-stackoverflow-anymore-josef-holzmayr-khosh-amoz/ Feb 14 09:23:32 Well written Feb 14 09:34:02 thx Feb 14 09:45:04 uh, busybox and systemd debug packages are empty in zeus. Did something change in the default build flags and -g is no longer there? Feb 14 09:52:52 mcfrisk: default haven't changed and we should have had warnings if they were stripped Feb 14 09:57:17 RP: ok, I'll investigate now on two different BSPs why these debug symbols are not there.. Feb 14 10:09:14 found a custom bbclass which is robbing debug symbols to a different binary package. no problems in zeus itself.. Feb 14 10:23:14 mcfrisk: ok, glad it wasn't anything we did :) Feb 14 10:41:45 New news from stackoverflow: Setting Linux Capabilities in Yocto ext4 Image Feb 14 10:48:17 RP: well, the same bbclass works well in sumo but robs all debug symbols to different binary package in zeus. something changed in -dbg handling.. Feb 14 10:48:45 mcfrisk: that is certainly possible... Feb 14 10:49:01 * RP can't remember when we reworked debug handling but we did at one point Feb 14 11:11:51 New news from stackoverflow: yocto poky-tiny does not create rcS symbolic links Feb 14 11:28:24 hi, me and my colleague are upgrading from krogoth to zeus, but systemd-random-seed.service is much slower with the same pool size of 4096, we've gone from 21ms to 1.245s, on zeus with a pool size of 8192, we get 368ms, but still a far cry from 21ms, has anyone got any ideas? Feb 14 11:29:49 FrazerClews: https://bbs.archlinux.org/viewtopic.php?id=249106 Feb 14 11:30:05 well, that was quick Feb 14 11:31:47 thanks for the help Feb 14 11:32:49 seems like VOLATILE_BINDS is only executed if readonly rootfs is enabled, is it possible to force it (want to retain writable rootfs till every issue is ironed out) Feb 14 11:34:22 LetoThe2nd: why is this a problem only after the upgrade? Feb 14 11:36:07 milloni: i *guess* that the upgrade brought a new kernel and/or systemd version (the latter almost for sure), and this has probably caused it. Feb 14 11:36:31 same kernel, different systemd - but why would a newer systemd have this problem? Feb 14 11:37:50 milloni: you're looking at it the wrong way. they probably realized that some way of getting random that they used so far has cryptographic weaknesses, and therefore "improved" the behaviour. Feb 14 11:38:08 milloni: which can, in turn, then have such side effects. Feb 14 11:38:10 ack, thanks Feb 14 12:01:38 i dont get any response in #u-boot. I cannot compile the "ubi" command tools into u-boot. Feb 14 12:01:43 http://dpaste.com/1EX3TZM Feb 14 12:29:05 Hi. I'm having a problem where i'm building a kernel image for a Machiattobin board. The Image binary i get from my yocto recipe that uses "linux-yocto.inc" doesn't boot, but if i use "make Image" in the same code, with the same config, with an sdk i generated from yocto, it boots. Does anyone have an idea on how to find the problem? Feb 14 12:30:00 troels are you sure that it uses the same dts and the same defconfig? Feb 14 12:30:13 In my code yocto replaces the defconfig Feb 14 12:31:05 I'm not copying the dts to the board, so i'm using the same dtb for both. Feb 14 12:32:37 For the defconfig, i let yocto config the build directory and generate the .config. Then i go into the work directory and call "make Image" after sourcing the sdk Feb 14 12:33:19 But i'll go through it again to double check Feb 14 12:50:57 Okay, i did a do_configure, then i went into the directory and did make Image directly and that image did not boot. So there is probably something different with the config Feb 14 13:09:09 perdmann: uboot iirc isn't free of charge 24/7 support for archaic vendor uboot forks patched to oblivion, sorry, try mainline and report back Feb 14 13:09:22 *irc Feb 14 13:26:38 perdmann: do you have CONFIG_MTD_PARTITIONS enabled? Feb 14 13:29:33 RP: ping Feb 14 13:30:07 I see no master branch : http://git.yoctoproject.org/cgit/cgit.cgi/poky/refs/heads Feb 14 13:31:50 dl9pf: hi Feb 14 13:33:28 dl9pf: halstead is looking into it Feb 14 13:33:46 dl9pf: it is there, just not in the web view Feb 14 13:34:02 hi. I have some problems with menuconfig option when configuring the linux kernel. For example I can't remove the text of the save/load option. Is that a bug or some incompatibility with my terminal emulator? Feb 14 13:34:20 dl9pf, I updated cgit and I'm still working out problems. Thank you for the report. Feb 14 13:34:53 halstead: ah roger ! Feb 14 13:36:02 question on "bitbake-layers layerindex-fetch -b zeus meta-xyz": it should checkout the zeus branch ... but as it stands it will clone master Feb 14 13:37:05 dl9pf: that sounds like a bug :( Feb 14 13:37:24 ok ... bugzilla ? Feb 14 13:37:50 dl9pf: or a patch to fix it? :) Feb 14 13:38:11 * RP can ask, right? :) Feb 14 13:38:25 yes, let me scratch that itch ... Feb 14 13:45:46 How is "Poky" pronounced? I was watching a video where Tim Orling was pronouncing it like this https://i.imgur.com/txUfzB9.jpg but I thought that it was more like this https://i.imgur.com/eL4Y9FI.jpg. Feb 14 13:47:30 fullstop: even the first engineers disagreed over the name pronouncination :) Feb 14 13:48:20 rburton: haha Feb 14 13:48:25 rburton: how is Årmströng pronounced? ;) Feb 14 13:48:26 RP: how did mallum pronounce it? surely his way wins Feb 14 13:48:30 Typo intended Feb 14 13:48:34 marex-cloud: when i say it, badly ;) Feb 14 13:48:40 That's fantastic Feb 14 13:48:40 dl9pf, master is listed again https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/ Feb 14 13:48:41 lol Feb 14 13:48:46 fullstop: it was named with sugar/candy in mind Feb 14 13:49:22 Take that, Tim! Feb 14 13:49:39 yeah i still say pokeey Feb 14 13:49:52 RP: and yet, the experience can sometimes be so bitter ;) Feb 14 13:49:52 rburton: you're wrong ;-) Feb 14 13:50:11 I'm happy to be wrong here Feb 14 13:50:33 jonmason: good question for you! Feb 14 13:50:43 It's sweet, yes, but definitely more flexible. Feb 14 13:51:32 I'm going to migrate from warrior -> zeus today. Wish me luck. Feb 14 13:51:55 fullstop: good luck, hopefully not too painful for that transition Feb 14 13:52:30 It's my personal layers that I wonder about.. but those should be easy enough to fix if there are problems. Feb 14 13:52:50 This thing isn't live yet, so I'd like to get as current as possible before I'm stuck on a particular branch. Feb 14 13:53:13 I think things will ship before 3.1, unfortunately. Feb 14 13:57:54 RP: which question is this? Poky pronunciation or layerindex-fetch? Feb 14 13:58:16 jonmason: poky pronunciation! Feb 14 13:59:23 haha. The Candy is pronounced "Pock-ee" Feb 14 13:59:54 jonmason: Puck-ee? Feb 14 14:00:17 jonmason: which is how I'd pronounce it Feb 14 14:00:20 jonmason: pokki- , no? Feb 14 14:00:21 ...but in my head I'll always picture gumby when I think of yocto. Feb 14 14:00:30 jonmason: it's Japanese Feb 14 14:01:47 My kids love that stuff. Sometimes we'll split a package, so ~11 sticks per person. They just about died from outrage when I bit the tops off of 11 at once instead of eating them one at a time. Feb 14 14:02:56 hmm, make your git tree mid rebase, then "bitbake pinentry" and it fails with m4 failures Feb 14 14:11:35 I need to reboot the new git server to increase the available memory. We are dropping connections to git clients. Feb 14 14:13:55 I have issues with https://git.yoctoproject.org/ - halstead is this the one you are talking about? Feb 14 14:14:17 frosteyes, Yes. It's resizing. Back online very soon. Feb 14 14:14:30 Cool :) Feb 14 14:18:06 frosteyes, Back up and very responsive. Feb 14 14:19:02 Nice. I have it now :) Feb 14 14:29:33 RP: mischief managed @ http://lists.openembedded.org/pipermail/bitbake-devel/2020-February/020888.html Feb 14 14:29:33 should be go into zeus at least as well. Feb 14 14:31:21 dl9pf: thanks! Feb 14 14:31:45 well, wait for v2 ;) Feb 14 14:32:05 ah, one of those kinds of patches Feb 14 14:32:58 can LAYERSERIES_CORENAMES be multiple Feb 14 14:33:13 dl9pf: I think so Feb 14 14:34:00 in well, not sure how that should be multiple in that context but ok. Feb 14 14:49:31 v2 out Feb 14 14:51:57 I don't know how to handle multiple LAYERSERIES_CORENAMES if we should clone a matching/specific git branch. Or should we use always the last entry ? Feb 14 14:52:58 basically branches[-1] ? Feb 14 14:53:48 this would be the magic best guess Feb 14 14:54:24 dl9pf: I'd also guess at [-1] Feb 14 14:54:45 ok happy to try that Feb 14 14:59:59 RP: all the debug messages in there do not show with -d Feb 14 15:02:16 dl9pf: pass. Probably missing some logger init code? :/ Feb 14 15:02:29 our logging needs work :/ Feb 14 15:11:25 Hello, I have built Linux operating system image using the YOCTO project. I am using this image on my embedded board. In order to connect with my board from my computer I need to use SSH server. So, is there anyone here who can tell me How to install the OpenSSH server in the linux image ? Feb 14 15:14:37 easiest: add ssh-server-openssh or ssh-server-dropbear to IMAGE_FEATURES and build a new one Feb 14 15:17:56 rburton In local.conf file I add this line ? IMAGE_FEATURES += "ssh-server-openssh" Feb 14 15:20:06 adding to EXTRA_IMAGE_FEATURES is neater Feb 14 15:22:45 rburton Okey thank you! And then after booting, in order to start the server, I have just to type : service ssh start Feb 14 15:22:50 ? Feb 14 15:28:13 rburton: should start automatically if its installed Feb 14 15:28:22 gaston48: ^^^ Feb 14 15:29:44 rburton Thank you :D Feb 14 15:36:50 zeddii: https://autobuilder.yoctoproject.org/typhoon/#/builders/102/builds/275 :/ Feb 14 15:48:41 Hi. I'm using an old yocto build (poky-morty), and am trying to find where the /dev/ dir is populated. It only creates mmcblkp0 up to 7, and i need to add more. Can someone please point me to the right direction? Feb 14 15:49:37 ikhorn: tgamblin tgamblin ugh ugh Feb 14 15:50:55 In Yocto Project Application Development and the Extensible Software Development Kit(eSDK) Manual, Appendix A.2. 6. Building an SDK Installer says the following: Feb 14 15:50:55 "To build the SDK installer for a standard SDK and populate the SDK image" Feb 14 15:50:56 what do they mean by "populate the SDK image" ? Feb 14 15:50:56 After running 'bitbake image -c populate_sdk' command, sdk folder was created in my build/tmp/deploy/sdk. In this folder there is .sh script. This script Feb 14 15:50:57 is SDK installer but what do they mean by 'and populate the SDK image'? What SDK image? Feb 14 15:51:39 dang, I should have cleaned when going from 2.7 -> 3.0. Feb 14 15:57:30 Ugh: ? Feb 14 15:58:02 sorry, using web client and missclicked Feb 14 15:58:16 k Feb 14 16:06:52 RP: you also need busybox patch for musl to work Feb 14 16:07:01 it seems you forgot to pick that up Feb 14 16:14:15 khem: no, I dropped musl since the busybox didn't apply Feb 14 16:15:01 again ? Feb 14 16:15:15 I think it could be utf-8 then Feb 14 16:15:20 khem: the resend version didn't come through when I looked at email Feb 14 16:16:09 shows here https://patchwork.openembedded.org/series/19281/ Feb 14 16:16:23 so it definitely left my outbox Feb 14 16:16:54 khem: right, its here now. It just wasn't earlier when I looked at patches Feb 14 16:16:57 khem: testing it Feb 14 16:17:14 khem: ok, busybox fails to apply when applied from email Feb 14 16:17:21 * RP can try from git Feb 14 16:17:23 ok, I have many threads in my mind so I can be wrong too :) Feb 14 16:18:07 RP: for the cpio/mips64 issue I think we should ask cisco to help Feb 14 16:18:23 khem: there is something wrong with this patch as even pulling it from your branch doesn't change anything Feb 14 16:18:30 I dont have access to mips64 system and it seems to work ok for other arches Feb 14 16:18:38 really ? Feb 14 16:20:49 it has been applying fine on my builds across debian10 and ubuntu 18.04 Feb 14 16:21:10 whats the OS on the box where it fails Feb 14 16:21:14 khem: your patch has "suppor the" in it whilst it should have "support the" Feb 14 16:21:43 khem: if I fix that it applies Feb 14 16:22:00 khem: can't see how it applies ;-) Feb 14 16:22:03 ok go for it Feb 14 16:23:04 its perhaps patch versions, I have had this issue between ubuntu 12.04 and 14.04 like 5 years ago Feb 14 16:23:08 unexplained Feb 14 16:25:54 khem: ok, -next fixed Feb 14 16:26:06 khem: I can't see how this wouldn't reproduce for you though Feb 14 16:26:51 let me see Feb 14 16:28:48 so I punted it out and did a git am of exact patch I sent out this morning and it applies http://ix.io/2bHZ Feb 14 16:30:21 bare patch -p1 also works Feb 14 16:30:37 khem: patch is 0001-Remove-syscall-wrappers-around-clock_gettime-closes-.patch though ? Feb 14 16:31:05 oh its busybox patching failing Feb 14 16:31:12 right, let me try that Feb 14 16:31:53 khem: right Feb 14 16:39:57 RP: the patch on master-next fails for me :) Feb 14 16:40:11 so we have reverse issue here Feb 14 16:42:16 khem: you must have a different piece of underlying busybox code Feb 14 16:52:14 RP: I will redo this patch Feb 14 16:52:22 just limit it to one patch Feb 14 16:53:39 khem: the trouble is master-next looks fine to me. I'm reluctant to do anything until we work out why we're seeing this difference Feb 14 16:54:02 can someone else see if master-next "bitbake busybox -c patch" works? Feb 14 16:54:19 khem: there is something very wrong :/ Feb 14 17:02:34 is it possible to create postinst_ontarget scripts that only include the `ontarget` part? Feb 14 17:03:28 RP: your change is fine so keep it I figured meta-riscv has a conflicting change Feb 14 17:03:35 RP: so I will fix that part Feb 14 17:04:22 RP: meta-riscv is carrying patches for busybox to support time_t 64bit Feb 14 17:04:36 which will be not needed after this change Feb 14 17:04:36 khem: right, that would explain it Feb 14 17:07:53 RP: I will still need to change the OE-core patch Feb 14 17:08:21 khem: so I should drop this and musl again for now? Feb 14 17:08:43 give me 10-15 mins Feb 14 17:09:05 khem: ok Feb 14 17:13:07 New news from stackoverflow: RAM and ROM test while booting in Yocto Feb 14 17:17:02 Yocto Project Application Development and the Extensible Software Development Kit (eSDK), section 1.2 SDK Development Model says the following: Feb 14 17:17:03 If you are going to develop your application on hardware, go to the machines download area and choose a target machine area from which to download the kernel image and root filesystem. Feb 14 17:17:30 'machines' hyperlink is Not Found Feb 14 17:23:43 jani191: link referred in /docs/3.0 instead of /docs/latest is up. Feb 14 17:27:27 RP: sending a v2 for busybox Feb 14 17:27:29 I'm new to yocto. Where is /docs/3.0 ? Feb 14 17:28:33 https://www.yoctoproject.org/docs/3.0/sdk-manual/sdk-manual.html Feb 14 17:30:18 In any case, you should make sure this is the doc manual for the release you are using. Feb 14 17:32:59 champagneg: I built yocto project for bsp release L4.19.35_1.1.0. How do I find what is my yocto project release? Feb 14 17:36:16 RP: squashfs-tools has a typo in subject 'swuashfs-tools' perhaps you can tweak it Feb 14 17:39:21 jani191: who provided that bsp? Feb 14 17:40:06 jani191: running bitbake should tell you the branch names, which should be release names Feb 14 17:48:07 khem: fixed Feb 14 18:00:26 RP: sheepishly, I sent a v2 for busybox patch can you see if this fixes the patching problem Feb 14 18:04:24 khem: I think that one is ok Feb 14 18:11:20 uff finally Feb 14 18:11:50 computers are hardly wrong Feb 14 18:16:07 morning Feb 14 18:16:30 what is the right way to add a dependency on lvm2-udevrules to cryptsetup from meta-openembedded? the cryptsetup tools seem to need the lvm2 udev rules for devicemapper, otherwise they hang waiting for udev notifications. Feb 14 18:38:49 khem. I bisected the musl -> x86 32 bit gpf problem. It's right where we'd expect: Feb 14 18:38:53 https://pastebin.com/HMpkPsXT Feb 14 18:39:03 but I have no idea how to fix it, but I do have a commit to point at Feb 14 18:39:11 RP ^^^^^^^^^^^ Feb 14 18:43:56 zeddii: what does crash look like Feb 14 18:44:18 is it init crashing or something else Feb 14 18:45:41 it's the one I sent you in email a while ago. sec, I'll see if I can grab it again. Feb 14 18:46:27 zeddii: can you please try musl+busybox from master-next Feb 14 18:46:36 I can next week. Feb 14 18:46:39 exi Feb 14 18:46:48 I'm out of time until ~Wednesday, but can pick it up again then. Feb 14 18:47:29 zeddii: I only see your tiktok videos in my email :) Feb 14 18:47:39 :P Feb 14 18:47:44 it will be a quick try Feb 14 18:47:56 or give me a way to reproduce it Feb 14 18:51:44 zeddii: you can reschedule your next video about tickling the elephants in Savannah and fix this Feb 14 18:55:20 khem: any clue about my cryptsetup problem? :) Feb 14 18:55:52 trout tickling Feb 14 18:55:55 https://en.wikipedia.org/wiki/Trout_tickling Feb 14 18:55:57 zeddii: the error is traps: python3[11312] general protection fault ip:b7e966b0 sp:bf8175cc error:0 in libc.so[b7e8b000+6b000] Feb 14 18:56:03 right ? Feb 14 18:56:04 yup. Feb 14 18:56:13 or that's what I've been using. Feb 14 18:56:29 I'm saving my bisect tree and can try master-next in the background. Feb 14 18:56:44 I'm being tortured by conference calls this afternoon. Feb 14 18:56:54 zeddii: so all I need is to use 5.4 recipe and then run python3 ? Feb 14 18:57:30 yah. I'm using master. musl and setting the preferred version to 5.4 Feb 14 18:57:43 the recipes, etc, are all there in master, just not activated as the deafult. Feb 14 18:58:10 I'm adding package-management to core-image-minimal, since dnf is an easy way to trigger the trap. Feb 14 18:58:23 but otherwise, it is just core-i-minimal. Feb 14 18:59:38 RP: send another patch on top which fixes apply failure on my machine, can you try it ? Feb 14 18:59:52 zeddii: ok, I will reproduce it Feb 14 19:00:28 and I just launched a build of master-next here, no change, except the different branch. I'll let you know what I see there. Feb 14 19:00:49 (it's almost done already, as you said, small delta) Feb 14 19:01:28 zeddii: Linux qemux86 5.4.15-yocto-standard Feb 14 19:01:31 is that ok ? Feb 14 19:01:50 yup. that should show it. Feb 14 19:02:04 ok adding python3 to mix Feb 14 19:02:05 5.2 is fine. 5.4 not. and bisect landed me on that pastebin. Feb 14 19:02:32 so it is the kernel, or some interface to the clock/time in the kernel, but we knew that as well. Feb 14 19:02:43 it's the same set of changes that hosed mips64 Feb 14 19:02:50 I owe those guys a kick in the shins Feb 14 19:03:20 I don't think it matters, but I've been using systemd as well. but it isn't involved in the crash. Feb 14 19:03:21 zeddii: simply executing python3 will cause it ? or do I need to run certain script Feb 14 19:03:58 it'll boot, and then I'm running the dnf command, others will probably trigger it, but the one that pointed me to the issue on the AB was that dnf one. Feb 14 19:12:58 Is there a reason not to try to remove "x11" from DISTRO_FEATURES_NATIVE? I don't need a graphical qemu-native (don't need qemu-native at all for that matter), and it's a lot of building to get gtk+3, x11, etc. Feb 14 19:15:47 I just wanted to mention that the migration from 2.7 -> 3.0 was uneventful except for some Bad Things that I was doing with shlib stuff. Feb 14 19:16:00 zeddii: just launching py3 does not crash Feb 14 19:25:30 zeddii: which dnf cmd will do it Feb 14 20:13:44 New news from stackoverflow: RAM and ROM test while booting in Yocto [closed] Feb 14 20:18:29 Is there a way to remove a package from a *packagegroup* in a machine or distro config? Feb 14 20:21:00 xyzzy42: RDEPENDS__remove_yourmachine = "foo" could do, or use a bbappend for it conditional on the machine or idstro Feb 14 20:21:03 in the machine/idstro layer Feb 14 20:22:14 kergoth, thanks, I see. Need to think of it as modifying the packagegroup rather than modifying the image or distro. Feb 14 20:23:24 a packagegroup is a separate recipe, so that'd be the ideal. if the packagegroup used RRECOMMENDS rather than RDEPENDS for the package in question, then you have more options without making the package manager unhappy, since recommends can usually be uninstalled after the fact, or excluded, without breaking the deps of the packagegroup Feb 14 20:24:53 Does that mean, if the packagegroup used RDEPENDS, and I use RDEPENDS_pn.._remove, that the package manager (deb) will think packagegroup has unmet dependencies? Feb 14 20:25:28 or rather, that if the packagegroup had used rrecommends instead of rdepends, then the package could be removed at runtime. Feb 14 20:31:58 the latter, if it used rrecommends, then you can remove it or exclude it without unmet dependencies. whereas rdepends that wouldn' twork, so you need to _remove it instead Feb 14 20:48:22 kergoth, isn't the normal syntax for a remove override RDEPENDS_remove_pn-packagename? Feb 14 20:56:00 xyzzy42: No, RDEPENDS__remove. The package name is part of the variable name in this case (while _pn- is an override). Feb 14 20:57:01 I am experiencing interesting issues with meta-java master-next when I turn on the archiver.bbclass ;) Now BitBake suddenly stops when it can not apply patches which went upstream. Shouldn't it stop anyhow if it can't apply patches? Feb 14 20:59:35 xyzzy42: but 'RDEPENDS" isn't defined, so that'll do nothing Feb 14 20:59:41 xyzzy42: it's RDEPENDS_packagename is the variable name Feb 14 21:00:00 ex RDEPENDS_${PN}. but hte exact one will depend on the packagegroup, so read the recipe Feb 14 21:01:41 Oh, the original bb file defined RDEPENDS_packagename, not RDEPENDS that is implicitly part of the recipe. Feb 14 21:06:54 RobertBerger: Sounds like something is using git instead of quilt to apply patches. But AFAIK, the archiver class should not have that effect... Feb 14 21:07:22 Unfortunately, even when done correctly, the remove just doesn't seem to work. And there doesn't seem to be a way to see the env. If I use bitbake -e myimage, I don't see RDEPENDS_<*> for any packages at all. bitbake -e packagegroup-core-full-cmdline-utils does show it, but nothing I've added in myimage.conf is taken into account. Feb 14 21:08:41 maybe the answer is that an image can include or not include packages, but it can not change the recipes of those package, including what they RDEPEND Feb 14 21:08:51 RobertBerger: I have seen that happen when doing devtool modify on a recipe that has a patch that is already applied upstream. Quilt seems to handle it, but devtool uses git to apply the patches and then it fails. Feb 14 21:09:25 xyzzy42: No recipe can affect another and that includes image recipes. Feb 14 21:09:40 @Saur: I have now something which compiles and even runs and as soon as I add the archiver class it freaks out with quilt Feb 14 21:11:32 @Saur: I think it's quite easy to reproduce. Just built openjdk-8 or openjre-8 and afterwards turn on the archiver class. This problem seems to lurk around at least since warrior. Feb 14 21:11:36 xyzzy42: So if you want to _remove a dependency for a packagegroup, you either need to do it in a bbappend for that packagegroup, or via the global configuration, e.g., in local.conf or your distro.conf Feb 14 21:12:40 @Saur: In my case with archiver class quilt seems to be unhappy. Feb 14 21:13:12 RobertBerger: Interesting. :) Feb 14 21:13:37 Since quilt should be the default, unless you have changed PATCHTOOL. Feb 14 21:15:05 I see, the image recipe is not really a peer to the distro config. And there is somewhat of a limitation on packagegroups here, in that they make the effectively make the packages they contain inter-dependent, even though they are not Feb 14 21:15:21 @Saur stay tuned, I'll try to load a logfile to pastebin Feb 14 21:18:15 @Saur: https://pastebin.com/RBtPydGD Feb 14 21:20:11 @Saur: Just for fun let me build again without the archiver class to see what's going to happen. Feb 14 21:24:46 Saur, kergoth: Thanks, it worked! mc is finally gone. Feb 14 21:24:57 :) Feb 14 21:26:30 took hours, but I understand the relationship between distro and image better, and also variables with a package override vs variables with a package in their name. Feb 14 21:32:11 @Saur: If I remove the archiver class it's happy: https://pastebin.com/f3tv52SY Feb 14 21:33:18 @Saur: But note, that without the archiver class it's do_patch and with the archiver class it's do_unpack_and_patch (which fails) Feb 14 21:33:18 RobertBerger: Ok, that's weirtd. Feb 14 21:34:04 @Saur What is do_unpack_and_patch ? Feb 14 21:34:16 RobertBerger: Yeah, but if I read the archiver class correctly, do_unpack_and_patch will call out first to do_unpack and then to do_patch... Feb 14 21:37:50 @Saur: Let me try just to include the archiver class without enabling anything and see what happens Feb 14 21:39:18 RobertBerger: Whetether do_unpack_and_patch is used or not depends on hw you configure the archiver class. It is always used for ARCHIVER_MODE[src] = "patched" and ARCHIVER_MODE[src] = "configured". For ARCHIVER_MODE[src] = "original" it is only enabled if ARCHIVER_MODE[diff] = "1" is also enabled. Feb 14 21:39:57 And for the new ARCHIVE_MODE[src] = "mirror" it is never enabled. Feb 14 21:40:22 @Saur: OK let me try. BTW this is similar: https://www.yoctoproject.org/pipermail/yocto/2018-August/042125.html Feb 14 21:42:02 RobertBerger: But that is due to not finding quilt at all. Feb 14 21:43:10 @Saur: Yes Feb 14 21:43:28 @Saur: I try now something like this: bitbake openjdk-8 -c do_unpack_and_patch Feb 14 21:43:59 @Saur: Just included the class in local.conf and run now explicitly this task Feb 14 21:44:18 @Saur: and it freaks out ;) Feb 14 21:44:18 RobertBerger: I noticed a difference in the logs. When it works, patches 1001 and 1002 are applied before 1003. However, when it fails, there is no mentioning of those two patches... Feb 14 21:44:30 1001 does not apply as well Feb 14 21:44:49 @Saur: I just removed them, since they were already upstream Feb 14 21:46:05 @Saur: I don't get it. Assuming the patch is already upstream shouldn't quilt freak out also without the archiver class? Feb 14 21:47:10 RobertBerger: I don't know how smart quilt is, i.e., if it can skip a patch if it detects that it is already applied. Feb 14 21:47:44 RobertBerger: But i definitely do not understand why activating the archiver class should change the behavior. Feb 14 21:48:18 @Saur: exactly Feb 14 21:48:31 @Saur: That's the patch: https://github.com/RobertBerger/meta-java/blob/2020-02-13-master-next-as-zeus-3.0%2B/recipes-core/openjdk/patches-openjdk-8/1001-hotspot-fix-crash-on-JNI_CreateJavaVM.patch Feb 14 21:49:39 @Saur: If I go in with devshell and check hotspot/src/os/linux/vm/os_linux.cpp around line 3192 I see it's already there Feb 14 21:51:22 @Saur: That's in the code: if ((mincore((address)stack_extent, os::vm_page_size(), vec) == -1) Feb 14 21:51:22 && ((size_t)addr > (size_t)stack_extent)) { Feb 14 21:55:33 @Saur: When I try quilt manually it says: quilt push Feb 14 21:55:33 File series fully applied, ends at patch patches/0012-autoconf-NativeCompilation-remove-sysroot.patch Feb 14 21:55:45 @Saur just before 1001 Feb 14 21:58:52 RobertBerger: What version of meta-java and openjdk-8 do you use? Feb 14 21:58:52 @Saur - no sorry quilt thinks it applied all the patches and I can pop them and apply them - no problem Feb 14 21:59:37 @Saur maybe someone forgot a quilt patch series in the sources which screws up everything? Feb 14 22:01:56 RobertBerger: Just wondering where you got the 10XX and 20XX patches from since I do not see them when looking at meta-java and openjdk-8 using the layerindex. Feb 14 22:06:32 @Saur from there - wait Feb 14 22:07:23 @Saur: http://git.yoctoproject.org/cgit/cgit.cgi/meta-java/tree/recipes-core/openjdk/patches-openjdk-8?h=master-next Feb 14 22:10:18 @Saur: http://git.yoctoproject.org/cgit/cgit.cgi/meta-java/commit/recipes-core/openjdk/patches-openjdk-8?h=master-next&id=7d30e6ff7b8a54d67256ce528e8c4fd7e63f6b14 Feb 14 22:36:29 zeddii, RP see https://patchwork.openembedded.org/patch/170067/ Feb 14 22:36:46 this should fix python3 gpf on musl/x86 Feb 14 22:40:53 problem was db was crashing when called by rpm under python which was invoked by python Feb 14 22:41:07 invoked by dnf Feb 14 22:42:34 @Saur: It looks like it tries to re-apply some patches with do_unpack_and_patch Feb 14 22:43:19 RobertBerger: That seems wrong. do_unpack_and_patch is supposed to use a different workdir than the normal do_unpack and do_patch... Feb 14 22:49:47 @Saur: Maybe the crappy meta-java layer moves things around, as we saw with TOPDIR. Feb 14 22:50:53 @Saur or maybe I should try some cleaning and give it another try. Feb 14 22:50:56 RobertBerger: I have no experience with meta-java so no idea what it does or not, but it sounds a bit far fetched that it should do something that interferes with the archiver class. Feb 14 22:52:34 @Saur: Let me try to do just the unpack step and see if I can apply the patches manually. Feb 14 22:52:54 @Saur: If that's the case something strange is happening with archiver Feb 14 22:54:37 @Saur: What I currently have moves S to some strange place and TOPDIR for the configure task as well: https://github.com/RobertBerger/meta-java/blob/2020-02-13-master-next-as-zeus-3.0%2B/recipes-core/openjdk/openjdk-8-common.inc#L29 Feb 14 23:01:07 @Saur: bitbake openjdk-8 -c do_unpack_and_patch -e | grep ^WORKDIR= Feb 14 23:01:08 WORKDIR="/workdir/build/container-x86-64-java/tmp/work/core2-64-resy-linux/openjdk-8/242-r0" Feb 14 23:01:59 bitbake openjdk-8 -c do_patch -e | grep ^WORKDIR= Feb 14 23:01:59 WORKDIR="/workdir/build/container-x86-64-java/tmp/work/core2-64-resy-linux/openjdk-8/242-r0" Feb 14 23:03:46 RobertBerger: do_unpack_and_patch() sets WORKDIR itself to ${ARCHIVER_WORKDIR}, which defaults to ${WORKDIR}/archiver-work/ Feb 14 23:04:00 So I do not think bitbake -e wil reflect that. Feb 14 23:05:43 bitbake openjdk-8 -c do_unpack_and_patch -e | grep ^ARCHIVER_WORKDIR= Feb 14 23:05:43 ARCHIVER_WORKDIR="/workdir/build/container-x86-64-java/tmp/work/core2-64-resy-linux/openjdk-8/242-r0/archiver-work/" Feb 14 23:07:01 RobertBerger: I guess if you look in that directory you should see the unpacked source and half applied patches that do_unpack_and_patch was working on before it failed. Feb 14 23:09:12 @Saur: yes kind of, until 1001-hotspot-fix-crash-on-JNI_CreateJavaVM.patch a series Feb 14 23:09:40 khem: thanks Feb 14 23:09:54 khem: I have your db patch for next, is there anything else? Feb 14 23:10:43 @Saur, but the sources are missing, which it wants to patch ;) Feb 14 23:11:23 khem: ah, busybox typo Feb 14 23:11:32 RP: yes the dnf libresolv patches Feb 14 23:13:55 khem: I'm waiting to read the latest in the thread about those ;-) Feb 14 23:13:57 @Saur: openjdk-8/242-r0/jdk8u-jdk8u242-ga$ ls Feb 14 23:13:57 ASSEMBLY_EXCEPTION configure get_source.sh jaxp jdk LICENSE Makefile patches README-builds.html THIRD_PARTY_README Feb 14 23:13:57 common corba hotspot jaxws langtools make nashorn README test Feb 14 23:14:29 @Saur: openjdk-8/242-r0/archiver-work/jdk8u-jdk8u242-ga$ ls Feb 14 23:14:29 ASSEMBLY_EXCEPTION common configure get_source.sh LICENSE make Makefile patches README README-builds.html test THIRD_PARTY_README Feb 14 23:14:47 RP: its settled Feb 14 23:15:25 @Saur: This might explain why it can't apply the patches Feb 14 23:15:31 khem: I think we still need to improve the "uses rpm" test for the QA tests too? Feb 14 23:15:48 RobertBerger: Yes, but it doesn't explain why the files are missing... Feb 14 23:15:55 RP: yes, I am hoping alex will fix it Feb 14 23:16:05 @Saur: hehe meta-java, let me see Feb 14 23:17:26 @Saur: https://github.com/RobertBerger/meta-java/blob/2020-02-13-master-next-as-zeus-3.0%2B/recipes-core/openjdk/openjdk-8-common.inc#L33 Feb 14 23:18:15 RP: we can wait on those Feb 14 23:18:36 perhaps until alex comes with patches, I will prod again next week Feb 14 23:18:37 RobertBerger: Ah, yes, that will fail since it does cd ${S} Feb 14 23:18:40 @Saur: https://github.com/RobertBerger/meta-java/blob/2020-02-13-master-next-as-zeus-3.0%2B/recipes-core/openjdk/openjdk-8-common.inc#L158 Feb 14 23:19:57 @Saur: Now the good question is where to hack this. Before unpack_and_patch? maybe Feb 14 23:21:40 RobertBerger: Hmm, thinking about it, that should actually still work since S follows along when do_unpack_and_patch changes WORKDIR. :/ Feb 14 23:22:00 RP: I sent another patch to ml about licenses Feb 14 23:22:34 about deleting do_populate_lic for images and package-index.bb Feb 14 23:24:32 RobertBerger: You could try to add `bb_warn "S: ${S}"` to do_unpack_extract_submodules() and see what it prints when its run through do_unpack_and_patch Feb 14 23:26:23 khem: To the wrong list. ;) Feb 14 23:29:11 thanks for noticing Feb 14 23:40:32 @Saur: openjdk-8-242-r0 do_unpack: --> S: /workdir/build/container-x86-64-java/tmp/work/core2-64-resy-linux/openjdk-8/242-r0/jdk8u-jdk8u242-ga <-- Feb 14 23:40:36 RP: Btw, how will you handle documentation patches? I sent a couple to the new docs list on Monday, so just wondering what to expect. Feb 14 23:40:55 there is separate ml for doc patches Feb 14 23:40:59 send them there Feb 14 23:41:25 RobertBerger: Ok, that doesn't look good if that was from do_patch was called by do_unpack_and_patch. Feb 14 23:41:38 RP: That's what I did. Feb 14 23:41:49 https://lists.yoctoproject.org/g/docs Feb 14 23:42:02 @Saur: I did a cleansstate followed by a do_unpack_and_patch Feb 14 23:42:10 RP: One of them even solves a Yocto ticket. :) Feb 14 23:43:12 RP: Which reminds me, do I need to do anything to the ticket once the patch is eventually accepted, or will it be closed by you? Feb 14 23:44:58 Saur: usually its helpful if the owner of the ticket resolves it Feb 14 23:45:14 Saur: I was hoping to get Mark Morton to review the docs patches, that is the reason for the delay Feb 14 23:45:38 RP: Ok, no problem. Just wanted to know what to expect. **** ENDING LOGGING AT Sat Feb 15 02:59:57 2020