<zeddii>
I've been watching the gcc 12 threads on lkml, yah, there are still problems
<zeddii>
but I'm not really keen to try and solve any of them myself, upstream will be there soon enough ,if not already there (I haven't checked for a few days)
<zeddii>
(and a thread from 7 hours ago: gcc inserts __builtin_popcount, causes 'modpost: "__popcountdi2" ... amdgpu.ko] undefined' )
jclsn904 has quit [Ping timeout: 240 seconds]
jclsn904 has joined #yocto
qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
jclsn904 has quit [Ping timeout: 240 seconds]
jclsn904 has joined #yocto
sakoman has joined #yocto
jclsn904 has quit [Ping timeout: 240 seconds]
jclsn904 has joined #yocto
jclsn904 has quit [Ping timeout: 260 seconds]
jclsn904 has joined #yocto
jclsn904 has quit [Ping timeout: 260 seconds]
troth has quit [Ping timeout: 250 seconds]
jclsn904 has joined #yocto
jclsn904 has quit [Ping timeout: 250 seconds]
troth has joined #yocto
jclsn904 has joined #yocto
jclsn904 has quit [Ping timeout: 250 seconds]
jclsn904 has joined #yocto
starblue has quit [Ping timeout: 256 seconds]
jclsn904 has quit [Ping timeout: 256 seconds]
starblue has joined #yocto
jclsn904 has joined #yocto
jclsn904 has quit [Quit: Ping timeout (120 seconds)]
<OutBackDingo>
If your provider offers you a subnet of public IP addresses and you want to expose them for NAT or different services running on your Firewall, you will also have to add them to your HA setup. Since adding a VHID for every IP would make the CARP traffic very noisy, you can also add a new IP Alias and choose the correct VHID where the first CARP IP is configured.
<OutBackDingo>
sooo... how is this accomplished
<OutBackDingo>
if i have a /25 subnet, do i add that to carp interfaces
<OutBackDingo>
so... carp the whole /25 ?
<OutBackDingo>
VHID 1 must be defined on interface WAN as a CARP VIP first. ughhh nope
<OutBackDingo>
no idea how this gets configured
mvlad has joined #yocto
rfuentess has joined #yocto
leon-anavi has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus has joined #yocto
camus has quit [Client Quit]
Wouter0100 has quit [Read error: Connection reset by peer]
<amahnui[m]>
Please I wish to ask how long it takes for changes made to the docs.yoctoproject.org to be adopted to the main website?
<amahnui[m]>
After being merged
troth has quit [Ping timeout: 250 seconds]
maciej_mrozowski has joined #yocto
pbergin_ has joined #yocto
pbergin has quit [Ping timeout: 240 seconds]
troth has joined #yocto
<maciej_mrozowski>
I have a package that is arch-agnostic tool (written in python, but also installs .pc to locate some .xml and .xsd files it provides, also cmake support as python script is code generator - think of it as similar to protoc), that is meant to run inside sdk. I package it as BBCLASSEXTEND="native nativesdk". But there is problem, yocto does not seem
<maciej_mrozowski>
to support finding native sdk dependencies. Neither PKG_CONFIG_PATH points to native sysroot, nor CMAKE_FIND_ROOT_PATH does.
<maciej_mrozowski>
Am I doing something that yocto fundamentally doesn't support? (in ex. yocto supports only nativesdk *binaries, as PATH is the only thing that is accessible from nativesdk)
<RP>
I've started a bisect to try and narrow it down, so far it looks like between the 17th and 27th march ish
<kanavin>
RP: not right now, no
<RP>
kanavin: thought it was worth asking just in case, thanks
<kanavin>
it'll probably be some version update from the gtk/glib stack
<RP>
kanavin: or rust and svg
<kanavin>
yup
<RP>
maciej_mrozowski: it depends on the context. If you're building the nativesdk variant of the recipe, it should have nativesdk PKG_CONFIG_PATH setup
<RP>
maciej_mrozowski: the paths in native and nativesdk do look a bit odd, as if there is a duplicate that shouldn't be there but they are right and it is likely your recipe perhaps doesn't account for them. I'm just guessing at the most common issue though
Schlumpf has quit [Quit: Client closed]
<maciej_mrozowski>
RP: Let's narrow down my problem to sdk use case for now (and ignore bitbake env). I don't have problem with building packages (via bitbake), I have problem with using SDK, I install opt-nativesdk <my_package>, it installs all listed in its RDEPENDS_<PN>-class-nativesdk, but cmake module (neither .pc file) the package provides, can be located
<maciej_mrozowski>
inside this sdk.
<RP>
maciej_mrozowski: Just to be clear, you're using the SDK outside bitbake and you're expecting to see a .pc file from a nativesdk component in that SDK?
<maciej_mrozowski>
Correct, .pc file installed in /usr/share/pkgconfig (and <package>-config.cmake installed in /usr/share/cmake/<package>)
<RP>
maciej_mrozowski: the SDK doesn't support that, it only supports building for the target, not nativesdk
<RP>
maciej_mrozowski: it would confuse too many people
<maciej_mrozowski>
<package> is not target package though. It's like "protoc". Intended to run in build host (hence native) and sdk host (hence nativesdk). Even If I make it target package, it still has inherent native nativesdk runtime deps like python.
<maciej_mrozowski>
I think my use case is not "sdk building for nativesdk", but "sdk using nativesdk"
<amahnui[m]>
I wish to ask if it is advisable to use $(...) notation instead of legacy backticked '...' in shell scripts?
<RP>
maciej_mrozowski: effectively you're talking about a cross tool and there is no .pc support for cross tools
<RP>
maciej_mrozowski: it isn't something pkg-config itself supports
<maciej_mrozowski>
I can assume this is Yocto imposed limitation though
<RP>
maciej_mrozowski: well, nobody has ever made a case for including the nativesdk datadir pkgconfig inside the target pkgconfig env
<RP>
maciej_mrozowski: note that there would be two datadir pkgconfig areas, the one in the target sysroot and the one in the nativesdk sysroot
<maciej_mrozowski>
Yes
<RP>
maciej_mrozowski: and if you do that, you'd have the issue that the compiler sysroot can't see inside the nativesdk sysroot
<RP>
so whilst I can see your argument, I don't think it would work well in general
m_jimmer12345 has quit [Quit: Client closed]
<kanavin>
RP: let me know once you get to the offending commit (if it isn't obvious)
<RP>
kanavin: Will do. It is going to take a while as it is a new rust build every time
<maciej_mrozowski>
RP "compiler sysroot can't see inside nativesdk sysroot" as in include search path would not work? What do you mean? Wouldn't appending native sysroot /usr/share/pkgconfig to PKG_CONFIG_PATH in sdk .sh script (and appending nativesdk sysroot to CMAKE_FIND_ROOT_PATH in generated cmake toolchain file) effectively make traget compiler sysroot "see
<maciej_mrozowski>
nativesdk sysroot"?
<kanavin>
RP: hopefully rust will not be rebuilt once the bisection set gets smaller
<RP>
maciej_mrozowski: we call gcc --sysroot=<target-sysroot> so the compiler will not see the nativesdk sysroot files at all
<RP>
kanavin: you'd think/hope but not so far and I see rust changes in the bisect window
<RP>
kanavin: I should have probably done this on an autobuilder with more sstate in hindsight
troth has quit [Ping timeout: 246 seconds]
<maciej_mrozowski>
RP ah, yeah, you are correct, my particular use case doe not end up passing include paths (which would not be resolvable within target-sysroot)
<RP>
maciej_mrozowski: we do have to think about the wider case though :/
<kanavin>
RP: I am meanwhile trying to get another effort at pending patches submission going :)
<RP>
maciej_mrozowski: where we have this in other cases I think we use ${bindir_crossscripts}
<RP>
maciej_mrozowski: there aren't many of them left as .pc files let us drop most of the -config scripts but it would give you a way to have your script accessible in a cross env
florian__ is now known as florian
<RP>
kanavin: sounds good. I was happy to see a few gcc patches falling out the system and libtool is slowing moving so we may stand some chance there eventually too
<RP>
kanavin: I found a few weird license patches we could drop which was a nice cleanup
starblue has quit [Ping timeout: 256 seconds]
troth has joined #yocto
starblue has joined #yocto
<maciej_mrozowski>
RP For protoc in yocto it was done by splitting the package - protoc executable was made nativesdk while the rest was made target packages. it was appropriate there (protoc is fully standalone, sans .so libs it needs) and could be some workaround for me. I would not be able to pull those target packages as ipk runtime deps.
Guest5 has quit [Quit: Client closed]
<maciej_mrozowski>
(and yes, I could provide <package>-config wrappr script that should be used inside my cmake config module, and instead of pkg-config)
<RP>
maciej_mrozowski: you have a weird corner case unfortunately and there aren't easy answers
maciej_mrozowski has quit [Quit: Client closed]
maciej_mrozowski has joined #yocto
Schiller has quit [Ping timeout: 250 seconds]
Guest92 has joined #yocto
<Guest92>
hello everyone
<maciej_mrozowski>
RP I think I came here more like for a wider opinion on how to tackle this use case in Yocto, preferably opinion from upstream.
<mckoan>
Guest92: hi
<maciej_mrozowski>
(maybe I'll start topic on ML)
<RP>
maciej_mrozowski: for better or worse I helped design some of this and I'm not sure there is a good way to improve it
<Guest92>
can anyone help me with with an issue i have been trying to solve for 3 days? i am on dunfell and itstool is failing in do_configure stage.
troth has quit [Ping timeout: 240 seconds]
<Guest92>
| configure: error: Python module libxml2 is needed to run this package
<Guest92>
it is looking for the libxml2 in site-packages of python3.8 native but it seems libxml2 package is not installing anything in the native path but it is installing in the target path
Guest5 has joined #yocto
<qschulz>
Guest92: did you add libxm2-native to your DEPENDS?
<qschulz>
libxml2*
<maciej_mrozowski>
RP I fully understand why nativesdk /usr/lib*/pkg-config is not accessible from target sysroot - it should not be. The only subject of potential discussion for me would be /usr/share/pkgconfig. But then cmake module / library search path is much more complicated and I'm not sure there is reliable way to ensure CMake locates in nativesdk sysroot
<maciej_mrozowski>
only "shared" modules and never "library" or "target" modules.
User553 has joined #yocto
<Guest92>
yes in itstool_2.0.6.bb :
<Guest92>
DEPENDS = "libxml2-native"
<Guest92>
.
<Guest92>
.
<Guest92>
BBCLASSEXTEND = "native nativesdk"
<Guest92>
RDEPENDS_${PN} += "libxml2-python"
<Guest92>
RDEPENDS_${PN}_class-native = ""
florian has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
<User553>
hello there. i have a docker container where Buildbot runs inside. I access the UI via the docker port. When i now run a secound Container with the same exact setup (just different container port and buildbotURL in master.cfg) it seems to not connect at all. Can someone explain and where to edit? Thx
<maciej_mrozowski>
Guest92 I might be wrong but I think you should make it DEPENDS="libxml2". The way you build istool itself (as -native or nativesdk-) will pull the right kind of libxml2 dependency
<RP>
maciej_mrozowski: that is my worry too
<RP>
maciej_mrozowski: we could make a special case work but it may just cause too many other problems - the fix may be worse than the original problem
<dwagenk>
Maybe someone here can point me to the right bit of documentation: I'd like to develop the bootloader update integration for a project using qemu instead of the real hardware. I've done similar things in the past for an x86 system with efi and a full disk image. With that stack (uefi, grub, rauc) and the correct QB_* settings in the machine config it was as simple as running `runqemu wic ovmf [serialstdio]` plus some parameters for an additional
<dwagenk>
virtual hard-disk.
<Guest92>
maciej_mrozowski qschulz I have tried both DEPENDS="libxml2" and DEPENDS="libxml2-native" but both have the same error thrown at configure stage. What is strange is when I cleanall both itstool and libxml2 and bitbake itstool libxml2; itstools does not wait for libxml2 to compile..
troth has joined #yocto
<dwagenk>
Now I'm on an arm based board and using u-boot and swupdate. Since I can't use the same u-boot as I'm using on-device I think the right approach would be to use a different u-boot when starting qemu, but keep the same rootfs and kernel (they are compatible and boot fine in qemu). Would a multiconfig build be the right approach for something like this? With a separate machine-qemu machine that builds the u-boot for qemu? And then the rootfs would
<dwagenk>
need to depend on the u-boot for qemu and set the correct QB_* options?
<qschulz>
Guest92: smells like your DEPENDS isn't taken into account somehow
<qschulz>
Guest92: can you check with bitbake -e itstool | grep ^DEPENDS= ?
<Guest92>
qschulz it's empty!
<Guest92>
$ bitbake -e itstool | grep ^DEPENDS=?
<Guest92>
$
florian_kc is now known as florian
<maciej_mrozowski>
RP Problem would appear if someone mistakenly installed nativesdk variant of package (instead of target one) and cmake (or pkgconfig) picked it up. This requires both of them to be actually provided. I think this rarely happens, package is usually made to be either in opkg or opkg-nativesdk. But if it's both, presence of both in their respective
<maciej_mrozowski>
sdks sysroots can be handled by proper search path order (target sysroot first, nativesdk sysroot at the end).
<maciej_mrozowski>
Anyway i guess I can start some wider discussion on the subject on ML (and meanwhile I'll work it around in my env)
<Guest92>
qschulz I removed =? from grep and this is what I get now
<RP>
maciej_mrozowski: we can have a wider discussion and from a technical aspect it is "easy" but I think the end result would be confusing :/
<qschulz>
Guest92: so libxml2-native wil be built before itstool that's for sure
<qschulz>
Guest92: the question mark was for the question punctuation, not an actual character for the command (though = was, but it works without just fine)
<maciej_mrozowski>
RP anyway, thanks!
<RP>
maciej_mrozowski: Let me give you a more evidence based answer
rfuentess has quit [Remote host closed the connection]
<Guest92>
exports/git-build/tmp/work/aarch64-fsl-linux/libxml2/2.9.10-r0/sysroot-destdir/usr/lib/python3.8/site-packages/libxml2mod.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=fe911a45fe9bb10bb360a9ccef0b3a64f7106a30, stripped
<Guest92>
the generated so is for aarch64
Guest5 has quit [Quit: Client closed]
<qschulz>
Guest92: because you're looking at the target libxml2 and not the host (native) libxml2
<qschulz>
they are built in different directories
<maciej_mrozowski>
RP I do not disagree. Most of them (x11 headers - *proto.pc for instance) are not intended to be used in nativesdk but pkgconfig would find them, but then compiler would not be able to resolve them. End result would be "doesn't work" which is ok because this is not valid use case, but that should fail at pkgconfig already, not at gcc.
<maciej_mrozowski>
(hence confusing)
Guest92 has quit [Quit: Client closed]
<qschulz>
Guest92: /exports/git-build/tmp/work/x86_64, or something like that should be where libxml2-native directory should be
<maciej_mrozowski>
*but that *should* fail at pkgconfig already
<RP>
maciej_mrozowski: today it would fail at pkg-config as the dependency wouldn't be there. With your proposed change, it would find it and then later fail at build time when gcc couldn't find the headers
<RP>
maciej_mrozowski: that isn't an improvement IMO
Guest92 has joined #yocto
<qschulz>
Guest92: /exports/git-build/tmp/work/x86_64, or something like that should be where libxml2-native directory should be
<Guest92>
but how do i make itstool search in this site-pacakges directory? it is searching in aarch64-fsl-linux directory in do_configre stage
<Guest92>
| checking whether /exports/git-build/tmp/work/aarch64-fsl-linux/itstool/2.0.6-r0/recipe-sysroot-native/usr/bin/python3-native/python3 version is >= 2.6... yes
<Guest92>
| checking for /exports/git-build/tmp/work/aarch64-fsl-linux/itstool/2.0.6-r0/recipe-sysroot-native/usr/bin/python3-native/python3 version... 3.8
<Guest92>
| checking for /exports/git-build/tmp/work/aarch64-fsl-linux/itstool/2.0.6-r0/recipe-sysroot-native/usr/bin/python3-native/python3 platform... linux
<Guest92>
| checking for /exports/git-build/tmp/work/aarch64-fsl-linux/itstool/2.0.6-r0/recipe-sysroot-native/usr/bin/python3-native/python3 script directory... ${libdir}/python3.8/site-packages
<Guest92>
| checking for /exports/git-build/tmp/work/aarch64-fsl-linux/itstool/2.0.6-r0/recipe-sysroot-native/usr/bin/python3-native/python3 extension module directory... ${libdir}/python3.8/site-packages
<Guest92>
| checking for python module libxml2... not found
<Guest92>
| configure: error: Python module libxml2 is needed to run this package
<Guest92>
| WARNING: /exports/git-build/tmp/work/aarch64-fsl-linux/itstool/2.0.6-r0/temp/run.do_configure.19180:1 exit 1 from 'exit 1'
<maciej_mrozowski>
RP Well my intention is not to make gcc find those nativesdk headers in target sysroot. and I agree with confusion argument the way they headers would be handled. (for my use case - passing some custom variables in .pc file - it is improvement though, i don't argue that benefit overweights drawbacks, I don't know Yocto enough)
<RP>
maciej_mrozowski: I'm just trying to explain why we do what we currently do and why changing to do what you're suggesting might not work for us :/
<Guest92>
qschulz i suppose the issue is itstool is still checking in aarch64-fsl-linux for native libs but it should search in x86_64 path.. but then again python3-native is found in the aarch64-fsl-linux path so it is expecting site-packages in the same path?
User553 has quit [Ping timeout: 250 seconds]
<qschulz>
Guest92: recipes have native sysroots available
Schlumpf has joined #yocto
<qschulz>
Guest92: this means that yes, you'll find native stuff in work/aarch64-fsl-linux
<qschulz>
but it's sysroots only
<qschulz>
Guest92: there are multiple questions actually
<qschulz>
the first one, we need to figure out if you need libxml2 during compile time for host python or if you need libxml2 for headers or libraries to link against for the target
<qschulz>
if former, you need libxml2-native, if latter, libxml2 in DEPENDS
<qschulz>
then, you need to check if what's required by your recipe is present in the native or target sysroot
<qschulz>
if not, then it's an issue in libxml2 recipe
<qschulz>
if yes, then it's likely an issue in your recipe
<qschulz>
might be that not all flags are passed or it pointsa to the incorrect sysroot for some reason
<Guest92>
qschulz Oh k. I am sure libxml2-native is required.
<Guest92>
I don't know how the sysroots are populated .. I can see recipe-sysroot-native path is empty but sysroot-destdir has the x86_64 libs..
<Guest92>
Libs not present in recipe-sysroot-native:
<Guest92>
$ ls /exports/5g-git-build/tmp/work/x86_64-linux/libxml2-native/2.9.10-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/
<Guest92>
README.txt
<Guest92>
Libs present in sysroot-destdir/../recipe-sysroot-native
<Guest92>
$ ls /exports/5g-git-build/tmp/work/x86_64-linux/libxml2-native/2.9.10-r0/sysroot-destdir/exports/5g-git-build/tmp/work/x86_64-linux/libxml2-native/2.9.10-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/
<Guest92>
drv_libxml2.py libxml2mod.so libxml2.py
<Guest92>
Libs should be present here?
<Guest92>
$ ls /exports/5g-git-build/tmp/work/aarch64-fsl-linux/libxml2/2.9.10-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/
<Guest92>
README.txt rpm
<Guest92>
qschulz same issue in /exports/git-build btw.. created another build root yesterday just to rebuild from scratch but same issue there
<jclsn9040>
landgraf: Any updates on the PREMIRRORS bug?
jclsn9040 is now known as jclsn
<jclsn>
I was also wondering, because I have these issues on gatesgarth. The bug is probably in master, isn't it?
Guest92 has quit [Quit: Client closed]
kroon has quit [Quit: Leaving]
codavi has joined #yocto
ar__ has quit [Ping timeout: 250 seconds]
Schlumpf has joined #yocto
User553 has joined #yocto
dlan has quit [Ping timeout: 272 seconds]
dlan has joined #yocto
maciej_mrozowski has quit [Quit: Client closed]
kriive has joined #yocto
rber|res has joined #yocto
Guest92 has joined #yocto
<Guest92>
qschulz solved it! this is so weird.. there were two recipes for libxml2 .. 2.9.2 and 2.9.10 and I had set PREFERRED_VERSION_libxml2="2.9.10" in machine.conf but turns out PREFERRED_VERSION_libxml2-native also needs to be set! it was using recipe-sysroot-native from 2.9.2 version which did not have any libs generated! it should have selected the
<Guest92>
higher version by default? but for some reason it was picking up 2.9.2 for native recipe
Guest6 has joined #yocto
<Guest92>
qschulz thanks for your pointer about different sysroot for native!
<paulbarker>
Hi folks, I'm looking at plans for the YP summit next month. Will there be a developer meeting as well as the presentations?
Guest6 has quit [Quit: Connection closed]
<RP>
paulbarker: tlwoerner would know
<paulbarker>
RP: I'd like to propose a discussion on layer metadata licensing (which I know there were some emails on recently on the licensing list as well). Probably better for the developer meeting if there will be one
<RP>
paulbarker: fair enough. Do you have a different view to what I replied with out of interest?
<qschulz>
Guest92: layer priority dictates the version of a recipe that will be used, so no, not necessarily the highest version number!
<paulbarker>
RP: I've got the meta-sancloud layer passing `reuse lint` and would like to see what others think to using that spec & tool.
Thomas12 has joined #yocto
<paulbarker>
I also think the points you and Konrad covered need spreading to other folks as it's not something that's often understood
pbergin__ has joined #yocto
<Guest92>
qschulz wow! will check the layer priority! thanks!!
<RP>
paulbarker: so copyright and spdx license identifiers in every file
<paulbarker>
RP: Yes. Easy enough for metadata but achieving that for patch files is less straight forward and is something I'd like to hear other opinions on
pbergin_ has quit [Ping timeout: 240 seconds]
<RP>
paulbarker: even for metadata I think there is a problem - it will confuse people who think it relates to the target recipe :(
<RP>
paulbarker: as for copyright about all we can do is claim it for "OpenEmbeded/Yocto project contributors" and I'm not sure that helps us much in reality
<RP>
paulbarker: anyway, yes, I guess it needs discussion. I just don't know we'll like the conclusions
<paulbarker>
RP: `reuse lint` has support for a top-level `.reuse/dep5` file to store copyright/licensing info which would help avoid confusion as it woudn't be in the recipe files themselves
<paulbarker>
The dep5 format is awkward but we could propose improvements if it's something we needed
<RP>
paulbarker: I was just looking at what you did in meta-sancloud. Do you have an example of a dep5 file somewhere?
OutBackDingo has joined #yocto
<paulbarker>
RP: We didn't need one so I don't have an example. The format is briefly described at https://reuse.software/spec/#dep5
<Thomas12>
Hi,
<Thomas12>
I'm using core-image-weston. When I interact with the screen, e.g. typing something in the terminal window, it sometimes (rather often) suddenly pops into the terminal login view when I stop typing. If I move the mouse or continue typing I come right back into the desktop. It happens like 1 second after I stop typing. Sometimes it doesn't happen at
<Thomas12>
all.
<Thomas12>
The lock screen is different, as it shows a small window with a green circle in it. has anybody ever experienced the same?
<RP>
paulbarker: thanks. Looks like wildcards are supported so there is some potential there I guess
<paulbarker>
RP: I think my main goal would be to widen understanding of metadata licensing (including GPL licenses classes), share experience and ideas for clarifying things in a machine readable way (such as by following the reuse spec, but there may be other options)
<RP>
paulbarker: I'm just worried this will end up going a similar way to the inclusive language work. We should try and work out a way forward with this, I just worry about the net impact on my workload. Which is a rather selfish viewpoint :/
<paulbarker>
RP: Nothing selfish about trying to keep the project sustainable
<RP>
paulbarker: I'm feeling a bit sensitive at the moment. I need to take a break, urgently but nobody else is going to debug and get the release out :(
<RP>
In debugging the release blocker, I've noticed other problems. I can't decide whether I should share them or just keep quiet since nobody else seems to have noticed or care
<RP>
paulbarker: anyway, I'm digressing, sorry
xmn has joined #yocto
<kanavin>
RP: I can pick up the adwaita item, I'd start by checking buildhistory-diff there
<manuel1985>
Is anyone using the LICENSE_CREATE_PACKAGE feature? I'm having issues using it with NO_RECOMMENDATIONS and adding license packages individually.
<LetoThe2nd>
paulbarker: there will be an oedvm too, the friday right after. i'm just spreading the different announcements apart a bit, the oedvm announce would come next week.
<RP>
kanavin: Thanks. I'm very tempted just to revert that upgrade for now but we will have to work out the issue one way or another at some point
<kanavin>
RP: that's fine too, it'll take me until tomorrow probably
troth has joined #yocto
<RP>
kanavin: I did confirm that reverting out of master did also resolve it so it at least clear cut where the issue is
<RP>
kanavin: we don't have an understanding of where the second issue is yet and it sounds like QA will have to debug that one as I can't reproduce. That means we do have some time
Austriker has joined #yocto
sakoman has joined #yocto
<Austriker>
Hi, I am trying to give fine grain folder access to my users in my image. So I want to do a bindfs of the specific folder into the home of the user. I tried to use the VOLATILE_BINDS and I have added volatile-binds in the IMAGE_INSTALL but it doesn't seem to work. Does volatile-binds only work when the rootfs is readonly (which is currently not the
<RP>
kanavin: you might know the answer to this. I usually run "runqemu qemux86-64 kvm". This ends up passing no parameters into the graphics options for qemu which results in show-cursor being missed. If you enable gtk, the menus are also corrupted. If you pass "sdl" or "gtk" to runqemu, it works
<RP>
kanavin: is there something we can to to make runqemu "autodetect" correctly?
<RP>
kanavin: it isn't as bad as I thought initially, its probably just the way I use it ended up broken
<RP>
(the menu corruption is from the font config being missed since gtk wasn't specified)
<kanavin>
RP: I think show-cursor is a part of -display option, and can't be set independently?
<RP>
kanavin: right
<RP>
kanavin: but if no display option is passed, can we "fix" that?
Thomas12 has quit [Quit: Client closed]
<RP>
kanavin: qemu --help says The default display is equivalent to "-display gtk"
<RP>
but I suspect that is configuration dependent
<kanavin>
RP: I think so too, and passing -display sdl (or gtk) by default will not go down well with people who don't want any display
<kanavin>
(and have configured qemu to disable both sdk and gtk)
<RP>
kanavin: Right. We may need to run qemu --help and parse which to use
<kanavin>
RP: or pass -display none
<kanavin>
RP: I was never comfortable with qemu attempting graphical output by default tbh
<kanavin>
it's prone to break if the environment isn't set for it
Austriker has quit [Ping timeout: 250 seconds]
<RP>
kanavin: it is expected though and I think the quick start may depend on it (I haven't checked recently)
pbergin_ has joined #yocto
pbergin__ has quit [Ping timeout: 246 seconds]
GLumen has joined #yocto
User553 has quit [Quit: Client closed]
Schiller has joined #yocto
<Schiller>
I have the YPAutobuilder running inside a Docker. Now i try to mount a directory as the builddirectory so my builds are accessable outside of the container. Permissions UID and GID are pokybuild3. I still get the Error <<rm: cannot remove '/home/pokybuild3/yocto-worker/meta-plusoptix/': Device or resource busy>>, which i do not understand
<Schiller>
in Buildstep 1 Clobber build dir
<qschulz>
Schiller: might want to check if you have SELinux enabled
<qschulz>
in whcih case, you need to properly label your volumes
<qschulz>
(or disable labelling, with --security-opt label=disable)
<kanavin>
RP: I think a revert might be the best way out. upstream did a mass purge of 'legacy' low res bitmap icons, and will also phase out 'generic app' icons in the svg format, saying that all apps must carry their own icons.
<kanavin>
I'll look into why svg icons aren't picked up, but those aren't for long either anyway.
pbergin_ has quit [Quit: Leaving]
<RP>
kanavin: that sounds like a good reason things are breaking and a good reason to revert for now
<qschulz>
/rant how is one supposed to figure out the proper licensing of newlib? there is ~50 licenses, almost none an exact match of known licenses, some inspired by BSD, some... well very much custom...
manuel1985 has quit [Remote host closed the connection]
<RP>
kanavin: revert and a "fix" for runqemu sent. Thanks for the help, I'm using your summary of things :)
manuel1985 has joined #yocto
Guest92 has quit [Quit: Client closed]
<kanavin>
RP: Thanks, the summaries are ok. I'm poking a bit more at the icon issue, but will go for a bike ride now.
frieder has quit [Remote host closed the connection]
ecdhe_ has quit [Ping timeout: 248 seconds]
Austriker has joined #yocto
ecdhe has joined #yocto
<RP>
kanavin: good plan! :)
Austriker has quit [Quit: Client closed]
manuel1985 has quit [Ping timeout: 260 seconds]
manuel1985 has joined #yocto
Schiller has quit [Quit: Client closed]
<kergoth>
i hate it when i notice a bug in somethign i just submitted. at least it wasn't 5 minutes after this time
Schlumpf has quit [Quit: Client closed]
<amahnui[m]>
Hello everyone, Please I would like to ask if there is a particular method that I can use to know which commands to use when attempting to test specific scripts or just the try and error method works.
<amahnui[m]>
For instance If I make a change to a shell script in scripts directory, is there a a way to know the particular command to use for testing or I will have to do try and error to know the command that works?
<kergoth>
if you're talking about oe-core scripts, which you haven't said, you can run oe-selftest to run the test suite, if it covers it
<kergoth>
'specific scripts' is super vague :)
<amahnui[m]>
I'm sorry about that.
<amahnui[m]>
scripts/bitbake-prserv-tool is one of the scripts I'm talking about
<RP>
amahnui[m]: you can always search for information about what uses that tool, e.g. "grep prserv-tool * -R"
<kergoth>
What.. if you use ${@} in a docstring at the beginning of a def'd python function, bitbake tries to expand it at parse time in code analysis? what? that's a python function, it shouldn't be expanding in it at all
<RP>
kergoth: which version? Didn't we stop it expanding variables in python code?
<RP>
kergoth: wouldn't surprise me though
<kergoth>
that's what i thought. it's current bitbake master, rev 41eeb4f3, that any_incompatible function i submitted broke parsing though i swear i tested it. /eyeroll
<kergoth>
i'll open a bug
<tlwoerner>
paulbarker: there is an upcoming Yocto Project Summit, the CFP closes two weeks from yesterday, please (everyone) get your proposals in!
<tlwoerner>
my understanding is that the OE BoD is planning a developers meeting on the friday after the summit. i'm not involved with planning that event
<jsbronder>
If I want to use sstate.yoctoproject.org, what do I need to do aside from setting SSTATE_MIRRORS? Right now I'm not getting any cache hits when bitbaking.
<qschulz>
jsbronder: need to set the hashequiv server to point to the one hosted by yoctoproject too
<jsbronder>
qschulz: So run my own bitbake-hashserv with --upstream set to something?
<qschulz>
jsbronder: BB_HASHSERVE_UPSTREAM in your local.conf
<qschulz>
jsbronder: you'd need to use the upstream one directly I believe
<qschulz>
but I've not setup any of this yet
<qschulz>
and I don't really plan to (hosting your own sstate mirror and hashequiv serv makes more sense IMO)
troth has quit [Ping timeout: 246 seconds]
<qschulz>
just build once locally to populate your sstate and hashequiv and then it should be enough?
<jsbronder>
This is for the workspaces where I do work I plan to contribute back, not the ones for $DAYJOB. If I'm trying to track master/kirkstone closely, then I'm getting big rebuilds frequently that I was hoping to avoid.
Perceval[m] has quit [Quit: You have been kicked for being idle]
OutBackDingo has quit [Ping timeout: 240 seconds]
<RP>
jsbronder: also, is your local config similar to something the autobuilder would build?
<jsbronder>
I believe so.
<RP>
jsbronder: fair enough, just checking. You will need BB_HASHSERV_UPSTREAM set for sstate to work
<qschulz>
RP: not this one, because it is redirected, but anything that is returned by Google with a direct link
<jsbronder>
RP: I had bookmarks to yoctoproject.org/docs/current/ thinking I'd always get the latest that way. So my mistake not noticing the version number wasn't changing.
<qschulz>
jsbronder: we need to add a big fat red header to that website
<RP>
These old links should be redirecting to docs.yoctoproject.org :/
<RP>
halstead: can we figure out what is going on there please?
<jsbronder>
RP: in particular then, BB_SIGNATURE_HANDLER = "OEEquivHash"
florian has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
<amahnui[m]>
RP: I'm currently downloading it. Once it's downloaded I would like to ask some few questions on how to proceed.
<RP>
amahnui[m]: You will need to figure out what the HTML to show the warning would look like. I don't know myself
paulg has joined #yocto
<qschulz>
amahnui[m]: and ideally make it responsive so it does not look awful on a phone/tablet/small PC
<amahnui[m]>
The warning will contain the link to the most current website right?
<amahnui[m]>
qschulz: I think if there is a theme for the css then I will try to make it inherit the properties of the existing css on the page if possible.
<qschulz>
amahnui[m]: anything different from 3.1 releases should mention it is outdated and encourage to update to a newer version
<halstead>
RP: Yes. I didn't find that link. I can figure this out now.
sakoman has quit [Ping timeout: 260 seconds]
<kergoth>
huh, how did i miss that INIT_MANAGER exists now
<RP>
kergoth: I keep meaning to get poky to use that
<kergoth>
Going through the mentor/siemens distro line by line, been ages since I did that :)
<kergoth>
Try to go through our main layers line by line file by file after every major release, but always hit time constraints
<RP>
kergoth: How many times did you wonder what you were thinking? :)
* RP
does that far too often :/
<kergoth>
Hah, repeatedly. "where the hell did this come from?" "why didn't i push that again?"
Tokamak has quit [Read error: Connection reset by peer]
<kergoth>
then comes digging into the git logs and jira issues
<kergoth>
then trying to repro issues that had oddball workarounds..
<halstead>
RP: All aliases to the old docs are now redirects to the new docs in the server config.
<RP>
kergoth: I had patches in master-next with reverts and I ended up having to revert the reverts and run on the autobuilder to remember what I needed to fix
<RP>
halstead: awesome, thanks!
<halstead>
RP: Thank you for helping me locate the issue.
sakoman has joined #yocto
Tokamak has joined #yocto
<amahnui[m]>
Does that mean I no longer need to work on it?
bonalais has joined #yocto
<amahnui[m]>
I mean on adding the header.
<RP>
amahnui[m]: no, we still need that for docs.yoctoproject.org
<amahnui[m]>
RP: I downloaded the zipped file you sent here and it contains a set of folders from 0.9 to 3.1.3. please which folder corresponds to docs.yoctoproject.org here.
<halstead>
ndec: I've backed out the change for the moment.
<ndec>
hmm. you either are super fast, or you had done the change already :)
<RP>
ndec: I have a handy sed command ;-)
<ndec>
still.. it would have taken me longer than that to figure out the sed command :)
<RP>
amahnui[m]: all of those are on docs.yoctoproject.org and we need to add a banner to all of them. Pick one and figure out how to do it, then we can script something to add to each one
<RP>
ndec: I didn't actually test the result I guess
<ndec>
heh
<RP>
we have michaelo and the autobuilder for that
<amahnui[m]>
RP: okay thanks I will commence with it right away
<amahnui[m]>
ndec: okay I will
<amahnui[m]>
Thanks for the pointer
tnovotny has quit [Quit: Leaving]
<RP>
kergoth: have a closer look at your patch as I wasn't talking about the example
<RP>
or I'm missing something
<kergoth>
RP: it’s in the function docstring.
<kergoth>
Not the actual code
<RP>
kergoth: look later in the patch you sent
<kergoth>
No worries. It’s trivial but found it helpful when we were actively supporting gplv2 builds.
<RP>
kergoth: I'd swear that patch edits meta/recipes-core/packagegroups/packagegroup-base.bb
<kergoth>
Oh, crap, I’m blind. Thanks!
<kergoth>
I’ll send a v3 later
barometz has quit [Quit: you can't fire me!]
barometz has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
Vonter has quit [Quit: WeeChat 3.5]
otavio has quit [Ping timeout: 250 seconds]
Vonter has joined #yocto
vladest has joined #yocto
Vonter has quit [Client Quit]
<landgraf>
jclsn: I haven't touch it for a while (and it is not assigned to me yet iirc... )
callum has quit [Ping timeout: 250 seconds]
Vonter has joined #yocto
otavio has joined #yocto
<jclsn>
landgraf: Will have to look into it I guess, although it is not really a show stopper
<jclsn>
Just something to complete my sprint
florian_kc has joined #yocto
otavio has quit [Ping timeout: 240 seconds]
otavio has joined #yocto
florian_kc is now known as florian
<amahnui[m]>
RP: ndec: None of the version folders contained an `index.html file`, so I decided to the banner to the `mega-manual.html` but it does not seem right. should I leave it in `mega-manual`?
<ndec>
Yes, you should modify the .html files like mega-manual.html. Or any other file references in the yocto doc transition branch
linums has joined #yocto
<amahnui[m]>
Okay I will do just that.
<RP>
landgraf: you'd be welcome to work on it!
<landgraf>
RP: I spent some time on it need to find better way to fix it without introducing new exception :)
<RP>
landgraf: I have lost track of the context so I can't really comment
<amahnui[m]>
Here is a screenshot of how it looks in my local environment.
<RP>
amahnui[m]: if you scroll the document does that remain at the top displayed? It does look like what we need
<amahnui[m]>
Yes it remains at the top displayed.
<amahnui[m]>
* RP: Yes it
<RP>
amahnui[m]: sounds good!
<amahnui[m]>
RP: Thanks, How do we proceed with the script to add to each one, Or it will be done manually for each version and page.
<RP>
amahnui[m]: I'm not familiar with how standard the files are and therefore I don't know what the easiest approach would be. Perhaps you could share the change as a patch so we could review it before we change everything
<RP>
?
<amahnui[m]>
RP: The issue is this directory is not a git directory, can you please point to the link of the repository so I can clone and do the changes in it? or is it the yocto-docs repo?
<RP>
amahnui[m]: it isn't a repository anywhere. You can create a patch by using diff -u on the commandline to show the difference between two files
<amahnui[m]>
sorry my data got finished
<amahnui[m]>
RP: the yocto-docs I have here has just .rst files instead of .html how do I generate the .html from it.
<RP>
amahnui[m]: these are old files from before we had sphinx. We had docbook docs back then
<amahnui[m]>
RP: That means I will run `git init` then run `diff -u <changed file> <unchanged file>` then do `git send-email`?
<RP>
amahnui[m]: you don't have to use git but I guess something like that could work
<amahnui[m]>
Please I wish to ask to send a patch without using git.
bonalais has quit [Quit: Connection closed for inactivity]
florian has joined #yocto
mvlad has quit [Remote host closed the connection]
linums has quit [Quit: Client closed]
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
florian has quit [Ping timeout: 248 seconds]
sgw has quit [Ping timeout: 240 seconds]
sgw has joined #yocto
<amahnui[m]>
I did so and ran `diff -u a b ` but I'm facing difficulties staging the differences
sakoman has quit [Read error: Connection reset by peer]
sakoman has joined #yocto
gsalazar has quit [Ping timeout: 256 seconds]
codavi has quit [Ping timeout: 246 seconds]
willo has quit [Ping timeout: 240 seconds]
willo has joined #yocto
tgamblin has quit [Quit: Leaving]
tgamblin has joined #yocto
leon-anavi has quit [Quit: Leaving]
GLumen has quit [Read error: Connection reset by peer]