<vvn>
is there a way to configure this via device tree? http://ix.io/3UTL
<vvn>
I'd like not to have a custom kernel and machine just for this addition RTC
jclsn90 has quit [Ping timeout: 248 seconds]
sakoman has quit [Quit: Leaving.]
starblue has quit [Ping timeout: 240 seconds]
jclsn90 has joined #yocto
starblue has joined #yocto
jclsn90 has quit [Ping timeout: 256 seconds]
sakoman has joined #yocto
jclsn904 has joined #yocto
jclsn904 has quit [Ping timeout: 240 seconds]
jclsn904 has joined #yocto
xperia64 has quit [Ping timeout: 250 seconds]
xperia64 has joined #yocto
jmiehe1 has joined #yocto
jmiehe has quit [Ping timeout: 240 seconds]
jmiehe1 is now known as jmiehe
abelloni has quit [Remote host closed the connection]
kmaincent1 has quit [Quit: WeeChat 1.9.1]
tperrot has quit [Read error: Connection reset by peer]
michaelo has quit [Read error: Connection reset by peer]
sakoman has quit [Quit: Leaving.]
jamestperk has quit [Ping timeout: 240 seconds]
Crofton has quit [Ping timeout: 240 seconds]
jamestperk has joined #yocto
Crofton has joined #yocto
amitk has joined #yocto
kroon has joined #yocto
manuel1985 has quit [Ping timeout: 248 seconds]
kranzo has joined #yocto
abelloni has joined #yocto
<RP>
smurray: np, just happy to have a fix, thanks! :)
goliath has joined #yocto
frieder has joined #yocto
pbergin has joined #yocto
alessioigor has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
<LetoThe2nd>
yo dudX & mckoan
alessioigor has quit [Quit: alessioigor]
<Guest5>
kergoth is there any way to access the value of variable that is set using d.setVar() in different task or in different recipe?
<LetoThe2nd>
Guest5: straight no. Yocto chant #1: recipe data is local, configuration data is global. means, that if you need something across all of your build, putting it into your distro is the best bet usually (but it of course depends a bit)
<qschulz>
Guest5: ONLY if setVar is used in an anonymous python function is it then available to other tasks in the same recipe
leon-anavi has joined #yocto
Schiller has joined #yocto
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
Crofton has quit [Ping timeout: 248 seconds]
moto-timo has quit [Ping timeout: 240 seconds]
moto-timo has joined #yocto
Crofton has joined #yocto
mvlad has joined #yocto
<RP>
ok, we broke edgerouter in 4.0rc1 so we're going to an rc2
<RP>
With that in mind, are there other commits we need?
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #yocto
Schiller has quit [Ping timeout: 250 seconds]
florian has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
florian_kc has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
coref[m] has joined #yocto
Schiller has joined #yocto
amitk_ has joined #yocto
amitk has quit [Ping timeout: 248 seconds]
<Schiller>
in the YPAutobuilder i would like to edit the var:${BUILDDIR} from ../build/build to ../build but i can't quite find the entry
<RP>
Schiller: I'd probably advise against that. The top level "build" is a buildbot thing, the other one is a yocto project level thing. You do need both for different reasons
Guest1469 has joined #yocto
<Schiller>
RP: thx was about to ask if it is even adviseable.
tre has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
Guest69 has joined #yocto
florian_kc has joined #yocto
<Guest69>
Hi everyone. Is it ok if I post a question here ? I am seeing some bitbake behaviour that I cannot figure out.
<LetoThe2nd>
Guest69: sure, go ahead. if the error or log is lengthy, then it might be good to put it onto a pastebinä
dacav has quit [Quit: leaving]
<Guest69>
Thanks. Okay so I am trying to install a pre-built ipk into a yocto image. For that I use the bin_package.bbclass and I override the do_fetch in the recipe. But I cannot get it to work. I made a simplified version of my recipe, which also does not work, here it is : DESCRIPTION = "My simple recipe"
<Guest69>
LICENSE = "CLOSED"
<Guest69>
do_configure[noexec] = "1"
<Guest69>
do_compile[noexec] = "1"
<Guest69>
do_fetch () {
<Guest69>
mkdir -p ${S}
<Guest69>
echo "Test" > ${S}/test
<Guest69>
}
<Guest69>
# Install the files to ${D}
<Guest69>
do_install () {
<Guest69>
install -d ${D}
<Guest69>
cp -dpR ${S}/* ${D}/
<Guest69>
}
<Guest69>
After bitbake -c fetch the ${S} contains the test file. But when I do bitbake -c install I get an error and ${S} is cleared, the file is gone.
jmiehe has quit [Quit: jmiehe]
<Guest69>
Using bin_package.bbclass this translates into the error : bin_package has nothing to install. Be sure the SRC_URI unpacks into S.
<Guest69>
I just don't understand why bitbake removes the file I just "fetched". In this case it's created by the echo "Test" > ${S}/test line, but in my real recipe a file is downloaded and unpacked there.
<qschulz>
Guest69: use SRC_URI variable instead of baking your own fetch task
<LetoThe2nd>
Guest69: first, i don't think you need to create ${D}. second, what error do you actually get? "an error" is not an exactly good description.
<Guest69>
Sorry, yeah it says : cp: cannot stat /home/my-home/my-yocto/build/tmp/qemuarm64/work/aarch64-poky-linux/my-simple-recipe/1.0-r0/my-simple-stupid-recipe-1.0/*': No such file or directory
<Guest69>
qschulz Unfortunately I cannot use SRC_URI. I do need some custom code to fetch the package
<Guest69>
But In general I am trying to understand this . I thought bitbake would not remove any content in ${S} between a do_fetch and do_install, Or am I wrong about that ?
Thomas1 has joined #yocto
dacav has joined #yocto
<LetoThe2nd>
I also think that it should not do that. But my gut feeling is that there is something fishy about the whole thing. Can't yet put my finger on it, sorry.
tomzy_0 has joined #yocto
dacav has quit [Quit: leaving]
dacav has joined #yocto
Schiller has quit [Quit: Client closed]
<Guest69>
Okay everyone thanks for your time to have a brief look at this
<Thomas1>
Hi,
<Thomas1>
I'm rather new to yocto and have a problem understanding a concept.
<Thomas1>
I am trying to create a system update workflow with SWUpdate.
<Thomas1>
My problem is that my SWUpdate seems to be missing bootloader support.
<Thomas1>
I've added a enable-uboot.cfg where I set:
<Thomas1>
CONFIG_UBOOT=y
<Thomas1>
# CONFIG_BOOTLOADER_NONE is not set
<Thomas1>
CONFIG_UPDATE_STATE_CHOICE_BOOTLOADER=y
<Thomas1>
CONFIG_BOOTLOADERHANDLER=y
<Thomas1>
I've also created a swupdate_%.bbappend where I add the .cfg file to my SRC_URI:
<Thomas1>
SRC_URI += "\
<Thomas1>
file://systemd.cfg \
<Thomas1>
file://rdiff.cfg \
<Thomas1>
file://enable-uboot.cfg \
<Thomas1>
file://hash.cfg \
<Thomas1>
file://archive.cfg \
<Thomas1>
file://part-format.cfg \
<Thomas1>
file://get-slot.sh \
<LetoThe2nd>
Thomas1: please use a pastebin in the future, and just drop the link to it with the question. thanks!
<qschulz>
Thomas1: is your bbappend listed in bitbake-layers show-appends?
<qschulz>
does bitbake -e swupdate | grep "^SRC_URI=" returns something with enable-uboot.cfg in there?
<LetoThe2nd>
and, does swupdate support cfg fragments?
<qschulz>
and if it does, does the final config file actually have uboot enabled? (wondering if swudate recipe has a menuconfig task to check?
<LetoThe2nd>
inevitable plug - have you looked at mender? O:-)
<Thomas1>
The official meta-swupdate also contains .cfg files.
<Thomas1>
My SRC_URI contains the enable_uboot.cfg.
<Thomas1>
How can I check the final config file?
<Thomas1>
I have looked at mender but for now we are set at swupdate. :)
Schiller has joined #yocto
Guest69 has left #yocto [#yocto]
<tomzy_0>
Thomas1: you should be able to look in WORKDIR of swupdate
<tomzy_0>
I believe
<tomzy_0>
Thomas1: smth like `build/tmp/work/XYZ/swupdate/V.X.Z/.config`
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
Schiller has quit [Quit: Client closed]
Schiller95 has joined #yocto
glembo[m] has joined #yocto
<amahnui[m]>
<qschulz> "so you can also take inspiration..." <- The which package of fedora displays where a particular in path is located
<qschulz>
amahnui[m]: yes, that's what which is supposed to do (though admittedly, `command -v` should be used now instead, don't remember the justification.. might even be related to bsd)
<qschulz>
glembo[m]: how is the package added to your image in the frst place?
florian_kc is now known as florian
<glembo[m]>
qschulz: I think ldconfig that comes with yocto poky by default. Is there a quick way I can find out?
<qschulz>
amahnui[m]: maybe which is already available on freebsd by default, I don't know
<qschulz>
or maybe it just does not exist and we need a replacement and handle things differently so that a freebsd compatible implementation can be made
<qschulz>
amahnui[m]: freebsd seems to be provide some linux-compatible package but that just highlights they do things differently and maybe so should we
<Thomas1>
LetoThe2nd: I might have been wrong. I think I need to set the configs in a defconfig file.
<amahnui[m]>
qschulz: qschulz: please I wish to ask how we may proceed
<amahnui[m]>
Sorry for taking a lot of time
<amahnui[m]>
We are having electrical problems here for about 2 days now.
<qschulz>
amahnui[m]: don't know, I'm just a contributor and have no knowledge about freebsd or what needs to be done to have it supported as building host for Yocto Project
<LetoThe2nd>
Thomas1: very well possible, yes.
<amahnui[m]>
qschulz: alright
<amahnui[m]>
Thanks a lot for helping out as that has giving me a clue on how freebsd works when packages and how to get the freebsd version of some debian packages
<qschulz>
glembo[m]: which version of yocto are you using?
Minvera has joined #yocto
ar__ has joined #yocto
<glembo[m]>
qschulz: dunfell
<qschulz>
glembo[m]: I assume removing ldconfig from DISRO_FEATURES should be enough
<qschulz>
glembo[m]: you can run bitbake -g <image-recipe> to check what pulls it in from the .dot file
<qschulz>
(don't try to run dot on it to output an image or pdf, it'll take hours and will be unusable in the end, just use a text editor)
codavi has quit [Ping timeout: 256 seconds]
rfuentess has quit [Remote host closed the connection]
pbergin has quit [Quit: Leaving]
Guest6 has joined #yocto
Guest6 has quit [Client Quit]
sakoman has joined #yocto
kriive has quit [Ping timeout: 260 seconds]
kroon has quit [Quit: Leaving]
GLumen has joined #yocto
Net147 has quit [Ping timeout: 256 seconds]
xmn has joined #yocto
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
<Guest1469>
0: rust-native-1.59.0-r0 do_compile - 2h29m19s just this task running and there is no progress bar for it. is it normal? there are 100 remaining tasks
<vvn>
Guest1469: the remaining 100 tasks certainly depend on rust-native:do_compile ;-)
<Guest1469>
woww i see
<Guest1469>
but it taked too much time:( but it finished now
<Guest1469>
where can i see sizes of these packages
<rfs613>
Guest1469: tmp/deploy/deb/all is where *.deb files are placed, if that's what you are looking for
<vvn>
Guest1469: luckily native packages are likely built only once. You should read the documentation (see the channel topic) to find out how to re-use the cache (SSTATE_DIR) and how to inspect built images (BUILDHISTORY_FEATURES)
Schiller95 has quit [Ping timeout: 250 seconds]
Thomas1 has quit [Quit: Client closed]
<vvn>
kergoth: I derivated beaglebone.conf into beaglebone-sdcard.conf and beaglebone-emmc.conf as I need images for both. What changed really is only the bootloader config and two configuration files in the rootfs (including fstab). Problem is the kernel, qtwebengine, and other stuffs get build twice. Did you have a similar experience to deal with different target mediums of the same machine, with
<vvn>
machine/distro features maybe?
Guest1469 has quit [Ping timeout: 250 seconds]
Schlumpf has quit [Quit: Client closed]
florian_kc has joined #yocto
tprrt has joined #yocto
tprrt is now known as tperrot
tre has quit [Remote host closed the connection]
florian has quit [Ping timeout: 240 seconds]
<kergoth>
vvn: for us, we have a separate variable to control that behavior without changing machine, so haven't run into that particular issue. still, rebuilding the bootloader shouldn't result in rebuilding everything that depends upon it, so i'd investigate why those things are changing. see bitabke -S printdiff and also sstate-diff-machines
<kergoth>
Oof, populate_sdk_ext is rather messy. There's so much hardcoded about what packages get included and controlled via booleans rather than obeying variables listing what targets we want. and assumes an esdk has to involve an image, so assumes the target is an application developer. it handlesl that use case well, but that's not the only one where an esdk could be useful
<kergoth>
hmmm
<kergoth>
Also can't change SDKDEPLOY as it uses that to pull buildtools-tarball, not just to control output..
<vvn>
kergoth: this I will do. I can still split my work better. My concern about the variable (and multiconfigs I presume?) is that you cannot share the same deploy dir I think (images will have the same basename, even if you set IMAGE_NAME_SUFFIX = "-sdcard" (same IMAGE_LINK_NAME in fact).
<kergoth>
The esdk that comes out of the build is impressively useful, don't get me wrong, just reading the bbclass...
<vvn>
well maybe I can merge the deploy dirs later
<nk058[m]>
Has anybody tried esdk on Honister? It does not seem to get the header and libraries in PACKAGE_INSTALL apart from core-image ones, or I've been doing something wrong.
<RP>
kergoth: it was developed to a point and then people got pulled off. There are neat ideas there, it needs re-envisaging
<nk058[m]>
* Has anybody tried esdk on Honister? It does not seem to get the header and libraries from `PACKAGE\_INSTALL` apart from `core-image` ones, or I've been doing something wrong.
<kergoth>
RP: yeah, agreed. the concept is sound. I can see why it's on future directions to get somebody diving into it
florian_kc has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
<RP>
kergoth: its actually going to be on the top 5 list as about the only thing we have to try and improve usability but we need to be clear it needs to be rethought in some areas
<RP>
(for usability, saying you want to improve it is fine but we need specifics which we don't have many of)
* kergoth
nods
<kergoth>
It kind of feels like archiver, a ton of little variables to control behavior, which isn't usually how we like to do things. I'd like to see more flexiblity on what's included, vars more like TOOLCHAIN_*_TASK rather than a bunch of flags to flip, and potentially a new SDKEXT_FEATURES or something
<kergoth>
might be nice to still be able to run bitbake from an esdk also, not only through devtool, but that might not be a valid use case, we should articulate the use cases we're looking to satisfy with it to begin with
<RP>
kergoth: right. I'd also like to be able make an existing build into an eSDK and vice-versa
<kergoth>
That's a good idea
<RP>
kergoth: that is kind of the concept that was behind the bblock and bbunlock commands there is a bugzilla entry for
goliath has quit [Quit: SIGSEGV]
Net147 has quit [Ping timeout: 272 seconds]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
amitk_ has quit [Ping timeout: 246 seconds]
amitk has joined #yocto
leon-anavi has quit [Quit: Leaving]
kevinrowland has quit [Quit: Client closed]
amitk has quit [Quit: leaving]
Guest5 has quit [Quit: Client closed]
amitk has joined #yocto
frieder has quit [Remote host closed the connection]
<vvn>
kergoth: how did you organize your code to fetch a different fstab depending on a given variable? FILESEXTRAPATHS:prepend := "${THISDIR}/${MACHINE}/${MEDIUM}:" or SRC_URI:append = " file://fstab-${MEDIUM}.conf" or something else?
<kergoth>
vvn: iirc we didn't, as we use wic, and used a .wks.in to adapt to the media
<kergoth>
and since wic updates fstab..
<vvn>
kergoth: unfortunately I use --source rawcopy for my image. I'll see how I can produce that without duplicating the recipes.
manuel1985 has quit [Quit: Leaving]
florian_kc has quit [Ping timeout: 240 seconds]
mckoan is now known as mckoan|away
florian_kc has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
linums has quit [Quit: Client closed]
linums has joined #yocto
kranzo has quit [Quit: Client closed]
linums has quit [Quit: Client closed]
amitk has quit [Ping timeout: 256 seconds]
davidinux has quit [Ping timeout: 246 seconds]
tomzy_0 has quit [Quit: Client closed]
davidinux has joined #yocto
linums has joined #yocto
<linums>
is there any guide how to create an uefi image?
florian__ has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
m_jimmer12345 has joined #yocto
<m_jimmer12345>
Hello there is there a way to add arch's to DNF ? Example;. I have all these "arch's" armv7at2hf_neon cortexa9_vfp sdk_provides_dummy_nativesdk cortexa5hf_vfp noarch sdk_provides_dummy_target x86_64_nativesdk
<m_jimmer12345>
- package binutils-cross-canadian-arm-2.34-r0.x86_64_nativesdk does not have a compatible architecture
<m_jimmer12345>
" x86_64_nativesdk "
linums has quit [Quit: Client closed]
<RP>
m_jimmer12345: that sounds like you're trying to install our packages onto your desktop system which isn't supported. nativesdk only works as part of the SDK
florian__ has quit [Read error: Connection reset by peer]
florian__ has joined #yocto
mvlad has quit [Remote host closed the connection]
<RP>
Not sure if people have seen it but we have two bugs, 14782 and 14783 which block our rc2 4.0 build :(
<RP>
The icons look messed up in my qemu image too
<RP>
I couldn't see the pcmanfm delay though
xmn has quit [Ping timeout: 240 seconds]
florian__ has quit [Ping timeout: 250 seconds]
<m_jimmer12345>
RP you are correct was trying to just update one package. So you are saying that only target packages are good ?
<RP>
m_jimmer12345: update them inside what?
<m_jimmer12345>
the VM that I have
<m_jimmer12345>
or say that my sdk only changes as local lib
* RP
notes that icons in M3 looked better so this is some regression during M4 :/
<m_jimmer12345>
would like it so that I amn not shi[pping the sdk each time
<RP>
m_jimmer12345: we stopped supporting package upgrades in the SDK a long time ago. It sounds like a good idea but it simply doesn't work
<m_jimmer12345>
I am also just really testing out the idea of OTA and how much I can and can not use
<RP>
m_jimmer12345: we did design the eSDK to be more updatable but is is a bit different
<m_jimmer12345>
Ok so all sdk's and all there rpm's/debs/ipks should never go to my local repo ?
<RP>
m_jimmer12345: we do build the sdk from those packages but once built it isn't designed to be updated with them
<m_jimmer12345>
Now comes the issue that there are "other" archs that are based off the MACHINE env
<RP>
No part of the SDK is designed to be package updatable
florian__ has joined #yocto
<m_jimmer12345>
Cool but what about the target ?
<RP>
m_jimmer12345: within the SDK or inside an actual target image on device
<m_jimmer12345>
the target
<RP>
m_jimmer12345: I'm asking as the SDK does have target components and I want to be sure we're talking about the same thing
<m_jimmer12345>
yes forget the sdk and all the native stuff
<RP>
m_jimmer12345: that can be updated with packages, at least in theory and is documented to a degree
JPEW has quit [Ping timeout: 260 seconds]
<m_jimmer12345>
I am saying on my board (one of 45+ machine.confs) I use the MACHINE to add custom code and make the PACKAGE_ARCH to be the MACHINE
JPEW has joined #yocto
<m_jimmer12345>
I would like to keep that so we don't break our Free software guidlines vs non-free
<RP>
the on target package manager should be configured to handle the package arches
<RP>
we built the images using the package manager and the same config
<m_jimmer12345>
How ?
<m_jimmer12345>
I get that but there is no arch called s12345
<RP>
m_jimmer12345: depends which package backend, they're all different
<m_jimmer12345>
but I have a board called s12345
<m_jimmer12345>
I dont want to expose to others
<RP>
m_jimmer12345: which backend(s) are you interested in?
<m_jimmer12345>
we are done with debs and ipks
<m_jimmer12345>
just need to handle the rpms
<m_jimmer12345>
for debs I jsut use the path to hack around it
<m_jimmer12345>
inhouse "repo manager tool"
<m_jimmer12345>
the issue comes down to the fact that alot of the archs are not in dnf as vaild archs \
<RP>
m_jimmer12345: I suspect we configure it to accept them as archs
<m_jimmer12345>
yeah I think that is what is going to have to happen
<RP>
m_jimmer12345: the code writing the arches is in meta/lib/oe/package_manager/rpm/__init__.py in _configure_dnf where it writes etc/dnf/vars/arch
goliath has joined #yocto
<m_jimmer12345>
our closed source stuff uses the PACKAGE_ARCH = "${MACHINE_ARCH}" for all the packages so we know not to include these in our EFSW(emac free software )
<RP>
m_jimmer12345: wouldn't it make more sense to add an extra arch specifically for that rather than using that existing arch which already has uses?
<m_jimmer12345>
We want to keep the packages seperate so "other" users can use our EFSW but not the ENFSW(emac non free software)
<m_jimmer12345>
keep in mind that we have over 40 + images
<RP>
m_jimmer12345: Right, but having a separate arch for the thing you want to separate would be easier wouldn't it?
<m_jimmer12345>
we dont want base files to over right base files
<m_jimmer12345>
that is what we do
<m_jimmer12345>
the arch is the machinename
<m_jimmer12345>
example meta-something/recipes-core/basefiles/ in the bbappend we add PACKAGE_ARCH = "${MACHINE_ARCH}"
<RP>
ok, whatever then, you know best clearly. The answer to your question is the code line above which is where the arch is written
<m_jimmer12345>
yeah I guess we are going to have to hack dnf. It seems like there would be something for this. Sorry I dont think I understood what you said I will re-read
<m_jimmer12345>
40 + machines*
<RP>
m_jimmer12345: You can add in extra values, i.e. your own package_arch