zpfvo has quit [Read error: Connection reset by peer]
zpfvo2 has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
vladest has joined #yocto
nemik has joined #yocto
zpfvo1 has quit [Ping timeout: 255 seconds]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
davidinux has joined #yocto
* alessioigor
waves all
michaelo has joined #yocto
matiop6 has joined #yocto
* jbo
hides
<jbo>
never trust a waving person :o
<matiop6>
Hi, hope for some directions. We migrated with our project from dunfell to kirkstone and now we having problem with dnf not finding glibc related .so Here is recipe and log of error. /recipe DESCRIPTION = "Recipe to load integrator software"
<matiop6>
is it somehow connected to kirkstone not linking GLIBC_2.4 in same path as dunfell?
matiop6 has quit [Quit: Client closed]
matiop6 has joined #yocto
vm1 has joined #yocto
mihai has quit [Quit: Leaving]
florian has joined #yocto
prabhakarlad has quit [Quit: Client closed]
vm1 has quit [Quit: Client closed]
vm1 has joined #yocto
davidinux has quit [Ping timeout: 248 seconds]
cperon has quit [Quit: You have been kicked for being idle]
rob_w_ has joined #yocto
leon-anavi has quit [Remote host closed the connection]
abelloni has joined #yocto
leon-anavi has joined #yocto
leon-anavi has quit [Remote host closed the connection]
leonanavi has joined #yocto
<rburton>
no, that's because your binary that is built outside of yocto doesn't have the same linkage as yocto
<rburton>
if you're happy to take full responsibility for the runtime dependencies then SKIP_FILEDEPS = "1" will stop yocto from looking at the binaries to generate RDEPENDS
<rburton>
of course the better solution is to always build everything *inside yocto* so you know dependencies and linkage is correct
<matiop6>
Of course it would be better but for now we cant build it from source. I will try SKIP_FILEDEPS to see if it run correctly. Thanks for advice
matiop6 has quit [Quit: Client closed]
ykrons has quit [Ping timeout: 240 seconds]
florian_kc has joined #yocto
kalj has joined #yocto
ykrons_ has joined #yocto
<jbo>
hmm... is there something in yocto which automatically overrides the RTC time during startup? I have an RTC on a SAMA5D2 device which appears to work but during boot it appears to get overriden.
<rburton>
if the RTC reports a time that is in the past compared to the build time, then the build time is used instead
<rburton>
an impressive amount of stuff fails if the time is out by decades, like you can't do any secure connections
d-s-e has joined #yocto
<LetoThe2nd>
rburton: i think that is essentially systemd behaviour?
<rburton>
there's a bit in sysv somewhere too
<LetoThe2nd>
k
<rburton>
but yes, it's explicitly something systemd does
<jbo>
hmm, I'll investigate and ask more questions afterwards - thanks!
florian_kc has quit [Ping timeout: 255 seconds]
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #yocto
prabhakarlad has joined #yocto
goliath has joined #yocto
florian_kc has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<dacav>
Hi. I've noticed that `devtool modify` has a --same-dir flag. I was wondering: if I use such flag together with `bitbake -c devshell <recipe>`, will I be able to build with the correct tools & settings (as defined by the recipe) without my build directory being under some /tmp/work area?
<dacav>
Any pitfall ahead?
<dacav>
To explain better what I have in mind, I like the fact that `devtool modify` allows me to mess with the code online, but I don't like to wait for bitbake to warm up, in between compilations.
seninha has joined #yocto
seninha has quit [Remote host closed the connection]
<dacav>
Also I'd like to leverage the quickfix feature of ViM (e.g. by doing `make >errors.err` from within the devshell
<jbo>
rburton, LetoThe2nd, I'm not making much progress on the RTC issue. What I did is booting up the system from a clean state. At that point both 'date' and 'hwclock' report the date to be 9 March 2018. Then I set the system time manually. running `date` again reflects the changes. Then I write that time to the RTC using hwclock -w. Now the RTC reports the same date. Then I power down the system. Upon booting up, the RTC clock seems to get overriden by the older, 9
<jbo>
March 2018 date.
<jbo>
so the RTC is not reporting a date decades behind the system time.
rfs613- is now known as rf613
<landgraf>
jbo: do your board has battery backup RTC at the first place?
<rburton>
jbo: oh that might be the hardcoded fallback date
<jbo>
landgraf, yes, it does. well, it has a supercap but I have a voltmeter on it and it's charged to 3.3V. It's a microchip SAMA5D27-SOM1-EK so not custom hardware.
<rburton>
so yeah, looks like your rtc isn't surviving, or its not being read properly
<rburton>
systemd or sysv?
<jbo>
any things on what to look for?
<jbo>
sysv
<jbo>
I am essentially using core-image-minimal with an overlay that adds a few utils such as alsa-utils etc.
<jbo>
I'm using the machine settings provided by meta-atmel.
<jbo>
I can definitely read from & write to the RTC.
<jbo>
what does work is doing an echo +60 > /sys/class/rtc/rtc0/wakealarm followed by an echo mem > /sys/power/state
<jbo>
the system goes to sleep and then wakes up after 60 seconds
<rburton>
i guess the script doing the resetting is /etc/init.d/hwclock.sh then
<jbo>
investigating...
<rburton>
set VERBOSE=yes in rcS.default and you get more chatter on boot
<jbo>
need to quickly check how/where to do that. haven't used sysv in over a decade
<rburton>
you can switch to systemd trivially and i recommend it :)
<jbo>
nah, I only have 128MB RAM :D
<jbo>
Hmm... reading through the hwclock.sh init script I am wondering whether the issue is that I don't have any timezone stuff going oin.
<jbo>
I don't have an /etc/localtime
<rburton>
should be find to just use UTC everywhere
<jbo>
that was the intention, at least - yeah
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
camus1 is now known as camus
d-s-e has quit [Ping timeout: 265 seconds]
<jbo>
rburton, so I set VERBOSE=yes in /etc/default/rcS but I don't see a lot of relevant information in dmesg.
<jbo>
but the RTC time was of course overriden again :D
<TRO[m]>
yocto checklayer issue - Can't be DISTRO and BSP type at the same time. Both conf/distro and conf/machine folders were found.
<TRO[m]>
-> is there a way to have both? Why is this an issue?
<rburton>
because layers which are yocto compatible should split BSP definition from distro policy
<TRO[m]>
hmm. and why? ;)
<rburton>
because a BSP should be general and not care about what software runs on it
<rburton>
eg if i use meta-ti, i don't get forced into using a specific distro
<rburton>
because i want to use _my_ distro
kalj has joined #yocto
<TRO[m]>
Ok, I try to add that AMI creation fetaure to meta-aws. So setting machine= and distro= will generate an uploadable image. And I need some cloud software in every image I create, this is why I created an distro including Poky adding some software, distro features and this is my distro.
<TRO[m]>
I should NOT add those settings in the MACHINE config I guess?
<TRO[m]>
What is the best approach then?
<rburton>
without looking at what you've done, an image class or something. you can have an example distro that shows how its done, so that people that want to integrate can do it. you shouldn't need a machine config at all, really.
<rburton>
(unless you have a dedicated machine for aws with special tunes/kernel/etc)
<TRO[m]>
Adding it to a DISTRO will allow me to build any image for the cloud...
<TRO[m]>
And of course I like to do it the correct way...
<rburton>
arguably you could depend on meta-intel and meta-arm for the intel-i7 and generic-arm64 machines.
<TRO[m]>
And how do I then add kernel config just for them?
manuel1985 has joined #yocto
<TRO[m]>
(and not ALL generic-arm64)
<rburton>
so the easiest way to pass the test is to split the bsp and the distro into separate layers. make the bsp layer extend the kernel recipes, and then the distro is an example of how to make it work.
<TRO[m]>
creating and supporting a separate repo is not easy in the long term...
<jbo>
rburton, I'm really stuck at the RTC time being overriden issue. do you have any other pointers or hints for me?
<rburton>
TRO[m]: same repo
<rburton>
the meta-arm repo had 5 layers at one point
<TRO[m]>
I saw this, but this will break all old releases then... not good.
<TRO[m]>
(I mean backporting will be not easy then)
<TRO[m]>
So might the direction on having a DISTRO feature or class is more what I prefer then.
<qschulz>
did you suffix your recipe name with -native too?
<qschulz>
Create a myrecipe-native.bb recipe that inherits the native class. If you use this method, you must order the inherit statement in the recipe after all other inherit statements so that the native class is inherited last.Create a myrecipe-native.bb recipe that inherits the native class. If you use this method, you must order the inherit statement in the recipe after all other inherit statements so
<qschulz>
that the native class is inherited last.
<barath>
it seems to do things correctly, but fails for me. originally because it can't find zlib's sstate manifest, which is no surprise (I think) because I see that it's not looking for zlib-native, but zlib. if I hack the recipe to use BBCLASSEXTEND instead, it works, because then it fixes the zlib dependency to become zlib-native instead.
<jclsn>
Are file not automatically copied to WORKDIR after they were added to SRC_URI? My recipe is not finding them
<rburton>
barath: correct. foo -> foo-native is a thing that happens in classextend only
<rburton>
if you have a recipe that is pain inherit native, then write the real deps
<barath>
unfortunately it's not my recipe :D
<barath>
I guess I'll take it up with meta-qt5-extra then
<barath>
is this documented? seems not. something to submit a patch for then
<rburton>
it is
<rburton>
"Internally, the BBCLASSEXTEND mechanism generates recipe variants by rewriting variable values and applying overrides such as :class-native. For example, to generate a native version of a recipe, a DEPENDS on “foo” is rewritten to a DEPENDS on “foo-native”."
<rburton>
nowhere does it say that inherit native will rewrite dependencies
<barath>
from the description of native.bbclass (Although applied differently, the native class is used with both methods.) I assumed the end result would be the same
<barath>
since the same class is applied
<rburton>
the renaming is part of how the class extension works
<rburton>
a recipe that inherits native is a native recipe and should have the correct dependencies defined
<barath>
yeah I agree that it makes sense when you think about it
<barath>
I was just confused since I expected the recipe to be correct, since it's not my recipe :D
ptsneves1 has joined #yocto
ptsneves has quit [Remote host closed the connection]
ptsneves1 is now known as ptsneves
rcw has quit [Quit: Leaving]
* landgraf
not joining the meeting because of conflict again :-/
thomasd13 has quit [Ping timeout: 248 seconds]
vladest has joined #yocto
kalj has quit [Ping timeout: 245 seconds]
<olani->
dacav: Using --same-dir will set B=S (using the EXTERNALSRC redirects). This might work, depends on the source package and possibly the recipe. Packages using meson wont support this, as far as I know.
<olani->
dacav: Of course, you wont get the cross-compilation setup unless you also use devshell.
<olani->
dacav: In other words, be prepared to spend some time getting it to work.
seninha has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
<RP>
landgraf: no problem. We moved one bug to you where there was a direct question, hope that was ok
rob_w_ has quit [Remote host closed the connection]
rob_w has quit [Quit: Leaving]
rfuentess has quit [Remote host closed the connection]
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
zpfvo2 has quit [Remote host closed the connection]
ykrons has joined #yocto
kevinrowland has joined #yocto
ykrons has quit [Ping timeout: 240 seconds]
<kevinrowland>
Folks, quick question. I put a bbplain in a task, and then bitbake -f the task, and I see the bbplain message on the console. Then I replace bbplain with bbnote and the message does not show up. Is that expected?
<kevinrowland>
I noticed in `logging.bbclass` that the `bbnote()` function has a comment which says "# Output: logs", while the `bbplain()` function has a comment which says "# Output: logs console".. but I didn't find anything in the mega manual about this difference
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
leo738 has joined #yocto
ykrons_ has joined #yocto
<leo738>
Hello all. Anyone suggest a reasonable machine for development? Perhaps something they got recently in the €1000 region. Looking at sonething with 4+ core Ryzen CPU but hard to narrow down the search
argonautx[m] has joined #yocto
florian_kc has joined #yocto
leo738 has quit [Quit: Client closed]
leo738 has joined #yocto
bradfa has quit []
vladest1 has joined #yocto
<tgamblin>
leo738: I have found success with the ThinkPad L and T series. There are usually decent options available on sale, or second-hand on sites like eBay if you don't mind that route. There does seem to be an ongoing issue with their USB-C docks, external monitors, and suspend/sleep states, however
vladest has quit [Ping timeout: 255 seconds]
vladest1 is now known as vladest
<leo738>
Many thanks! I only do development on a laptop at the moment but was thinking of investing in a powerful desktop to get compile times down to something reasonable.
<tgamblin>
If you're going to be doing lots of YP builds or similar, you probably want desktop with 12+ cores
Thorn has quit [Ping timeout: 255 seconds]
leo738 has quit [Quit: Client closed]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
leo738 has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
leo738 has quit [Client Quit]
frieder has quit [Remote host closed the connection]
Thorn has joined #yocto
ptsneves has quit [Ping timeout: 260 seconds]
leo738 has joined #yocto
leo738 has quit [Client Quit]
<khem>
lucaceresoli_: ping ?
leo738 has joined #yocto
florian_kc has joined #yocto
leo738 has quit [Client Quit]
ykrons_ has quit [Ping timeout: 255 seconds]
prabhakarlad has quit [Quit: Client closed]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
ykrons has joined #yocto
kevinrowland has quit [Quit: Client closed]
ykrons has quit [Ping timeout: 276 seconds]
ykrons has joined #yocto
prabhakarlad has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
ykrons has quit [Ping timeout: 255 seconds]
alessioigor has quit [Quit: alessioigor]
ykrons has joined #yocto
goliath has joined #yocto
leo738 has joined #yocto
leo738 has quit [Quit: Client closed]
bps has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
leo738 has joined #yocto
leo738 has quit [Client Quit]
<yudjinn[m]>
So I'm a little stuck with something. I want to semver my images so that "major" changes only happen if there was a rebuild of specific major packages (libc, kernel, etc). I keep my MAJOR version stored as a var in `major.inc` so anything building artifacts also tags them appropriately. Is there any way to effectively say "if X is rebuilt, make sure MAJOR == OLD_MAJOR ? I plan on making OLD_MAJOR roll with a CI job, so it should always be up
<yudjinn[m]>
to date, Im just not sure how to handle this. I thought `taskdepends` may help but I dont have much experience and assumed there has to be a more used method, and this cant be the first time this problem arose
ykrons has quit [Ping timeout: 255 seconds]
ykrons_ has joined #yocto
ykrons_ has quit [Ping timeout: 250 seconds]
ecdhe has quit [Read error: Connection reset by peer]