Re: [yocto] meta-mingw: unable to run executables on Windows
On Wed, Nov 14, 2018 at 8:08 PM Joshua Watt wrote: > > On Wed, Nov 14, 2018 at 8:41 PM Mark Hatle wrote: > > > > On 11/14/18 9:54 AM, Mark Hatle wrote: > > > On 11/13/18 3:56 AM, Samuli Piippo wrote: > > >> Hi, > > >> > > >> I've just upgraded poky and meta-mingw layers from sumo to thud and as a > > >> result > > >> a lot of the executables in the toolchain no longer run correctly on > > >> Windows. > > > > > > Which version of windows? > > > > > >> I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, > > >> gcc/g++ work > > >> fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds > > >> and > > >> exit without any output. > > >> > > >> Has anyone else seen this? > > > > > > I've run a toolchain made on mingw after sumo, but before thud's release. > > > I'll > > > see if I can find a VM and give it a try later today. > > > > I'm running on Windows 7 for my testing (ya, I know old.. but it's what I > > got.) > > > > Can you try adding the following to your conf/local.conf: GCCPIE_mingw32 = > > "" this will be effective just for SDK and native versions I hope, but in cases if we have this override also applicable for target then this fix is not correct. We have to keep using it for target builds. > > > > I found that the SDK was not working properly here as well, but only > > binutils. > > The above seems to fix the issue. (You do have to rebuild your SDK.) > > I also saw this issue on Windows 7, and your described fix corrected > it (Thanks!). On the plus side, the automated SDK testing that I'm > working on discovered it as well (e.g. the tests failed because of > it), which means that the tests are working and should help prevent > issues like this in the future once I get it merged. > > > > > > --Mark > > > > > > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-mingw: unable to run executables on Windows
On Wed, Nov 14, 2018 at 8:41 PM Mark Hatle wrote: > > On 11/14/18 9:54 AM, Mark Hatle wrote: > > On 11/13/18 3:56 AM, Samuli Piippo wrote: > >> Hi, > >> > >> I've just upgraded poky and meta-mingw layers from sumo to thud and as a > >> result > >> a lot of the executables in the toolchain no longer run correctly on > >> Windows. > > > > Which version of windows? > > > >> I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, > >> gcc/g++ work > >> fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds > >> and > >> exit without any output. > >> > >> Has anyone else seen this? > > > > I've run a toolchain made on mingw after sumo, but before thud's release. > > I'll > > see if I can find a VM and give it a try later today. > > I'm running on Windows 7 for my testing (ya, I know old.. but it's what I > got.) > > Can you try adding the following to your conf/local.conf: GCCPIE_mingw32 = "" > > I found that the SDK was not working properly here as well, but only binutils. > The above seems to fix the issue. (You do have to rebuild your SDK.) I also saw this issue on Windows 7, and your described fix corrected it (Thanks!). On the plus side, the automated SDK testing that I'm working on discovered it as well (e.g. the tests failed because of it), which means that the tests are working and should help prevent issues like this in the future once I get it merged. > > > --Mark > > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-mingw: unable to run executables on Windows
On 11/14/18 9:54 AM, Mark Hatle wrote: > On 11/13/18 3:56 AM, Samuli Piippo wrote: >> Hi, >> >> I've just upgraded poky and meta-mingw layers from sumo to thud and as a >> result >> a lot of the executables in the toolchain no longer run correctly on Windows. > > Which version of windows? > >> I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ >> work >> fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds and >> exit without any output. >> >> Has anyone else seen this? > > I've run a toolchain made on mingw after sumo, but before thud's release. > I'll > see if I can find a VM and give it a try later today. I'm running on Windows 7 for my testing (ya, I know old.. but it's what I got.) Can you try adding the following to your conf/local.conf: GCCPIE_mingw32 = "" I found that the SDK was not working properly here as well, but only binutils. The above seems to fix the issue. (You do have to rebuild your SDK.) > --Mark > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [bitbake-devel] difference between DEPLOYDIR vs D
IIrc DEPLOYDIR contents get copied to DEPLOY_DIR by sstate for the do_deploy task. I.e. tmp/deploy/. This is independent of packaging. On Wed, Nov 14, 2018 at 5:38 PM Davis Roman wrote: > Hello, > > I'm trying to understand the correlation between the $DEPLOYDIR and $D > variables. > > They both seem very similar. > > Do files from DEPLOYDIR eventually get copied to D in order to finally > make its way into the final package? > > If so, why bother with DEPLOYDIR and instead just copy straight into D? > > Thank you, > > Davis > -- > ___ > bitbake-devel mailing list > bitbake-de...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/bitbake-devel > -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] difference between DEPLOYDIR vs D
Hello, I'm trying to understand the correlation between the $DEPLOYDIR and $D variables. They both seem very similar. Do files from DEPLOYDIR eventually get copied to D in order to finally make its way into the final package? If so, why bother with DEPLOYDIR and instead just copy straight into D? Thank you, Davis -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-gplv2][PATCH] grep: fix install if bindir == base_bindir
This same fix was made to the grep recipe in poky at hash
5f137933c05646dee685d7846cba875ae74064cd. Not everyone gets the luxury of
using GPLv3 code, so the same fix needs to be applied to the GPLv2
version.
Signed-off-by: Wes Lindauer
---
recipes-extended/grep/grep_2.5.1a.bb | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/recipes-extended/grep/grep_2.5.1a.bb
b/recipes-extended/grep/grep_2.5.1a.bb
index 97ca768..b331fee 100644
--- a/recipes-extended/grep/grep_2.5.1a.bb
+++ b/recipes-extended/grep/grep_2.5.1a.bb
@@ -38,11 +38,13 @@ do_configure_prepend () {
do_install () {
autotools_do_install
- install -d ${D}${base_bindir}
- mv ${D}${bindir}/grep ${D}${base_bindir}/grep
- mv ${D}${bindir}/egrep ${D}${base_bindir}/egrep
- mv ${D}${bindir}/fgrep ${D}${base_bindir}/fgrep
- rmdir ${D}${bindir}/
+if [ "${base_bindir}" != "${bindir}" ]; then
+ install -d ${D}${base_bindir}
+ mv ${D}${bindir}/grep ${D}${base_bindir}/grep
+ mv ${D}${bindir}/egrep ${D}${base_bindir}/egrep
+ mv ${D}${bindir}/fgrep ${D}${base_bindir}/fgrep
+ rmdir ${D}${bindir}/
+fi
}
inherit update-alternatives
--
2.14.5
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FW: final pass on release notes....and general status of readiness
Especially true for the manuals... always go to the website for best set of manuals. Scott On Wed, Nov 14, 2018 at 1:41 PM akuster808 wrote: > > On 11/14/18 12:47 PM, Jolley, Stephen K wrote: > > We will release YP 2.6 M4 rc1 shortly. Please give feedback if any is > required. > > > Please add the note that Tip of Thud is not what is being released. > > This will just confuse folks trying to connect the dots. > > > - armin > > > > Thanks, > > > > Stephen > > > > *From:* Graydon, Tracy > *Sent:* Wednesday, November 14, 2018 12:33 PM > *To:* Jolley, Stephen K > ; Michael Halstead > > *Subject:* final pass on release notesand general status of readiness > > > > Ugh, I am not seeing the email I sent with the finalized release notes. I > dunno if I sent it or not because I am having a nightmare with Outlook on > Mac eating things and generally not working right. > > > So, by way of sanity check, attached. The only changes were adding the > binutils CVES to Known issues: > > > > binutils: fix CVE-2018-18309, CVE-2018-18605, CVE-2018-18606, > CVE-2018-18607 > > > > And the gitsm known issue: > > > > - gitsm fixes on master-next: > > * The submodule name and path were assumed to be the same, which is not > necessarily true. > > * Submodules refer to a specific commit, not branch, but we erroneously > check against the branch specified in SRC_URI. This results in > > failure if a submodule commit is not on that branch. > > > > So, nothing major there. Just really a sanity check on the gitsm wording. > > > > Everything is ready to go. Pages are set and just need to be published. > Release announcement is ready. So we just need to do the final mirror and > tagging magic, and announce. > > > > If the wording on gitsm issue looks reasonable, we are good to go. > > > > -t > > > > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FW: final pass on release notes....and general status of readiness
On 11/14/18 12:47 PM, Jolley, Stephen K wrote: > > We will release YP 2.6 M4 rc1 shortly. Please give feedback if any is > required. > Please add the note that Tip of Thud is not what is being released. This will just confuse folks trying to connect the dots. - armin > > > Thanks, > > > > Stephen > > > > *From:* Graydon, Tracy > *Sent:* Wednesday, November 14, 2018 12:33 PM > *To:* Jolley, Stephen K ; Michael Halstead > > *Subject:* final pass on release notesand general status of readiness > > > > Ugh, I am not seeing the email I sent with the finalized release > notes. I dunno if I sent it or not because I am having a nightmare > with Outlook on Mac eating things and generally not working right. > > > So, by way of sanity check, attached. The only changes were adding > the binutils CVES to Known issues: > > > > binutils: fix CVE-2018-18309, CVE-2018-18605, CVE-2018-18606, > CVE-2018-18607 > > > > And the gitsm known issue: > > > > - gitsm fixes on master-next: > > * The submodule name and path were assumed to be the same, which is > not necessarily true. > > * Submodules refer to a specific commit, not branch, but we > erroneously check against the branch specified in SRC_URI. This results in > > failure if a submodule commit is not on that branch. > > > > So, nothing major there. Just really a sanity check on the gitsm wording. > > > > Everything is ready to go. Pages are set and just need to be > published. Release announcement is ready. So we just need to do the > final mirror and tagging magic, and announce. > > > > If the wording on gitsm issue looks reasonable, we are good to go. > > > > -t > > > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] FW: final pass on release notes....and general status of readiness
We will release YP 2.6 M4 rc1 shortly. Please give feedback if any is required. Thanks, Stephen From: Graydon, Tracy Sent: Wednesday, November 14, 2018 12:33 PM To: Jolley, Stephen K ; Michael Halstead Subject: final pass on release notesand general status of readiness Ugh, I am not seeing the email I sent with the finalized release notes. I dunno if I sent it or not because I am having a nightmare with Outlook on Mac eating things and generally not working right. So, by way of sanity check, attached. The only changes were adding the binutils CVES to Known issues: binutils: fix CVE-2018-18309, CVE-2018-18605, CVE-2018-18606, CVE-2018-18607 And the gitsm known issue: - gitsm fixes on master-next: * The submodule name and path were assumed to be the same, which is not necessarily true. * Submodules refer to a specific commit, not branch, but we erroneously check against the branch specified in SRC_URI. This results in failure if a submodule commit is not on that branch. So, nothing major there. Just really a sanity check on the gitsm wording. Everything is ready to go. Pages are set and just need to be published. Release announcement is ready. So we just need to do the final mirror and tagging magic, and announce. If the wording on gitsm issue looks reasonable, we are good to go. -t --- yocto-2.6 Errata --- Release Name: bitbake-thud-20.0.0 Branch: 1.40.0 Tag: 1.40.0 Hash: 0cfc71d1a342b82781b0ba547421e41f6340902a md5: 0076740c69f41349c7799c874172391e Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/bitbake-thud-20.0.0.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.6/bitbake-thud-20.0.0.tar.bz2 Release Name: eclipse-poky-neon-thud-20.0.0 Branch: thud Tag: 2018-10 Hash: 303e46a6848f1937d12541a7fd58e61aa1361225 md5: f8ac98038e49fa22be3889291a137d2d Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/eclipse-poky-neon-thud-20.0.0.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.6/eclipse-poky-neon-thud-20.0.0.tar.bz2 Release Name: eclipse-poky-oxygen-thud-20.0.0 Branch: thud Tag: 2018-10 Hash: f1a20dc6a5a252a4ed4484b618d579cbbc7d146e md5: 61fd3f89fc5b7bb21a0adb42939f7787 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/eclipse-poky-oxygen-thud-20.0.0.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.6/eclipse-poky-oxygen-thud-20.0.0.tar.bz2 Release Name: meta-gplv2-thud-20.0.0 Branch: thud Tag: thud-20.0.0 Hash: 379ea8dd144b06aeb459e9a82c792c84d8a5baf7 md5: 8eb5e25e99245fcd135f6089011d6b3d Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/meta-gplv2-thud-20.0.0.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.6/meta-gplv2-thud-20.0.0.tar.bz2 Release Name: meta-intel-thud-20.0.0 Branch: thud Tag: thud-20.0.0 Hash: 847dcbb866bb48c3a051967dd0b46b452aa9d5c4 md5: ae67136bccf0a9799c51714e5fa8ee31 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/meta-intel-thud-20.0.0.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.6/meta-intel-thud-20.0.0.tar.bz2 Release Name: meta-mingw-thud-20.0.0 Branch: thud Tag: thud-20.0.0 Hash: 8ddd31f2dfe506e45f22a6dd67f997045a34804e md5: 2f32bb5cccee1bd3da40bb6b4e330cd9 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/meta-mingw-thud-20.0.0.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.6/meta-mingw-thud-20.0.0.tar.bz2 Release Name: meta-qt3-thud-20.0.0 Branch: thud Tag: thud-20.0.0 Hash: 02f273cba6c25f5cf20cb66d8a417a83772c3179 md5: 7b73bf1132428ea898938b03815cad21 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/meta-qt3-thud-20.0.0.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.6/meta-qt3-thud-20.0.0.tar.bz2 Release Name: meta-qt4-thud-20.0.0 Branch: thud Tag: thud-20.0.0 Hash: 8e791c40140460825956430ba86b6266fdec0a93 md5: 54d50515ac648ccfb8dba421705716e5 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/meta-qt4-thud-20.0.0.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.6/meta-qt4-thud-20.0.0.tar.bz2 Release Name: oecore-thud-20.0.0 Branch: thud Tag: thud-20.0.0 Hash: 1fd7d0f2fbf7e200844c675ddb77513a8d5d7327 md5: 8fd9580cc86bc3231da4647c6bba5231 Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/oecore-thud-20.0.0.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.6/oecore-thud-20.0.0.tar.bz2 Release Name: poky-thud-20.0.0 Branch: thud Tag: thud-20.0.0 Hash: 84eecb017ef92ef36b4df730908828e54aeff85c md5: 0bde045803827b62e53ccc07c7b5b6ad Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.6/poky-thud-20.0.0.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.6/poky-thud-20.0.0.tar.bz2 - New Features / Enhancements - * Linux kernel 4.18/4.14, gcc 8.2, glibc 2.28 and ~245 other recipe upgrades * Enabled security flags+pie by
Re: [linux-yocto] [PATCH] kmemleak: Turn kmemleak_lock to raw spinlock on RT
On 11/13/18 4:11 AM, zhe...@windriver.com wrote: From: He Zhe See https://lore.kernel.org/patchwork/patch/1011368/ for upstream status. kmemleak_lock, as a rwlock on RT, can possibly be held in atomic context and causes the follow BUG. Thanks. I'm waiting to see if there's any upstream feedback, and will wait a couple more days before deciding to merge. The alternative to making this a raw lock would be to simply declare it incompatible with -rt (Which is what we've done with different debug mechanisms in the past). Since there really should be relatively few (none??) -rt specific kmemleaks, and if you are really concerned about -rt, you likely wouldn't be running with it enabled. Bruce BUG: scheduling while atomic: migration/15/132/0x0002 Modules linked in: iTCO_wdt iTCO_vendor_support intel_rapl pcc_cpufreq pnd2_edac intel_powerclamp coretemp crct10dif_pclmul crct10dif_common aesni_intel matroxfb_base aes_x86_64 matroxfb_g450 matroxfb_accel crypto_simd matroxfb_DAC1064 cryptd glue_helper g450_pll matroxfb_misc i2c_ismt i2c_i801 acpi_cpufreq Preemption disabled at: [] cpu_stopper_thread+0x71/0x100 CPU: 15 PID: 132 Comm: migration/15 Not tainted 4.19.0-rt1-preempt-rt #1 Hardware name: Intel Corp. Harcuvar/Server, BIOS HAVLCRB1.X64.0015.D62.1708310404 08/31/2017 Call Trace: dump_stack+0x4f/0x6a ? cpu_stopper_thread+0x71/0x100 __schedule_bug.cold.16+0x38/0x55 __schedule+0x484/0x6c0 schedule+0x3d/0xe0 rt_spin_lock_slowlock_locked+0x118/0x2a0 rt_spin_lock_slowlock+0x57/0x90 __rt_spin_lock+0x26/0x30 __write_rt_lock+0x23/0x1a0 ? intel_pmu_cpu_dying+0x67/0x70 rt_write_lock+0x2a/0x30 find_and_remove_object+0x1e/0x80 delete_object_full+0x10/0x20 kmemleak_free+0x32/0x50 kfree+0x104/0x1f0 ? x86_pmu_starting_cpu+0x30/0x30 intel_pmu_cpu_dying+0x67/0x70 x86_pmu_dying_cpu+0x1a/0x30 cpuhp_invoke_callback+0x92/0x700 take_cpu_down+0x70/0xa0 multi_cpu_stop+0x62/0xc0 ? cpu_stop_queue_work+0x130/0x130 cpu_stopper_thread+0x79/0x100 smpboot_thread_fn+0x20f/0x2d0 kthread+0x121/0x140 ? sort_range+0x30/0x30 ? kthread_park+0x90/0x90 ret_from_fork+0x35/0x40 The following call trace, caused by grabbing kmemleak_lock twice, is also observed. kernel BUG at kernel/locking/rtmutex.c:1048! invalid opcode: [#1] PREEMPT SMP PTI CPU: 5 PID: 689 Comm: mkfs.ext4 Not tainted 4.18.16-rt9-preempt-rt #1 Hardware name: Intel Corp. Harcuvar/Server, BIOS HAVLCRB1.X64.0015.D62.1708310404 08/31/2017 RIP: 0010:rt_spin_lock_slowlock_locked+0x277/0x2a0 Code: e8 5e 64 61 ff e9 bc fe ff ff e8 54 64 61 ff e9 b7 fe ff ff 0f 0b e8 98 57 53 ff e9 43 fe ff ff e8 8e 57 53 ff e9 74 ff ff ff <0f> 0b 0f 0b 0f 0b 48 8b 43 10 48 85 c0 74 06 48 3b 58 38 75 0b 49 RSP: 0018:936846d4f3b0 EFLAGS: 00010046 RAX: 8e3680361e00 RBX: 83a8b240 RCX: 0001 RDX: RSI: 8e3680361e00 RDI: 83a8b258 RBP: 936846d4f3e8 R08: 8e3680361e01 R09: 82adfdf0 R10: 827ede18 R11: R12: 936846d4f3f8 R13: 8e3680361e00 R14: 936846d4f3f8 R15: 0246 FS: 7fc8b6bfd780() GS:8e369f34() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 55fb5659e000 CR3: 0007fdd14000 CR4: 003406e0 Call Trace: ? preempt_count_add+0x74/0xc0 rt_spin_lock_slowlock+0x57/0x90 ? __kernel_text_address+0x12/0x40 ? __save_stack_trace+0x75/0x100 __rt_spin_lock+0x26/0x30 __write_rt_lock+0x23/0x1a0 rt_write_lock+0x2a/0x30 create_object+0x17d/0x2b0 kmemleak_alloc+0x34/0x50 kmem_cache_alloc+0x146/0x220 ? mempool_alloc_slab+0x15/0x20 mempool_alloc_slab+0x15/0x20 mempool_alloc+0x65/0x170 sg_pool_alloc+0x21/0x60 __sg_alloc_table+0x101/0x160 ? sg_free_table_chained+0x30/0x30 sg_alloc_table_chained+0x8b/0xb0 scsi_init_sgtable+0x31/0x90 scsi_init_io+0x44/0x130 sd_setup_write_same16_cmnd+0xef/0x150 sd_init_command+0x6bf/0xaa0 ? cgroup_base_stat_cputime_account_end.isra.0+0x26/0x60 ? elv_rb_del+0x2a/0x40 scsi_setup_cmnd+0x8e/0x140 scsi_prep_fn+0x5d/0x140 blk_peek_request+0xda/0x2f0 scsi_request_fn+0x33/0x550 ? cfq_rb_erase+0x23/0x40 __blk_run_queue+0x43/0x60 cfq_insert_request+0x2f3/0x5d0 __elv_add_request+0x160/0x290 blk_flush_plug_list+0x204/0x230 schedule+0x87/0xe0 __write_rt_lock+0x18b/0x1a0 rt_write_lock+0x2a/0x30 create_object+0x17d/0x2b0 kmemleak_alloc+0x34/0x50 __kmalloc_node+0x1cd/0x340 alloc_request_size+0x30/0x70 mempool_alloc+0x65/0x170 ? ioc_lookup_icq+0x54/0x70 get_request+0x4e3/0x8d0 ? wait_woken+0x80/0x80 blk_queue_bio+0x153/0x470 generic_make_request+0x1dc/0x3f0 submit_bio+0x49/0x140 ? next_bio+0x38/0x40 submit_bio_wait+0x59/0x90 blkdev_issue_discard+0x7a/0xd0 ? _raw_spin_unlock_irqrestore+0x18/0x50 blk_ioctl_discard+0xc7/0x110 blkdev_ioctl+0x57e/0x960 ? __wake_up+0x13/0x20 block_ioctl+0x3d/0x50 do_vfs_ioctl+0xa8/0x610 ? vfs_write+0x166/0x1b0 ksys_ioctl+0x67/0x90
Re: [yocto] meta-mingw: unable to run executables on Windows
On 11/13/18 3:56 AM, Samuli Piippo wrote: > Hi, > > I've just upgraded poky and meta-mingw layers from sumo to thud and as a > result > a lot of the executables in the toolchain no longer run correctly on Windows. Which version of windows? > I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ > work > fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds and > exit without any output. > > Has anyone else seen this? I've run a toolchain made on mingw after sumo, but before thud's release. I'll see if I can find a VM and give it a try later today. --Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Inconsistent kernel builds with custom defconfig
I am trying to build a Linux kernel with a custom defconfig and am getting inconsistent builds. On a fresh/new run of "bitbake virtual/kernel" I get an incorrect kernel (zImage is ~1.1M in size). If I then do a "bitbake -c cleanall virtual/kernel" and then rerun "bitbake virtual/kernel" I get a good kernel (zImage is ~4.6M). I am using Yocto Sumo and standard Poky from git.yoctoproject.org/poky.git and only my custom kernel recipe and machine via a custom meta layer. My meta layer can be found at https://gitlab.com/cjmeyer/meta-socfpga and the builds I am running target the "arria10" machine. The defconfig I am using in the recipe is generated using "ARCH=arm make socfpga_defconfig" with the same Kernel sources being used in the recipe. I then copy the generated ".config" file to my "defconfing" in my kernel recipe. To reproduce the bad zImage after a successful run, I delete all files and directories from the Yocto build directory except for the "conf" directory. After doing this, rerunning "bitbake virtual/kernel" results in a bad zImage again (~1.1M in size). Comparing the ".config" in the kernel build directory in my Yocto build directory after a bad zImage is generated shows many, many differences to the defconfig from the recipe (I used a diff tool that understands kernel config files so it diffed the config, next the text). This leads me to believe that the configuration steps in my builds are not running consistently or correctly but I am not sure why. cmeyer -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] wic creates invalid image
Hi Alex & Dimitris, Thank you for the info. I tried to use gpt partition table as you suggested, but the raspberry pi compute module 3 I am using wouldn't boot, so i switched back to mbr/msdos. Now that I understand the origin of the extra extended partition, I can work around it. best regards, Donal On Tue, 13 Nov 2018 at 19:29, Dimitris Tassopoulos wrote: > Hi Alex, > > If you don't want the extended partitions you need to create a gpt > partition, you can do this by adding this to your wks file. > > bootloader --ptable gpt > > Regards, > Dimitris > > > On Tue, 13 Nov 2018, 20:23 Alex Kiernan >> On Tue, Nov 13, 2018 at 7:13 PM Donal Morrissey >> wrote: >> > >> > Hi There, >> > I have a problem with an image being created by wic. If I add more than >> 4 partition definitions to the wks file, the generated image will include >> an additional partition with no Fstype, and spanning the full length of the >> additional partitions. >> > >> > Take the following wks file: >> > >> > part --source rawcopy --sourceparams="file=> path>/image-r0/uboot.env" --ondisk "mmcblk0" --align 4096 --no-table >> > part --source bootimg-partition --ondisk "mmcblk0" --fstype=vfat >> --label boot --align 4096 --active --fixed-size 40 >> > part --source rootfs --ondisk "mmcblk0" --fstype=ext4 --label primary >> --align 4096 --fixed-size 147456k --exclude-path data/ >> > part --source rootfs --ondisk "mmcblk0" --fstype=ext4 --label secondary >> --align 4096 --fixed-size 147456k --exclude-path data/ >> > part --ondisk "mmcblk0" --fstype=ext4 --label appdata1 --align 4096 >> --fixed-size 147456k >> > part --ondisk "mmcblk0" --fstype=ext4 --label appdata2 --align 4096 >> --fixed-size 147456k >> > bootloader --ptable msdos >> > >> > wic will create a .direct file with the following structure: >> > Num StartEnd Size Fstype >> > 1 12582912 54525951 41943040 fat16 >> > 2 54525952205520895150994944 ext4 >> > 3 205520896356515839150994944 ext4 >> > 4 360709632666894335306184704 >> > 5 360710144511705087150994944 ext4 >> > 6 515899392666894335150994944 ext4 >> > >> > Note the start and end addresses of partition 4, it spans from the >> start of partitions 5 (appdata1) to the end of partition 6 (appdata2). >> > >> > If I modify the wks file and remove the entry for appdata2, the created >> direct file is valid: >> > >> > Num StartEnd Size Fstype >> > 1 12582912 54525951 41943040 fat16 >> > 2 54525952205520895150994944 ext4 >> > 3 205520896356515839150994944 ext4 >> > 4 356515840507510783150994944 ext4 >> > >> > Any suggestions on what is going on here? >> > >> >> I've not checked, but I'd assume it's switched to extended partitions, >> since MBR only has 4 primary partitions. >> >> -- >> Alex Kiernan >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] m4-native, zedboard, "Please port gnulib fseeko.c to your platform"
On Wed, Nov 14, 2018 at 5:19 PM Gunnar Andersson wrote: > > Robert, > > On Tue, 2018-11-13 at 15:28 -0500, Robert P. J. Day wrote: > > been away from YP for a few months, diving back in, want to build a > > core-image-minimal for my zedboard, and i will first admit that i'm > > using a non-approved distro (fully-updated fedora 29): > > > > [...] > > > but i'm unsure (read, have no clue) how to deal with this > > If upgrading Yocto/poky and layers is not an option for you, then building > in a container is the typical approach. This isolates you from any host- > distro issues, since any distro can be used in the container. > > Many just set up their own with a simple Docker file, but from what I > remember the CROPS project is one common project recommended in the past. > Here's a random starting point I found [1]. > move to thud, ive confirmed it works on fedora 29 after seeing the same issue, or ...VM with Debian / Ubuntu > HTH, > - Gunnar > > [1] https://www.yoctoproject.org/learn-items/cross-platform-enablement-for-t > he-yocto-project-with-containers/ > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] meta-gnome: what are dependencies for gnome-full-desktop (gnome interface)
On Wed, 14 Nov 2018 at 11:46, Knoppix wrote: > My question were implement the missing recipes for yocto->meta-gnome > To start from point I did want to learn dependency graphic of gnome3. > I subscripted devel right know. > Just to repeat: all of the recipes you'll need to write are on the oe-devel list now. They need work and testing, and your contributions are welcome. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] meta-gnome: what are dependencies for gnome-full-desktop (gnome interface)
My question were implement the missing recipes for yocto->meta-gnome To start from point I did want to learn dependency graphic of gnome3. I subscripted devel right know. Mr Burton: Thank you. On Wed, Nov 14, 2018 at 2:25 PM Burton, Ross wrote: > On Wed, 14 Nov 2018 at 08:42, Knoppix wrote: > >> (Excuse me for my english I am not native) >> >> One disappointment for me was learn that meta-gnome is not >> fully-supported for running desktop. So i want to write all remain recipes >> to use desktop environment. I want to start from scratch (except from >> meta-debian-recipes) because for learn gnome world. >> >> Dear friends, how can I learn what are the necessary binaries >> for gnome interface (i.e: desktop window panel, topbar, >> settings and other UI full-desktop-environment) to use on yocto project? >> Which project is I should start to write its recipe? >> > > If you just want to know what the GNOME dependencies are then you should > be asking GNOME. GNOME has a build tool called jhbuild, the module sets in > tht list all of the dependencies required. > > Note that there's a series to add the GNOME 3 desktop to meta-gnome under > review on the openembedded-devel list, so working on that would avoid > duplication of effort. > > Ross > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] meta-gnome: what are dependencies for gnome-full-desktop (gnome interface)
On Wed, 14 Nov 2018 at 08:42, Knoppix wrote: > (Excuse me for my english I am not native) > > One disappointment for me was learn that meta-gnome is not fully-supported > for running desktop. So i want to write all remain recipes to use desktop > environment. I want to start from scratch (except from meta-debian-recipes) > because for learn gnome world. > > Dear friends, how can I learn what are the necessary binaries > for gnome interface (i.e: desktop window panel, topbar, > settings and other UI full-desktop-environment) to use on yocto project? > Which project is I should start to write its recipe? > If you just want to know what the GNOME dependencies are then you should be asking GNOME. GNOME has a build tool called jhbuild, the module sets in tht list all of the dependencies required. Note that there's a series to add the GNOME 3 desktop to meta-gnome under review on the openembedded-devel list, so working on that would avoid duplication of effort. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] m4-native, zedboard, "Please port gnulib fseeko.c to your platform"
Robert, On Tue, 2018-11-13 at 15:28 -0500, Robert P. J. Day wrote: > been away from YP for a few months, diving back in, want to build a > core-image-minimal for my zedboard, and i will first admit that i'm > using a non-approved distro (fully-updated fedora 29): > [...] > but i'm unsure (read, have no clue) how to deal with this If upgrading Yocto/poky and layers is not an option for you, then building in a container is the typical approach. This isolates you from any host- distro issues, since any distro can be used in the container. Many just set up their own with a simple Docker file, but from what I remember the CROPS project is one common project recommended in the past. Here's a random starting point I found [1]. HTH, - Gunnar [1] https://www.yoctoproject.org/learn-items/cross-platform-enablement-for-t he-yocto-project-with-containers/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Enable wpa_supplicant@wlan0.service on boot with systemd
Thank you Chen Qi,
This makes it a lot clearer...
On Wed, 14 Nov 2018 at 10:23, ChenQi wrote:
> For the current codes, manually creating symlink is the easiest way to
> achieve your goal.
> The current mechanism in systemd.bbclass has to 'enable' or 'disable' all
> services in SYSTEMD_SERVICE_xxx. There's no mechanism to enable or disable
> a subset of them.
> This might need to be improved.
>
> Best Regards,
> Chen Qi
>
> On 11/14/2018 05:11 PM, Conor Slater wrote:
>
> Dear All,
>
> I'm trying to start wpa_supplicant with wlan0 as the interface on boot
> using systemd.
>
> I've created the following .bbappend for wpa_supplicant to install the new
> configuration and enable the wpa_supplicant@wlan0.service. This doesn't
> enable the service and somehow breaks being able the start the
> wpa_supplicant@wlan0.service.
>
> Has anybody else figured out how to get this to work?
>
> $ cat wpa-supplicant_2.%.bbppend:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>
> SRC_URI_append = " file://wpa_supplicant-wlan0.conf"
>
> inherit systemd
>
> SYSTEMD_PACKAGES = "${PN}"
> SYSTEMD_SERVICE_${PN} += " wpa_supplicant@wlan0.service"
> SYSTEMD_AUTO_ENABLE = "enable"
>
> do_install_append () {
> install -d ${D}${sysconfdir}/wpa_supplicant
> install -m 0644 ${WORKDIR}/wpa_supplicant-wlan0.conf
> ${D}/${sysconfdir}/wpa_supplicant/
> }
>
> As a workaround, I created a .bbappend to manually create the symlink for
> systemd which does enable the service. Although, I would like to know if
> there is a better way of doing this.
>
> $ cat wpa-supplicant_2.%.bbppend:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>
> SRC_URI_append = " file://wpa_supplicant-wlan0.conf"
>
> do_install_append () {
> install -d ${D}${sysconfdir}/wpa_supplicant
> install -m 0644 ${WORKDIR}/wpa_supplicant-wlan0.conf
> ${D}/${sysconfdir}/wpa_supplicant/
> install -d ${D}${sysconfdir}/systemd/system/multi-user.target.wants
> ln -s ../../../../lib/systemd/system/wpa_supplicant@.service ${D}${
> sysconfdir}/systemd/system/multi-user.target.wants/wpa_supplicant@wlan0.service
> }
>
>
>
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Enable wpa_supplicant@wlan0.service on boot with systemd
For the current codes, manually creating symlink is the easiest way to
achieve your goal.
The current mechanism in systemd.bbclass has to 'enable' or 'disable'
all services in SYSTEMD_SERVICE_xxx. There's no mechanism to enable or
disable a subset of them.
This might need to be improved.
Best Regards,
Chen Qi
On 11/14/2018 05:11 PM, Conor Slater wrote:
Dear All,
I'm trying to start wpa_supplicant with wlan0 as the interface on boot
using systemd.
I've created the following .bbappend for wpa_supplicant to install the
new configuration and enable the wpa_supplicant@wlan0.service. This
doesn't enable the service and somehow breaks being able the start the
wpa_supplicant@wlan0.service.
Has anybody else figured out how to get this to work?
$ cat wpa-supplicant_2.%.bbppend:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI_append = " file://wpa_supplicant-wlan0.conf"
inherit systemd
SYSTEMD_PACKAGES = "${PN}"
SYSTEMD_SERVICE_${PN} += " wpa_supplicant@wlan0.service"
SYSTEMD_AUTO_ENABLE = "enable"
do_install_append () {
install -d ${D}${sysconfdir}/wpa_supplicant
install -m 0644 ${WORKDIR}/wpa_supplicant-wlan0.conf
${D}/${sysconfdir}/wpa_supplicant/
}
As a workaround, I created a .bbappend to manually create the symlink
for systemd which does enable the service. Although, I would like to
know if there is a better way of doing this.
$ cat wpa-supplicant_2.%.bbppend:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI_append = " file://wpa_supplicant-wlan0.conf"
do_install_append () {
install -d ${D}${sysconfdir}/wpa_supplicant
install -m 0644 ${WORKDIR}/wpa_supplicant-wlan0.conf
${D}/${sysconfdir}/wpa_supplicant/
install -d ${D}${sysconfdir}/systemd/system/multi-user.target.wants
ln -s ../../../../lib/systemd/system/wpa_supplicant@.service
${D}${sysconfdir}/systemd/system/multi-user.target.wants/wpa_supplicant@wlan0.service
}
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Enable wpa_supplicant@wlan0.service on boot with systemd
Dear All,
I'm trying to start wpa_supplicant with wlan0 as the interface on boot
using systemd.
I've created the following .bbappend for wpa_supplicant to install the new
configuration and enable the wpa_supplicant@wlan0.service. This doesn't
enable the service and somehow breaks being able the start the
wpa_supplicant@wlan0.service.
Has anybody else figured out how to get this to work?
$ cat wpa-supplicant_2.%.bbppend:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI_append = " file://wpa_supplicant-wlan0.conf"
inherit systemd
SYSTEMD_PACKAGES = "${PN}"
SYSTEMD_SERVICE_${PN} += " wpa_supplicant@wlan0.service"
SYSTEMD_AUTO_ENABLE = "enable"
do_install_append () {
install -d ${D}${sysconfdir}/wpa_supplicant
install -m 0644 ${WORKDIR}/wpa_supplicant-wlan0.conf
${D}/${sysconfdir}/wpa_supplicant/
}
As a workaround, I created a .bbappend to manually create the symlink for
systemd which does enable the service. Although, I would like to know if
there is a better way of doing this.
$ cat wpa-supplicant_2.%.bbppend:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI_append = " file://wpa_supplicant-wlan0.conf"
do_install_append () {
install -d ${D}${sysconfdir}/wpa_supplicant
install -m 0644 ${WORKDIR}/wpa_supplicant-wlan0.conf
${D}/${sysconfdir}/wpa_supplicant/
install -d ${D}${sysconfdir}/systemd/system/multi-user.target.wants
ln -s ../../../../lib/systemd/system/wpa_supplicant@.service
${D}${sysconfdir}/systemd/system/multi-user.target.wants/wpa_supplicant@wlan0.service
}
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-gnome: what are dependencies for gnome-full-desktop (gnome interface)
(Excuse me for my english I am not native) One disappointment for me was learn that meta-gnome is not fully-supported for running desktop. So i want to write all remain recipes to use desktop environment. I want to start from scratch (except from meta-debian-recipes) because for learn gnome world. Dear friends, how can I learn what are the necessary binaries for gnome interface (i.e: desktop window panel, topbar, settings and other UI full-desktop-environment) to use on yocto project? Which project is I should start to write its recipe? My question is what should I search on search-engines? Would you advice me a tutorial please? Kind regards. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
