<rfs613>
I see rburton has done CVE-2022-0778 (openssl), by upreving the package. For dunfell, presumably we only want the CVE backported, rather than updating 1.1.1l -> 1.1.1n, correct?
<moto-timo>
rfs613: it depends on whether the release has new features or is just security and bug fixes.
goliath has quit [Quit: SIGSEGV]
<rfs613>
wasn't expecting an answer until tomorrow ;-)
<jclsn>
mckoan: Thanks, so the defconfigs are the same
<jclsn>
I have really no idea why devtool is producing a different kernel than bitbake
manuel1985 has joined #yocto
<jclsn>
The sources are identical and the defconfigs are identical
<ernstp>
See there's a 3.1.15 release in the pipe for Dunfell. Maybe get CVE-2022-0778 in there also sakoman ?
tre has joined #yocto
kroon has joined #yocto
goliath has joined #yocto
tnovotny has joined #yocto
manuel1985 has quit [Ping timeout: 268 seconds]
rfuentess has joined #yocto
dev1990 has joined #yocto
Schlumpf has joined #yocto
leon-anavi has joined #yocto
manuel1985 has joined #yocto
florian has joined #yocto
camus has joined #yocto
<RP>
ernstp: 3.1.15 was built and is in QA
Bardon has quit [Ping timeout: 256 seconds]
manuel1985 has quit [Ping timeout: 240 seconds]
lucaceresoli has joined #yocto
florian_kc has joined #yocto
g-Guest75 has joined #yocto
<g-Guest75>
Hello, the Yocto release info state that we can expect new LTS release in April 2022. Is there a more precise date known? Can we expect this release at the beginning or at the end of April?
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #yocto
<RP>
g-Guest75: see the weekly status reports on the list. First rc build is due at the start and QA/release takes around a week
<RP>
g-Guest75: if it took us 4 rc's it would be early may, one rc would be early april
<g-Guest75>
Great, thanks for info
<kayterina[m]>
which bitbake command creates the run.do_compile.xxx script for a recipe? I execute the compile script by hand to bypass the parsing of recipes
<RP>
kayterina[m]: it is done by bitbake <recipe>, there is no more specific command
<kayterina[m]>
a,ok. Is it maybe unrecommended to run the script by hand when testing? For a single change in code it saves a lot of time.
<RP>
kayterina[m]: for testing it is fine but it doesn't account for things like dependencies being present
<RP>
kayterina[m]: I guess more specifically, bitbake <recipe> -c compile
<kayterina[m]>
thanks
prabhakarlad has joined #yocto
otavio_ has quit [Remote host closed the connection]
otavio has joined #yocto
DaxTailor has joined #yocto
<sotaoverride>
sorry dont have my logging on, did someone tell me how I can get checksum for image artifacts, like is there a neat way of going about it in the image recipe? Pretty sure rburton taught me how thats done, but I forgot. The ref manual doesnt talk about it either.
<rburton>
just add .md5sum or whatever to the IMAGE_FSTYPES
<rburton>
eg ext4 ext4.md5sum
<sotaoverride>
nice! Thanks rbutron!
Bardon has joined #yocto
<DaxTailor>
Hello everyone.
<DaxTailor>
I broke my Yocto environment by renaming the parent directory from /opt2/phytec-yocto-imx8mm to /opt2/ee-helmholtz-phytec-yocto-imx8mm. Then I changed all configurations with the absolute path, deleted the build/tmp folder, after bitbake tolled me to do so. Now bitbake is starting but I get a lot of error messages and warnings. Is there
<DaxTailor>
anything I can do to make this working again? I did not expect that kind of problems by renaming the parent directory. (The reason I did this was to fit with our github repository naming convention.)
<DaxTailor>
Hopefully this can be fixed, otherwise I might have to install the bsp again.
<qschulz>
DaxTailor: remove everything except sstate-cache and downloads directories
<DaxTailor>
You mean everything in build?
<qschulz>
yup
<DaxTailor>
Ok, i try.
<Schlumpf>
Hi, I have a maybe simple question: I build one image for 2 slightly different machines. Now I have 2 config files in a recipe, one for the first machine and one for the other. How to tell bitbake to include only the correct config file?
<qschulz>
OR, you can use subdirectories: e.g. files/machine1/test.conf and files/machine2/test.conf and have SRC_URI += "file://test.conf" in your recipe
<g-Guest75>
or I believe you could just store the config file under the specific path in layer e.g. `recipe-name/files/machin1-name/config-1.cfg`
<DaxTailor>
@qschulz Now I get an error that workspace/conf/layer.conf can't be found.
mvlad has joined #yocto
<DaxTailor>
Now its starting again, created layer.conf as empty file.
<DaxTailor>
Thank you very much, is it building mow without errors.
<qschulz>
DaxTailor: remove workspace from your conf/bblayers.conf
<qschulz>
(which means you probably didn't remove everything in buikd :) )
<qschulz>
DaxTailor: have fun :)
<Schlumpf>
qschulz g-Guest75 many thanks
<ernstp>
Schlumpf: a trick i use sometimes is to add a SRC_URI "file://doesnt-exist" and then in the error message you can see a long list of all the paths Yocto searched for the file, in order of prio
<g-Guest75>
Or you can go to WORKDIR of given recipe and check latest do_fetch.log file - the paths should be there also
<qschulz>
ernstp: bitbake-getvar FILESPATH will return this without requiring the trick :)
<qschulz>
actually, re-reading my own notes, that might not be enough
<RP>
hhm, perhaps bitbake-worker shouldn't use stdout as pickled event data
<sotaoverride>
could someone link me the yocto variable lists please? Or just tell me what the varaible for the /etc dir would be. I know theres the ${D}/..., not sure if there's one for /etc
<rburton>
bitbake.conf has the main variables
<rburton>
in
<rburton>
you want ${sysconfdir}
<sotaoverride>
so ${D}/${syscondir} ?
<rburton>
${D}${sysconfdir}, no need for an extra slash really
<sotaoverride>
cool. thanks again rburton!
Guest7483 has joined #yocto
Guest7483 is now known as Jurgen
<rburton>
huh sysconfdir etc are not in the variable glossery
<rfs613>
sakoman: for dunfell version of CVE-2022-0778 (openssl), I'm guessing you'd prefer just a backport of the fix, rather than version bump of openssl 1.1.1l -> 1.1.1n ?
<RP>
rfs613: I suspect we would be ok with bumping the version for openssl
<RP>
rfs613: it is effectively a stable release
<sakoman>
rfs613: yes, if bug/security fix release version bump is fine
<rfs613>
ok, in that case, we'd remove the previously backported fix for CVE-2021-4160
<sakoman>
rfs613: yes
<RP>
sakoman: was there a problem bumping the version last time?
<cb5r>
JPEW: alrighty - then enjoy!
* rfs613
wondered that as well
<rfs613>
the previous CVE-2021-4160 was fixed in 1.1.1m (although the CVE is not mentioned in the commit)
<sakoman>
rfs613: quite a few in 1.1.1n too! But they all seem to be fixes, so version bump is fine
jmiehe has joined #yocto
<qschulz>
RP: michaelo: ndec: I think i'll be hated for this idea but I thought about ONLY having the latest migration guide in a given release. e.g. 3.5 migration guide only in 3.5 release. Then it's gone for 3.6 release (which will have its own 3.6 migration guide). This allows to keep links to appropriate bitbake version and ref-manual of YP docs without having to make them verbatim once we remove the
<qschulz>
variables or rename them later on
<rfs613>
sakoman: okay, I'll prepare a patch for this
<qschulz>
don't know how much work is involved and all the small things I didn't think about
<sakoman>
rfs613: Thanks, I really appreciate it!
<Jurgen>
Hopefully I'm in right place, my sincere apologies if I'm not.
<Jurgen>
Regarding breakpad recipe - when I set the BREAKPAD_BIN variable, the .sym table generated is only for the binary without included libraries (missing symbols). Is there any elegant solution how to generate all .sym tables in binary and its dependencies?
<RP>
qschulz: trouble is that people will want to upgrade LTS to LTS so they will want other migration guides :/
<qschulz>
RP: it would be transparent to the user. We'd handle this from the build scripts
<qschulz>
and fetch the html pages from other releases
<qschulz>
I don't know how to explain it clearly
<qschulz>
nor do I have an implementation in mind
Jurgen has quit [Quit: Connection closed]
<RP>
qschulz: not sure how that would work though given the references are either in the manual or they're not :/
<cb5r>
Does anyone know the correct meta-rust branch for dunfell? bitbake is having trouble parsing the : syntax in both master and "test-dunfell" branches. I just saw that there is also rust-embedded/meta-rust-bin - can I just use that instead???
lucaceresoli_ has joined #yocto
lucaceresoli has quit [Quit: Leaving]
lucaceresoli_ has quit [Client Quit]
lucaceresoli has joined #yocto
<qschulz>
cb5r: it most likely means you're on an old dunfell reelase which does not support the new override syntax?
tre has quit [Remote host closed the connection]
<cb5r>
qschulz: Does the syntax change happen within dunfell release? Then it looks like it...
dev1990 has quit [Quit: Konversation terminated!]
<cb5r>
Which version is relevant for the override syntax support? bitbake?
<RP>
Nice, I can knock out 60 million of 225 million function calls from a "bitbake -p" for core
<RP>
That has to help...
<qschulz>
cb5r: latest releases of dunfell support both syntaxes
<qschulz>
cb5r: yes, bitbake is the relevant project to look for
<RP>
and that puts 3% of our parsing time in sha256
<qschulz>
RP: not too bad :)
<qschulz>
cb5r: it's anyway recommended you upgrade to the latest dot release when a new one is out
<qschulz>
security fixes, bug fixes
<qschulz>
etc...
<qschulz>
and here, brings support for the : override syntax
<RP>
224 of 300s in parsing is in finalize() :/
<cb5r>
qschulz: OK. My poky is on tags/yocto-3.1.7. So can I safely just switch to 3.1.14 then?
<qschulz>
cb5r: this upgrade is supposed to be painless yes, that's the point of dot/patch releases
<qschulz>
we're doing our best but bugs can still slip through
kanavin has quit [Remote host closed the connection]
<qschulz>
so let us know if something doesn't go as expected
<cb5r>
New territory for me here - thank you for the helps! :) I'll give it a try!
kanavin has joined #yocto
<RP>
yay, new perf worker went green
DaxTailor has quit [Quit: Client closed]
<qschulz>
RP: all workers I could find are using Sphinx v3.2.1... which puzzles me since there's support for Ubuntu 16.04 and 21.10 and I would xpect the versions to be different
<qschulz>
so I guess we've a fixed version of Sphinx somewhere in the autobuilder worker building script or whatever
<qschulz>
because I couldn't see anyting related to this in the run-docs-build script
<ndec>
qschulz: hey! iirc sphinx comes from $docs_buildtools. in other words something else to do :)
<qschulz>
ndec: true! I forgot that I commented out those lines to build it locally :D
<RP>
ndec: Perhaps we should merge a few more python modules to master? :)
<RP>
moto-timo: something else to fix? ^^^ :)
* RP
should find that branch
<ndec>
well having sphinx in core would make sense..
<qschulz>
ndec: could even use externalsrc to build the docs <3
<qschulz>
(not the externalsrc part that is exciting :) )
<moto-timo>
I remember looking at that... I forget what the state is... but I think it had a ton of dependencies
<moto-timo>
of course so did python3-cryptography
<RP>
moto-timo: I wonder how many we already merged now
<RP>
The bitbake parsing patches are in master-next if anyone wants to play with timing btw
<moto-timo>
RP: let me look for the branch (I hope I pushed it)
<qschulz>
ndec: although, not sure how it would work since we're building multiple versions of the same git repo :/
<RP>
moto-timo: I think I had the "latest" one as I built that tarball :/
<ndec>
qschulz: it's probably enough to be able to build the sdk with the right tools to build the docs. it would be an improvement already.
<moto-timo>
ndec: agreed
<qschulz>
ndec: right
<sielicki>
<vmeson> "sielicki: VIRTUAL-RUNTIME_syslog..." <- for future reference, this works but additionally requires `VIRTUAL-RUNTIME_base-utils-syslog = ""`
<sielicki>
i'd make a comment on that SO post if i had an account
<RP>
moto-timo: I found the patches I used and they appear to still parse...
<vmeson>
sielicki: if you prefer, just open a defect in the YP bugzilla for docs.
<sielicki>
I'd prefer to send a patch, I've been doing OE stuff for work for some time now and the only thing holding me back from contributing is that I'm generally inheriting massive debt that keeps me too far away from master to think about it.
<sielicki>
maybe this can get me on the right track
<sielicki>
OT but it doesn't help that work has some weird O365 plan that disables app passwords, which means I can't use SMTP/POP/IMAP, which means I can't send emails from my shell. /rant.
<qschulz>
sielicki: if that can help, the mail address you use to send the patch is not seen in the patch once applied
<qschulz>
so you could send mails from a temporary mail address if need be
<qschulz>
(i'm sending with my personal address for example, but the author of the patch is my company address
<qschulz>
(i have damned O365 too, with MFA and couldn't be bothered to set it up for git send-email :) )
<sielicki>
oh good call, I didn't consider that was possible. I'll give that a shot.
Werner has joined #yocto
Werner has left #yocto [Leaving]
<RP>
Saur[m]: can I tempt you into timing bitbake -p of the bitbake patches in master-next, see if they each improve things much for you?
amitk has quit [Ping timeout: 256 seconds]
_whitelogger has joined #yocto
<RP>
moto-timo: yes, correct
<moto-timo>
RP: so we can't declare minimum 3.7 for kirkstone I'm guessing
<RP>
moto-timo: I'd rather not at this point
<moto-timo>
RP: fair enough
* moto-timo
worn out from all the changes as well
<RP>
moto-timo, ndec: sphinx needs requests which needs pyopenssl which needs python3-cryptography which fails to build in nativesdk form
<RP>
rust issues
<moto-timo>
sigh
<moto-timo>
yeah, we can only build setuptools_rust native right now
<RP>
moto-timo: my thoughts aren't printable
<moto-timo>
neither are mine
<moto-timo>
upstream sure does make our lives interesting
<RP>
moto-timo: we're not building for target so this should work. I think the problem is more nativesdk rust
<RP>
Could not find specification for target "x86_64-pokysdk-linux"
<moto-timo>
RP: ah right... MOAR KOFFEEE
<moto-timo>
that whole "specification" thing is a mess in rust
<moto-timo>
shadows of all the hoops we had to do for sysconfig for python
<sielicki>
many more to come, just give me a few more weeks to move us off thud
<vmeson>
sielicki: It's great to see new contributors. Thanks!! (ugh thud is so old! ;-) )
<sielicki>
we actively cut releases for things on dora.
<sielicki>
can I get a vibe for what people are doing to manage build directories nowadays? Previously I've used android's repo tool, I know KAS is a thing, and we have a mess of shell scripts. Is KAS considered best practice at this point?
<rburton>
kas is certainly a good option
<vmeson>
sielicki: I think it's a holy war like editors. We (Wind River) use a wrapper for repo, others use kas.
<rburton>
kas is more 'fire-and-forget' in that it does the fetch and build. its less optimal for interactive builds.
<sielicki>
the thing I liked about repo was that it was bare and uncontainerized, and didn't stop me from using devtool actively. That's my main concern with kas is that it's going to get in the way of an upstream-style workflow.
<sielicki>
I haven't looked enough at kas to understand if it strictly builds within a container or if it can just handle the bare clone for you.
<sielicki>
Seems to me like their mechanism for local.conf injection is somewhat reimplementing multiconfig
<qschulz>
sielicki: you have kas containers but it's not part of kas per se
tnovotny has quit [Quit: Leaving]
<qschulz>
python3 -m pip install kas (or something similar_ should do the trick
<smurray>
I couldn't find a way to not have kas overwrite the .conf files with 'kas checkout' last time I played with it, is there some magic to avoid that so oe-init-build-env will work w/o going and rm'ing stuff?
tlhonmey has joined #yocto
<rburton>
you can get kas to fetch and setup a build directory that you can then build stuff with manually
<rburton>
RP: should we rename flit_core.bbclass to python_flit_core?
<RP>
rburton: yes
<rburton>
i'll do that whilst I <cough> have some related changes
<RP>
rburton: I don't want to know :/
<rburton>
they're good!
fabatera[m] has joined #yocto
<rburton>
the class rename is by far the most invasive one
florian_kc has quit [Ping timeout: 240 seconds]
<moto-timo>
they are good changes and simple
<moto-timo>
But I’m not sure I have a leg to stand on 😂
florian has quit [Quit: Ex-Chat]
<moto-timo>
And what about setuptools_build_meta? Although the name is already long…
<Saur[m]>
RP: I'll definitely give your parsing patches some testing. :)
<RP>
moto-timo: I'm very much in favour of namespacing these
<moto-timo>
RP: I am fine with that
<rburton>
i can see in the medium term the setuptools classes reducing down to legacy and modern, with the current setuptools being gone and the build_meta replacing it
<moto-timo>
RP: and the fall out in meta-python is still rather small atm. good time to fix up
<alejandrohs>
downloads.yoctoproject.org is unusually slow for me, is anyone else having this problem?
<moto-timo>
rburton: I had a half-baked idea of just using build_meta everywhere... but then we found the other setup.py corner cases and I dropped the concept for now
<moto-timo>
rburton: and I didn't want to generate pyproject.toml... already better that we dropped all my do_configure hacks
mckoan is now known as mckoan|away
Belgarion has joined #yocto
* moto-timo
wonders where we'll be in a year after more upstream melding
Schlumpf has quit [Ping timeout: 256 seconds]
* RP
is finding nativesdk rust is entirely missing
<RP>
vmeson: why am I being sucked into fixing this :(
<RP>
hmm, nativesdk-python3-cryptography just built
* RP
suspects that shouldn't have worked
<rburton>
probably!
<RP>
rburton: I'll let you try and arm sdk version of this ;-)
<rburton>
moto-timo: do you know any setuptools_build_meta recipes that build C extensions?
MiguelH has joined #yocto
<moto-timo>
rburton: very quick search showed python3-lz4 in meta-python
* moto-timo
wishes for a magic tool to tell us this
<rburton>
thought might be worth triple checking they're built properly
<rburton>
oe-pkgdata-util should be able to tell, ish
<moto-timo>
after the fact... I mean more like a pypi.org query but I also want a pony
<MiguelH>
Hey, is anyone else experiencing a huge degradation downloading from downloads.yoctoproject.org? I have attempted two different machines in different networks/IPS and both can only reach 40kps.
<MiguelH>
I'm not even using it directly, it gets there from PREMIRRORS/MIRRORS, and it seems override that is a major PITA.
<rburton>
moto-timo: gonna make lz4 install the tests so we can exercise binary generation
<moto-timo>
rburton: yeah, I think we need more ptest enabled for c-extension recipes... hopefully that is a small subset
<moto-timo>
(vs. boiling the entire meta-python ptest ocean)
<moto-timo>
it's been on my list for too long :/
* moto-timo
sees recipetool helping with that in 4.1
<rfs613>
fabatera[m]: you need to set a specific git SHA hash in SRCREV, so the fetcher knows which version to take. If you want the 'latest on branch' you can use SRCREV = "${AUTOREV}"
florian_kc has joined #yocto
manuel1985 has quit [Ping timeout: 240 seconds]
<moto-timo>
AUTOREV is only recommended for development... it forces a fetch/reparse every single time
<moto-timo>
SRCREV is the way to go
<vmeson>
RP, I missed the librsvg nativesdk problem and no one created a defect. I'm doing build and see what's wrong.
<RP>
vmeson: I have nativesdk fixes in my branch
<vmeson>
RP, ah good. Sorry that I missed the email/problem.
<RP>
moto-timo: based on rburton's buildtools-tarball tests, we have automated tests of the sphinx docs build in the SDK :)
<moto-timo>
RP that is rather nice
<RP>
It doesn't quite build cleanly but I think I need to upgrade sphinx. Now I know how to test it :)
<moto-timo>
I made a branch with your changes... just so I have a starting point
<moto-timo>
not that I have a tonne of time to work on this today
<kanavin>
"QEMU 7.0 adds a "-display dbus" option for exporting the display for external processes with a gtk4-rs Rust-based GTK4 viewer in the works for a future version of GNOME Boxes and virt-viewer.
<kanavin>
"
<kanavin>
nice, maybe we can drop all those awkward sdl-native/gtk-native builds at some point
<kanavin>
and just use the viewer from the host distro
<moto-timo>
nice
<RP>
kanavin: when all the hosts have a gtk4 viewer :)
<kanavin>
I guess it also nicely sidesteps the question of adding gtk4 and wayland support to qemu
<RP>
kanavin: I can see the attraction
<moto-timo>
old hosts... sigh... the gift that keeps on giving and giving and giving
<kanavin>
RP: you know me, I would drop sdl support long before that :)
* moto-timo
forced to install a bare metal Ubuntu 18.04 for NVidia tools
<moto-timo>
VM is not good enough
<RP>
moto-timo: as a warning, there are unqualified BSD licence fields in that series
<moto-timo>
recipe quality disparity rears its ugly head again
mvlad has quit [Remote host closed the connection]
<moto-timo>
and of course patchtest would only catch new recipes/patches... so we probably need to run some checks on meta-openembedded (like HOMEPAGE)
<RP>
moto-timo: well, these aren't from meta-oe, they're new recipes that were never put anywhere
<moto-timo>
RP: ah right, from armpit
<RP>
moto-timo: I'm trying to see if I can get the up to date
<armpit>
wakes up
<RP>
armpit: brought some of your patches back from the dead
<armpit>
recipe-zombes
florian_kc has quit [Ping timeout: 240 seconds]
<RP>
moto-timo: I've updated the branch with upgrades for sphinx, htmlhelp and seralizinghtml
<RP>
moto-timo: testsdk then passes :)
<moto-timo>
RP: that is great news
MiguelH has quit [Ping timeout: 256 seconds]
<RP>
moto-timo: I suspect we have the BSD license issue, HOMEPAGE, maintainers and then on to things like reproducibility
<moto-timo>
khem: the failure should have happened long ago... python3-kiwisolver 1.3.2 was still using old distutils (which cannot be built as wheels). Curious why it only showed up now.
<khem>
1.4.0 still has same problem
<rburton>
khem: using build_meta is the right thing to do, alternatively manually add a depends on python3-pip-native
<khem>
yeah I was coming to same conclusion. thanks for confirming
<moto-timo>
khem: it needs a DEPENDS on setuptools-scm-native
<moto-timo>
and then hacked most of the result away and only kept the SRC_URI for the crates
<moto-timo>
this will need to get incorporated into core and devtool/recipetool in the next release cycle
<khem>
yeah agreed cargo bitbake is useful
<moto-timo>
ideally we need it to run during devtool upgrade so the AUH checks the crates
jmiehe has joined #yocto
goliath has joined #yocto
<moto-timo>
I also have a maturin recipe but we don't have anything I'm aware of that needs it yet... I want to wait until we do and see what a maturin.bbclass would look like
<moto-timo>
if someone has a use case I am happy to run with it
<moto-timo>
I thought about submitting maturin to meta-oe... it's capable of building crates and python with rust extensions... so it wasn't obvious if it should go into meta-python or meta-oe or some other layer
florian_kc has quit [Ping timeout: 240 seconds]
<RP>
moto-timo: I've updated master-next with maintainers and homepage fixes
<RP>
moto-timo: I'm handing off to abelloni to run a test build
<RP>
moto-timo: I'm assuming you're ok to handle the fallout on the meta-oe side for this?
<moto-timo>
RP: aye aye. I am on board.
GNUmoon has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
florian_kc has joined #yocto
<Saur[m]>
RP: I have done some measurements on your three bitbake patches. The third patch (where you disable the logger) seems to be a clear win, while the jury is still out on the first two. This is with only poky on my slow computer at home.
<RP>
abelloni: Ive targeted your branch for a perf-debian11 run, lets see if we can see any performance difference with the bitbake patches
xmn has quit [Remote host closed the connection]
<RP>
Saur[m]: any kind of number for the real win in the third patch out of interest?
<RP>
Saur[m]: I was torn on the first two as well. The profile shows fewer function calls but it didn't seem to want to measure by wall clock
<Saur[m]>
I first averaged five parse runs, which indicated that the first patch was a small win while the second was a loss. Then I did the same with 20 parse runs, which indicated that both the first and second were losses...
xmn has joined #yocto
<Saur[m]>
In my first run, the average parsing time went from 54.5 s to 51.7 s with the third patch. In my second run it went from 54.0 s to 52.8 s.
<RP>
Saur[m]: hmm, right. Glad it wasn't just me then :)
<RP>
It definitely should be faster at least for the first one
<RP>
Saur[m]: thanks for testing
xmn has quit [Ping timeout: 256 seconds]
<Saur[m]>
Yes! I finally have remote access to work again after more than three weeks.
<abelloni>
RP: ah, my config took the master branch of bitbake
<abelloni>
let me fix that
<Saur[m]>
Hmm, we've had a couple of failures in our Jenkins builds with Honister lately that failed with: DEBUG: Executing shell function do_flush_pseudodb / server did not respond to shutdown query.
<RP>
abelloni: there are some patches in master-next of bitbake it would be good to test
<abelloni>
RP: I updated my branch it now contains them
<RP>
abelloni: great. It hasn't triggered yet so should pick them up
<RP>
abelloni: just wondering if we should restart the other build :/
<RP>
khem: did you ever have any follow up to ross' questions on the virtual/egl changes?
kevinrowland has joined #yocto
codavi has quit [Ping timeout: 245 seconds]
ak77 has quit [Ping timeout: 240 seconds]
florian_kc has quit [Ping timeout: 256 seconds]
yannd has quit [Remote host closed the connection]