Re: [yocto] distrodata documentation in 2.7 Mega Manual
I can take the section in the ref-manual for the "distrodata.bbclass" out. However, I could use some clarifications on the following areas where "distrdata" is referenced. I don't think I can just remove all of the terms. Here they are: * In dev-manual's "Using the Auto Upgrade Helper (AUH)" section - https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#gs-using-the-auto-upgrade-helper: Step 5 talks about making configurations in the local.conf file. First thing is to enable "distrodata" by inheriting the class. Do we have an equivalent for this now that the class is gone? * in ref-manual's "do_distrodata" task section - https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#ref-tasks-distrodata: Does this task disappear as well? Or, is there an equivalent? * In ref-manual's "do_checkpkg" task section - https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#ref-tasks-checkpkg: This task was included as part of the distrodata.bbclass. How do we address the do_checkpkg task section now? * In the UPSTREAM_CHECK_GETTAGREGEX variable description in the ref-manual glossary - https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_GITTAGREGEX: How do we change this? * in the UPSTREAM_CHECK_REGEX variable description also in the glossary - https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_REGEX: How do we change this? * in the UPSTREAM_CHECK_URI variable description also int he glossary - https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_URI: How do we change this? Thanks, Scott On Tue, May 21, 2019 at 12:31 PM Paul Barker wrote: > Just reading the 2.7 Mega Manual at > https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html and > noticed a possible bug. > > "24.15.9. Removed Classes" indicates that the `distrodata` class is now > gone. However it's still referred to in several other places in the > documentation. May need a bit of garbage collection. > > Thanks, > > -- > Paul Barker > Managing Director & Principal Engineer > Beta Five Ltd > -- > ___ > 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] GPLv3 package present in rootfs
On Wed, 22 May 2019 at 06:26, virendra kumar thakur
wrote:
> still some package gnutls, libidn2, libassuan, are added into rootfs.
Randomly picking libassuan:
LICENSE_${PN} = "LGPLv2.1+"
The library itself is LGPL-2. Have you verified the *package*
licenses for what is actually going into the image?
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-gplv2][PATCH] bc: use u-a for bc as well
* bc can be provided by busybox as well (e.g. if you have your own
defconfig and forget to explicitly disable it:
...
*
* Miscellaneous Utilities
*
adjtimex (4.7 kb) (ADJTIMEX) [N/y/?] n
bbconfig (9.7 kb) (BBCONFIG) [N/y/?] n
bc (45 kb) (BC) [Y/n/?] (NEW) dc (36 kb) (DC) [Y/n/?] y
Use bc code base for dc (larger, more features) (FEATURE_DC_BIG) [Y] (NEW) y
Interactive mode (+4kb) (FEATURE_BC_INTERACTIVE) [Y/n/?] (NEW) Enable
bc/dc long options (FEATURE_BC_LONG_OPTIONS) [Y/n] (NEW) beep (2.4 kb) (BEEP)
[N/y/?] n
chat (6.3 kb) (CHAT) [N/y/?] n
conspy (10 kb) (CONSPY) [N/y/?] n
...
), causing conflict in u-a:
update-alternatives: Error: not linking /usr/bin/bc to /bin/busybox.nosuid
since /usr/bin/bc exists and is not a link
and then whole do_rootfs or do_populate_sdk to fail because busybox postinst
is failing:
do_populate_sdk: Postinstall scriptlets of ['busybox'] have failed. If the
intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} (). Deferring to
first boot via 'exit 1' is no longer supported.
Signed-off-by: Martin Jansa
---
recipes-extended/bc/bc_1.06.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-extended/bc/bc_1.06.bb b/recipes-extended/bc/bc_1.06.bb
index d8c8a86..3de1b24 100644
--- a/recipes-extended/bc/bc_1.06.bb
+++ b/recipes-extended/bc/bc_1.06.bb
@@ -20,7 +20,7 @@ SRC_URI[sha256sum] =
"4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea7
inherit autotools texinfo update-alternatives
-ALTERNATIVE_${PN} = "dc"
+ALTERNATIVE_${PN} = "bc dc"
ALTERNATIVE_PRIORITY = "100"
BBCLASSEXTEND = "native"
--
2.17.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] problem adding a user
Rudolf,
Here is the first half of the file, the whole file is over the 500k limit of
free pastebin:
https://pastebin.com/UcnKebce
And here is the 2nd half of the file:
https://pastebin.com/9117tdUU
Greg
From: Rudolf Streif
Sent: Wednesday, May 22, 2019 12:42:40 PM
To: Greg Wilson-Lindberg
Cc: Yocto list discussion
Subject: Re: [yocto] problem adding a user
Greg,
Can you share the logfile via Pastebin?
:rjs
On Tue, May 21, 2019 at 11:09 AM Greg Wilson-Lindberg
mailto:gwil...@sakuraus.com>> wrote:
Rudolf,
Something else is happening to me. I changed to this in the image recipe:
SAKURA_USER = "sakura"
SAKURA_PASSWD = "Distracted"
SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"
EXTRA_USERS_PARAMS = "\
usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
usermod -a -G sudo,dialout ${SAKURA_USER}; \
"
deleting all of the commented out lines, and I get this in the log file:
/scribe/1.0-r0/rootfs -p '' sakura]
nothing between the single quotes. It's acting like SAKURA_PASS is not defined.
This is only happening when I'm trying the MD5 password.
Greg
From: Rudolf Streif mailto:rudolf.str...@ibeeto.com>>
Sent: Tuesday, May 21, 2019 5:37:23 AM
To: Greg Wilson-Lindberg
Cc: Yocto list discussion
Subject: Re: [yocto] problem adding a user
Greg,
usermod does not work for the MD5 algorithm with the explicit password hash as
it contains the $ field delimiters which are interpreted by the shell executing
the usermod command. Use single quotes around the password hash:
usermod -p '${SAKURA_PASS}' ${SAKURA_USER};
:rjs
On Mon, May 20, 2019, 11:55 Greg Wilson-Lindberg
mailto:gwil...@sakuraus.com>> wrote:
Hi Rudolf,
I've had more time to work with this and I'm still having problems getting
everything to work properly. I've attached the image recipe recipe that I'm
using so I don't leave any thing out that may be relevant.
When I build with a password that is no more more than 8 characters long
and no non-alphabetic characters:
SAKURA_PASSWD = "Distract"
SAKURA_PASS = "WRsDFfg1BsrDM"
everything works correctly.
I first tried that using the `openssl ...` form, and then I tried the
-1, MD5 BSD form and had problems, so I changed to doing the openssl
on the command line and making sure that I don't have any characters
that display as '.' or '/'. Again, if I don't do more than 8 characters
and no special characters everything works.
When I changed to using 'Ds$tr@ct' it stopped working. The build finishes
and the log file shows the usermod being exectued correctly:
NOTE: scribe: Performing usermod with [-R
/home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
-p kyNsrvS0elMWU sakura]
NOTE: scribe: Performing usermod with [-R
/home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
-a -G sudo,dialout sakura]
But when I try to sign in it doesn't work.
I then tried the 10 character password 'Distracted', the build fails:
NOTE: scribe: Performing usermod with [-R
/home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
-p sakura]
Usage: usermod [options] LOGIN
Options:
-c, --comment COMMENT new value of the GECOS field
-d, --home HOME_DIR new home directory for the user account
-e, --expiredate EXPIRE_DATE set account expiration date to EXPIRE_DATE
-f, --inactive INACTIVE set password inactive after expiration
to INACTIVE
-g, --gid GROUP force use GROUP as new primary group
-G, --groups GROUPS new list of supplementary GROUPS
-a, --append append the user to the supplemental GROUPS
mentioned by the -G option without removing
him/her from other groups
-h, --helpdisplay this help message and exit
-l, --login NEW_LOGIN new value of the login name
-L, --locklock the user account
-m, --move-home move contents of the home directory to the
new location (use only with -d)
-o, --non-unique allow using duplicate (non-unique) UID
-p, --password PASSWORD use encrypted password for the new password
-P, --clear-password PASSWORD use clear password for the new password
-R, --root CHROOT_DIR directory to chroot into
-s, --shell SHELL new login shell for the user account
-u, --uid UID new UID for the user account
-U, --unlock unlock the user account
-v, --add-subuids FIRST-LAST add range of subordinate uids
-V, --del-subuids FIRST-LAST remove range of subordinate uids
-w, --add-subgids FIRST-LAST add range of subordinate gids
-W, --del-subgids
Re: [yocto] problem adding a user
Greg,
Can you share the logfile via Pastebin?
:rjs
On Tue, May 21, 2019 at 11:09 AM Greg Wilson-Lindberg
wrote:
> Rudolf,
>
> Something else is happening to me. I changed to this in the image recipe:
>
> SAKURA_USER = "sakura"
>
> SAKURA_PASSWD = "Distracted"
> SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"
>
> EXTRA_USERS_PARAMS = "\
> usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
> usermod -a -G sudo,dialout ${SAKURA_USER}; \
> "
>
> deleting all of the commented out lines, and I get this in the log file:
>
>
> /scribe/1.0-r0/rootfs -p '' sakura]
>
>
> nothing between the single quotes. It's acting like SAKURA_PASS is not
> defined.
>
> This is only happening when I'm trying the MD5 password.
>
>
> Greg
> --
> *From:* Rudolf Streif
> *Sent:* Tuesday, May 21, 2019 5:37:23 AM
> *To:* Greg Wilson-Lindberg
> *Cc:* Yocto list discussion
> *Subject:* Re: [yocto] problem adding a user
>
> Greg,
>
> usermod does not work for the MD5 algorithm with the explicit password
> hash as it contains the $ field delimiters which are interpreted by the
> shell executing the usermod command. Use single quotes around the password
> hash:
>
> usermod -p '${SAKURA_PASS}' ${SAKURA_USER};
>
> :rjs
>
> On Mon, May 20, 2019, 11:55 Greg Wilson-Lindberg
> wrote:
>
>> Hi Rudolf,
>>
>> I've had more time to work with this and I'm still having problems getting
>> everything to work properly. I've attached the image recipe recipe that I'm
>> using so I don't leave any thing out that may be relevant.
>>
>> When I build with a password that is no more more than 8 characters long
>> and no non-alphabetic characters:
>>
>> SAKURA_PASSWD = "Distract"
>> SAKURA_PASS = "WRsDFfg1BsrDM"
>>
>> everything works correctly.
>>
>> I first tried that using the `openssl ...` form, and then I tried the
>> -1, MD5 BSD form and had problems, so I changed to doing the openssl
>> on the command line and making sure that I don't have any characters
>> that display as '.' or '/'. Again, if I don't do more than 8 characters
>> and no special characters everything works.
>>
>> When I changed to using 'Ds$tr@ct' it stopped working. The build finishes
>> and the log file shows the usermod being exectued correctly:
>>
>> NOTE: scribe: Performing usermod with [-R
>> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>> -p kyNsrvS0elMWU sakura]
>> NOTE: scribe: Performing usermod with [-R
>> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>> -a -G sudo,dialout sakura]
>>
>> But when I try to sign in it doesn't work.
>>
>> I then tried the 10 character password 'Distracted', the build fails:
>>
>> NOTE: scribe: Performing usermod with [-R
>> /home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
>> -p sakura]
>> Usage: usermod [options] LOGIN
>>
>> Options:
>> -c, --comment COMMENT new value of the GECOS field
>> -d, --home HOME_DIR new home directory for the user account
>> -e, --expiredate EXPIRE_DATE set account expiration date to EXPIRE_DATE
>> -f, --inactive INACTIVE set password inactive after expiration
>> to INACTIVE
>> -g, --gid GROUP force use GROUP as new primary group
>> -G, --groups GROUPS new list of supplementary GROUPS
>> -a, --append append the user to the supplemental GROUPS
>> mentioned by the -G option without removing
>> him/her from other groups
>> -h, --helpdisplay this help message and exit
>> -l, --login NEW_LOGIN new value of the login name
>> -L, --locklock the user account
>> -m, --move-home move contents of the home directory to the
>> new location (use only with -d)
>> -o, --non-unique allow using duplicate (non-unique) UID
>> -p, --password PASSWORD use encrypted password for the new password
>> -P, --clear-password PASSWORD use clear password for the new password
>> -R, --root CHROOT_DIR directory to chroot into
>> -s, --shell SHELL new login shell for the user account
>> -u, --uid UID new UID for the user account
>> -U, --unlock unlock the user account
>> -v, --add-subuids FIRST-LAST add range of subordinate uids
>> -V, --del-subuids FIRST-LAST remove range of subordinate uids
>> -w, --add-subgids FIRST-LAST add range of subordinate gids
>> -W, --del-subgids FIRST-LAST remove range of subordinate gids
>>
>> ERROR: scribe: usermod command did not succeed.
>>
>> So, even though I'm putting in the openssl output:
>> openssl passwd -1 "Distracted"
>> $1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0
>>
>>
[yocto] Building single package as image, respecting dependencies
Hi there,
I am currently working on a minimal CLI only system.
The image is based on 'core-image-base' using sysvinit and busybox.
To reduce image size and boot time, I removed as many packages as possible. For
some application cases I will need python3 though.
My idea was to have python3 as some kind of add-on in a squashfs image, that
can be mounted only when needed.
So I tried to build an image only containing the python3 package, but as little
as possible otherwise, like this:
inherit image
IMAGE_FSTYPES = "squashfs-xz"
DEFAULT_TASK_PROVIDER = ""
DISTRO_EXTRA_RDEPENDS = ""
DISTRO_FEATURES = ""
POKY_DEFAULT_EXTRA_RDEPENDS = ""
IMAGE_FEATURES = ""
IMAGE_LINGUAS = ""
CORE_IMAGE_BASE_INSTALL = ""
RDEPENDS_${PN} = ""
PACKAGE_EXCLUDE = "busybox openssl run-postinsts update-rc.d"
VIRTUAL-RUNTIME_dev_manager = ""
VIRTUAL-RUNTIME_login_manager = ""
VIRTUAL-RUNTIME_init_manager = ""
VIRTUAL-RUNTIME_initscripts = ""
VIRTUAL-RUNTIME_keymaps = ""
VIRTUAL-RUNTIME_base-utils = ""
PREFERRED_PROVIDER_virtual/base-utils = ""
IMAGE_INSTALL = "python3"
But like this I can only manually exclude packages I already have in my main OS
image. Some packages can't be excluded at all, as python3 depends on them and
won't build if they are excluded.
Is there a way to have dependencies between images? So I could have the
python-image build know which dependencies are already built into my OS image
and therefore not include them itself?
Or would it be better to avoid building a second image and rather build
'python3' with my OS-image, adding it to PACKAGE_EXCLUDE and from within this
build process pack all python3 files into an image? If I were to pursue this
method, any suggestions on how to separate the python3 files from the rest of
my rootfs, including the necessary dependencies?
Any advice and idea is much appreciated.
Mit freundlichen Grüßen / Best regards
Norman Stetter
SW ENWICKLUNG EMBEDDED SYSTEMS
Garz & Fricke GmbH
21079 Hamburg
Direct: +49 40 791899 - 477
Fax: +49 40 791899 - 39
norman.stet...@garz-fricke.com
www.garz-fricke.com
[yocto] GPLv3 package present in rootfs
Hello team, I want to remove some GPLv3 package from rootfs, but it is still present. I am using INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0" still some package gnutls, libidn2, libassuan, are added into rootfs. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] NPM Fetcher question
On 21.05.2019 21:54, Alexander Kanavin wrote: > I think Jean-Marie might be able to help as he recently did a bit of NPM > fixing? > > > Alex > > On Tue, 21 May 2019 at 19:52, Scott Rifenbark wrote: >> Hi, >> >> I am trying to determine if the information in >> https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM is relevant and >> up-to-date for current YP release. I am having trouble finding a resource >> familiar with this topic. I was using the Registry Modules part quite recently to add a recipe for NPM package using the "devtool add". It was not perfect experience. I was having problems with not all of the cheksums being filled in the lockdown file properly. Also, one of the dependency packages was a native one (compilation required) which had further implications. I was going to report my experience - in a short blog post at the very lest, but failed to do so yet. Let me know if you need anything specific, maybe I could help. >> >> Can anyone point me to the expert for this area? >> >> Thanks, >> Scott Rifenbark (docs) >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] configuration for a layer apart from local.conf
Yes - your distro configuration file is the correct place to do it. Alex On Wed, 22 May 2019 at 07:12, Pandey, Kamal wrote: > > Hi, > > I want to know if there is any other place where we can set configuration for > a particular layer, apart from local.conf. For example if I want to set > LICENSE_FLAGS_WHITELIST can I do that in layer.conf, or do I need to do that > in local.conf only. Similarly for BBMASK too. So basically my question is, > for setting the configurations of a particular layer, is there any place > where I can set those variables inside that layer only? > > Best Regards > > Kamal Pandey > > > > -- > ___ > 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] setting SRC_URI runtime - possible options
On Wed, May 22, 2019 at 9:50 AM Paul Barker wrote: > On Tue, 21 May 2019, at 11:23, Belisko Marek wrote: > > On Tue, May 21, 2019 at 12:14 PM Alexander Kanavin > > wrote: > > > You can write a class which sets the template for SRC_URI and then a > > > series of recipes that inherit the class, and define the variable that > > > would turn the template into the actual URI. > > OK I think it make sense. So parsing of config file will be done in > > class and then class will be used in recipes to set correct SRU_URI. > > Do you have any idea what is wrong with actual code I posted? Why it is > > doing some strange things? Thanks. > > You're setting the SRC_URI value only in the do_fetch task. It's needed in > at least the do_unpack task as well and possibly other tasks. > > You could look at setting this in an anonymous python function instead if > you really need to parse a config file. > Yes I was using anonymous python function before but then when project was unpacked the SRCPV + SRCREV was somehow not updated. I'll try to look more on it and debug. Thanks. > > -- > Paul Barker > Managing Director & Principal Engineer > Beta Five Ltd > BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] setting SRC_URI runtime - possible options
On Tue, 21 May 2019, at 11:23, Belisko Marek wrote: > On Tue, May 21, 2019 at 12:14 PM Alexander Kanavin > wrote: > > You can write a class which sets the template for SRC_URI and then a > > series of recipes that inherit the class, and define the variable that > > would turn the template into the actual URI. > OK I think it make sense. So parsing of config file will be done in > class and then class will be used in recipes to set correct SRU_URI. > Do you have any idea what is wrong with actual code I posted? Why it is > doing some strange things? Thanks. You're setting the SRC_URI value only in the do_fetch task. It's needed in at least the do_unpack task as well and possibly other tasks. You could look at setting this in an anonymous python function instead if you really need to parse a config file. -- Paul Barker Managing Director & Principal Engineer Beta Five Ltd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
