alimon has quit [Remote host closed the connection]
mckoan|away has quit [Ping timeout: 256 seconds]
jmiehe has quit [Quit: jmiehe]
alimon has joined #yocto
kevinrowland has quit [Ping timeout: 256 seconds]
lexano has quit [Ping timeout: 252 seconds]
lexano has joined #yocto
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #yocto
sakoman has joined #yocto
AKN has joined #yocto
mixfix41 has joined #yocto
mixfix41 has quit [Remote host closed the connection]
Guest2 has joined #yocto
<AKN>
Hi I trying to include hci_uart.ko in image.
<AKN>
Kernel 5.10
<AKN>
Bringing up the broadcom bluetooth module
Guest234 has joined #yocto
<Guest234>
ERROR: gstreamer1.0-1.16.2.imx-r0 do_unpack: gitsm: submodule unpack failed: UnpackError Unpack failure for URL: 'gitsm://gitlab.freedesktop.org/gstreamer/common.git;protocol=https;name=common;subpath=common;bareclone=1;nobr anch=1'. No up to date source found: clone directory not available or not up to date: /home/zmj031180/yocto/BSP-
<Guest234>
Yocto-FSL-i.MX8MP-PD21.1.3/build/downloads/git2/gitlab.freedesktop.org.gstreamer.common.git; shallow clone not a vailable: /home/zmj031180/yocto/BSP-Yocto-FSL-i.MX8MP-PD21.1.3/build/downloads/gitsmshallow_gitlab.freedesktop.o rg.gstreamer.common.git_bare_59cb678-1.tar.gz
<Guest234>
I reported this error in bitmake phytec-qt5demo-image. What's going on?
mckoan|away has joined #yocto
<Guest234>
I reported this error in bitbake phytec-qt5demo-image. What's going on?
Guest2 has quit [Ping timeout: 256 seconds]
<Guest234>
ERROR: gstreamer1.0-1.16.2.imx-r0 do_unpack: gitsm: submodule unpack failed: UnpackError Unpack failure for URL: 'gitsm://gitlab.freedesktop.org/gstreamer/common.git;protocol=https;name=common;subpath=common;bareclone=1;nobr anch=1'. No up to date source found: clone directory not available or not up to date: /home/zmj031180/yocto/BSP-
<Guest234>
Yocto-FSL-i.MX8MP-PD21.1.3/build/downloads/git2/gitlab.freedesktop.org.gstreamer.common.git; shallow clone not a vailable: /home/zmj031180/yocto/BSP-Yocto-FSL-i.MX8MP-PD21.1.3/build/downloads/gitsmshallow_gitlab.freedesktop.o rg.gstreamer.common.git_bare_59cb678-1.tar.gz
<Guest234>
ERROR: gstreamer1.0-1.16.2.imx-r0 do_unpack: Unpack failure for URL: 'gitsm://gitlab.freedesktop.org/gstreamer/c ommon.git;protocol=https;name=common;subpath=common;bareclone=1;nobranch=1'. No up to date source found: clone d irectory not available or not up to date: /home/zmj031180/yocto/BSP-Yocto-FSL-i.MX8MP-PD21.1.3/build/downloads/g
<Guest234>
it2/gitlab.freedesktop.org.gstreamer.common.git; shallow clone not available: /home/zmj031180/yocto/BSP-Yocto-FS L-i.MX8MP-PD21.1.3/build/downloads/gitsmshallow_gitlab.freedesktop.org.gstreamer.common.git_bare_59cb678-1.tar.g z
<Guest234>
ERROR: Logfile of failure stored in: /home/zmj031180/yocto/BSP-Yocto-FSL-i.MX8MP-PD21.1.3/build/tmp/work/aarch64 -phytec-linux/gstreamer1.0/1.16.2.imx-r0/temp/log.do_unpack.11082
<Guest234>
ERROR: Task (/home/zmj031180/yocto/BSP-Yocto-FSL-i.MX8MP-PD21.1.3/sources/poky/../poky/meta/recipes-multimedia/g streamer/gstreamer1.0_1.16.2.bb:do_unpack) failed with exit code '1'
mixfix41 has joined #yocto
goliath has quit [Quit: SIGSEGV]
Guest234 has quit [Quit: Ping timeout (120 seconds)]
jclsn0 has joined #yocto
jclsn has quit [Ping timeout: 256 seconds]
AKN has quit [Read error: Connection reset by peer]
amitk has joined #yocto
Guest2 has joined #yocto
sakoman has quit [Quit: Leaving.]
AKN has joined #yocto
Guest2 has quit [Quit: Ping timeout (120 seconds)]
mihai has joined #yocto
<mihai>
good morning
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
g-Guest75 has quit [Quit: Client closed]
pgowda_ has joined #yocto
GNUmoon has quit [Ping timeout: 240 seconds]
<jclsn0>
Good morning
jclsn0 is now known as jclsn
<jclsn>
So I really can't seem to find out why bitbake and devtool are producing different kernels.
<jclsn>
Any other ideas?
<jclsn>
Else I would just rollback the kernel and try to apply the patches with devtool instead of creating my own kernel branch
<jclsn>
See if that makes a difference
<jclsn>
But I would rather find the cause actually
<jclsn>
This is really a weird error
selff has joined #yocto
vladest has quit [Quit: vladest]
<selff>
hello everyone. on the yocto side, after writing an image to the sd card, i have space equal to the size of the written image, i cannot use the remaining free space. how can i auto-extend? for example, i have 16gb sd card, image is 800mb. after writing the image, i cannot use the remaining 15.2gb.
vladest has joined #yocto
selff has quit [Ping timeout: 256 seconds]
frieder has joined #yocto
GNUmoon has joined #yocto
selff has joined #yocto
<rburton>
Selff if you use wic then it can expand a specified partition
<jclsn>
Actually devtool is not the issue, but the difference is when I check out a workspace
<jclsn>
They don't occur when I build without a local workspace. So it seems that another poky version is used when I check out the kernel, because these errors should have already been fixed says RP
lucaceresoli has joined #yocto
<mckoan>
selff: see IMAGE_ROOTFS_EXTRA_SPACE
<jclsn>
I will drive to the company soon, set up another host to build on and see if that makes a difference. I am at a point where I can only guess why I am getting these kernel runtime errors
cb5r has joined #yocto
<jclsn>
Ah yeah btw, when I do a devtool reset linux-fslc-imx and build again, I get these errors https://pastebin.com/EL71B8Uu
<jclsn>
So somehow the kernel versions must be different
<jclsn>
Do they not?
<jclsn>
:q!
<selff>
rburton i will check, ty.
<selff>
mckoan i saw that but i need auto-expand.
<selff>
mckoan we can give only a certain percentage or value for IMAGE_ROOTFS_EXTRA_SPACE.
<selff>
rburton i found it, ty so much.
<mckoan>
selff: postinstall auto-expand is more complicated ;-)
rob_w has joined #yocto
<RP>
jclsn: I suspect the configuration of the kernel is different, not the kernel version
<jclsn>
RP: I diffed the defconfigs. They are the same
manuel1985 has joined #yocto
<RP>
jclsn: some kernel patch missing? Are there any kernel patches or is it a git tree?
<jclsn>
RP: It is our self-hosted git repository of linux-fslc with our patches applied on the custom branch
<jclsn>
Works for my two colleagues
<jclsn>
On my machine it fails
<mihai>
something is messing around with PV, "git999" is not "natural" :)
<RP>
jclsn: but only after devtool?
<jclsn>
RP: No runtime failure occurs with normal bitbake build
<jclsn>
When I checkout with devtool modify and build from that workspace, the resulting kernel boots fine
<RP>
jclsn: you need to work out what the difference is between the two configurations, then you'll have some idea of the difference you're looking for in the two build paths
xmn has quit [Ping timeout: 256 seconds]
jmiehe has joined #yocto
Schlumpf has joined #yocto
<kayterina[m]>
can an image be build with libc and have parts of it built with musl?
leon-anavi has joined #yocto
<RP>
kayterina[m]: not without games with multiconfig currently
<kayterina[m]>
How serious games? I have a recipe that wants staticly linked libraries and uses musl. If I bitbake mc:musl that recipe can I include that in final image, perhaps by adding it to a do_install()?
<qschulz>
kayterina[m]: with multiconfig, you can add images/binaries from other configs into the final image
florian has joined #yocto
<kayterina[m]>
α,οκ, i'll look into that then.
tre has joined #yocto
selff has quit [Ping timeout: 256 seconds]
<mckoan>
I'm trying to modify weston.ini but my weston-init.bbappend is completely ignored, do you have any hint about weston.ini customization? Is there any special build, maybe using a class or somehow?
<rburton>
check bitbake-layers show-appends to verify your append is actually being used
<mckoan>
rburton: my recipe is taken into account and I can see that declaring a task do_display_banner()
<mckoan>
moreover, even if I modify directly the original meta/recipes-graphics/wayland/weston-init/weston.ini my changes are ignored
<hmw[m]>
Hi, im tring to migrat from a other yocto branche to dunfell but when i run my application that requires mysql the qt application chrashes on
<hmw[m]>
db = QSqlDatabase::addDatabase("QMYSQL", name);
tgamblin has quit [Ping timeout: 240 seconds]
tgamblin has joined #yocto
tangofoxtrot has quit [Ping timeout: 260 seconds]
tre has quit [Remote host closed the connection]
tangofoxtrot has joined #yocto
<kayterina[m]>
I get a yocto note saying it deferrs a recipe to the same recipe?
<kayterina[m]>
"NOTE: Deferring mc:musl:/home/katerina/project/sources/poky/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_package after /home/katerina/project/sources/poky/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_package"
paulbarker has quit [Quit: Connection closed for inactivity]
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #yocto
<RP>
kayterina[m]: note the mc:musl: at the start
<kayterina[m]>
ouch. didn't see it. It says that it will not use mc for that recipe?
mvlad has joined #yocto
<kayterina[m]>
*musl
<RP>
kayterina[m]: it appears to be building the "normal" config version and a "musl" multiconfig version of it
<kayterina[m]>
RP: and how come it only does the do_package ?
<RP>
kayterina[m]: they might be the same thing which is why it is deferring it, I can't tell from the log
<kayterina[m]>
ok.
<RP>
qschulz: have some fun changes in master-next which add all the sphinx dependencies and then a docs-tarball recipe, complete with a test
<RP>
qschulz: if this comes together we can upgrade to sphinx 4.4 on the autobuilders
BobPungartnik has joined #yocto
BobPungartnik has quit [Client Quit]
<qschulz>
RP: nice! looking forward to it and the patches I'll need to send for the docs :D
cb5r[m] has joined #yocto
<barometz>
Downloads from http://downloads.yoctoproject.org/mirror/sources/ from at least two locations in .nl are <100K/s right now (and have been for a day or so, if our build stalls are any indication). Is this a known problem and/or is there anything I/we can do to help figure out what's up?
<RP>
barometz: our admin is sleeping atm, ask again in around 4 hours
<barometz>
will do :)
cb5r has quit [Quit: cb5r]
cb5r[m] is now known as cb5r
cb5r has quit [Quit: Reconnecting]
cb5r has joined #yocto
* RP
tries to remember what he was doing before docs recipes
selff has joined #yocto
<qschulz>
RP: optimizing the function calls?
<qschulz>
you were asking people to test one of your branches for speed-ups
<selff>
i asked something about image auto extend and a friend helped me. who was he/she?
<RP>
qschulz: right! I wonder what other ideas I was thinking of :)
<selff>
It works, but the 128gb sd card was only able to expand up to 60gb. why couldn't it expand the rest?
manuel1985 has quit [Ping timeout: 256 seconds]
selff has quit [Quit: Client closed]
codavi has joined #yocto
jclsn[m] has joined #yocto
<jclsn[m]>
RP: That is what I was trying, but I have no clue
<jclsn[m]>
Been searching for three days
<jclsn[m]>
I also don't think that both approaches should yield the same kernel build
<jclsn[m]>
I mean this is what you use Yocto for: You get a reproducible build no matter on what you build it on. Especially when you use Docker containers.
<jclsn[m]>
So it makes absolutely no sense to me why my colleagues can build fine and I am getting errors.
goliath has joined #yocto
ar__ has joined #yocto
codavi has quit [Ping timeout: 256 seconds]
manuel1985 has joined #yocto
lucaceresoli has quit [Remote host closed the connection]
lucaceresoli has joined #yocto
<RP>
jclsn[m]: it doesn't make sense and would be nice to get to the bottom of it
<RP>
we do want to be reproducible
<jclsn[m]>
I know
<jclsn[m]>
I am currently building on another machine with the same tooling
<jclsn[m]>
But fetching binutils is taking forever
<qschulz>
jclsn[m]: just copy the downloads directory
<qschulz>
RP: a bunch of your patches for sphinx are missing your SoB
<jclsn[m]>
qschulz: I deleted it on both
<jclsn[m]>
I've deleted 20+ times in the last three days to make sure that there is a fresh build every time
<RP>
qschulz: ah, I'll fix that, thanks
<jclsn[m]>
But always this kernel panic
sakoman has joined #yocto
AKN has quit [Read error: Connection reset by peer]
florian has quit [Quit: Ex-Chat]
pgowda_ has quit [Quit: Connection closed for inactivity]
hcg has joined #yocto
rob_w has quit [Remote host closed the connection]
<hcg>
I wonder if anyone can help me - I am migrating to the honister release and for some reason all -dev packages are being included in my image, but they were not in our dunfell release. Is there a subtle behaviour change I may have missed?
<RP>
hcg: probably some recipe has broken packaging or dependencies and it is pulling in a long chain of them
<rburton>
hcg: 'packagegroup-devtools' isn't part of core and sounds like it might pull in -dev packages, is that yours?
<rburton>
the key line is 'NOTE: Installing the following packages:', that's the list of everything its being told to install explicitly
<rburton>
it then installs a load of -dev
<rburton>
so one of those is depending on at least one -dev, which pulls in more
<hcg>
That is ours, but it does not pull in the -dev packages. At the moment our production is running on dunfell and none of the -dev packages are installed there.
<rburton>
well one of that list is.
<rburton>
bitbake package-index and you can read the package index by hand
alimon has quit [Remote host closed the connection]
Guma has joined #yocto
alimon has joined #yocto
xmn has joined #yocto
AKN has quit [Read error: Connection reset by peer]
<RP>
wow, libtool 2.4.7 just released
<cb5r>
After I added something to DISTRO_FEATURES - how does the change get applied? If I just rerun I still get a "not in DISTRO_FEATURES" error :/
florian_kc has joined #yocto
<barometz>
Downloads from http://downloads.yoctoproject.org/mirror/sources/ from at least two locations in .nl are <100K/s right now (and have been for a day or so, if our build stalls are any indication). Is this a known problem and/or is there anything I/we can do to help figure out what's up?
<barometz>
(repeat from earlier, but I did check and my download of binutils that I started around that time is still going)
<khem>
RP: the egl replies were in my todo, done now
<khem>
does new libtool have sysroot support ?
<RP>
khem: it does not have our fixes. I did submit them and I'm hoping the maintainer will get there next
<RP>
khem: thanks, now we need rburton :)
<rburton>
cb5r: how did you add?
<RP>
khem: the libtool maintainer wanted to get a release out first, then look at new patches
<hcg>
rburton: sorry, I had to attend a meeting - that packagegroup-devtools pulls in 'opkg nano htop mountdebugfs' only - I will assume that maybe one of our recipes is broken so I will try creating an image which does not install any of our stuff and see if it is still installing -dev packages
<rburton>
yeah, core-image-minimal will demonstrate if its your images/deps or some distro config
Minvera has joined #yocto
<cb5r>
rburton: I added the following to my meta-device/conf/distro/wayland.conf: DISTRO_FEATURES_append = " x11 gobject-introspection-data"
<rburton>
presumably you're using a release which uses _ as the override
<cb5r>
(Context: I have a wayland based dunfell build and would like to include squeekboard into it. But apparently it requires gnome3 and x11 for some reason)
<rburton>
and you've DISTRO=wayland
<rburton>
bitbake recipe-which-breaks -e | less, search for DISTRO_FEATURES=
<rburton>
scroll up and you'll see how the value is generated
<rburton>
sqeekboard is very much wayland-specific
<rburton>
so it won't be asking you to enable x11
<rburton>
a dependency of it might, i guess
<cb5r>
I have poky on the "dunfell" branch (latest commits)
<landgraf>
is there am argument like "exit on first failed test" for oe-selftest ?
<RP>
landgraf: I don't think so
StayLearning[m] has quit [Quit: You have been kicked for being idle]
<RP>
hmm, I wonder where I put that libtool experiment branch I had :/
<cb5r>
rburton: I was quite suprised to see that it wants x11 as well... The only match I get from your command is this: NOTE: Set DISTRO_VERSION='dunfell-12.0-19-g7fcf58d' for distro guf-wayland (matches tags with dunfell[-/]*)
<rburton>
bitbake -e [recipename]?
<rburton>
you'll get *pages* of output
manuel1985 has quit [Ping timeout: 250 seconds]
<vmeson>
go-1.18 for 3.5 ?... is anyone working on it? https://go.dev/doc/devel/release#go1.18 The main advantage aside from 1.18 features is that support would be supported for a bit longer.
* vmeson
is not a goer...
<cb5r>
rburton: Woops - my bad. It looks to me as if the .conf file is not parsed again. I see the values that are set in the conf file but DISTRO_FEATURES is missing my latest append edit
florian_kc has quit [Ping timeout: 250 seconds]
<rburton>
then its not being used at all
<cb5r>
you mean I basically edited the wrong conf file?
Guma has quit [Ping timeout: 240 seconds]
<rburton>
yes
<cb5r>
The INCLUDE HISTORY at the beginning of the output shows that file though ?_?
<rburton>
did you save it? :)
<cb5r>
definitely, multiple times :D
<cb5r>
Ah I see that the two things I am trying to add are both removed prior to my append... I guess the remove wins +.+
<rburton>
yes, remove wins
<rburton>
this is why -e is so useful
<cb5r>
Very nice "trick"! Thank you :)
* cb5r
is happy because it's building now
<abelloni>
or bitbake-getvar once you upgrade
<abelloni>
my recommendation is usually to avoid _remove
Guma has joined #yocto
<kergoth>
in the cases where _remove is needed, at least use an intermediate variable which could be altered. FOO_remove = "${FOO_REMOVE}"; FOO_REMOVE ?= "bar"; then you can set FOO_REMOVE = "" or even FOO_REMOVE_remove in a later file if needed
<rburton>
RP: crypto-vectors sent
<RP>
khem: I just pushed the flit changes to master so meta-oe can be updated too
<RP>
rburton: thanks!
* RP
needs to sort the other fix :/
<khem>
yeah thanks
<khem>
somehow github is acting today have thrown me off cliff all morning
Schlumpf has quit [Quit: Client closed]
<hcg>
rburton: I have identified a recipe which appears to be broken. If I comment that particular recipe out of my build, I see no -dev packages, and uncomment it and the -dev packages reappear. The recipe is actually from the meta-ti layer and I guess a hint that is is not going to misbehave is INSANE_SKIP:${PN} += "already-stripped dev-deps"
<rburton>
i'd use honister of meta-ti then, in case crossing the streams is the problem
<rburton>
but if you've isolated a recipe, tell the meta-ti owners
<rburton>
bonus points for replicating with just core-image-minimal + this recipe
<hcg>
meta-ti actually does not have a honister branch - the latest they have are dunfell-next and then master
Guma has quit [Quit: Good Night Everyone...]
<hcg>
the master branch has the overrides update in it, so it builds with honister
<khem>
prebuilts hell 🙂
<RP>
abelloni: I've sent the other pyc workaround so we're probably good for another build with rburton's fixes
<abelloni>
sure, I4ll get that going soon
manuel1985 has joined #yocto
xmn has quit [Quit: xmn]
<qschulz>
halstead: greetings! We've got some people complaining about slow downloads.yoctoproject.org. barometz here publicly at least
frieder has quit [Remote host closed the connection]
<qschulz>
I had my two last builds stuck on linux-yocto and glibc downloads for a few hours (not sure it uses those mirrors from the logs)
<halstead>
qschulz: The public sstate traffic is competting with downloads traffic and filling the pipe.
<halstead>
RP: Should I prioritize downloads.yoctoproject.org over sstate.yoctoproject.org ?
<qschulz>
halstead: oooooh nice dilemma :)
<khem>
halstead git-pw sometimes fetches same patch in series for two different patch numbers
<RP>
halstead: Probably, yes
<RP>
halstead: are we generating that much sstate traffic? :/
<halstead>
RP: It appears so. I can pull stats.
<RP>
halstead: prioritise the downloads
<halstead>
khem: I'm not sure how to help with that. Do you have a suggestion?
<barometz>
for what it's worth this has gotten us to consider setting up a local mirror, so maybe occasional slowness has its benefits (they said, half kidding)
<qschulz>
halstead: RP: highlights I should really start working on setting up my own mirror, shared sstate and hashserv instead of having my CI do everything from scratch every time.
<qschulz>
barometz: I see we had the same thoughts :)
<RP>
kergoth: I did try an "isupper" approach but that fails with prefix, bindir and friends
<kergoth>
Hmm. I was thinking about checking globals() and/or __builtins__ and our bb evaluation context, to at least avoid the hardcoded list
<kergoth>
wouldn't need to check eval context, those should return values, not raise keyerrors
<kergoth>
My only concern with that would be performance of assembling that list..
<kergoth>
RP: ^
<kergoth>
I wouldn't go based on case, that won't do
* kergoth
shrugs
<RP>
kergoth: right, I used the list as it handled the majority of the pain points but it is horrible :/
<kergoth>
The idea here is just to avoid unnecessary datasmart getvars yeah?
<RP>
kergoth: yes. They're fast but obviously skipping them is faster :)
<Belgarion>
halstead: is downloads.yoctoproject.org blocking certain ip blocks? i've noticed that all connection attempts from machines on our new ip block times out, while machines still on the old ip block is able to connect
<halstead>
Belgarion: We've received a few reports of this. We are not denying any IP blocks on purpose. Can you email it-coreprojects-helpdesk@linuxfoundation.org with information about your IP block, a traceroute and any logs you think might be helpful?
<RP>
kergoth: I'm trying to figure out what the real performance bottlenecks are and this was noise but noise I thought we should stop entirely
<kergoth>
I'm actually wondering now how often folks *use* the ability to look up variables with bare words in inline python :)
<RP>
kergoth: disabling it finds the uses on core :)
<kergoth>
The intention was to make it less verbose and more readable, but that's less of an issue now that we don't have to pass ", True" all the damn time
<RP>
kergoth: I did wonder if we should remove it but torn on that
<kergoth>
Yeah.. not sure. I still rather like it when reading the code. But it's another case of us having multiple ways to do things and folks don't know what to use, too
<kergoth>
Tough call
<RP>
kergoth: something to think about, I proposed the list as a compromise for now...
<halstead>
Belgarion: may I PM you to collect some data in real time?
<Belgarion>
sure
<kergoth>
RP: capturing the __builtins__ at class definition time probably wouldn't be a bad way to go, that at least isn't going to change much. Then add os/bb/oe as explicit exceptions
mckoan is now known as mckoan|away
<kergoth>
RP: avoids the issue of *when* to capture globals() since it changes due to imports
* kergoth
shrugs
amitk has quit [Ping timeout: 240 seconds]
<kergoth>
__builtins__ having int, etc.
<kergoth>
i.e. builtins = dir(__builtins__) in the class definition, then explicitly add the xceptions to it, and check that in __missing__
<kergoth>
RP: should also conisder removing those items from execs
manuel1985 has quit [Ping timeout: 252 seconds]
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
nateglims has joined #yocto
<nateglims>
If I add a license to a software layer and run 'yocto-check-layer', it complains about changing the signature of other software. Is that expected?
florian_kc has joined #yocto
manuel1985 has joined #yocto
Tokamak has quit [Ping timeout: 240 seconds]
Tokamak has joined #yocto
prabhakarlad has quit [Quit: Client closed]
hcg has quit [Quit: Client closed]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cb5r>
I switched poky tag from 3.1.7 to 3.1.14 and now poky/meta/recipes-core/kbd/kbd_2.2.0.bb fails to build. Might this be due to a clean working build directory now? Do I have to purge everything and start a clean build or what is the fastest way to (hopefully) fix this?
Tokamak has joined #yocto
<RP>
kergoth: that does sound like a reasonable idea. Fancy sending a patch? :)
nateglims has quit [Quit: Client closed]
<khem>
hmmm ssh to qemu is not working today anything interesting changed in master-next ?
Minvera has quit [Remote host closed the connection]
<RP>
khem: shouldn't have done and AB tests are ok
<RP>
sakoman: I just added more debugging for the tinfoil event issue
<RP>
abelloni: I sent that libtool patch in the hope we can put it through some testing, see how things look with it
<khem>
RP: this is qemuriscv 🙂
<RP>
khem: I wish we had that on the AB :/
nateglims has joined #yocto
<khem>
but it was working ok couple of days back
<khem>
so I am hoping to figure it out since its not such a long time
<khem>
it could also be some env issue
<RP>
khem: that narrows down the range of potential changes for sure
GNUmoon has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
amitk has quit [Ping timeout: 252 seconds]
<RP>
abelloni: probably hold on the libtool patch, my local build found something odd :/
<RP>
joy. New libtool breaks pseudo somehow
florian_kc has quit [Ping timeout: 240 seconds]
<khem>
RP: so its only on qemuriscv32 and openssh, so I think I might not have tried openssh for quite a while on that machine, since I was trying core-image-weston and core-image-sato and both use dropbear
mvlad has quit [Remote host closed the connection]
Ebeneezer_Smooge has quit [Ping timeout: 256 seconds]
SSmoogen has joined #yocto
camus1 has joined #yocto
Guma__ has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
GNUmoon has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has joined #yocto
<khem>
so here we go, openssh: update 8.8 -> 8.9 broke it for rv32 ☹️
<khem>
RP: found the root of openssh problem, sent a patch to ml, thanksfully Alex has done some upstream reporting,
nateglims has quit [Quit: Client closed]
florian_kc has joined #yocto
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
<Guma__>
I just build fresh yocto image for the first time. It boots just fine. I realized by running iptables -L that there were not rules. So I added some rules I like and saved with iptables-save ? /etc/iptables.rules. After boot it is not loading. Amd I missing something?
<abelloni>
I guess you need to add a service to load the rules
<Guma__>
Aha.Ok I am running in runlevel 3. What "S" start level is safe to add this in /etc/irc3.d/
<Guma__>
Also any online quick tamplates I can modify?
<abelloni>
there is meta/recipes-extended/iptables/iptables/iptables.service for systemd
<manuel1985>
I'm running my image inside qemu with slirp. I can ping the host from inside the container. How do I make qemu to route packets to the internet?
<manuel1985>
`/usr/sbin/sysctl net.ipv4.ip_forward` tells me ipv4 forwarding is enabled.