jclsn1007 has quit [Quit: Ping timeout (120 seconds)]
jclsn1007 has joined #yocto
jclsn1007 has quit [Ping timeout: 260 seconds]
jclsn1007 has joined #yocto
jclsn1007 has quit [Ping timeout: 272 seconds]
jclsn1007 has joined #yocto
agrue has quit [Ping timeout: 250 seconds]
jclsn1007 has quit [Ping timeout: 246 seconds]
troth has quit [Ping timeout: 246 seconds]
troth has joined #yocto
jclsn1007 has joined #yocto
florian has joined #yocto
jclsn10074 has joined #yocto
jclsn1007 has quit [Ping timeout: 246 seconds]
jclsn10074 has quit [Ping timeout: 246 seconds]
amitk has joined #yocto
<amahnui[m]>
<vmeson> "amahnui: it depends on what..." <- What i run is bitbake core-image-sato
jclsn10074 has joined #yocto
jclsn10074 has quit [Ping timeout: 246 seconds]
jclsn10074 has joined #yocto
jclsn10074 has quit [Ping timeout: 260 seconds]
jclsn10074 has joined #yocto
jclsn10074 has quit [Quit: Ping timeout (120 seconds)]
jclsn10074 has joined #yocto
<amahnui[m]>
I succeeded to install freebsd and its de finally 🥳
Guest82 has joined #yocto
Portia[m] is now known as PortiaOld[m]
sakoman has quit [Quit: Leaving.]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
<amahnui[m]>
I'm currently working from there
florian_kc has joined #yocto
florian has quit [Ping timeout: 272 seconds]
rob_w has joined #yocto
mtaluca has joined #yocto
<hmw[m]>
Hi when i run a qt application with gdb conneted i get a sigill on starting a mysql db connection when i don´t connect gdb the application runs fine ( with mysql connection)
mtaluca has quit [Ping timeout: 260 seconds]
mvlad has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
<LetoThe2nd>
yo dudX, yo mckoan
vmeson has quit [*.net *.split]
fullstop has quit [*.net *.split]
Ebeneezer_Smooge has quit [*.net *.split]
sotaoverride has quit [*.net *.split]
warthog9 has quit [*.net *.split]
LetoThe2nd has quit [*.net *.split]
flynn378 has quit [*.net *.split]
jonmason has quit [*.net *.split]
Shaun has quit [*.net *.split]
flynn378 has joined #yocto
vmeson has joined #yocto
Shaun has joined #yocto
SSmoogen has joined #yocto
jonmason has joined #yocto
Shaun has quit [Changing host]
Shaun has joined #yocto
fullstop has joined #yocto
LetoThe2nd has joined #yocto
warthog9 has joined #yocto
fitzsim has quit [*.net *.split]
Habbie has quit [*.net *.split]
zeddii has quit [*.net *.split]
derRichard has quit [*.net *.split]
erbo has quit [*.net *.split]
smurray has quit [*.net *.split]
mischief has quit [*.net *.split]
override has quit [*.net *.split]
svuorela has quit [*.net *.split]
erbo has joined #yocto
zeddii has joined #yocto
smurray has joined #yocto
derRichard has joined #yocto
svuorela has joined #yocto
override has joined #yocto
mischief has joined #yocto
Habbie has joined #yocto
sotaoverride has joined #yocto
tomzy_0 has joined #yocto
rfuentess has joined #yocto
davidinux has joined #yocto
frieder has joined #yocto
frieder has quit [Read error: Connection reset by peer]
frieder has joined #yocto
frieder has quit [Read error: Connection reset by peer]
frieder has joined #yocto
gsalazar has joined #yocto
sstiller has joined #yocto
goliath has joined #yocto
dacav has quit [Remote host closed the connection]
LocutusOfBorg has joined #yocto
leon-anavi has joined #yocto
dev1990 has joined #yocto
sstiller has quit [Read error: Connection reset by peer]
GillesM has joined #yocto
zeddii has quit [Ping timeout: 246 seconds]
zeddii has joined #yocto
shoragan has joined #yocto
<qschulz>
o/
<LetoThe2nd>
qschulz: \o
willo has quit [Ping timeout: 240 seconds]
willo has joined #yocto
<kanavin_>
here's a question I don't know an answer for. Where does the convention for PASS/FAIL test markers come from?
florian_kc is now known as florian
<RP>
kanavin_: I think we used something existing as a basis for our ptest standard, maybe from autoconf's tests?
<kanavin_>
RP: right, I'm now trying to find where in auto-land those markers are actually defined :)
<kanavin_>
libxml upstream is asking that as somehow it's not obvious to them in my patch submission - "
<Saur[m]>
RP: If you add `ROOTFS_POSTPROCESS_COMMAND:remove = "foobar"` to your configuration, parsing will fail. This is due to an error introduced in bitbake commit 6aecc2fe where you add an argument to a call to handle_remove() which should not be there.
<Saur[m]>
What I do not understand is why `ROOTFS_POSTPROCESS_COMMAND` triggers that code path, as it is supposed to be for shell functions.
xmn has quit [Quit: ZZZzzz…]
troth has quit [Ping timeout: 246 seconds]
ghp has quit [Ping timeout: 250 seconds]
<LetoThe2nd>
Is there a way to get MACHINE from bitbake -e? I just was surprised that its not included as-is.
<RP>
LetoThe2nd: how are you trying to grep it?
<LetoThe2nd>
RP: the classic - ^/MACHINE
<RP>
LetoThe2nd: it is listed as unexport MACHINE I suspect
<LetoThe2nd>
RP: no, can't confirm. bitbake-getvar also is kinda unhelpful.
<RP>
LetoThe2nd: well, I suspect meta/conf/bitbake.conf:MACHINE[unexport] = "1" is the issue
<LetoThe2nd>
RP: is there a deeper reason for this?
<RP>
LetoThe2nd: there was some major piece of software which broke if you had MACHINE set in it's build environment
<RP>
nowadays we'd just put this in the specific recipe but at the time...
<LetoThe2nd>
RP: yeah the comment says binutils. hm.
<Saur[m]>
RP: But shouldn't it still be in `bitbake -e` even if it is unexported?
<LetoThe2nd>
the value shows up indirectly, in the line above "unset MACHINE"
<LetoThe2nd>
but it's kinda ugly to get it out of there.
<qschulz>
LetoThe2nd: remove the unexport line and watch the whole world burn :)
<RP>
LetoThe2nd: I'd be in favour of moving this to the binutils recipes now FWIW
<RP>
Saur[m]: it specifically does unset as the user may have done MACHINE=XXX bitbake Y
<LetoThe2nd>
RP: technically agreed, but might cause fallout (gut feeling)
<RP>
LetoThe2nd: welcome to the world of making improvements/cleanups :)
<RP>
it may not even be an issue for binutils now
<Saur[m]>
Hmm, ok. I guess it is the same code that generates the run.do_... files that generates the output for `bitbake -e`?
<LetoThe2nd>
RP: yeah, sure. but I wouldn't bet on it at this stage of the release.
<Saur[m]>
RP: Did you see my problem with `ROOTFS_POSTPROCESS_COMMAND:remove` above?
<RP>
Saur[m]: exactly the same code, yes. bitbake -e was meant for use by a shell, not human grepping
<RP>
Saur[m]: I did, I'm trying to get to an environment where I can try it
<Saur[m]>
Figures. Then it is much more understabdable why it does unset.
<Saur[m]>
Ok, good. But I cannot figure out why `ROOTFS_POSTPROCESS_COMMAND[func] == 1`. That is just weird.
<RP>
Saur[m]: fix pushed
<Saur[m]>
Found it. It was in `image.bbclass`. Interesting, I thought [func] was only for python/shell functions declared in bitbake files, but I guess it is used for variables that take shell like values as well...
<RP>
Saur[m]: I think we did that so we had better dependency handling within those cars
<RP>
vars
<Saur[m]>
Ok.
<Saur[m]>
Well, at least it found that error. ;)
<RP>
clearly a corner case in the tests :(
<Saur[m]>
RP: On to something completely different:
<Saur[m]>
I know we have somewhat different opinions on the UI, but I have given it a lot of thought and I had an idea yesterday that I want to run by you. So please, bear with me.
<Saur[m]>
How about we move the setscene line to after the main progress line, then add a progress bar and finally make the line only show when there are setscene tasks running?
<Saur[m]>
That way we keep the main status line at the top as it has always been, and the setscene line behaves much like the other subtasks below, i.e., it only shows when there is active work going on at which times it shows the progress.
<Saur[m]>
I have implemented it and I think it works very well.
starblue has quit [Ping timeout: 260 seconds]
<RP>
Saur[m]: the trouble is the ordering. setscene in a user's mind is before the tasks and I'm not keen on a UI which reverses that. I'm also not keen on a UI which shows and hides information depending on where things are at. If hash equiv shows matches, it would mean the bar appearing and disappearing which I think would confuse more than it help
starblue has joined #yocto
<Saur[m]>
RP: But that is exactly how the other tasks below behaves. They come and go as they are being worked.
<RP>
LetoThe2nd: looks like ld uses MACHINE in linker scripts. I'm not sure if that is or isn't safe from the environment now :/
<RP>
Saur[m]: but setscene progress isn't just an individual task
<Saur[m]>
The setscene tasks are just a subset of the total work done, ie covered by the main progress line.
<RP>
Saur[m]: which is an argument for not having one for setscene tasks in my view
<RP>
Saur[m]: I'm not adding a setscene progress bar, much as you may want one
Schlumpf has joined #yocto
<RP>
Saur[m]: I was wondering about a patch to remove more of the progress bars as they really annoyed me yesterday, hiding information about how long the task had been running in favour of some progress information I wasn't interested in ;-)
<RP>
Saur[m]: I didn't write it but it just illustrates the different expectations people have from the UI
<Saur[m]>
I can relate to the absence of how long time the task has taken. However, I would prefer to add that time, rather than remove the progress bar.
<Saur[m]>
They both serve different purposes.
<RP>
right, the progress bars are also making me feel ill. Not often I do a fetch with no local sources :/
<RP>
They were broken as the linux-yocto one restarted from 0% about three different times. I do know why but it isn't a good user experience
<Saur[m]>
RP: Hmm, if the problem, in your eyes, are the progress bars themselves, maybe the solution would be to add a `--progress-bar` option to bitbake, and those who wants the bars (like me) can have them, and those who are annoyed by them (like you) can just forget about them?
<RP>
Saur[m]: I still think the setscene progress bar is just going to mislead and confuse people though as people don't understand what it represents. We need the information in the UI somewhere but we need to focus the user on the correct "overall progress" indicator
<RP>
Yes, I personally despise the progress bars but even then I don't believe we should mislead users on the UI and the setscene one will do that.
<Saur[m]>
Which is why I thought my latest idea was in line with that. I.e., the main progress is there all the time, and while the setscene tasks run (and the main progress typically don't update) the setscene progress bar shows what is happening.
<RP>
Saur[m]: part of the trouble is that it can go backwards as new potential build paths are discovered by hashequiv
tomzy_0 has quit [Quit: Client closed]
<Saur[m]>
Well, if it isn't shown when there are no setscene tasks running, it isn't really going backwards, it is just a "new" bar showing up.
<Saur[m]>
Anyway, I have to run to get lunch now.
cambrian_invader has quit [Ping timeout: 240 seconds]
xmn has joined #yocto
tomzy_0 has joined #yocto
<RP>
LetoThe2nd: a quick test locally seems to suggest MACHINE being set doesn't cause issues
troth has quit [Ping timeout: 248 seconds]
<RP>
LetoThe2nd: hang on, unexports are totally pointless now since we tightly control the execution environment and don't take random variables from the parent shell anyway?
troth has joined #yocto
rhadye has joined #yocto
<rburton>
wasn't unexport to stop exporting things that were exported initially?
<RP>
rburton: right, but with the "modern" design, even if in the original env, they wouldn't be in the task env
<RP>
The big question now, what else needs to be done before we build rc1
ilunev has joined #yocto
<rburton>
i mean if bitbake.conf does export FOO, but that breaks a specific recipe
<rburton>
isn't that what unexport is for?
<RP>
rburton: yes, it does help that. I'm not aware of anything exporting TARGET_ARCH, DISTRO or MACHINE though?
<rburton>
i was thinking in the abstract sense and not really paying attention to the thread, sorry
<RP>
rburton: this is bitbake.conf doing an unexport which seems unneeded now
<rburton>
yeah that does seem pointless
<RP>
rburton: made sense when it was added 15 years ago :)
<Saur[m]>
RP: Since we seem to be in agreement that we always want the elapsed time of a build task, I sent a patch for that.
<Saur[m]>
Bah, to the wrong list of course...
<RP>
Saur[m]: doing this at the point we're trying to build rc1 isn't probably a great idea
<Saur[m]>
RP: I'll leave that for you to decide. It can just as well be applied later.
<Saur[m]>
RP: Btw, I assume there was a reason you left the unexport of SHELL in bitbake.conf?
<RP>
Saur[m]: does that code break the length of progress bars for task numbers greater than a single digit? :/
<RP>
Saur[m]: yes, SHELL is a much more recent addition and I think there are subtleties around that
<Saur[m]>
RP: Shouldn't be any difference compared to before.
<Saur[m]>
OK.
<Saur[m]>
The code that updates the progress bar is the same as before.
<Saur[m]>
RP: The pbar.setmessage() call in updateFooter() handles it. The length of the message can change as much as you like, it will still show the line with the progress bar add correctly.
<qschulz>
amahnui[m]: agreed. Since you've your whole configuration correctly set up now, one more patch you can send :)
<Saur[m]>
I tested by adding randint(0, 1000000) to tasknum for each update and it showed just fine.
<qschulz>
amahnui[m]: BTW, for small changes, there's no need to ask for permission, you can send a patch and if someone disagrees the discussion can happen by mail :)
<RP>
Saur[m]: ah, right. I knew there had to be something
<amahnui[m]>
> amahnui: agreed. Since you've your whole configuration correctly set up now, one more patch you can send :)
<amahnui[m]>
I will do that right away
<amahnui[m]>
> amahnui: BTW, for small changes, there's no need to ask for permission, you can send a patch and if someone disagrees the discussion can happen by mail :)
<amahnui[m]>
Alright I understand
<qschulz>
(I mean, you never need to ask for permission, it's just that for big changes, you might want to discuss it first to not spend too much time on something that is not desired, but nothing prevents you from doing it and sending a patch anyway :) )
<RP>
BignauxRonan[m]: I'm guessing that is from qemu as you have gobject-introspection turned on. You could turn that off if you don't need/use it
<RP>
BignauxRonan[m]: the other option would be to figure out the correct qemu params
<BignauxRonan[m]>
RP: i was trying second option but don't find right options for now.
<RP>
BignauxRonan[m]: something like DISTRO_FEATURES:remove = "gobject-introspection-data"
<RP>
BignauxRonan[m]: sorry, I misread that. I don't know what the qemu options are for that arch or if it is supported
<BignauxRonan[m]>
that's not a supported CPU option, but it has support, could be work
guysoft[m] has joined #yocto
<amahnui[m]>
> (I mean, you never need to ask for permission, it's just that for big changes, you might want to discuss it first to not spend too much time on something that is not desired, but nothing prevents you from doing it and sending a patch anyway :) )
<amahnui[m]>
Thanks a lot for the clarification 🙏
<amahnui[m]>
I also wish to say my freebsd OSis functioning well now
<RP>
BignauxRonan[m]: I'm not seeing r5900 cpu support in qemu so the only option may be to find something close :/
<BignauxRonan[m]>
there are some support since the author of linux 5.x port would like to compile natively gentoo ...
<BignauxRonan[m]>
i try some QB_CPU = "-cpu 34Kf" to look
<BignauxRonan[m]>
it doesn't take the variable.
guysoft42 has quit [Remote host closed the connection]
<amahnui[m]>
> amahnui: that being said, you can send a patch to have double quotes around variables in the oe-init-buildenv script, that's for sure
<amahnui[m]>
Hello qschulz rburton Please I wish to ask if you could help me pointers to work on this
ar__ has joined #yocto
<qschulz>
amahnui[m]: git clone poky in a directory with a space and modify oe-init-build-env until it works
codavi has joined #yocto
<amahnui[m]>
Okay thanks I'm on it
<qschulz>
amahnui[m]: the issue is that in shell, most of the time, you should use a variable directly but use it with quotes
<qschulz>
(you can also fix other shellcheck warnings if there are others, but one logical change per commit please)
<amahnui[m]>
qschulz: Alright I will start working on it right away
ar__ has quit [Ping timeout: 246 seconds]
argonautx has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
jclsn10074 is now known as jclsn
sakoman has joined #yocto
fitzsim has joined #yocto
simonew has joined #yocto
bonalais has quit [Quit: Connection closed for inactivity]
<kergoth>
RP: iirc the SHELL thing is most obvious if you use a non-posix compliant shell. Try a bitbake build with “export SHELL=fish” or something to make things blow up
amitk has quit [Ping timeout: 260 seconds]
cambrian_invader has joined #yocto
<RP>
kergoth: I noticed that we do have SHELL mentioned for special handling in bb.utils, I wonder if that shouldn't be there...
<RP>
kergoth: I also wondered if we did the environment cleaning when you added SHELL back in 2015...
ecdhe has quit [Remote host closed the connection]
mckoan is now known as mckoan|away
frieder has quit [Remote host closed the connection]
rfuentess has quit [Remote host closed the connection]
amitk has joined #yocto
jclsn has quit [Ping timeout: 260 seconds]
<vvn>
hi there -- if layers are split correctly, you end up with BSP layers (where machine configurations reside), Distro layers (where distro configurations reside), and Application layers (where software packages reside). What about images though, do you guys consider images part of an application layer, or would you consider a fourth "integration" layer type containing image recipes?
florian_kc has joined #yocto
<rburton>
images can be considered distro
<rburton>
distro is the integration point
florian_kc has quit [Ping timeout: 272 seconds]
<vvn>
rburton: let's say that for your company product you use the "beaglebone" machine from meta-ti and meta-arago for the distribution. I guess you add a meta-<company> layer with your software packages and images, maybe stronger policies via multiconfig or a custom distro requiring a base one. Would you consider such proprietary layer a "distro" layer?
<rburton>
yes
<rburton>
its your distro layer
<vvn>
damn you read fast :]
<rburton>
a distro layer is the integration point
<rburton>
depends on layers for software or bsps, defines how they're configured (distro) and built (images)
<vvn>
got it. If sharing is needed, then a distro layer can be split to extract software packages in an application layer, like meta-qt5 for example.
<rburton>
yeah, if you end up with a load of recipes for open source software then either create a new layer, or contribute them to an existing one
<vvn>
rburton: isn't it weird if a distro layer depends on bsp layers?
<vvn>
I guess it kinda makes sense for a proprietary distro layer, to describe all the supported BSPs.
<vvn>
The term distro is confusing when you think about it as a generic Linux distro, while in fact it's really about build policies and integration point.
jclsn has joined #yocto
GLumen has joined #yocto
florian_kc has joined #yocto
GLumen has quit [Quit: Konversation terminated!]
GLumen has joined #yocto
roussinm has joined #yocto
Mike23 has joined #yocto
amitk has quit [Ping timeout: 246 seconds]
<amahnui[m]>
Hello qschulz I added double quotes to the variable ($OEROOT) and ran shellcheck and it never pointed ``` ^-----^ SC2086: Double quote to prevent globbing and word splitting.``` that it was giving when there were no quotes. But when i run "source oe-init-build-env" it gives me the error ```/home/abongwa/Desktop/projects/test repo/poky/scripts/oe-setup-builddir: 45: .: Can't open /home/abongwa/Desktop/projects/test```
florian_kc has quit [Ping timeout: 240 seconds]
<amahnui[m]>
Instead of the normal ```bash: /home/abongwa/Desktop/projects/test: No such file or directory``` error.
agrue has joined #yocto
<amahnui[m]>
I thought of a way of implementing a recursive function which grabs each name and puts it in double quotes but I'm still facing difficulties implementing it as the directory is dynamic depending on user's preference.
agrue has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
mvlad has quit [Remote host closed the connection]
rob_w has quit [Read error: Connection reset by peer]
otavio has quit [Read error: Connection reset by peer]
goliath has quit [Quit: SIGSEGV]
callum has joined #yocto
tomzy_0 has quit [Quit: Client closed]
leon-anavi has quit [Ping timeout: 240 seconds]
callum has quit [Quit: Client closed]
leon-anavi has joined #yocto
florian_kc has quit [Ping timeout: 268 seconds]
<cambrian_invader>
is it possible to keep Linux build output between build runs?
<cambrian_invader>
it seems like every time I make a configuration change *everything* gets recompiled
<cambrian_invader>
which takes around 10m, vs perhaps 15s for an incremental build
zwelch has quit [Ping timeout: 260 seconds]
<RP>
cambrian_invader: a lot depends on what you change and where/how
<cambrian_invader>
I did a menuconfig and enabled/disabled a few drivers
<cambrian_invader>
and then everything was recompiled
<cambrian_invader>
whereas if I had been using a bare source, I would have expected maybe 30 files recompiled
<RP>
cambrian_invader: I'd guess that is as the system is trying to track the config change and package the output
<cambrian_invader>
right, but it seems like someone is running "make clean"
<cambrian_invader>
or something equivalent
<RP>
cambrian_invader: a new config is probably making it decide to build from scratch just to be sure. There are ways to just rebuild your changes but not when using menuconfig so easily
<cambrian_invader>
ugh
<cambrian_invader>
bitbake is really terrible if you are actually developing software
<RP>
cambrian_invader: yes and no. It is being careful about capturing your config which under different circumstances, you might worry about
<cambrian_invader>
sure, but Linux has a great build system already
<RP>
I do wish we had people to work on these workflows :/
<cambrian_invader>
and it can determine what needs to be recompiled and what doesn't
<RP>
cambrian_invader: there is more to a linux image than just the kernel
<cambrian_invader>
right, so re-run do_compile and the parts after that
<cambrian_invader>
but do_compile should turn into "make" and no more
<RP>
cambrian_invader: I suspect the problem is configure, not compile as compile effectively does just that
leon-anavi has quit [Remote host closed the connection]
Guest82 has quit [Quit: Client closed]
<GLumen>
cambrian_invader: Have you tried running `bitbake-whatchanged` after menuconfig but before building? It might give you some insight in to why bitbake decided to re-run more tasks that you expected.