ChanServ changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: | Join us or Speak at Yocto Project Summit (2021.11) Nov 30 - Dec 2, more: | Join the community: | IRC logs available at | Having difficulty on the list or with someone on the list, contact YP community mgr ndec
linkliu59 has quit [Ping timeout: 260 seconds]
linkliu59 has joined #yocto
paulg has quit [Remote host closed the connection]
paulg has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
Vonter_ has joined #yocto
<Ch^W_> RP: Here is a gist of the patch update I emailed to the list:
<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 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.
mckoan|away is now known as mckoan
<mckoan> good morning
hpsy has quit [Quit: Client closed]
hpsy has joined #yocto
kroon has joined #yocto
Vonter_ has joined #yocto
gsalazar_ has joined #yocto
Vonter_ has quit [Ping timeout: 258 seconds]
zpfvo has joined #yocto
<hmw[m]> good morning
<hmw[m]> how do i set a perered version of linux-libc-headers?
goliath has quit [Quit: SIGSEGV]
<JosefHolzmayrThe> hmw: be providing a recipe for it and then using PREFERRED_VERSION, probably.
<hmw[m]> PREFERRED_VERSION_linux-libc-headers = "5.10.%" ?
<JosefHolzmayrThe> PREFERRED_VERSION:linux-libc-headers it is on master, and it also only works if there is a recipe that provides said version.
<hmw[m]> tnx
amitk has quit [Quit: leaving]
amitk has joined #yocto
amitk has quit [Client Quit]
amitk has joined #yocto
gsalazar__ has joined #yocto
Vonter_ has joined #yocto
gsalazar_ has quit [Ping timeout: 264 seconds]
alejandr1 has quit [Read error: Connection reset by peer]
kroon has quit [Quit: Leaving]
Vonter_ has quit [Ping timeout: 258 seconds]
kroon has joined #yocto
alejandr1 has joined #yocto
Vonter_ has joined #yocto
tnovotny has joined #yocto
Vonter_ has quit [Ping timeout: 258 seconds]
pgowda_ has joined #yocto
<qschulz> RP: I saw over the week-end that the can of worms is open for the JSON files :p
<JosefHolzmayrThe> qschulz: JSON files? where are JSON files?!?
<qschulz> JosefHolzmayrThe: IIUC, the format of the sigdata files is changed from pickled objects to JSON files
<JosefHolzmayrThe> ah
goliath has joined #yocto
mattsm has quit [Quit: Ping timeout (120 seconds)]
kpo_ has quit [Read error: Connection reset by peer]
mattsm has joined #yocto
<wyre> can bitbake include a recipe in the workspace into a specific layer? Have I to do this manually? 🤔
<JosefHolzmayrThe> wyre: you mean, once you are finished with it, after you worked on it with devtool? i think it can, go for devtol help
wwilly has quit [Quit: Leaving]
ndec_ is now known as ndec
florian has joined #yocto
<JosefHolzmayrThe> how crazy would it be to put DL_DIR and maybe even SSTATE on a remote location, connected over rclone?
<qschulz> I think it's a bad idea for SSTATE if you don't have a blazing fast download speed from your remote location?
<qschulz> what are you trying to achieve?
<JosefHolzmayrThe> and if i had?
<qschulz> you would have the network overhead for every sstate-cache checks
<qschulz> so still much slower than local fs I'd assume but it's just guessing :)
<JosefHolzmayrThe> i'm not doubting that it will be slower, probably also substantially, but would it work?
<qschulz> let us know :p
RP has quit [Ping timeout: 252 seconds]
<JosefHolzmayrThe> exactly the "i did not hope for"-answer :P
Stormenberg has joined #yocto
<rburton> JosefHolzmayrThe: isn't the stuff local if you use rclone, it's just mirrored remotely too?
RP has joined #yocto
<rburton> the canonical solution is local sstate_dir, remote readonly sstate mirror, task to sync local to remote
<RP> qschulz: yes, I hadn't realised the code used them as sets :(
<JosefHolzmayrThe> rburton: yeah i know, but what if i want a remote sstate and have no nfs or such?
<JosefHolzmayrThe> e.g. want to use aws s3 or such?
<rburton> then you need to write locally then mirror afterwards
<rburton> which is trivial, after a successful build do the sync
<JosefHolzmayrThe> and how do i use the remote one? any example?
<JosefHolzmayrThe> k
<rburton> local.conf.sample has an example using the autobuilder sstate
<rburton> stuff in a mirror is downloaded to your local sstate dir, so if your intention is to reduce disk usage then sorry
<JosefHolzmayrThe> yeah i know that one, but its a) public and b) uses the whole http sutff
<rburton> sure, but its an example of the syntax
<rburton> it runs through bb.fetch2
<qschulz> you upload your SSTATE_DIR to your remote and rnu a webserver serving those files
<qschulz> and rsync every now and then to keep your mirror up to date
<qschulz> same mechanism can be used for DL_DIR
<rburton> or if s3 wasn't an abstract example, you can use s3: urls
<JosefHolzmayrThe> yeah but... it kinda doesn't feel like i want it to.
<JosefHolzmayrThe> thanks for the input, will dig deeper.
<qschulz> not sure to understand the issue, can you elaborate?
<JosefHolzmayrThe> qschulz: not yet, sorry.
<qschulz> :)
<JosefHolzmayrThe> read as: "busy evaluating crazy brainfarts"
Tyaku has joined #yocto
bps has quit [Ping timeout: 260 seconds]
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
bps has quit [Ping timeout: 264 seconds]
bps has joined #yocto
bps has joined #yocto
Tyaku has quit [Quit: Lost terminal]
leon-anavi has joined #yocto
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
<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
jwillikers has joined #yocto
<wyre> well, I don't get why I'm having this error now
<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?
<qschulz> libcheck-native is compiled so it can run on the host/build machine
<qschulz> libcheck is built for running on the target (the "recipient" of your image)
<wyre> is this in that way for all suffixed -native recipes? 🤔
<qschulz> wyre: I've pointed you to the documentation where this is explained
<wyre> oh, yes, I'm reading it right now, thank you 😊
pgowda_ has quit [Quit: Connection closed for inactivity]
michaelo has joined #yocto
<rburton> wyre: if you need check then add it to depends
jwillikers has quit [Remote host closed the connection]
Jonathan has joined #yocto
artri has joined #yocto
vladest has quit [Ping timeout: 258 seconds]
atril has joined #yocto
artri has quit [Ping timeout: 258 seconds]
kiran has joined #yocto
bluelightning_ has joined #yocto
bluelightning has quit [Ping timeout: 264 seconds]
jwillikers has joined #yocto
hpsy has quit [Quit: Client closed]
kroon has quit [Quit: Leaving]
nucatus has joined #yocto
<wyre> could I include extra cmake flags with EXTRA_OECMAKE variable? 🤔
leon-anavi has quit [Remote host closed the connection]
Schlumpf has quit [Quit: Client closed]
<rburton> yes, that's what it is for
<wyre> rburton, what about TARGET_CFLAGS?
<rburton> that is for CC flags
<rburton> like -Wall or -DFOO=bar
fleg has quit [Remote host closed the connection]
dlan has quit [Remote host closed the connection]
leon-anavi has joined #yocto
fleg has joined #yocto
<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
<JPEW> *meta-oe
<moto-timo> I was attempting to get more of the look of
<moto-timo> Same
<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
<Xagen> and i'd like to build it as nativesdk
<Xagen> but can't seem to get it to work
<Xagen> it can't find bfd, which is supposed to be from binutils
dev1990 has joined #yocto
dev1990 has quit [Client Quit]
dev1990 has joined #yocto
<rburton> what's the actual error? it most likely is expecting native tools and can't handle doing a cross compile (which is needed for nativesdk)
<Xagen> | configure: error: bfd.h not found.
<Xagen> | bfd.h is usually distributed in a binutils development package.
<Xagen> and then it exits
pidge has quit [Quit: Client closed]
pidge10 has joined #yocto
pidge10 has quit [Client Quit]
<rburton> you'll likely need to depend on binutils
<rburton> the recipe will need quite a bit of sorting out to remove the native assumptions
<rburton> i'm assuming you already renamed the recipe, removed the inherit native, and added a bbclassextend
<Xagen> correct
<rburton> there's definitely a bfd.h inside target binutils, so you just need to stop it insisting on bintuils-native
<Xagen> thanks :)
<Xagen> i'll keep poking at it then
zpfvo has quit [Quit: Leaving.]
goliath has joined #yocto
mckoan is now known as mckoan|away
florian has quit [Quit: Ex-Chat]
tangofoxtrot has quit [Remote host closed the connection]
tangofoxtrot has joined #yocto
<JPEW> moto-timo: I just ran into the mozjs error; apparently I just hadn't made it that far yet :)
<moto_timo[m]> Yeah.
<moto_timo[m]> The good news is I fixed gfbgraph (and thus gnome-photos) and gnome-calendar
<moto_timo[m]> Also, phoc and phosh need to inherit pkgconfig
<moto_timo[m]> Latest phosh branch updates pushed, sans -gnome image since it doesn’t build yet.
<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 [Errno -2] Name or service not known
<kanavin_> known issue?
<halstead> kanavin_: First I've seen it.
<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:
<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 <<<' % -c 'import crypt; print(crypt.crypt("somesecret", "salt"))'))
nucatus has quit [Remote host closed the connection]
<vd> kergoth: also is 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
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
nucatus has joined #yocto
nucatus has quit [Ping timeout: 265 seconds]
<halstead> RP: Would this form work?
<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
<RP> finding the commonality is the hard bit :)
bps has quit [Ping timeout: 260 seconds]
florian has joined #yocto
<halstead> Is there a way to find the timestamp of the warnings from ?
<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
manuel1985 has quit [Ping timeout: 245 seconds]
* halstead nods.
<kanavin_> halstead, here's another (different) fail that I think is the same issue - network timeouts in qemu(!)
<kanavin_> RP ^^^
<kanavin_> but I'll run it again to confirm
neverpanic has quit [Quit: brb]
neverpanic has joined #yocto
GillesM has quit [Remote host closed the connection]
Vonter_ has joined #yocto
jwillikers has joined #yocto
fleg has quit [Remote host closed the connection]
Vonter_ has quit [Ping timeout: 260 seconds]
atril has quit [Ping timeout: 260 seconds]
<halstead> It doesn't look like the logs in the build-renamed dir have any more exact time info.
<RP> halstead: /home/pokybuild/yocto-worker/genericx86-64-alt/build/build-renamed/tmp/work/core2-64-poky-linux/gtk+3/3.24.30-r0/temp/log.do_package.41319
<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> Here is an example:
nucatus has quit [Ping timeout: 265 seconds]
<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.
goliath has quit [Quit: SIGSEGV]
Wouter0100 has quit [Ping timeout: 245 seconds]
Wouter0100 has joined #yocto
GillesM has joined #yocto