<Ch^W_>
RP: The only changes I made were to lines 29, 100, 102, and 110.
Vonter_ has quit [Ping timeout: 252 seconds]
<Ch^W_>
And the more I ponder it, the more I like your idea. It more or less causes bitbake behave like Git.
Vonter_ has joined #yocto
Vonter_ has quit [Ping timeout: 252 seconds]
hpsy has quit [Ping timeout: 256 seconds]
Vonter_ has joined #yocto
camus has joined #yocto
Vonter_ has quit [Ping timeout: 252 seconds]
Vonter_ has joined #yocto
Vonter_ has quit [Ping timeout: 265 seconds]
Vonter_ has joined #yocto
Vonter_ has quit [Ping timeout: 264 seconds]
Vonter_ has joined #yocto
Vonter_ has quit [Ping timeout: 264 seconds]
Vonter_ has joined #yocto
Guest32 has joined #yocto
Vonter_ has quit [Ping timeout: 265 seconds]
<Guest32>
Hello, I have a question. I'm using Yocto Dunfell and I'm trying to remove qemu-edk2 support. How I can remove the edk2 support from qemu?
Ad0 has quit [Ping timeout: 268 seconds]
Vonter_ has joined #yocto
Vonter_ has quit [Ping timeout: 252 seconds]
alicef has quit [*.net *.split]
risca_ has quit [*.net *.split]
Gaffel_ has quit [*.net *.split]
tkoskine has quit [*.net *.split]
xantoz has quit [*.net *.split]
tkoskine has joined #yocto
alicef has joined #yocto
risca has joined #yocto
xantoz has joined #yocto
xmn has quit [Ping timeout: 265 seconds]
Gaffel has joined #yocto
amitk has joined #yocto
Schlumpf has joined #yocto
sakoman has quit [Ping timeout: 264 seconds]
m4ho has quit [Quit: WeeChat 3.1]
alessioigor has joined #yocto
manuel1985 has quit [Ping timeout: 252 seconds]
alessioigor has quit [Quit: alessioigor]
sakoman has joined #yocto
hpsy has joined #yocto
zyga-mbp has joined #yocto
rsalveti has quit [Quit: Connection closed for inactivity]
bps has joined #yocto
bps has joined #yocto
Schlumpf has quit [Quit: Ping timeout (120 seconds)]
<JosefHolzmayrThe>
Guest32: remove from where and whats the reasoning?
tre has joined #yocto
<Guest32>
I have a low memory system that is booting from RAM and I don't need the UEFI support
<JosefHolzmayrThe>
Guest32: but how does that relate to qemu?
goliath has joined #yocto
<Guest32>
bash-5.0# ls -lah /usr/share/qemu/ | grep edk
<Guest32>
-rw-r--r-- 1 root root 64M Mar 9 2018 edk2-aarch64-code.fd
<Guest32>
-rw-r--r-- 1 root root 64M Mar 9 2018 edk2-arm-code.fd
<Guest32>
-rw-r--r-- 1 root root 64M Mar 9 2018 edk2-arm-vars.fd
<Guest32>
-rw-r--r-- 1 root root 3.5M Mar 9 2018 edk2-i386-code.fd
<Guest32>
-rw-r--r-- 1 root root 3.5M Mar 9 2018 edk2-i386-secure-code.fd
<Guest32>
-rw-r--r-- 1 root root 528K Mar 9 2018 edk2-i386-vars.fd
<Guest32>
-rw-r--r-- 1 root root 42K Mar 9 2018 edk2-licenses.txt
<Guest32>
-rw-r--r-- 1 root root 3.5M Mar 9 2018 edk2-x86_64-code.fd
<Guest32>
-rw-r--r-- 1 root root 3.5M Mar 9 2018 edk2-x86_64-secure-code.fd
<Guest32>
edk2 seems to be part of qemu ...
<JosefHolzmayrThe>
Guest32: i'd rather guess that something in your image/distro/machine pulls it in, and if you don't need it, then remove it there.
Schlumpf has joined #yocto
manuel1985 has joined #yocto
mvlad has joined #yocto
<Guest32>
do you have an example? I want qemu without edk2 ...
<JosefHolzmayrThe>
Guest32: but you do want qemu?
<Guest32>
Yes, I want qemu ...
rfuentess has joined #yocto
<JosefHolzmayrThe>
Guest32: according to this list http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/qemu/qemu.inc#n148 i cannot easily spot a switch that would affect uefi or edk2. so I'd say thats your starting point: find out what build parameter makes qemu build and install all that stuff, then turn it off. one sidenode: before you dig too deep, make sure that you're actually looking at the right thing. oe-pkgdata-util will help
<JosefHolzmayrThe>
you map the file to a recipe/package
<JosefHolzmayrThe>
Guest32: and trimming down supported architectures might be helpful too.
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
pidge957 is now known as pidge
pidge has quit [Quit: Client closed]
pidge has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
<wyre>
does bitbake provide cmake? 🤔
<rburton>
there is an oe-core recipe for cmake
<rburton>
bitbake doesn't provide anything
<wyre>
rburton, I mean for the build process in the docker instance where I'm running bitbake
<rburton>
right. oe-core has a recipe for cmake.
<rburton>
like it has a recipe for autoconf or gcc.
<wyre>
rburton, so actually cmake has to be built before built c packages with it? 🤔
<rburton>
bitbake is a python tool which reads recipe files, and executes them. nothing else.
<rburton>
well, yes, of course
<rburton>
inherit cmake in the recipe that uses cmake and that will add a dependency on cmake-native for you
<wyre>
rburton, what do you mean with "cmake-native"?
<rburton>
that's teh recipe that provides a cmake you can run during the build
<wyre>
rburton, I wrote a recipe to build a c program with cmake, but I'm having these errors https://bpa.st/QSIA
<wyre>
and I think they could be because some cmake extension is missing 🤔
<rburton>
does your recipe inherit pkgconfig?
<rburton>
because your cmake is calling pkgconfig
<JosefHolzmayrThe>
i think the standard sdk includes qemu, and i thought it also would include the kernel+image that it was built for, but has that changed?
<wyre>
rburton, no, it doesn't, I'll try inheriting pkgconfig also
<wyre>
can I do it like `inherit cmake pkgconfig`?
<qschulz>
yes
<wyre>
well, currently is inheriting also pkgconfig but the error is still the same
<wyre>
maybe I need to set DEPENDS 🤔
jwillikers has joined #yocto
tgamblin has joined #yocto
<manuel1985>
I'm reorganizinig my metalayers. I'd md5sum the whole generated rootfs before and after my change to assert my change is functionally neutral. Is there any smarter way of doing that?
<JosefHolzmayrThe>
manuel1985: having a proper automated testing strategy.
<JosefHolzmayrThe>
manuel1985: from guessing i'd expect md5sum to trip over timestamps and such
<qschulz>
probably the cache of metadata parsing might be enough?
<JosefHolzmayrThe>
one thing that i've learnt in the last year is: "if you're afraid to touch or refactor it, then it means that your testing strategy needs improving"
otavio has joined #yocto
bps has quit [Ping timeout: 258 seconds]
<wyre>
rburton, is `check` also inheritable?
<qschulz>
wyre: only bbclass files are inheritable
<qschulz>
so if there's a check.bbclass, yes you *can* inherit it.
<qschulz>
wyre: make sure that the flags passed by Yocto are used in your cmake and not overridden in your cmakelists.txt or whatever
<wyre>
qschulz, what flags are passed by yocto?
<qschulz>
cflags, cxxflags, ldflags, cmake specific flags etc
<wyre>
I've got an empty EXTRA_OECMAKE
jwillikers has quit [Quit: jwillikers]
<qschulz>
best practice is to default variables if not defined, and if you want a particular flag being used, you add to the variable and not replace it
<wyre>
apparently is cmake which is missing `check`
<qschulz>
I've read that this is required when tests are enabled, not sure you need that? Might want to try disabling it from EXTRA_OECMAKE or similar/ I don't know anything about cmake so can't help more than that
<qschulz>
otherwise I assume DEPENDS += "libcheck-native" might help
wwilly has joined #yocto
Stormenberg has quit [Quit: Leaving]
<wyre>
qschulz, what's the difference between libcheck-native and just libcheck?
<wyre>
rburton, I can't see the flags set when I use EXTRA_OECMAKE in the bitbake output
<rburton>
they'll be passed to cmake in do_configure
<wyre>
so I guess I should read the do_configure log to see them?
<rburton>
yes
<wyre>
and how can I found it? 🤔 has bitbake some command to check logs per recipe?
<rburton>
if you install the extra 'bb' utility, yes. otherwise, tmp/work/*/RECIPE/VERSION/temp/log.do_configure
<rburton>
i've installed bb so `bb log RECIPE TASK` shows that file
<JPEW>
moto-timo: Are you giving a talk on phosh of the Yocto summit?
Jonathan has quit [Quit: Client closed]
<moto-timo>
JPEW: working on the proposal this morning. I ‘ve been fighting the gnome stack (for a packagegroup-gnome-apps install vs a sato lookalike).
<moto-timo>
more recipes in meta-gnome need inherit pkgconfig
<JPEW>
moto-timo: Ya, I found one yesterday (`colord-native`)
<moto-timo>
And gjs is currently unbuildable because it depends on an older mozjs
<moto-timo>
upstream is working on mozjs-91 compatibility
<JPEW>
I've been testing with master-next of meta-or
<moto-timo>
I have an upgrade to gjs in the works, but current release requires mozjs-78
willo has quit [Ping timeout: 260 seconds]
<JPEW>
Ah, is gjs needed by the extra packages you're installing (I'm only building older `phosh` and `phoc` and it seems to build OK)
<moto-timo>
gnome-weather is a recipe I’m trying to add
<moto-timo>
gnome-screenshot seems ok, but I haven’t built a full image yet while figuring out other landmines
Guest32 has quit [Quit: Client closed]
Tyaku has joined #yocto
rsalveti has joined #yocto
bps has joined #yocto
bps has joined #yocto
bps has quit [Ping timeout: 260 seconds]
<moto-timo>
gnome-photos needs gfbgraph, which is currently failing because it checks for rest-0.7 and we have rest-0.8.1 (which is from 2019... so hrmm)
goliath has quit [Quit: SIGSEGV]
<kanavin_>
moto-timo, gjs has an open pull request for mozjs 91
<moto-timo>
kanavin: I saw the branch and a recent merge to "prepare for mozjs-91"
sb27 has quit [Quit: Client closed]
wwilly has quit [Ping timeout: 260 seconds]
wwilly has joined #yocto
<tlwoerner>
moto-timo: yea! +1 (YPS proposal)
tre has quit [Remote host closed the connection]
<tlwoerner>
gentle reminder to everyone that the CFP for the next YPS closes tomorrow :-)
<wyre>
when I run `bitbake <my_recipe>` where are the compiled binaries stored?
<wyre>
tmp/work/?
<kanavin_>
wyre, tmp/deploy/
<wyre>
kanavin_, but for that shouldn't I do something like `bitbake -c deploy <my_recipe>`?
<wyre>
I cannot see it in tmp/deploy
<qschulz>
except if my_recipe is an image recipe, yes
<qschulz>
what are you looking for exactly?
<wyre>
qschulz, I'd like to build just my recipe to get the binaries
<qschulz>
in tmp/deploy you have your packages, which do contain the binaries you compiled, and also some deployed artifacts, among which your image, the result of bitbaking your image recipe
<qschulz>
then tmp/work/<arch>/<my-recipe>/<some-vers>/
<wyre>
and cannot I get the generated package for my specific recipe (which is not an image recipe)
<qschulz>
ideally your binary should be in tmp/work/<arch>/<my-recipe>/<some-vers>/image (which is $D) if you did the install task correctly
<kanavin_>
wyre, taking things out of tmp/work is not recommended - tmp/deploy exists specifically as a place for 'deliverables'
<qschulz>
wyre: the package is in tmp/deploy as I said earlier
<qschulz>
note that this is clearly only for development/hacks
<wyre>
qschulz, I can see images, licenses and rpm folders inside tmp/deploy
<qschulz>
wyre: rpm is a package format
<wyre>
I guess it should be an rpm package inside rpm folder
<wyre>
but I cannot see it
<qschulz>
wyre: then I'm pretty sure you didn't do your install task properly
<qschulz>
as empty packages are not created and put in tmp/deploy/<pkg-fromat>
<kanavin_>
wyre, I think you need to run bitbake -c deploy recipename for the rpm to show up in tmp/deploy
<wyre>
I guess all packages are rpm because I've got `PACKAGE_CLASSES ?= 'package_rpm'`, right?
<qschulz>
kanavin_: I think this is done in do_package_write_<format> which is run before do_build, so any time bitbake <recipe> is called
<qschulz>
wyre: yes
<wyre>
does that also mean that final image will handle packages through rpm?
<kanavin_>
wyre, yes, image creation is basically a gigantic package installation transaction
<kanavin_>
yocto does not compose root filesystem directly, but outsources the job to package managers
<kanavin_>
dnf for rpm, apt for deb or opkg for ipk
Tyaku has quit [Quit: Lost terminal]
<wyre>
kanavin_, have I also to write a do_deploy task? 🤔
<kanavin_>
wyre, give me a sec
<qschulz>
wyre: no
<qschulz>
you write a deploy task if you want artifacts to go into tmp/deploy/images/<image>/
<qschulz>
when the image is created
rfuentess has quit [Remote host closed the connection]
<kanavin_>
wyre, I just checked: simply run bitbake recipename, and packages will show up in tmp/deploy/rpm
<kanavin_>
there are some subdirs in there but you will find it
dlan has joined #yocto
jwillikers has quit [Remote host closed the connection]
tnovotny has quit [Quit: Leaving]
Xagen has joined #yocto
<Xagen>
hi everyone
<Xagen>
i'm using a recipe from meta-intel for sbsigntool
<moto-timo>
I’ll probably refactor core-image-phosh to have the knobs core-image-sato has (or similar)
<moto-timo>
manuel1985: phosh is a possible wayland compositor for gtk+3 apps, but it is currently decidedly phone form factor (lock screen by default with numeric only PIN and portrait layout)
<moto-timo>
Well, phosh is the shell, phoc is the compositor to be precise
<manuel1985>
moto-timo: Thanks :)
<manuel1985>
moto-timo: FYI The readme says one shall execute ./kas/kas-container but .kas/ doesn't contain that file
<manuel1985>
Guess I'll just use plain kas, don't like that kas-container script anyway.
<moto-timo>
manuel1985: that's just how I run it and that branch is still WIP. I had permissions issues with straight kas
<moto-timo>
manual1985: you can also run it just normal command line, but look at the kas files for hints about what to put into local.conf (especially a default PIN/password, otherwise you will never get past the lockscreen in the GUI, even though passwordless root will still work in a console)
<moto-timo>
and I can't spell
<manuel1985>
moto-timo: Got you, thanks
<moto-timo>
manuel1985: also, for qemu it is a bit wonky because the canvas extends beyond the display and I haven't figured out why yet. Most of my success has been on rpi4
florian has joined #yocto
vd has joined #yocto
<vd>
how can I set a variable from the output of a shell command?
<moto-timo>
JPEW: gentle nudge to upstream your mutter-gsettings sub-package
<JPEW>
Oh, right!
wwilly has quit [Quit: Leaving]
leon-anavi has quit [Quit: Leaving]
sb27 has joined #yocto
manuel1985 has quit [Ping timeout: 264 seconds]
florian has quit [Ping timeout: 264 seconds]
GlennTrimble has joined #yocto
GlennTrimble has quit [Client Quit]
<kanavin_>
halstead, stdio: WARNING: libusb1-1.0.24-r0 do_package: Error contacting Hash Equivalence Server typhoon.yocto.io:8686: [Errno -2] Name or service not known
<kanavin_>
halstead, it could be something in my patchset, I'm not sure :-/
suchas has joined #yocto
<halstead>
kanavin_: Not happening now. Perhaps this is related to the network issues RP was having and the connection to github failing.
<halstead>
kanavin_: Have we seen these succeed before?
<kanavin_>
halstead, in general, yes, but not with this patchset, as it's the first time I'm running it
<halstead>
kanavin_: I'm curious if the connect string is formatted correctly. Could it be as simple as that?
suchas has quit [Quit: Leaving]
florian has joined #yocto
<kanavin_>
halstead, I need to check where that warning is coming from first, and whether anything from my patchset is involved in that
<kanavin_>
I'm not a hashequiv specialst, JPEW is
<JPEW>
kanavin_: Ya, hashequiv needs to handle a missing upstream better
<kanavin_>
JPEW, does hashequiv use anything from -native builds?
<JPEW>
There is a patch on the ML to check if the upstream exists when bitbake starts (not from me), but the server itself needs to handle it better also; a missing upstream really isn't fatal, just perhaps non-optimal
<kanavin_>
JPEW, I have a massive version update set, and wondering if something in it broke hashequiv with those warnings
<JPEW>
kanavin_: It does not use any -native recipes; pure host python
<kanavin_>
JPEW, phew :)
<vd>
how can I set a variable from the output of a shell command like this: d.setVar('FOO', 'output is: %s' % <call to a shell command>)
linkliu62 has quit [Ping timeout: 264 seconds]
linkliu60 has quit [Ping timeout: 252 seconds]
<kergoth>
vd: bb.process.run()
<vd>
thank you
<moto-timo>
kanavin_: but I can see why you might be nervous. lol
Tokamak has quit [Ping timeout: 252 seconds]
<vd>
kergoth: is there a better way to call python from python instead of doing this: d.setVar('FOO', '>>> %s <<<' % bb.process.run(python -c 'import crypt; print(crypt.crypt("somesecret", "salt"))'))
nucatus has quit [Remote host closed the connection]
<vd>
kergoth: also is bb.process.run() called at parse time or at run time?
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
vladest has joined #yocto
sakoman has quit [Quit: Leaving.]
nucatus has joined #yocto
amitk_ has joined #yocto
amitk has quit [Ping timeout: 264 seconds]
nucatus has quit [Ping timeout: 265 seconds]
kiran has quit [Ping timeout: 264 seconds]
florian has quit [Ping timeout: 252 seconds]
nucatus has joined #yocto
kuzz has joined #yocto
nucatus has quit [Ping timeout: 260 seconds]
GillesM has joined #yocto
<tlwoerner>
what does this mean?
<tlwoerner>
No currently running tasks (56 of 56/445 of 446)
amitk has joined #yocto
<tlwoerner>
i'm not too concerned about the "no currently running tasks" part, it's the rest that has me wondering
mvlad has quit [Remote host closed the connection]
amitk_ has quit [Ping timeout: 258 seconds]
<moto-timo>
I think the 56 of 56 is native tools and the 445 of 446 is the image/target task queue
<moto-timo>
New behavior. It used to run the 56 of 56 first and then the 445 of 446 after that
amitk has quit [Quit: leaving]
<kanavin_>
I think those are setscene/full
<JPEW>
right, because setscene and regular tasks are intermixed now
<rburton>
yeah, it's setscene/normal
bluelightning_ is now known as bluelightning
<tlwoerner>
ah okay. thanks :-)
<tlwoerner>
yes, this feels new
<moto_timo[m]>
TIL
<JPEW>
TIL what TIL means
<rburton>
it landed about a week ago, so yes its new :)
<moto-timo>
JPEW: lol
<moto-timo>
JPEW: frequent Twitter thing
<JPEW>
Ya, I've heard it spoken out a lot, but I never put it together
Vonter_ has joined #yocto
<JPEW>
And I'm not on the Twitters much
<moto-timo>
Safer that way
bps has quit [Ping timeout: 264 seconds]
manuel1985 has joined #yocto
<kanavin_>
you don't want to know what I use twitter for
<kanavin_>
it's surprisingly good for that purpose
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Vonter_ has quit [Ping timeout: 258 seconds]
sakoman has joined #yocto
* tlwoerner
looks for kanavin_'s twitter handle, but doesn't find anything obvious
<RP>
What is twitter? :)
<RP>
kanavin_, halstead: That looks very like the "something wrong with networking" thing which we keep seeing intermittently :(
<RP>
there is no way the autobuilder shouldn't know and be able to resolve that address
<RP>
we should track which hosts this is happening on and when
<RP>
halstead: interesting. I'd probably have just gone for noting on a wiki page or a google doc or something!
<halstead>
RP: That might be a bit harder to analyze but if you think it would be easier.
<halstead>
For users that is. ;)
<RP>
halstead: probably
<RP>
abelloni: ^^^ - thoughts?
<RP>
halstead: I don't have a strong opinion, just that we need to work out the pattern. I wondered if some service was restarting at that time. Is that distro using systemd and anything in the logs at that time when the error happened?
<abelloni>
why not
<abelloni>
I can also extract what I have from the swat stats but I'm not sure all of the network issues we've had are related
<abelloni>
The data I have is bug#,worker,completion timestamp
<RP>
abelloni: I suspect there is some subset which are
<abelloni>
I guess we can get the 9356 seconds interval
<RP>
halstead: the warnings are in the full build log so you can also look at the position of them in the log relative to the build
<RP>
halstead: if you login to the system and look at the build if it is still there that would narrow down further as I suspect some are in individual task logs and would be at the start of tasks
<RP>
halstead: warning is at the end of the log and one of the last things to run so the log timestamp should match with the rough time it happened
<RP>
(Oct 18 17:11)
<halstead>
I wonder what the cost benefit ratio is for adding timestamps to log output? I bet there have been other times it would have been useful.
<RP>
halstead: It is harder than you'd think as should the stamp be added at source or at the time it is printed to the user/UI :/
<RP>
In this case anything would be helpful but I know a soon as we do it, the accuracy would then come into question and people would want it at source
<RP>
I'm sure I have patches somewhere but it got ugly :(
<halstead>
Ehmm.. well. One of those things where almost good enough would be simple and doing it right is a pain? I understand.
nucatus has joined #yocto
<agherzan>
I reckon there is a bug on dunfell with pseudo and coreutils 9.0 on host. I can't yet point exactly how it happens, but it looks like when under fakeroot, sometimes, install (hosttool) strips the binary even if the respective flag was not passed.
<agherzan>
What is even more awkward is that on a subsequent install (with force bitbake flag), it behaves as expected - both binaries are not stripped.