LetoThe2nd has quit [Quit: Connection closed for inactivity]
BCMM has quit [Quit: Konversation terminated!]
<vd>
vmeson BUILDNAME isn't empty in fact, but BBTARGETS is (warning added in an image recipe)
tp43_ has quit [Ping timeout: 245 seconds]
wooosaiiii has quit [Ping timeout: 268 seconds]
alicef_ has quit [Quit: install gentoo]
xmn has quit [Ping timeout: 245 seconds]
jwillikers has joined #yocto
ChanServ has quit [*.net *.split]
ChanServ has joined #yocto
jwillikers has quit [Remote host closed the connection]
nerdboy_ has joined #yocto
nerdboy has quit [Ping timeout: 245 seconds]
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
nerdboy_ is now known as nerdboy
nerdboy has quit [Changing host]
nerdboy has joined #yocto
<smurray>
RP abelloni dl9pf: meta-agl-core should be good on the autobuilder now, I think
tp43_ has joined #yocto
paulg has quit [Ping timeout: 240 seconds]
cocoJoe has joined #yocto
<vmeson>
vd: again, it's hard for anyone to be helpful if you don't provide some kind of context. Are you using poky? what branch, what image? ...
amitk has joined #yocto
dlan has quit [Ping timeout: 252 seconds]
dlan has joined #yocto
wooosaiiii has joined #yocto
wooosaiiii has quit [Ping timeout: 240 seconds]
sakoman has quit [Quit: Leaving.]
mranostaj has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
mranostaj has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
mranostaj has quit [Ping timeout: 245 seconds]
mranostaj has joined #yocto
tp43_ has quit [Ping timeout: 245 seconds]
rob_w has joined #yocto
puru has joined #yocto
ant__ has quit [Ping timeout: 252 seconds]
<wCPO>
qschulz: I don't see any errors in log.do_compile which kinda(?) make sense as CONFIG_ZRAM=m was silently removed. Maybe it is the config logic removing the "broken" option?
mcon has joined #yocto
frieder has joined #yocto
goliath has joined #yocto
frieder has quit [Remote host closed the connection]
frieder has joined #yocto
tre has joined #yocto
<wCPO>
I'm very new to Yocto. I'm considering creating a recipe for https://github.com/systemd/zram-generator/ and upstreaming it. Does Yocto/OpenEmbedded accept this kind of recipe and what would be the relevant repository?
sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
<mranostaj>
swap on zram seems interesting to me
<wCPO>
mranostaj: yeh, we are considering using it for a compressed tmpfs, mkfs.ext4 /dev/zram0 && mount
<wCPO>
Is foo:append preferred over foo_append?
zpfvo has joined #yocto
<mihai>
wCPO: yes
<mihai>
specially if you're working on master
kranzo has joined #yocto
Vonter has quit [Ping timeout: 245 seconds]
Vonter has joined #yocto
<RP>
smurray: last build looked green :)
<kranzo>
how would i supply a patch properly to be merged in hardknott and master? (git send-email)
<mihai>
kranzo: submit in master, wait for review and merge, request backport to hardknott
<kranzo>
openembedded-core@lists.openembedded.org the right list for changes to meta/classes/goarch.bbclass ? and if should i rebase on poky:master or openembedded-core:master? im still confused a bit about the combination of the repos
<kranzo>
*am i right that ...
<kanavin>
RP: I'm back in Berlin, and working on a big batch of package updates that should go in before the freeze
<kanavin>
RP: otherwise, the new job is fine, how much time I can have for upstream yocto isn't yet clear, but they're well aware that someone has to do the maintenance
<kanavin>
rburton, ^^^
zyga has joined #yocto
florian has joined #yocto
behanw[m] has quit [Quit: Bridge terminating on SIGTERM]
halstead[m] has quit [Quit: Bridge terminating on SIGTERM]
Emantor[m] has quit [Quit: Bridge terminating on SIGTERM]
moto_timo[m] has quit [Quit: Bridge terminating on SIGTERM]
m1kr0[m] has quit [Quit: Bridge terminating on SIGTERM]
Spectrejan[m] has quit [Quit: Bridge terminating on SIGTERM]
falk0n[m] has quit [Quit: Bridge terminating on SIGTERM]
rostam98[m] has quit [Quit: Bridge terminating on SIGTERM]
michaelo[m]1 has quit [Quit: Bridge terminating on SIGTERM]
cody has quit [Quit: Bridge terminating on SIGTERM]
shoragan|m has quit [Quit: Bridge terminating on SIGTERM]
Pierre-jeanTexie has quit [Quit: Bridge terminating on SIGTERM]
tokamak[m] has quit [Quit: Bridge terminating on SIGTERM]
jordemort has quit [Quit: Bridge terminating on SIGTERM]
lexano[m] has quit [Quit: Bridge terminating on SIGTERM]
jonesv[m] has quit [Quit: Bridge terminating on SIGTERM]
t_unix[m] has quit [Quit: Bridge terminating on SIGTERM]
hmw[m] has quit [Quit: Bridge terminating on SIGTERM]
PascalBach[m] has quit [Quit: Bridge terminating on SIGTERM]
berton[m] has quit [Quit: Bridge terminating on SIGTERM]
Saur[m] has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
SamuelDolt[m] has quit [Quit: Bridge terminating on SIGTERM]
kayterina[m] has quit [Quit: Bridge terminating on SIGTERM]
dwagenk has quit [Quit: Bridge terminating on SIGTERM]
ejoerns[m] has quit [Quit: Bridge terminating on SIGTERM]
meck[m] has quit [Quit: Bridge terminating on SIGTERM]
Alban[m] has quit [Quit: Bridge terminating on SIGTERM]
barath has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
ndec[m] has quit [Quit: Bridge terminating on SIGTERM]
jwillikers[m] has quit [Quit: Bridge terminating on SIGTERM]
<rburton>
kranzo: poky contains oe-core, so you can send patches for iether to oe-core@
wooosaiii has joined #yocto
jordemort has joined #yocto
rostam98[m] has joined #yocto
wooosaiiii has quit [Ping timeout: 245 seconds]
<RP>
kanavin: very cool :)
Spectrejan[m] has joined #yocto
Alban[m] has joined #yocto
lexano[m] has joined #yocto
meck[m] has joined #yocto
kayterina[m] has joined #yocto
Emantor[m] has joined #yocto
Saur[m] has joined #yocto
<RP>
kanavin: I've been focusing on the overrides changes and things like the glibc upgrade which has caused a few issues
khem has joined #yocto
shoragan[m] has joined #yocto
Pierre-jeanTexie has joined #yocto
cody has joined #yocto
shoragan|m has joined #yocto
ejoerns[m] has joined #yocto
moto_timo[m] has joined #yocto
dwagenk has joined #yocto
t_unix[m] has joined #yocto
berton[m] has joined #yocto
ndec[m] has joined #yocto
hmw[m] has joined #yocto
PascalBach[m] has joined #yocto
falk0n[m] has joined #yocto
jonesv[m] has joined #yocto
barath has joined #yocto
jwillikers[m] has joined #yocto
behanw[m] has joined #yocto
SamuelDolt[m] has joined #yocto
halstead[m] has joined #yocto
michaelo[m] has joined #yocto
tokamak[m] has joined #yocto
m1kr0[m] has joined #yocto
<kranzo>
rburton but still do i base on my patch on git.openembedded.org or git.yoctoproject.org
xmn has joined #yocto
<kranzo>
its the same change but on different folders
goliath has joined #yocto
<rburton>
kranzo: whatever you're actually using so you can test it
<kranzo>
ok poky then, how do i mention what is my base? or better what is the actual mailinglist to adress? i just struggle to get it right cause i never ever used mailinglists before :D
<rburton>
the mailing list for anything in meta/ is oe-core@
<rburton>
you don't need to specify poky or oe-core as for anything in meta/ they're identical
<rburton>
poky is just bitbake+oe-core+some other repositories, all squashed together
<kranzo>
@lists.openembedded.org or @@lists.yoctoproject.org, i feel a bit dumb right now :D
<mcon>
Hi, as part of a custom layer I need to clone from a private GitLab server a certain project. GitLab standard URL for this i something like: "git clone git@server.somwhere.com:project/subproject.git" and I was unable to have yocto (poky thud) generate this as it insists on "type://user:pass@server/project/subproject.git" (enforced in poky/bitbake/lib/bb/fetch2/__init__.py#407) what am I missing?
<mcon>
kranzo: Thanks, I'll try it ASAP. I did not remember trying this combination.
xmn has quit [Ping timeout: 256 seconds]
<wCPO>
OnkelUlla: thanks for the pointer, could very likely be useful
<kranzo>
mcon seems like gitlab cant use username:password for ssh cloning, so the correct way would be: git://user:pass@server/namespace/project.git;branch=$branch;protocoll=https
<kranzo>
*protocol ...
<mcon>
kranzo: I'm not trying to use "user:pass@server" at all as I have uploaded my keys. I have a plain "git clone git@server:namespace/project.git" that works perfectly from the command line. My problem is how to have yocto to generate it. I do not think https:// is enabled at all on this server
<kranzo>
@mcon then git://git@server/namespace/project.git;protocol=ssh should work, so you have to replace the : with a / between server and namespace
<qschulz>
and then rely on your ssh-agent or keyring having unlocked the passphrase of the ssh key (if you do have a passphrase)
<qschulz>
which usually requires a bit of tinkering if you're using containers for example
<kranzo>
as workaround i did bitbake -c fetch on the host (keys set up) and then a bitbake in the container, for automated setups i recommend the gitlab examples for setting up container-local ssh keys and the agent
<rskumar>
i am trying to build Zeus image in Podman. I noticed that linux-libc-headers are not properly copied to recipe-sysroot.. for example: unistd.h, asm/sigcontext.h
<rskumar>
i had to clean and build linux-libc-headers again to get it. Can someone help me to understand why this happens?
<rskumar>
i am able to build Jethro version in the same podman.. But, i am getting build errors only with Zeus version
BCMM has joined #yocto
<LetoThe2nd>
rskumar: that sounds like it might be a problem with a recipe that is not sysroot-safe. those were introduced in pyro.
<rskumar>
another observation is that I am able to build Zeus in Ubuntu16.04 dedicated setup. I get build errors only with Podman container(Ubuntu16.04) running on RHEL8.3
<ad__>
hi, mm, for dunfell, i installed all host tools in bionic as in the manual, but bitbake says:
<ad__>
file
<ad__>
ERROR: The following required tools (as specified by HOSTTOOLS) appear to be unavailable in PATH, please install them in order to proceed:
<ad__>
the "file" tool seems needed ...
chobo has joined #yocto
<wCPO>
Is there any difference between SRI_URI += "foo" and SRI_URI:append = "foo"?
<wCPO>
kranzo: make sense. So if I don't use a variable it should be the same? ex: SRI_URI += "foo" vs SRI_URI:append = " foo"?
otavio_ has joined #yocto
rob_w has quit [Quit: Leaving]
rskumar has quit [Quit: Client closed]
<tlwoerner>
OnkelUlla: thanks for the pointer
<tlwoerner>
wCPO: so far that patch only handles the sysvinit case. i submitted it to get feedback before continuing since, if RP would prefer a different approach, i would rather know now than later
<batcha[m]>
How come I randomly keep getting "bb.cooker.CollectionError: Errors during parsing layer configuration" bb (layers) issues after I add layers via "bitbake-layers add-layer ../layers/X"?
<batcha[m]>
Its like it corrupts the bblayers file, and after i remove the line and re-add the same layer using the same command, it works out (or randomly doesnt).
<tlwoerner>
RP: you were asking something about how i was handling the packagegroups so i pushed an RFC patch for you to look at
<rpcme>
What is the expected behavior when you define a MACHINE configuration that doesn't exist?
<rpcme>
For example, for a stupid amount of time I was staring at "MACHINE=am64xx-evam bitbake -e tisdk-base-image" that should have been "MACHINE=am64xx-evm bitbake -e tisdk-base-image" which resulted in an unnerving "cannot find toolchain" error even though I had configured the external toolchain correctly.
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<abelloni>
bitbake should fail quite quickly, complaining the machine configuration doesn't exist
<rpcme>
Yes I think this is an issue in meta-arago with the external toolchain handler. I could not repro the same behavior with poky and poky core-image-minimal fails the way you stated.
xmn has quit [Ping timeout: 240 seconds]
camus has joined #yocto
<rpcme>
I will post to TI E2E forums instead. I really have no idea where else to post it since I was pinched for asking about meta-arago in the meta-ti yocto forum :D
<kranzo>
the one who is pulling needs a privatekey with access to rhe repo
<kranzo>
an alternative is creating a accesstoken with read access and using https cloining with username:accesstoken
davidinux has quit [Ping timeout: 240 seconds]
zyga has joined #yocto
d0ku has joined #yocto
goliath has quit [Quit: SIGSEGV]
tp43_ has joined #yocto
<JaMa>
RP: rburton: should libpthread be installed in uninative tarball as well now? I'm seeing pkgconfig-native failure (bundled glib failing to find libpthread) when uninative is enabled
<_franck_>
yeah that's what I did first, but the recipe I try to build (I want libextractor) needs to detect gstreamer in order to enable support for it. With gstreamer1.0 it doesn't detect it.
<_franck_>
must be something else
<_franck_>
configure: NOTICE: gstreamer not found, gstreamer support disabled
<_franck_>
I do have gstreamer, but may be not the dev libs
<_franck_>
gstreamer1.0 RPROVIDES gstreamer1.0-dev ---> what does it mean exactly ?
<_franck_>
because I don't have these ${libdir}/gstreamer-1.0/*.a files
<JaMa>
looks like libpthread.so.0 itself is there, will debug why bundled glib doesn't find it anymore
<JaMa>
honister$ ls -lah uninative-3.*/*/lib/*pthread*
<JaMa>
-rwxr-xr-x 1 bitbake bitbake 115K Feb 1 2021 uninative-3.2-glibc-2.33/x86_64-linux/lib/libpthread-2.33.so
<JaMa>
-rwxr-xr-x 1 bitbake bitbake 14K Aug 2 01:33 uninative-3.3-glibc-2.34/x86_64-linux/lib/libpthread.so.0
<rburton>
_franck_: .a files are not built if you're using poky, as that disables static libraries
kranzo has quit [Quit: Client closed]
kranzo has joined #yocto
kranzo has left #yocto [#yocto]
kranzo has joined #yocto
kranzo has quit [Remote host closed the connection]
<_franck_>
rburton you mean there is no static library include in any poky package (excuse me for beeing a noob) ?
kranzo has joined #yocto
<rburton>
yes
* _franck_
needs to google that
<_franck_>
ah ok
<rburton>
to save time and space, poky turns off static libraries
<_franck_>
any solution to workaround that ?
<rburton>
do you actually need static libraries?
<rburton>
statically linking to gstreamer makes very little sense
<rburton>
you just need DEPENDS=gstreamer1.0
<_franck_>
no I don't. I need gtramer dev, which is not in this recipe I guess. -dev only provides static libraries
<rburton>
do "oe-pkgdata-util list-pkgs-files -p gstreamer1.0"
<rburton>
you'll see the -dev has headers and shared libraries in
<rburton>
erm, list-pkg-files
<rburton>
JaMa: can you replicate with a fresh poky and nothing else? works here...
<kranzo>
gstreamer-dev in the ubuntu is not the same as the -dev build by yocto, sounds a bit like a name confusion
<kergoth>
ubuntu splits it into multiple individual packages just like we do. one recipe, multiple packages, just as they have one source package, multiple binary packages
<kergoth>
we tend toward more granularity in ours to save space, generally, though
<_franck_>
rburton : ok I see thanks. So I need to figure out why libextractor doesn't detect gstreamer
<kranzo>
true but the content may differ, so maybe ubuntu has static libs shipped in that package
tp43_ has quit [Ping timeout: 258 seconds]
<_franck_>
I don't have /usr/include/gstreamer-1.0/.... with DEPENDS=gstreamer1.0. Something is wrong
<JaMa>
rburton: can replicate with oe-core and nodistro config (with and without uninative enabled)
<kergoth>
_franck_: you cant just look in /usr/include, files for your dependencies are in staging, not the host
<JaMa>
rburton: host is ubuntu-20.04 with glibc-2.31 in docker
<_franck_>
oe-pkgdata-util list-pkg-files gstreamer1.0 doesn't list include files. oe-pkgdata-util list-pkg-files gstreamer1.0-dev does. So you mean depend on gstreamer1.0 automatically includes gstreamer1.0-dev ?
<rburton>
DEPEND is recipe, it will include the sysroot for that recipe
tp43_ has joined #yocto
<rburton>
list-pkg-files is actually listing the packages, which is not the same thing
<rburton>
but anything thats in the -dev package is in the sysroot
<rburton>
(typically)
<_franck_>
ok, I thought depend meant I depend on this package
<_franck_>
"Putting a package name such as “foo-dev” in DEPENDS does not make sense."
<_franck_>
ok :)
eduardas has quit [Quit: Konversation terminated!]
<kranzo>
and dont forget the proper RDEPENDS to get the shared libs installed
amitk has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
<rburton>
well, that will happen for you
<kranzo>
ok nvm then
<rburton>
all binaries will be scanned for links, and rdepends added as required. the only time you need to manually add libraries to RDEPENDS is if you use dlopen()
<_franck_>
so if I only need DEPEND = gstreamer1.0, it doesn't solve my problem because I tried 100 times :)
<rburton>
i'd check that you inherited pkgconfig
<rburton>
and if that doesn't work, actually share the log and your recipe
<rburton>
its likely failing as you need to depend on more bits of gstreamer, not just the core
<JaMa>
rburton: it doesn't like the loader from uninative, if I switch back then it works, but doesn't show any error https://pastebin.com/iLNW8bFc
<rburton>
JaMa: i hate uninative
<rburton>
JaMa: can you file a bug?
<_franck_>
rburton: I dont have inherited pkgconfig
<_franck_>
I'll clean and retry
<_franck_>
thanks for your help
<rburton>
no need to clean, just add and re-bitbake
<_franck_>
I did but same thing
<JaMa>
rburton: I'll continue to debug it a bit more (to find out what exactly is failing in conftest) then file a bug when run out of time
<_franck_>
rburton I'll be back in 5 minutes, I'll share the logs and recipe
kranzo_ has joined #yocto
dev1990 has joined #yocto
kranzo_ has left #yocto [#yocto]
override_ has joined #yocto
zpfvo has quit [Quit: Leaving.]
<override_>
hey, is there a way of using a specific DEPENDS for a do_fetch only?
<rburton>
so DEPENDS is shorthand for setting do_configure[depends]
<override_>
ok, and how can I set to to just work for a do_fetch task?
<rburton>
so you can set do_fetch[depends]. the classes already do that, that's how it knows to setup eg xz-native to unpack a .xz file
<rburton>
_franck_: remove the PACKAGES and INHIBIT and INSANE lines
<rburton>
and your last do_install_append
<rburton>
basically your PACKAGES and FILES are bad, which is why you get lots of errors
<rburton>
but what's the actual configure error?
<_franck_>
configure: NOTICE: gstreamer not found, gstreamer support disabled
<_franck_>
^
<rburton>
what's the line above that
<rburton>
i ask because it checks for four different bits of gstreamer
<mcon>
I am trying to integrate a yocto build in GitLab CI/DC framework. What is the best practice to use incremental build on all "git push" and start a full rebuild only "on request" (nightly build)?
<rburton>
mcon: by full rebuild, do you mean from a clean sstate so it rebuilds the compilers?
<mcon>
rburton: Rebuild all artifacts from scratch, without using cache or whatever. Toolchain can stay (I can cleanup by hand if something really changes).
<rburton>
so selective rebuild
<rburton>
much easier if you say 'incremental' or '100% from scratch'
<mcon>
rburton: If that's a problem I can live with a truly full nightly rebuild (including redownload of sources (but that seems an overkill ;) )
<rburton>
well always preserve DL_DIR between runs
<rburton>
always have a clean build directory
<rburton>
preserve sstate_dir between jobs but blast it away for your nightly
zyga has quit [Remote host closed the connection]
<_franck_>
rburton:
<_franck_>
checking for GSTREAMER...
<_franck_>
yes
<_franck_>
checking for GSTREAMER_TAG...
<_franck_>
no
<_franck_>
checking for GSTREAMER_PBUTILS...
<_franck_>
no
<_franck_>
checking for GSTREAMER_APP...
<_franck_>
no
<_franck_>
checking for GSF...
<_franck_>
no
<rburton>
there you go
<_franck_>
so it finds gstreamer
<rburton>
pbutils is in -plugins-base
<_franck_>
I guess I need to create recipes for the others
<rburton>
so is tag
<_franck_>
ah cool
<rburton>
no, they're in oe-core
<rburton>
so is app
<mcon>
rburton: do you have GitLab experience? My problems mostly stem from trying to redo in scripts (thought to be run by hand) most of what I seem to understand GitLab is already doing by itself :/
<JaMa>
rburton: weird pthread_create returns EPERM when running inside docker, but only with uninative loader
<yates_home>
rburton: why is there a recipe-sysroot and recipe-sysroot-native built for each recipe? these are all common to the one native toolsset and target toolset, right?
<rburton>
might be gettext being dumb, leave that for now :)
<override_>
rburton: hows do_fetch[deptask] different from do_fetch[depends] ?
<_franck_>
you told me to remove INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
<_franck_>
INHIBIT_PACKAGE_STRIP = "1
<_franck_>
however, now I get /usr/lib/.debug/....
nerdboy_ has joined #yocto
<_franck_>
A Issue: extract: Files/directories were installed but not shipped in any package
<rburton>
wow must be an old yocto
<_franck_>
:)
<rburton>
that's been automatically packaged for years
<_franck_>
that's the yocto I have to work on
<rburton>
but the default rules put that into PN-dbg, so I guess you're still setting PACKAGES
<rburton>
don't do that
<_franck_>
If I don't nothing is done. I don't understand.
goliath has joined #yocto
* _franck_
really needs to read yocto documentation
nerdboy has quit [Ping timeout: 240 seconds]
<_franck_>
let me try again
<rburton>
a good 50% of your recipe should be deleted
<_franck_>
:)
kranzo[m] has joined #yocto
<_franck_>
if I remove PACKAGE, it doesn't configure and compile anything
<rburton>
it will re-package without recompiling
<_franck_>
ok
<rburton>
<handwave> magic!
<rburton>
'oe-pkgdata-util list-pkg-files -p libextractor' will show what it packaged where
<_franck_>
still 30% to remove
kranzo has quit [Quit: Client closed]
mranostaj has joined #yocto
<override_>
what good is getVarFlags function for when we can just do stuff like do_fetch[deptask]
<JaMa>
rburton: you were right, if I run docker with --privileged then it doesn't return EPERM, is this known issue or should I still create that ticket?
<rburton>
JaMa: might be worth creating a ticket still, but it's mostly a docker bug
d0ku has quit [Remote host closed the connection]
<JaMa>
ok, will create one as pkgconfig-native suddenly failing isn't obvious to be caused by docker bug :)
<rburton>
no :)
<rburton>
first time that happened it an age to figure it out
tre has quit [Remote host closed the connection]
<RP>
creating bugs is great but we do need help fixing them too :/
<RP>
right, so does anyone care about meta-gplv2? It is breaking and I really don't care about it
<JaMa>
what broke it? glibc upgrade or something else? I don't care about it, but I guess someone in LGE eventually will be when they start caring about anything newer than dunfell
<smurray>
RP: we have an option to pull it in for AGL, but don't regularly test it, I'm not sure whether members rely on it or not
<smurray>
RP: I also know of one large non-AGL customer of ours that does all their builds with it
<RP>
JaMa: I have changes to elfutils which break it
<smurray>
RP: in other news, I fat-fingered and sent the oe-core patch for the PR server to bitbake-devel first, so you may see it twice
<RP>
I'm sure I can "fix" it, I'm just depressed I get to poke at it again :(
<RP>
smurray: np :)
xmn has joined #yocto
<override_>
yo anyone wana explain why/wehn we use getVarFlags over something like do_fetch[deptask]??? i dont quite understand the idea behind it
<smurray>
RP: I did find in the asyncio docs that there's a way to hand an existing socket to the asyncio server code, but it looks like it'd be kind of unwieldy to attempt making that work wrt caching like was being done before
<RP>
smurray: lets see how it works without that first :)
<RP>
curses. I did fix the thing :/
<smurray>
RP: yeah, I figure the cost of opening the socket every time will not be visible compared to actually doing packaging, but could be wrong
<RP>
khem: do you have the symbol versions and compiler ifdef line?
<RP>
moto-timo: I've fixed that layer far too often :(
<moto-timo>
<cough>Eclipse plugins</cough>
<RP>
smurray: I guess we should perhaps see what the connection count is like without that cache just to see what it is doing
<smurray>
RP: you'll see in the patch that I call close on the connection, I added that since running with -X dev indicated a bunch of sockets left open when running the PR selftests
<smurray>
RP: so there's definitely multiple connections from a single process in the e.g. PR export usecase, but I was thinking it less likely in normal building
xmn has quit [Quit: ZZZzzz…]
mcon has quit [Quit: mcon]
<khem>
RP: compiler defs would be #if defined(__riscv) && __riscv_xlen == 32 and #if defined(__riscv) && __riscv_xlen == 64
Ad0 has quit [Ping timeout: 245 seconds]
Ad0 has joined #yocto
florian has joined #yocto
florian has quit [Ping timeout: 252 seconds]
xmn has joined #yocto
stkw0 has quit [*.net *.split]
stkw0 has joined #yocto
nerdboy_p has joined #yocto
nerdboy_ has quit [Ping timeout: 248 seconds]
davidinux has quit [Ping timeout: 268 seconds]
frieder has quit [Remote host closed the connection]
zyga-mbp has quit [Read error: Connection reset by peer]
zyga-mbp has joined #yocto
zyga-mbp has quit [Client Quit]
xmn has quit [Quit: ZZZzzz…]
d0ku has joined #yocto
amitk has quit [Ping timeout: 252 seconds]
xmn has joined #yocto
leon-anavi has quit [Quit: Leaving]
vmeson has quit [Ping timeout: 240 seconds]
florian has quit [Ping timeout: 258 seconds]
vmeson has joined #yocto
vmeson has quit [Client Quit]
florian has joined #yocto
jwillikers has quit [Remote host closed the connection]
florian has quit [Ping timeout: 252 seconds]
vmeson has joined #yocto
<RP>
khem: ok, just means another world rebuild but yes
<RP>
smurray: I'm mostly worried about the do_package code
<smurray>
RP: yes, that occurred to me, but I don't believe that executes in a reused process from a pool?
<RP>
smurray: I think the problematic pattern is repeated expansion of the PR value and the worry that exact expansion is its own connection
<smurray>
RP: hrm, okay
<smurray>
RP: it looked to me like it'll only get called once in the do_packagedata -> package_get_auto_pr code path
<RP>
smurray: possibly, I haven't looked at it in a while
mcon has joined #yocto
<RP>
smurray: looking at the code I think you're right and it should be ok
<RP>
smurray: I think I'm remembering a different horror story
<smurray>
RP: whew ;)
<RP>
smurray: the connection caching was in Lianhao's original code!
<smurray>
RP: afaict it really was only benefitting PR export now, since the connections were happening from the extra prexport event handlers during parsing
<RP>
smurray: I suspect the reason was less for performance and more to stop it breaking the server
<smurray>
RP: heh
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
<RP>
smurray: I've put it in for testing overnight
<smurray>
RP: fingers crossed!
<RP>
smurray: yes! Thanks for preserving with this, it will be worth it in the end :)
<RP>
persevering
<smurray>
thanks, hoping it gets in since the r/o feature would be useful