Wednesday, 2022-04-13

*** jclsn904 <jclsn904!> has quit IRC (Ping timeout: 250 seconds)00:16
*** jclsn904 <jclsn904!> has joined #yocto00:18
zeddiiI've been watching the gcc 12 threads on lkml, yah, there are still problems00:19
zeddiibut 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)00:20
zeddii(and a thread from 7 hours ago: gcc inserts __builtin_popcount, causes 'modpost: "__popcountdi2" ... amdgpu.ko] undefined' )00:24
*** jclsn904 <jclsn904!> has quit IRC (Ping timeout: 240 seconds)00:24
*** jclsn904 <jclsn904!> has joined #yocto00:29
*** qschulz <qschulz!> has quit IRC (Remote host closed the connection)00:32
*** qschulz <qschulz!> has joined #yocto00:35
*** jclsn904 <jclsn904!> has quit IRC (Ping timeout: 240 seconds)00:37
*** jclsn904 <jclsn904!> has joined #yocto00:42
*** sakoman <sakoman!> has joined #yocto00:46
*** jclsn904 <jclsn904!> has quit IRC (Ping timeout: 240 seconds)00:50
*** jclsn904 <jclsn904!> has joined #yocto00:56
*** jclsn904 <jclsn904!> has quit IRC (Ping timeout: 260 seconds)01:03
*** jclsn904 <jclsn904!> has joined #yocto01:06
*** jclsn904 <jclsn904!> has quit IRC (Ping timeout: 260 seconds)01:19
*** troth <troth!> has quit IRC (Ping timeout: 250 seconds)01:21
*** jclsn904 <jclsn904!> has joined #yocto01:25
*** jclsn904 <jclsn904!> has quit IRC (Ping timeout: 250 seconds)01:30
*** troth <troth!> has joined #yocto01:35
*** jclsn904 <jclsn904!> has joined #yocto01:35
*** jclsn904 <jclsn904!> has quit IRC (Ping timeout: 250 seconds)01:47
*** jclsn904 <jclsn904!> has joined #yocto01:53
*** starblue <starblue!> has quit IRC (Ping timeout: 256 seconds)02:01
*** jclsn904 <jclsn904!> has quit IRC (Ping timeout: 256 seconds)02:02
*** starblue <starblue!> has joined #yocto02:03
*** jclsn904 <jclsn904!> has joined #yocto02:08
*** jclsn904 <jclsn904!> has quit IRC (Quit: Ping timeout (120 seconds))02:23
*** jclsn904 <jclsn904!> has joined #yocto02:23
*** jclsn9040 <jclsn9040!> has joined #yocto02:27
*** jclsn904 <jclsn904!> has quit IRC (Ping timeout: 248 seconds)02:29
*** jclsn9040 <jclsn9040!> has quit IRC (Ping timeout: 256 seconds)02:33
*** jclsn9040 <jclsn9040!> has joined #yocto02:39
*** jclsn9040 <jclsn9040!> has quit IRC (Ping timeout: 250 seconds)03:01
*** jclsn9040 <jclsn9040!> has joined #yocto03:07
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 -
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto04:36
*** amitk <amitk!~amit@> has joined #yocto04:42
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:48
*** alessioigor <alessioigor!~alessioig@> has joined #yocto05:09
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Client Quit)05:10
OutBackDingopffft this is so confusing05:23
OutBackDingoIf 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.05:23
OutBackDingosooo...  how is this accomplished05:24
OutBackDingoif i have a /25 subnet, do i add that to carp interfaces05:24
OutBackDingoso...  carp the whole /25 ?05:37
OutBackDingoVHID 1 must be defined on interface WAN as a CARP VIP first. ughhh nope05:40
OutBackDingono idea how this gets configured05:46
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto06:04
*** rfuentess <rfuentess!> has joined #yocto06:13
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto06:17
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)06:17
*** camus <camus!~Instantbi@2409:8a1e:911c:7f00:5c50:8f8e:553:941f> has joined #yocto06:22
*** camus <camus!~Instantbi@2409:8a1e:911c:7f00:5c50:8f8e:553:941f> has quit IRC (Client Quit)06:25
*** Wouter0100 <Wouter0100!> has quit IRC (Read error: Connection reset by peer)06:25
*** Wouter0100 <Wouter0100!> has joined #yocto06:25
*** kroon <kroon!> has joined #yocto06:28
*** pbergin <pbergin!~pbergin@> has joined #yocto06:30
*** OutBackDingo <OutBackDingo!~quassel@> has quit IRC (Quit: - Chat comfortably. Anywhere.)06:50
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:50
*** OutBackDingo <OutBackDingo!~quassel@> has joined #yocto06:52
*** frieder <frieder!> has joined #yocto06:53
*** Net147 <Net147!~Net147@user/net147> has quit IRC (Quit: Quit)06:54
*** Net147 <Net147!> has joined #yocto06:54
*** tnovotny <tnovotny!> has joined #yocto06:55
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto06:57
*** Guest5 <Guest5!~Guest5@> has joined #yocto07:02
*** mckoan|away is now known as mckoan07:05
mckoangood morning07:05
*** kranzo <kranzo!> has joined #yocto07:10
*** florian <florian!> has joined #yocto07:19
*** OutBackDingo <OutBackDingo!~quassel@> has quit IRC (Quit: - Chat comfortably. Anywhere.)07:20
*** OutBackDingo <OutBackDingo!~quassel@> has joined #yocto07:22
*** florian_kc <florian_kc!> has joined #yocto07:24
*** florian <florian!> has quit IRC (Read error: Connection reset by peer)07:25
*** florian__ <florian__!> has joined #yocto07:26
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Quit: WeeChat 3.5)07:26
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto07:28
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Client Quit)07:29
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto07:29
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)07:29
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto07:36
*** troth <troth!> has quit IRC (Ping timeout: 260 seconds)07:41
mckoangood morning qschulz, all07:41
*** Fanfwe <Fanfwe!> has joined #yocto07:49
*** troth <troth!> has joined #yocto07:56
*** Schiller <Schiller!> has joined #yocto08:02
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:681c:e269:e506:c767> has quit IRC (Ping timeout: 248 seconds)08:04
*** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Quit: Leaving)08:09
*** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has joined #yocto08:17
*** xmn <xmn!> has quit IRC (Ping timeout: 250 seconds)08:41
*** OutBackDingo <OutBackDingo!~quassel@> has quit IRC (Quit: - Chat comfortably. Anywhere.)08:47
amahnui[m]Hello 👋09:13
amahnui[m]Please I wish to ask how long it takes for changes made to the to be adopted to the main website?09:13
amahnui[m]After being merged09:15
*** troth <troth!> has quit IRC (Ping timeout: 250 seconds)09:17
*** maciej_mrozowski <maciej_mrozowski!~maciej_mr@> has joined #yocto09:18
*** pbergin_ <pbergin_!> has joined #yocto09:18
*** pbergin <pbergin!~pbergin@> has quit IRC (Ping timeout: 240 seconds)09:20
*** troth <troth!> has joined #yocto09:22
maciej_mrozowskiI 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 seem09:23
maciej_mrozowskito support finding native sdk dependencies. Neither PKG_CONFIG_PATH points to native sysroot, nor  CMAKE_FIND_ROOT_PATH does.09:23
RPkanavin: I don't suppose you have any ideas on ?09:23
maciej_mrozowskiAm 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)09:24
RPI've started a bisect to try and narrow it down, so far it looks like between the 17th and 27th march ish09:24
kanavinRP: not right now, no09:24
RPkanavin: thought it was worth asking just in case, thanks09:25
kanavinit'll probably be some version update from the gtk/glib stack09:25
RPkanavin: or rust and svg09:25
RPmaciej_mrozowski: it depends on the context. If you're building the nativesdk variant of the recipe, it should have nativesdk PKG_CONFIG_PATH setup09:26
RPmaciej_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 though09:28
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)09:30
maciej_mrozowskiRP: 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 located09:32
maciej_mrozowskiinside this sdk.09:32
RPmaciej_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?09:33
maciej_mrozowskiCorrect, .pc file installed in /usr/share/pkgconfig (and <package>-config.cmake installed in /usr/share/cmake/<package>)09:34
RPmaciej_mrozowski: the SDK doesn't support that, it only supports building for the target, not  nativesdk09:35
RPmaciej_mrozowski: it would confuse too many people09:35
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.09:37
maciej_mrozowskiI think my use case is not "sdk building for nativesdk", but "sdk using nativesdk"09:38
amahnui[m]I wish to ask if it is advisable to use $(...) notation instead of legacy backticked '...'  in shell scripts?09:38
RPmaciej_mrozowski: effectively you're talking about a cross tool and there is no .pc support for cross tools09:40
RPmaciej_mrozowski: it isn't something pkg-config itself supports09:40
*** kranzo <kranzo!> has quit IRC (Quit: Client closed)09:40
maciej_mrozowskiRP: pkg-config supports /usr/share/pkgconfig though which is location for arch-agnostic modules, and there is
maciej_mrozowskiI can assume this is Yocto imposed limitation though09:45
RPmaciej_mrozowski: well, nobody has ever made a case for including the nativesdk datadir pkgconfig inside the target pkgconfig env09:45
RPmaciej_mrozowski: note that there would be two datadir pkgconfig areas, the one in the target sysroot and the one in the nativesdk sysroot09:46
RPmaciej_mrozowski: and if you do that, you'd have the issue that the compiler sysroot can't see inside the nativesdk sysroot09:46
RPso whilst I can see your argument, I don't think it would work well in general09:47
*** m_jimmer12345 <m_jimmer12345!~m_jimmer1@> has quit IRC (Quit: Client closed)09:47
kanavinRP: let me know once you get to the offending commit (if it isn't obvious)09:49
RPkanavin: Will do. It is going to take a while as it is a new rust build every time09:49
maciej_mrozowskiRP "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  "see09:50
maciej_mrozowskinativesdk sysroot"?09:50
kanavinRP: hopefully rust will not be rebuilt once the bisection set gets smaller09:50
RPmaciej_mrozowski: we call gcc --sysroot=<target-sysroot> so the compiler will not see the nativesdk sysroot files at all09:51
RPkanavin: you'd think/hope but not so far and I see rust changes in the bisect window09:51
RPkanavin: I should have probably done this on an autobuilder with more sstate in hindsight09:52
*** troth <troth!> has quit IRC (Ping timeout: 246 seconds)09:53
maciej_mrozowskiRP ah, yeah, you are correct, my particular use case doe not end up passing include paths (which would not be resolvable within target-sysroot)09:53
RPmaciej_mrozowski: we do have to think about the wider case though :/09:54
kanavinRP: I am meanwhile trying to get another effort at pending patches submission going :)09:54
RPmaciej_mrozowski: where we have this in other cases I think we use ${bindir_crossscripts}09:55
RPmaciej_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 env09:56
*** florian__ is now known as florian09:56
RPkanavin: 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 too09:56
RPkanavin: I found a few weird license patches we could drop which was a nice cleanup09:57
*** starblue <starblue!> has quit IRC (Ping timeout: 256 seconds)10:02
*** troth <troth!> has joined #yocto10:03
*** starblue <starblue!> has joined #yocto10:04
maciej_mrozowskiRP 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.10:04
*** Guest5 <Guest5!~Guest5@> has quit IRC (Quit: Client closed)10:05
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)10:06
RPmaciej_mrozowski: you have a weird corner case unfortunately and there aren't easy answers10:08
*** maciej_mrozowski <maciej_mrozowski!~maciej_mr@> has quit IRC (Quit: Client closed)10:10
*** maciej_mrozowski <maciej_mrozowski!~maciej_mr@> has joined #yocto10:10
*** Schiller <Schiller!> has quit IRC (Ping timeout: 250 seconds)10:12
*** Guest92 <Guest92!~Guest92@> has joined #yocto10:14
Guest92hello everyone10:14
maciej_mrozowskiRP I think I came here more like for a wider opinion on how to tackle this use case in Yocto, preferably opinion from upstream.10:16
mckoanGuest92: hi10:16
maciej_mrozowski(maybe I'll start topic on ML)10:17
RPmaciej_mrozowski: for better or worse I helped design some of this and I'm not sure there is a good way to improve it10:17
Guest92can 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.10:18
*** troth <troth!> has quit IRC (Ping timeout: 240 seconds)10:20
Guest92| configure: error: Python module libxml2 is needed to run this package10:20
Guest92it 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 path10:20
*** Guest5 <Guest5!~Guest5@> has joined #yocto10:22
qschulzGuest92: did you add libxm2-native to your DEPENDS?10:22
maciej_mrozowskiRP 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 sysroot10:24
maciej_mrozowskionly "shared" modules and never "library" or "target" modules.10:24
*** User553 <User553!> has joined #yocto10:24
Guest92yes in :10:25
Guest92DEPENDS = "libxml2-native"10:25
Guest92BBCLASSEXTEND = "native nativesdk"10:25
Guest92RDEPENDS_${PN} += "libxml2-python"10:25
Guest92RDEPENDS_${PN}_class-native = ""10:25
*** florian <florian!> has quit IRC (Read error: Connection reset by peer)10:26
*** florian_kc <florian_kc!> has joined #yocto10:26
User553hello 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? Thx10:27
maciej_mrozowskiGuest92 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 dependency10:28
RPmaciej_mrozowski: that is my worry too10:28
RPmaciej_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 problem10:28
dwagenkMaybe 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 additional10:32
dwagenkvirtual hard-disk.10:32
Guest92maciej_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..10:34
*** troth <troth!> has joined #yocto10:34
dwagenkNow 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 would10:35
dwagenkneed to depend on the u-boot for qemu and set the correct QB_* options?10:35
qschulzGuest92: smells like your DEPENDS isn't taken into account somehow10:36
qschulzGuest92: can you check with bitbake -e itstool | grep ^DEPENDS= ?10:36
Guest92qschulz it's empty!10:38
Guest92$ bitbake -e itstool | grep ^DEPENDS=?10:38
*** florian_kc is now known as florian10:39
maciej_mrozowskiRP 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 respective10:41
maciej_mrozowskisdks  sysroots can be handled by proper search path order (target sysroot first, nativesdk sysroot at the end).10:41
maciej_mrozowskiAnyway i guess I can start some wider discussion on the subject on ML (and meanwhile I'll work it around in my env)10:42
Guest92qschulz I removed =? from grep and this is what I get now10:43
Guest92$ bitbake -e itstool | grep -i ^DEPENDS10:43
Guest92DEPENDS="pkgconfig-native autoconf-native automake-native libtool-native libtool-cross gnu-config-native  virtual/aarch64-fsl-linux-gcc virtual/aarch64-fsl-linux-compilerlibs virtual/libc libxml2-native python3-native "10:43
RPmaciej_mrozowski: we can have a wider discussion and from a technical aspect it is "easy" but I think the end result would be confusing :/10:44
qschulzGuest92: so libxml2-native wil be built before itstool that's for sure10:45
qschulzGuest92: the question mark was for the question punctuation, not an actual character for the command (though = was, but it works without just fine)10:46
maciej_mrozowskiRP anyway, thanks!10:46
RPmaciej_mrozowski: Let me give you a more evidence based answer10:48
*** rfuentess <rfuentess!> has quit IRC (Remote host closed the connection)10:48
RPmaciej_mrozowski: - you'll see a list of arch independent pc files there from the native builds on my system10:49
RPmaciej_mrozowski: I suspect several of those would break the target build if injected into the pkg-config patch10:49
Guest92qschulz haha ok10:50
Guest92but this means libxml2-native is not producing the native libs; only the target libs10:50
Guest92$ ls /exports/git-build/tmp/work/aarch64-fsl-linux/libxml2/2.9.10-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/10:50
Guest92README.txt  rpm10:50
Guest92$ ls /exports/git-build/tmp/work/aarch64-fsl-linux/libxml2/2.9.10-r0/sysroot-destdir/usr/lib/python3.8/site-packages/10:50  libxml2.py10:50
Guest92$ file /exports/git-build/tmp/work/aarch64-fsl-linux/libxml2/2.9.10-r0/sysroot-destdir/usr/lib/python3.8/site-packages/libxml2mod.so10:50
Guest92 exports/git-build/tmp/work/aarch64-fsl-linux/libxml2/2.9.10-r0/sysroot-destdir/usr/lib/python3.8/site-packages/ ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=fe911a45fe9bb10bb360a9ccef0b3a64f7106a30, stripped10:51
Guest92the generated so is for aarch6410:51
*** Guest5 <Guest5!~Guest5@> has quit IRC (Quit: Client closed)10:52
qschulzGuest92: because you're looking at the target libxml2 and not the host (native) libxml210:52
qschulzthey are built in different directories10:52
maciej_mrozowskiRP 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.10:52
maciej_mrozowski(hence confusing)10:52
*** Guest92 <Guest92!~Guest92@> has quit IRC (Quit: Client closed)10:52
qschulzGuest92: /exports/git-build/tmp/work/x86_64, or something like that should be where libxml2-native directory should be10:52
maciej_mrozowski*but that *should* fail at pkgconfig already10:53
RPmaciej_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 headers10:54
RPmaciej_mrozowski: that isn't an improvement IMO10:54
*** Guest92 <Guest92!~Guest92@> has joined #yocto10:55
qschulzGuest92: /exports/git-build/tmp/work/x86_64, or something like that should be where libxml2-native directory should be10:55
*** troth <troth!> has quit IRC (Ping timeout: 250 seconds)10:58
Guest92qschulz right! found it!!11:01
Guest92$ file x86_64-linux/libxml2-native/2.9.10-r0/sysroot-destdir/exports/git-build/tmp/work/x86_64-linux/libxml2-native/2.9.10-r0/recipe-sysroot-native/usr/lib/python3.8/site-packages/libxml2mod.so11:01 ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=ae21a89ed08456ca60e6da0e45fd039f25f7a451, stripped11:01
Guest92but how do i make itstool search in this site-pacakges directory? it is searching in aarch64-fsl-linux directory in do_configre stage11:01
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... yes11:01
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.811:01
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... linux11:01
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-packages11:01
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-packages11:01
Guest92| checking for python module libxml2... not found11:01
Guest92| configure: error: Python module libxml2 is needed to run this package11:01
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'11:01
maciej_mrozowskiRP 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)11:02
RPmaciej_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 :/11:03
Guest92qschulz 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?11:05
*** User553 <User553!> has quit IRC (Ping timeout: 250 seconds)11:05
qschulzGuest92: recipes have native sysroots available11:05
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto11:05
qschulzGuest92: this means that yes, you'll find native stuff in work/aarch64-fsl-linux11:05
qschulzbut it's sysroots only11:06
qschulzGuest92: there are multiple questions actually11:06
qschulzthe 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 target11:07
qschulzif former, you need libxml2-native, if latter, libxml2 in DEPENDS11:07
qschulzthen, you need to check if what's required by your recipe is present in the native or target sysroot11:08
qschulzif not, then it's an issue in libxml2 recipe11:08
qschulzif yes, then it's likely an issue in your recipe11:09
qschulzmight be that not all flags are passed or it pointsa to the incorrect sysroot for some reason11:09
Guest92qschulz Oh k. I am sure libxml2-native is required.11:20
Guest92I 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..11:20
Guest92Libs not present in recipe-sysroot-native:11:20
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/11:20
Guest92Libs present in sysroot-destdir/../recipe-sysroot-native11:20
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/11:20  libxml2.py11:20
Guest92Libs should be present here?11:20
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/11:20
Guest92README.txt  rpm11:20
Guest92qschulz same issue in /exports/git-build btw.. created another build root yesterday just to rebuild from scratch but same issue there11:22
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto11:45
RPkanavin: it seems to be "adwaita-icon-theme: upgrade 41.0 -> 42.0" which is at least logical12:03
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:3842:2eab:78a1:eab> has joined #yocto12:04
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)12:17
jclsn9040landgraf: Any updates on the PREMIRRORS bug?12:22
*** jclsn9040 is now known as jclsn12:22
jclsnI was also wondering, because I have these issues on gatesgarth. The bug is probably in master, isn't it?12:23
*** Guest92 <Guest92!~Guest92@> has quit IRC (Quit: Client closed)12:37
*** kroon <kroon!> has quit IRC (Quit: Leaving)12:39
*** codavi <codavi!~akiCA@user/akica> has joined #yocto12:42
*** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 250 seconds)12:46
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto12:46
*** User553 <User553!> has joined #yocto12:48
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Ping timeout: 272 seconds)12:51
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto12:52
*** maciej_mrozowski <maciej_mrozowski!~maciej_mr@> has quit IRC (Quit: Client closed)12:54
*** kriive <kriive!~kriive@user/kriive> has joined #yocto12:55
*** rber|res <rber|res!~rber|> has joined #yocto12:58
*** Guest92 <Guest92!~Guest92@> has joined #yocto13:02
Guest92qschulz 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 the13:07
Guest92higher version by default? but for some reason it was picking up 2.9.2 for native recipe13:07
*** Guest6 <Guest6!~Guest6@> has joined #yocto13:09
Guest92qschulz thanks for your pointer about different sysroot for native!13:12
paulbarkerHi folks, I'm looking at plans for the YP summit next month. Will there be a developer meeting as well as the presentations?13:14
*** Guest6 <Guest6!~Guest6@> has quit IRC (Quit: Connection closed)13:15
RPpaulbarker: tlwoerner would know13:15
paulbarkerRP: 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 one13:16
RPpaulbarker: fair enough. Do you have a different view to what I replied with out of interest?13:17
qschulzGuest92: layer priority dictates the version of a recipe that will be used, so no, not necessarily the highest version number!13:18
paulbarkerRP: I've got the meta-sancloud layer passing `reuse lint` and would like to see what others think to using that spec & tool.13:19
*** Thomas12 <Thomas12!> has joined #yocto13:20
paulbarkerI also think the points you and Konrad covered need spreading to other folks as it's not something that's often understood13:20
*** pbergin__ <pbergin__!~pbergin@> has joined #yocto13:20
Guest92qschulz wow! will check the layer priority! thanks!!13:20
RPpaulbarker: so copyright and spdx license identifiers in every file13:21
paulbarkerRP: 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 on13:22
*** pbergin_ <pbergin_!> has quit IRC (Ping timeout: 240 seconds)13:22
RPpaulbarker: even for metadata I think there is a problem - it will confuse people who think it relates to the target recipe :(13:22
RPpaulbarker: 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 reality13:23
RPpaulbarker: anyway, yes, I guess it needs discussion. I just don't know we'll like the conclusions13:24
paulbarkerRP: `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 themselves13:24
paulbarkerThe dep5 format is awkward but we could propose improvements if it's something we needed13:24
RPpaulbarker: I was just looking at what you did in meta-sancloud. Do you have an example of a dep5 file somewhere?13:25
*** OutBackDingo <OutBackDingo!~quassel@> has joined #yocto13:25
paulbarkerRP: We didn't need one so I don't have an example. The format is briefly described at
Thomas12I'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 at13:26
Thomas12The lock screen is different, as it shows a small window with a green circle in it. has anybody ever experienced the same?13:26
RPpaulbarker: thanks. Looks like wildcards are supported so there is some potential there I guess13:27
paulbarkerRP: The dep5 format is based on, but I'd like to see a more straightforward alternative supported13:27
paulbarkerRP: 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)13:30
RPpaulbarker: 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 :/13:32
paulbarkerRP: Nothing selfish about trying to keep the project sustainable13:33
RPpaulbarker: 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 :(13:34
RPIn 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 care13:35
RPpaulbarker: anyway, I'm digressing, sorry13:35
*** xmn <xmn!> has joined #yocto13:36
kanavinRP: I can pick up the adwaita item, I'd start by checking buildhistory-diff there13:36
manuel1985Is anyone using the LICENSE_CREATE_PACKAGE feature? I'm having issues using it with NO_RECOMMENDATIONS and adding license packages individually.13:40
LetoThe2ndpaulbarker: 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.13:41
RPkanavin: 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 point13:42
kanavinRP: that's fine too, it'll take me until tomorrow probably13:44
*** troth <troth!> has joined #yocto13:44
RPkanavin: I did confirm that reverting out of master did also resolve it so it at least clear cut where the issue is13:44
RPkanavin: 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 time13:45
*** Austriker <Austriker!> has joined #yocto13:47
*** sakoman <sakoman!> has joined #yocto13:50
AustrikerHi, 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 the13:53
Austrikercase). VOLATILE_BINDS_append = " \13:53
Austriker    /data /home/toto/data\n\13:53
Austriker"I am following this example for the acces control:
RPkanavin: 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 works13:55
RPkanavin: is there something we can to to make runqemu "autodetect" correctly?13:56
RPkanavin: it isn't as bad as I thought initially, its probably just the way I use it ended up broken13:56
RP(the menu corruption is from the font config being missed since gtk wasn't specified)13:57
kanavinRP: I think show-cursor is a part of -display option, and can't be set independently?13:57
RPkanavin: right13:58
RPkanavin: but if no display option is passed, can we "fix" that?13:58
*** Thomas12 <Thomas12!> has quit IRC (Quit: Client closed)13:59
RPkanavin: qemu --help says The default display is equivalent to "-display gtk"13:59
RPbut I suspect that is configuration dependent13:59
kanavinRP: I think so too, and passing -display sdl (or gtk) by default will not go down well with people who don't want any display14:00
kanavin(and have configured qemu to disable both sdk and gtk)14:00
RPkanavin: Right. We may need to run qemu --help and parse which to use14:00
kanavinRP: or pass -display none14:02
kanavinRP: I was never comfortable with qemu attempting graphical output by default tbh14:03
kanavinit's prone to break if the environment isn't set for it14:03
*** Austriker <Austriker!> has quit IRC (Ping timeout: 250 seconds)14:04
RPkanavin: it is expected though and I think the quick start may depend on it (I haven't checked recently)14:06
*** pbergin_ <pbergin_!> has joined #yocto14:10
*** pbergin__ <pbergin__!~pbergin@> has quit IRC (Ping timeout: 246 seconds)14:12
*** GLumen <GLumen!> has joined #yocto14:16
*** User553 <User553!> has quit IRC (Quit: Client closed)14:18
*** Schiller <Schiller!> has joined #yocto14:18
SchillerI 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 understand14:20
Schillerin Buildstep 1 Clobber build dir14:22
qschulzSchiller: might want to check if you have SELinux enabled14:23
qschulzin whcih case, you need to properly label your volumes14:23
qschulz(or disable labelling, with --security-opt label=disable)14:23
kanavinRP: 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.14:27
kanavinI'll look into why svg icons aren't picked up, but those aren't for long either anyway.14:28
*** pbergin_ <pbergin_!> has quit IRC (Quit: Leaving)14:31
RPkanavin: that sounds like a good reason things are breaking and a good reason to revert for now14:34
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...14:50
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:3842:2eab:78a1:eab> has quit IRC (Remote host closed the connection)14:53
RPkanavin: revert and a "fix" for runqemu sent. Thanks for the help, I'm using your summary of things :)14:53
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto14:54
*** Guest92 <Guest92!~Guest92@> has quit IRC (Quit: Client closed)14:54
kanavinRP: Thanks, the summaries are ok. I'm poking a bit more at the icon issue, but will go for a bike ride now.14:55
*** frieder <frieder!> has quit IRC (Remote host closed the connection)15:01
*** ecdhe_ <ecdhe_!~ecdhe@user/ecdhe> has quit IRC (Ping timeout: 248 seconds)15:02
*** Austriker <Austriker!> has joined #yocto15:03
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto15:05
RPkanavin: good plan! :)15:06
*** Austriker <Austriker!> has quit IRC (Quit: Client closed)15:10
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 260 seconds)15:12
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto15:26
*** Schiller <Schiller!> has quit IRC (Quit: Client closed)15:28
kergothi hate it when i notice a bug in somethign i just submitted. at least it wasn't 5 minutes after this time15:28
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)15:29
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.15:30
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?15:30
kergothif 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 it15:35
kergoth'specific scripts' is super vague :)15:35
amahnui[m]I'm sorry about that.15:36
amahnui[m]scripts/bitbake-prserv-tool is one of the scripts I'm talking about15:37
RPamahnui[m]: you can always search for information about what uses that tool, e.g. "grep prserv-tool * -R"15:41
kergothWhat.. 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 all15:42
RPkergoth: which version? Didn't we stop it expanding variables in python code?15:42
RPkergoth: wouldn't surprise me though15:43
kergoththat'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. /eyeroll15:43
kergothi'll open a bug15:43
tlwoernerpaulbarker: there is an upcoming Yocto Project Summit, the CFP closes two weeks from yesterday, please (everyone) get your proposals in!15:51
tlwoernermy understanding is that the OE BoD is planning a developers meeting on the friday after the summit. i'm not involved with planning that event15:53
jsbronderIf I want to use, what do I need to do aside from setting SSTATE_MIRRORS?  Right now I'm not getting any cache hits when bitbaking.15:53
qschulzjsbronder: need to set the hashequiv server to point to the one hosted by yoctoproject too15:53
jsbronderqschulz: So run my own bitbake-hashserv with --upstream set to something?15:55
qschulzjsbronder: BB_HASHSERVE_UPSTREAM in your local.conf15:55
qschulzjsbronder: you'd need to use the upstream one directly I believe15:56
qschulzbut I've not setup any of this yet15:56
qschulzand I don't really plan to (hosting your own sstate mirror and hashequiv serv makes more sense IMO)15:57
*** troth <troth!> has quit IRC (Ping timeout: 246 seconds)15:57
qschulzjust build once locally to populate your sstate and hashequiv and then it should be enough?15:57
jsbronderThis 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.15:59
*** Perceval[m] <Perceval[m]!~percevalm@2001:470:69fc:105::1:2f86> has quit IRC (Quit: You have been kicked for being idle)16:00
*** OutBackDingo <OutBackDingo!~quassel@> has quit IRC (Ping timeout: 240 seconds)16:00
RPjsbronder: also, is your local config similar to something the autobuilder would build?16:00
jsbronderI believe so.16:01
RPjsbronder: fair enough, just checking. You will need BB_HASHSERV_UPSTREAM set for sstate to work16:01
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)16:01
qschulzjsbronder: makes perfect sense :)16:02
*** mckoan is now known as mckoan|away16:04
jsbronderugh, I didn't realize the big html docs on aren't current anymmore.  All I really needed to do was read here,
RPjsbronder: which docs aren't current?16:11
RPmichaelo[m]: ^^^16:11
*** troth <troth!> has joined #yocto16:11
qschulzRP: not this one, because it is redirected, but anything that is returned by Google with a direct link16:12
jsbronderRP:  I had bookmarks to thinking I'd always get the latest that way.  So my mistake not noticing the version number wasn't changing.16:13
qschulzjsbronder: we need to add a big fat red header to that website16:14
RPThese old links should be redirecting to :/16:14
RPhalstead: can we figure out what is going on there please?16:14
jsbronderRP: in particular then, BB_SIGNATURE_HANDLER = "OEEquivHash"16:14
jsbronderwhoops, I meant,
amahnui[m]qschulz: what if a link is added at the top of the website redirecting to the main one?16:15
amahnui[m]current one I mean16:15
qschulzRP: we would still need headers for anything that isn't redirected16:16
qschulzwhich would be the case for everything that predates the move to Sphinx16:16
*** OutBackDingo <OutBackDingo!~quassel@> has joined #yocto16:17
RPqschulz: that is at least a smaller subset16:21
RPqschulz: we could probably patch those en-mass16:22
qschulzRP: I don't know where those are generated though16:23
qschulzmaybe halstead or michaelo[m] or ndec knows16:23
RPqschulz: they're just in a tarball we extract so we can edit them16:25
* RP could put the tarball somewhere if someone wants to have a go16:26
amahnui[m]RP: I would like to do it16:27
amahnui[m]s/do/have/, s/it/a go/16:28
RPactually, it is already there:
*** florian <florian!> has quit IRC (Read error: Connection reset by peer)16:31
*** florian_kc <florian_kc!> has joined #yocto16:31
amahnui[m]RP: I'm currently downloading it. Once it's downloaded I would like to ask some few questions on how to proceed.16:34
RPamahnui[m]: You will need to figure out what the HTML to show the warning would look like. I don't know myself16:35
*** paulg <paulg!> has joined #yocto16:37
qschulzamahnui[m]: and ideally make it responsive so it does not look awful on a phone/tablet/small PC16:40
amahnui[m]The warning will contain the link to the most current website right?16:49
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.16:51
qschulzamahnui[m]: anything different from 3.1 releases should mention it is outdated and encourage to update to a newer version16:52
qschulzfor 3.1 releases, see
qschulzbut the message should be slightly different because we don't know what the current version of the docs will be at any point in time16:53
RPqschulz: these are only the old docbook versions16:53
qschulz(from the static webpage you'll modify)16:53
RPqschulz: ah, yes, sorry, tigh16:53
qschulzRP: yes, those are the problematic ones16:53
qschulzRP: though I just discovered gatesgarth is not marked as EoL16:53
* RP was thinking 3.1 was sphinx16:54
qschulzRP: it is!16:54
qschulzbut half of it only :)16:54
RPqschulz: right16:54
qschulzwell, a third of it16:54
qschulzamahnui[m]: so probably just saying that this is an outdated version and poitnt o shall be enough16:55
qschulzamahnui[m]: my dream would be to have a header that is always at the top of the current view (i.e. if you scroll it's still o on the page)16:55
qschulzbut one thing after another, a header at the top of the page would be great already16:56
amahnui[m]Thanks qschulz and RP  for breaking it down. Somehow the file is still downloading :) internet connection here today is not the best16:59
RPmichaelo[m], qschulz: new docs buildtools with the latest sphinx if you're interested:
*** goliath <goliath!~goliath@user/goliath> has joined #yocto17:06
qschulzRP: what would be the benefit of using this compared to running pip install -U sphinx?17:06
qschulzRP: just wondering since i've never (knowingly) used the buildtools17:06
RPqschulz: the autobuilders don't have random stuff pip installed on them17:08
RPthey're meant to be minimal setups for testing17:08
*** callum <callum!> has joined #yocto17:14
halsteadRP: I'm in the backscroll trying to understand what is wrong with the docs. It seems like all the links posted are working as expected.17:18
RPhalstead: shouldn't redirect to the new docs site and be something newer than 3.1 ?17:19
halsteadRP: Yes. I didn't find that link. I can figure this out now.17:20
*** sakoman <sakoman!> has quit IRC (Ping timeout: 260 seconds)17:29
kergothhuh, how did i miss that INIT_MANAGER exists now17:29
RPkergoth: I keep meaning to get poky to use that17:30
kergothGoing through the mentor/siemens distro line by line, been ages since I did that :)17:30
kergothTry to go through our main layers line by line file by file after every major release, but always hit time constraints17:31
RPkergoth: How many times did you wonder what you were thinking? :)17:31
* RP does that far too often :/17:31
kergothHah, repeatedly. "where the hell did this come from?" "why didn't i push that again?"17:31
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Read error: Connection reset by peer)17:31
kergoththen comes digging into the git logs and jira issues17:31
kergoththen trying to repro issues that had oddball workarounds..17:31
halsteadRP: All aliases to the old docs are now redirects to the new docs in the server config.17:32
RPkergoth: 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 fix17:32
RPhalstead: awesome, thanks!17:32
halsteadRP: Thank you for helping me locate the issue.17:33
*** sakoman <sakoman!> has joined #yocto17:34
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto17:37
amahnui[m]Does that mean I no longer need to work on it?17:40
*** bonalais <bonalais!> has joined #yocto17:41
amahnui[m]I mean on adding the header.17:42
RPamahnui[m]: no, we still need that for docs.yoctoproject.org17:43
ndecRP: halstead the links here no longer work. is that because of what was just changed?17:44
ndec should still work, or perhaps I did not scrollback enough..17:45
RPndec: We should fix those links in the transisiton repo17:46
ndechmm. where are the old docs?17:47
RPndec: we have them on now ?17:47
halsteadndec: I did break those. Bad regex.17:48
ndecright.. but how come we never noticed the links aren't working?17:48
ndecwell, perhaps we should still update the links, so that they are direct links, not assuming the aliased are in place?17:48
RPndec: that was my thinking17:49
RPndec: I can do it if you want?17:49
ndecwe should have done it earlier.. but since it worked we didn't notice, or forgot..17:50
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 here.17:50
halsteadndec: I've backed out the change for the moment.17:51
ndecand fwiw.. for whoever is following the discussions these links to the 'old' docs , in their old locations are set here in index-*.rst files.17:53
RPndec: patch sent17:53
ndechmm. you either are super fast, or you had done the change already :)17:54
RPndec: I have a handy sed command ;-)17:54
ndecstill.. it would have taken me longer than that to figure out the sed command :)17:54
RPamahnui[m]: all of those are on 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 one17:55
RPndec: I didn't actually test the result I guess17:55
RPwe have michaelo and the autobuilder for that17:55
ndecamahnui[m]: btw, if you end up fixing it, you should take the credit too and update :)17:57
amahnui[m]RP: okay thanks I will commence with it right away18:05
amahnui[m]ndec: okay I will18:06
amahnui[m]Thanks for the pointer18:06
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)18:06
RPkergoth: have a closer look at your patch as I wasn't talking about the example18:17
RPor I'm missing something18:17
kergothRP: it’s in the function docstring.18:18
kergothNot the actual code18:18
RPkergoth: look later in the patch you sent18:18
kergothNo worries. It’s trivial but found it helpful when we were actively supporting gplv2 builds.18:19
RPkergoth: I'd swear that patch edits meta/recipes-core/packagegroups/packagegroup-base.bb18:19
kergothOh, crap, I’m blind. Thanks!18:20
kergothI’ll send a v3 later18:20
*** barometz <barometz!> has quit IRC (Quit: you can't fire me!)18:27
*** barometz <barometz!> has joined #yocto18:29
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)18:29
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Quit: WeeChat 3.5)18:35
*** otavio <otavio!> has quit IRC (Ping timeout: 250 seconds)18:35
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto18:35
*** vladest <vladest!> has joined #yocto18:36
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Client Quit)18:36
landgrafjclsn: I haven't touch it for a while (and it is not assigned to me yet iirc... )18:37
*** callum <callum!> has quit IRC (Ping timeout: 250 seconds)18:37
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto18:37
*** otavio <otavio!> has joined #yocto18:37
jclsnlandgraf: Will have to look into it I guess, although it is not really a show stopper18:37
jclsnJust something to complete my sprint18:38
*** florian_kc <florian_kc!> has joined #yocto18:42
*** otavio <otavio!> has quit IRC (Ping timeout: 240 seconds)18:42
*** otavio <otavio!> has joined #yocto18:45
*** florian_kc is now known as florian18:46
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`?19:00
ndecYes, you should modify the .html files like mega-manual.html. Or any other file references in the yocto doc transition branch19:04
*** linums <linums!> has joined #yocto19:04
amahnui[m]Okay I will do just that.19:06
RPlandgraf: you'd be welcome to work on it!19:08
landgrafRP: I spent some time on it need to find better way to fix it without introducing new exception :)19:13
RPlandgraf: I have lost track of the context so I can't really comment19:15
landgrafRP: This one
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 250 seconds)19:43
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)19:57
RPlandgraf: hmm, right. I'm still struggling to remember the specifics of that one :(19:57
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 260 seconds)20:09
*** goliath <goliath!~goliath@user/goliath> has joined #yocto20:33
*** florian <florian!> has quit IRC (Ping timeout: 240 seconds)20:39
amahnui[m]Hi RP ndec I think I successfully added the banner and gave it a fixed position as well for one of the versions20:46
* amahnui[m] uploaded an image: (314KiB) < >20:48
amahnui[m]Here is a screenshot of how it looks in my local environment.20:48
RPamahnui[m]: if you scroll the document does that remain at the top displayed? It does look like what we need20:50
amahnui[m]Yes it remains at the top displayed.20:54
amahnui[m]* RP: Yes it20:54
RPamahnui[m]: sounds good!20:54
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.20:57
RPamahnui[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 everything20:59
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?21:03
RPamahnui[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 files21:06
amahnui[m]sorry my data got finished21:32
amahnui[m]RP: the yocto-docs I have here has just .rst files instead of .html how do I generate the .html from it.21:32
RPamahnui[m]: these are old files from before we had sphinx. We had docbook docs back then21:34
amahnui[m]RP: That means I will run `git init` then run `diff -u <changed file> <unchanged file>` then do  `git send-email`?21:38
RPamahnui[m]: you don't have to use git but I guess something like that could work21:42
amahnui[m]Please I wish to ask  to  send a patch without using git.21:43
*** bonalais <bonalais!> has quit IRC (Quit: Connection closed for inactivity)21:50
*** florian <florian!> has joined #yocto21:52
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)22:02
*** linums <linums!> has quit IRC (Quit: Client closed)22:03
*** Wouter0100 <Wouter0100!> has quit IRC (Read error: Connection reset by peer)22:09
*** Wouter0100 <Wouter0100!> has joined #yocto22:10
*** florian <florian!> has quit IRC (Ping timeout: 248 seconds)22:13
*** sgw <sgw!~swold_loc@user/sgw> has quit IRC (Ping timeout: 240 seconds)22:20
*** sgw <sgw!~swold_loc@user/sgw> has joined #yocto22:23
amahnui[m]I did so and ran `diff -u a b ` but I'm facing difficulties staging the differences22:35
*** sakoman <sakoman!> has quit IRC (Read error: Connection reset by peer)22:37
*** sakoman <sakoman!> has joined #yocto22:37
*** gsalazar <gsalazar!> has quit IRC (Ping timeout: 256 seconds)22:47
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 246 seconds)23:02
*** willo <willo!> has quit IRC (Ping timeout: 240 seconds)23:09
*** willo <willo!> has joined #yocto23:09
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29f:f340:cfbf:d57d:b0f7:eb51> has quit IRC (Quit: Leaving)23:24
*** tgamblin <tgamblin!~tgamblin@2607:fea8:c29f:f340::81bf> has joined #yocto23:25
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)23:48
*** GLumen <GLumen!> has quit IRC (Read error: Connection reset by peer)23:55

Generated by 2.17.2 by Marius Gedminas - find it at!