Re: [yocto] bitbake is corrupting my files during unpacking
Can you send the patch yourself since you already know how to do it ? On 07/27/2018 12:34 PM, Burton, Ross wrote: We don't take patches via pull requests (that repo is a mirror for convenience and should have PRs disabled), but patches on the openembedded-core mailing list. https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines has details as to the required patch formatting. Summary: Commit message should be of the form 'recipe: summary'. The patch you're adding also needs a summary explaining what it does, an Upstream-Status value (Pending I guess, as upstream is dead we can't submit it) and your Signed-off-by. Ross On 27 July 2018 at 10:27, MOHAMMAD RASIM wrote: Yes I made a pull request to the master branch https://github.com/openembedded/openembedded-core/pull/34 note that this issue can be replicated by unzipping any linux-kernel (I think), I tested that it exist in the zip file of torvalds tree https://github.com/torvalds/linux/archive/master.zip so it's easy to replicate and test Also, to anyone how face the same issue and find this message, I solved the issue without patching unzip by using tar.gz file instead of unzip file (thanks to github for providing that) so instead of https://github.com/torvalds/linux/archive/master.zip use https://github.com/torvalds/linux/archive/master.tar.gz Thanks On 07/23/2018 09:51 PM, Burton, Ross wrote: Yes, please do. Mohammad, as you can replicate this on demand, would you be able to fix the unzip recipe with the patch in that bug and send a patch? Ross On 23 July 2018 at 19:42, Andre McCurdy wrote: On Sat, Jul 21, 2018 at 12:55 AM, MOHAMMAD RASIM wrote: well apparently this is caused by the unzip binary that is compiled by the openembedded unzip recipe. If I unzip the same zip file with the unzip binary that is shipped with my system(manjaro) then the files are not corrupted but when I use the unzip binary compiled by the openembedded recipe I get error and file corruptions. These are some of the errors I get when unzipping with the openembedded unzip: ... symlink error: File name too long This error happens to multiple files where the file is symlinked to the content of the file and not to a path ! Where should I report this bug ? openembedded ? unzip upstream ? If you google the "symlink error" you should find multiple hits, which all indicate a known bug in upstream unzip 6.0. So, it should be reported upstream. However, given that the last unzip release is now over 9 years old and there doesn't appear to be a public upstream development branch, the chances of getting a timely response don't look too good. We should probably add the fix to the unzip recipe in oe-core: https://bugzilla.redhat.com/show_bug.cgi?id=972427 -- ___ 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] bitbake is corrupting my files during unpacking
We don't take patches via pull requests (that repo is a mirror for convenience and should have PRs disabled), but patches on the openembedded-core mailing list. https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines has details as to the required patch formatting. Summary: Commit message should be of the form 'recipe: summary'. The patch you're adding also needs a summary explaining what it does, an Upstream-Status value (Pending I guess, as upstream is dead we can't submit it) and your Signed-off-by. Ross On 27 July 2018 at 10:27, MOHAMMAD RASIM wrote: > Yes I made a pull request to the master branch > https://github.com/openembedded/openembedded-core/pull/34 > > note that this issue can be replicated by unzipping any linux-kernel (I > think), I tested that it exist in the zip file of torvalds tree > https://github.com/torvalds/linux/archive/master.zip > > so it's easy to replicate and test > > Also, to anyone how face the same issue and find this message, I solved the > issue without patching unzip by using tar.gz file instead of unzip file > (thanks to github for providing that) so instead of > https://github.com/torvalds/linux/archive/master.zip use > https://github.com/torvalds/linux/archive/master.tar.gz > > > Thanks > > > > On 07/23/2018 09:51 PM, Burton, Ross wrote: >> >> Yes, please do. Mohammad, as you can replicate this on demand, would >> you be able to fix the unzip recipe with the patch in that bug and >> send a patch? >> >> Ross >> >> On 23 July 2018 at 19:42, Andre McCurdy wrote: >>> >>> On Sat, Jul 21, 2018 at 12:55 AM, MOHAMMAD RASIM >>> wrote: well apparently this is caused by the unzip binary that is compiled by the openembedded unzip recipe. If I unzip the same zip file with the unzip binary that is shipped with my system(manjaro) then the files are not corrupted but when I use the unzip binary compiled by the openembedded recipe I get error and file corruptions. These are some of the errors I get when unzipping with the openembedded unzip: ... symlink error: File name too long This error happens to multiple files where the file is symlinked to the content of the file and not to a path ! Where should I report this bug ? openembedded ? unzip upstream ? >>> >>> If you google the "symlink error" you should find multiple hits, which >>> all indicate a known bug in upstream unzip 6.0. >>> >>> So, it should be reported upstream. However, given that the last unzip >>> release is now over 9 years old and there doesn't appear to be a >>> public upstream development branch, the chances of getting a timely >>> response don't look too good. >>> >>> We should probably add the fix to the unzip recipe in oe-core: >>> >>>https://bugzilla.redhat.com/show_bug.cgi?id=972427 >>> -- >>> ___ >>> 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] bitbake is corrupting my files during unpacking
Yes I made a pull request to the master branch https://github.com/openembedded/openembedded-core/pull/34 note that this issue can be replicated by unzipping any linux-kernel (I think), I tested that it exist in the zip file of torvalds tree https://github.com/torvalds/linux/archive/master.zip so it's easy to replicate and test Also, to anyone how face the same issue and find this message, I solved the issue without patching unzip by using tar.gz file instead of unzip file (thanks to github for providing that) so instead of https://github.com/torvalds/linux/archive/master.zip use https://github.com/torvalds/linux/archive/master.tar.gz Thanks On 07/23/2018 09:51 PM, Burton, Ross wrote: Yes, please do. Mohammad, as you can replicate this on demand, would you be able to fix the unzip recipe with the patch in that bug and send a patch? Ross On 23 July 2018 at 19:42, Andre McCurdy wrote: On Sat, Jul 21, 2018 at 12:55 AM, MOHAMMAD RASIM wrote: well apparently this is caused by the unzip binary that is compiled by the openembedded unzip recipe. If I unzip the same zip file with the unzip binary that is shipped with my system(manjaro) then the files are not corrupted but when I use the unzip binary compiled by the openembedded recipe I get error and file corruptions. These are some of the errors I get when unzipping with the openembedded unzip: ... symlink error: File name too long This error happens to multiple files where the file is symlinked to the content of the file and not to a path ! Where should I report this bug ? openembedded ? unzip upstream ? If you google the "symlink error" you should find multiple hits, which all indicate a known bug in upstream unzip 6.0. So, it should be reported upstream. However, given that the last unzip release is now over 9 years old and there doesn't appear to be a public upstream development branch, the chances of getting a timely response don't look too good. We should probably add the fix to the unzip recipe in oe-core: https://bugzilla.redhat.com/show_bug.cgi?id=972427 -- ___ 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] bitbake is corrupting my files during unpacking
Yes, please do. Mohammad, as you can replicate this on demand, would you be able to fix the unzip recipe with the patch in that bug and send a patch? Ross On 23 July 2018 at 19:42, Andre McCurdy wrote: > On Sat, Jul 21, 2018 at 12:55 AM, MOHAMMAD RASIM > wrote: >> well apparently this is caused by the unzip binary that is compiled by the >> openembedded unzip recipe. >> If I unzip the same zip file with the unzip binary that is shipped with my >> system(manjaro) then the files are not corrupted but when I use the unzip >> binary compiled by the openembedded recipe I get error and file corruptions. >> These are some of the errors I get when unzipping with the openembedded >> unzip: >> ... >> symlink error: File name too long >> >> This error happens to multiple files where the file is symlinked to the >> content of the file and not to a path ! >> Where should I report this bug ? openembedded ? unzip upstream ? > > If you google the "symlink error" you should find multiple hits, which > all indicate a known bug in upstream unzip 6.0. > > So, it should be reported upstream. However, given that the last unzip > release is now over 9 years old and there doesn't appear to be a > public upstream development branch, the chances of getting a timely > response don't look too good. > > We should probably add the fix to the unzip recipe in oe-core: > > https://bugzilla.redhat.com/show_bug.cgi?id=972427 > -- > ___ > 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] bitbake is corrupting my files during unpacking
On Sat, Jul 21, 2018 at 12:55 AM, MOHAMMAD RASIM wrote: > well apparently this is caused by the unzip binary that is compiled by the > openembedded unzip recipe. > If I unzip the same zip file with the unzip binary that is shipped with my > system(manjaro) then the files are not corrupted but when I use the unzip > binary compiled by the openembedded recipe I get error and file corruptions. > These are some of the errors I get when unzipping with the openembedded > unzip: > ... > symlink error: File name too long > > This error happens to multiple files where the file is symlinked to the > content of the file and not to a path ! > Where should I report this bug ? openembedded ? unzip upstream ? If you google the "symlink error" you should find multiple hits, which all indicate a known bug in upstream unzip 6.0. So, it should be reported upstream. However, given that the last unzip release is now over 9 years old and there doesn't appear to be a public upstream development branch, the chances of getting a timely response don't look too good. We should probably add the fix to the unzip recipe in oe-core: https://bugzilla.redhat.com/show_bug.cgi?id=972427 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake is corrupting my files during unpacking
well apparently this is caused by the unzip binary that is compiled by
the openembedded unzip recipe.
If I unzip the same zip file with the unzip binary that is shipped with
my system(manjaro) then the files are not corrupted but when I use the
unzip binary compiled by the openembedded recipe I get error and file
corruptions.
These are some of the errors I get when unzipping with the openembedded
unzip:
lchmod (file attributes) error: Function not implemented
linux-amlogic-amlogic-3.14-nougat/security/keys/request_key_auth.c -> /*
Request key authorisation token key definition.^J *^J * Copyright (C)
2005 Red Hat, Inc. All Rights Reserved.^J * Written by David Howells
(dhowe...@redhat.com)^J *^J * This program is free software; you can
redistribute it and/or^J * modify it under the terms of the GNU General
Public License^J * as published by the Free Software Foundation; either
version^J * 2 of the License, or (at your option) any later version.^J
*^J * See Documentation/security/keys-request-key.txt^J */^J^J#include
^J#include ^J#include
^J#include ^J#include
^J#include ^J#include
"internal.h"^J#include ^J^Jstatic int
request_key_auth_instantiate(struct key *,^J^I^I^I^I^Istruct
key_preparsed_payload *);^Jstatic void request_key_auth_describe(const
struct key *, struct seq_file *);^Jstatic void
request_key_auth_revoke(struct key *);^Jstatic void
request_key_auth_destroy(struct key *);^Jstatic long
request_key_auth_read(const struct key *, char __user *,
size_t);^J^J/*^J * The request-key authorisation key type definition.^J
*/^Jstruct key_type key_type_request_key_auth = {^J^I.name^I^I=
".request_key_auth",^J^I.def_datalen^I= sizeof(struct
request_key_auth),^J^I.instantiate^I=
request_key_auth_instantiate,^J^I.describe^I=
request_key_auth_describe,^J^I.revoke^I^I=
request_key_auth_revoke,^J^I.destroy^I=
request_key_auth_destroy,^J^I.read^I^I=
request_key_auth_read,^J};^J^J/*^J * Instantiate a request-key
authorisation key.^J */^Jstatic int request_key_auth_instantiate(struct
key *key,^J^I^I^I^I^Istruct key_preparsed_payload
*prep)^J{^J^Ikey->payload.data = (struct request_key_auth
*)prep->data;^J^Ireturn 0;^J}^J^J/*^J * Describe an authorisation
token.^J */^Jstatic void request_key_auth_describe(const struct key
*key,^J^I^I^I^I struct seq_file *m)^J{^J^Istruct request_key_auth *rka =
key->payload.data;^J^J^Iseq_puts(m, "key:");^J^Iseq_puts(m,
key->description);^J^Iif (key_is_instantiated(key))^J^I^Iseq_printf(m, "
pid:%d ci:%zu", rka->pid, rka->callout_len);^J}^J^J/*^J * Read the
callout_info data (retrieves the callout information).^J * - the key's
semaphore is read-locked^J */^Jstatic long request_key_auth_read(const
struct key *key,^J^I^I^I^I char __user *buffer, size_t
buflen)^J{^J^Istruct request_key_auth *rka =
key->payload.data;^J^Isize_t datalen;^J^Ilong ret;^J^J^Idatalen =
rka->callout_len;^J^Iret = datalen;^J^J^I/* we can return the data as is
*/^J^Iif (buffer && buflen > 0) {^J^I^Iif (buflen >
datalen)^J^I^I^Ibuflen = datalen;^J^J^I^Iif (copy_to_user(buffer,
rka->callout_info, buflen) != 0)^J^I^I^Iret = -EFAULT;^J^I}^J^J^Ireturn
ret;^J}^J^J/*^J * Handle revocation of an authorisation token key.^J *^J
* Called with the key sem write-locked.^J */^Jstatic void
request_key_auth_revoke(struct key *key)^J{^J^Istruct request_key_auth
*rka = key->payload.data;^J^J^Ikenter("{%d}", key->serial);^J^J^Iif
(rka->cred) {^J^I^Iput_cred(rka->cred);^J^I^Irka->cred =
NULL;^J^I}^J}^J^J/*^J * Destroy an instantiation authorisation token
key.^J */^Jstatic void request_key_auth_destroy(struct key
*key)^J{^J^Istruct request_key_auth *rka =
key->payload.data;^J^J^Ikenter("{%d}", key->serial);^J^J^Iif (rka->cred)
{^J^I^Iput_cred(rka->cred);^J^I^Irka->cred =
NULL;^J^I}^J^J^Ikey_put(rka->target_key);^J^Ikey_put(rka->dest_keyring);^J^Ikfree(rka->callout_info);^J^Ikfree(rka);^J}^J^J/*^J
* Create an authorisation token for /sbin/request-key or whoever to
gain^J * access to the caller's security data.^J */^Jstruct key
*request_key_auth_new(struct key *target, const void
*callout_info,^J^I^I^I^I size_t callout_len, struct key
*dest_keyring)^J{^J^Istruct request_key_auth *rka, *irka;^J^Iconst
struct cred *cred = current->cred;^J^Istruct key *authkey =
NULL;^J^Ichar desc[20];^J^Iint ret;^J^J^Ikenter("%d,",
target->serial);^J^J^I/* allocate a auth record */^J^Irka =
kmalloc(sizeof(*rka), GFP_KERNEL);^J^Iif (!rka) {^J^I^Ikleave(" =
-ENOMEM");^J^I^Ireturn ERR_PTR(-ENOMEM);^J^I}^J^Irka->callout_info =
kmalloc(callout_len, GFP_KERNEL);^J^Iif (!rka->callout_info)
{^J^I^Ikleave(" = -ENOMEM");^J^I^Ikfree(rka);^J^I^Ireturn
ERR_PTR(-ENOMEM);^J^I}^J^J^I/* see if the calling process is already
servicing the key request of^J^I * another process */^J^Iif
(cred->request_key_auth) {^J^I^I/* it is - use that instantiation
context here too
*/^J^I^Idown_read(&cred->request_key_auth->sem);^J^J^I^I/* if the auth
key has been revoked, then the key we're^J^I^I * servicing is
[yocto] bitbake is corrupting my files during unpacking
Hi, I'm new to openembedded and yocto. I'm using the openpli meta layers to build openembedded https://github.com/OpenPLi/openpli-oe-core Now I'm trying to build a recipe for the kernel but I encountered a strange issue, bitbake is corrupting my source files when unpacking from zip file (http link of zip file) but not when using git to get the source the files are fine and not corrupted, the downloaded zip file itself is not corrupted and If I unzip it from the sources directory(outside bitbake environment) then the resulting files are not corrupted The zip file I'm downloading https://github.com/PLi-metas/linux-amlogic/archive/amlogic-3.14-nougat.zip examples of corruption I saw : 1- /drivers/w1/slaves/Kconfig (this file is converted to a broken symlink not to a path but to the content of the file itself, see: file build/tmp/work-shared/k2pro_s905/kernel-source/drivers/w1/slaves/Kconfig build/tmp/work-shared/k2pro_s905/kernel-source/drivers/w1/slaves/Kconfig: broken symbolic link to #\012# 1-wire slaves configuration\012#\012\012menu "1-wire Slaves"\012\012config W1_SLAVE_THERM\012\011tristate "Thermal family implementation"\012\011help\012\011 Say Y here if you want to connect 1-wire thermal sensors to your\012\011 wire.\012\012config W1_SLAVE_SMEM\012\011tristate "Simple 64bit memory family implementation"\012\011help\012\011 Say Y here if you want to connect 1-wire\012\011 simple 64bit memory rom(ds2401/ds2411/ds1990*) to your wire.\012\012config W1_SLAVE_DS2408\012\011tristate "8-Channel Addressable Switch (IO Expander) 0x29 family support (DS2408)"\012\011help\012\011 Say Y here if you want to use a 1-wire\012\011 DS2408 8-Channel Addressable Switch device support\012\012config W1_SLAVE_DS2408_READBACK\012\011bool "Read-back values written to DS2408's output register"\012\011depends on W1_SLAVE_DS2408\012\011default y\012\011help\012\011 Enabling this will cause the driver to read back the values written\012\011 to the chip's output register in order to detect errors.\012\012\011 This is slower but useful when debugging chips and/or busses.\012\012config W1_SLAVE_DS2413\012\011tristate "Dual Channel Addressable Switch 0x3a family support (DS2413)"\012\011help\012\011 Say Y here if you want to use a 1-wire\012\011 DS2413 Dual Channel Addressable Switch device support\012\012config W1_SLAVE_DS2423\012\011tristate "Counter 1-wire device (DS2423)"\012\011select CRC16\012\011help\012\011 If you enable this you can read the counter values available\012\011 in the DS2423 chipset from the w1_slave file under the\012\011 sys file system.\012\012\011 Say Y here if you want to use a 1-wire\012\011 counter family device (DS2423).\012\012config W1_SLAVE_DS2431\012\011tristate "1kb EEPROM family support (DS2431)"\012\011help\012\011 Say Y here if you want to use a 1-wire\012\011 1kb EEPROM family device (DS2431)\012\012config W1_SLAVE_DS2433\012\011tristate "4kb EEPROM family support (DS2433)"\012\011help\012\011 Say Y here if you want to use a 1-wire\012\011 4kb EEPROM family device (DS2433).\012\012config W1_SLAVE_DS2433_CRC\012\011bool "Protect DS2433 data with a CRC16"\012\011depends on W1_SLAVE_DS2433\012\011select CRC16\012\011help\012\011 Say Y here to protect DS2433 data with a CRC16.\012\011 Each block has 30 bytes of data and a two byte CRC16.\012\011 Full block writes are only allowed if the CRC is valid.\012\012config W1_SLAVE_DS2760\012\011tristate "Dallas 2760 battery monitor chip (HP iPAQ & others)"\012\011depends on W1\012\011help\012\011 If you enable this you will have the DS2760 battery monitor\012\011 chip support.\012\012\011 The battery monitor chip is used in many batteries/devices\012\011 as the one who is responsible for charging/discharging/monitoring\012\011 Li+ batteries.\012\012\011 If you are unsure, say N.\012\012config W1_SLAVE_DS2780\012\011tristate "Dallas 2780 battery monitor chip"\012\011depends on W1\012\011help\012\011 If you enable this you will have the DS2780 battery monitor\012\011 chip support.\012\012\011 The battery monitor chip is used in many batteries/devices\012\011 as the one who is responsible for charging/discharging/monitoring\012\011 Li+ batteries.\012\012\011 If you are unsure, say N.\012\012config W1_SLAVE_DS2781\012\011tristate "Dallas 2781 battery monitor chip"\012\011depends on W1\012\011help\012\011 If you enable this you will have the DS2781 battery monitor\012\011 chip support.\012\012\011 The battery monitor chip is used in many batteries/devices\012\011 as the one who is responsible for charging/discharging/monitoring\012\011 Li+ batteries.\012\012\011 If you are unsure, say N.\012\012config W1_SLAVE_DS28E04\012\011tristate "4096-Bit Addressable 1-Wire EEPROM with PIO (DS28E04-100)"\012\011depends on W1\012\011select CRC16\012\011help\012\011 If you enable this you will have the DS28E04-100\012\011 chip support.\012\012\011 Say Y
