Wednesday, 2022-06-08

*** jclsn0 <jclsn0!> has quit IRC (Ping timeout: 246 seconds)00:10
*** jclsn0 <jclsn0!> has joined #yocto00:15
*** jclsn0 <jclsn0!> has quit IRC (Ping timeout: 244 seconds)00:20
*** jclsn0 <jclsn0!> has joined #yocto00:26
*** qschulz <qschulz!> has quit IRC (Remote host closed the connection)00:32
*** jclsn0 <jclsn0!> has quit IRC (Ping timeout: 240 seconds)00:32
*** qschulz <qschulz!> has joined #yocto00:35
*** jclsn0 <jclsn0!> has joined #yocto00:39
*** jclsn0 <jclsn0!> has quit IRC (Ping timeout: 240 seconds)00:45
*** jclsn0 <jclsn0!> has joined #yocto00:47
*** jclsn0 <jclsn0!> has quit IRC (Ping timeout: 244 seconds)00:53
*** jclsn0 <jclsn0!> has joined #yocto01:00
*** jclsn0 <jclsn0!> has quit IRC (Ping timeout: 258 seconds)01:06
*** jclsn0 <jclsn0!> has joined #yocto01:12
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 250 seconds)01:16
*** jclsn0 <jclsn0!> has quit IRC (Ping timeout: 244 seconds)01:16
*** Tokamak <Tokamak!> has joined #yocto01:20
*** jclsn0 <jclsn0!> has joined #yocto01:26
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)01:30
*** RobertBerger <RobertBerger!~rber|> has joined #yocto01:32
*** rber|res <rber|res!~rber|> has quit IRC (Ping timeout: 240 seconds)01:34
*** camus <camus!~Instantbi@> has joined #yocto01:39
*** starblue <starblue!> has quit IRC (Ping timeout: 244 seconds)01:43
*** starblue <starblue!> has joined #yocto01:45
*** jpuhlman <jpuhlman!> has quit IRC (Ping timeout: 248 seconds)01:49
*** jpuhlman <jpuhlman!> has joined #yocto01:50
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 244 seconds)01:54
*** nemik <nemik!> has joined #yocto01:54
*** nemik <nemik!> has quit IRC (Ping timeout: 246 seconds)01:58
*** nemik <nemik!~nemik@> has joined #yocto01:59
*** jclsn0 <jclsn0!> has quit IRC (Ping timeout: 246 seconds)02:22
*** sakoman <sakoman!> has joined #yocto02:27
*** jclsn0 <jclsn0!> has joined #yocto02:29
*** jclsn0 <jclsn0!> has quit IRC (Ping timeout: 276 seconds)02:36
*** jclsn0 <jclsn0!> has joined #yocto02:41
*** jclsn <jclsn!~jclsn@2a04:4540:6526:e800:4c39:1743:a773:9889> has quit IRC (Ping timeout: 240 seconds)02:46
*** jclsn0 <jclsn0!> has quit IRC (Ping timeout: 240 seconds)02:46
*** jclsn <jclsn!~jclsn@2a04:4540:6510:f400:4e59:5fc7:cbc4:5ea4> has joined #yocto02:48
*** jclsn0 <jclsn0!> has joined #yocto02:54
*** Tokamak <Tokamak!> has quit IRC (Ping timeout: 244 seconds)02:54
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto02:58
*** jclsn0 <jclsn0!> has quit IRC (Ping timeout: 256 seconds)02:58
*** Tokamak_ <Tokamak_!> has joined #yocto03:03
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 256 seconds)03:04
*** jclsn0 <jclsn0!> has joined #yocto03:05
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto03:11
*** Tokamak_ <Tokamak_!> has quit IRC (Ping timeout: 246 seconds)03:11
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)03:19
*** Tokamak_ <Tokamak_!> has joined #yocto03:24
*** ptsneves <ptsneves!> has quit IRC (Quit: Client closed)03:24
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 256 seconds)03:25
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 256 seconds)03:34
*** nemik <nemik!> has joined #yocto03:34
*** nemik <nemik!> has quit IRC (Ping timeout: 246 seconds)03:38
*** nemik <nemik!~nemik@> has joined #yocto03:39
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 246 seconds)04:03
*** nemik <nemik!> has joined #yocto04:04
*** nemik <nemik!> has quit IRC (Ping timeout: 255 seconds)04:08
*** nemik <nemik!~nemik@> has joined #yocto04:08
*** dev1990 <dev1990!> has quit IRC (Remote host closed the connection)04:10
*** dev1990 <dev1990!> has joined #yocto04:10
*** Tokamak_ <Tokamak_!> has quit IRC (Ping timeout: 255 seconds)04:37
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)04:37
*** RobertBerger <RobertBerger!~rber|> has quit IRC (Quit: Leaving)04:38
*** rber|res <rber|res!~rber|> has joined #yocto04:38
*** Tokamak <Tokamak!> has joined #yocto04:48
*** kroon <kroon!> has joined #yocto04:50
*** davidinux <davidinux!> has quit IRC (Ping timeout: 246 seconds)05:11
*** Guest58 <Guest58!> has joined #yocto05:11
*** Guest58 <Guest58!> has quit IRC (Client Quit)05:12
*** Tokamak <Tokamak!> has quit IRC (Ping timeout: 246 seconds)05:34
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto05:37
*** olani <olani!~olani@> has quit IRC (Ping timeout: 272 seconds)05:48
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 256 seconds)05:54
*** nemik <nemik!> has joined #yocto05:54
*** nemik <nemik!> has quit IRC (Ping timeout: 276 seconds)05:58
*** nemik <nemik!~nemik@> has joined #yocto05:59
*** te-johan <te-johan!> has joined #yocto06:12
*** rfuentess <rfuentess!> has joined #yocto06:14
te-johanhi, i'm trying to debug why i'm so easily getting pseudo mismatch abort errors. at the moment if i do any changes to my layer i usually have to rebuild everything to avoid it. Is there any gotchas when building in docker, like inodes changing or similar?06:18
*** frieder <frieder!> has joined #yocto06:38
*** rob_w <rob_w!> has joined #yocto06:40
*** rfs613 <rfs613!> has quit IRC (Quit: restart)06:47
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:47
*** rfs613 <rfs613!> has joined #yocto06:48
*** mckoan|away is now known as mckoan06:49
mckoangood morning06:49
*** xmn <xmn!> has quit IRC (Ping timeout: 276 seconds)06:49
LetoThe2ndyo dudX06:51
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto06:55
mckoanhey LetoThe2nd07:07
LetoThe2ndmckoan: howdy07:09
*** ptsneves <ptsneves!> has joined #yocto07:17
*** m4ho <m4ho!~m4ho@> has quit IRC (Ping timeout: 240 seconds)07:24
*** prabhakarlad <prabhakarlad!> has joined #yocto07:28
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:29
*** m4ho <m4ho!~m4ho@> has joined #yocto07:41
*** davidinux <davidinux!~davidinux@> has joined #yocto07:41
*** simpat2022[m] <simpat2022[m]!~simpat202@2001:470:69fc:105::2:26a9> has joined #yocto07:45
*** bps <bps!~bps@user/bps> has joined #yocto07:52
*** gsalazar <gsalazar!> has quit IRC (Quit: Leaving)07:53
*** gsalazar <gsalazar!> has joined #yocto07:53
*** GuestNew118 <GuestNew118!~GuestNew1@> has joined #yocto08:00
GuestNew118Hello Yocto Wizards, after bumping to Yocto 4.0 bitbake complains about recipes based on Tag as SRCREV (Recipe uses a floating tag/branch without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev()) there is a way to disable it ? all my recipes are based on tags...08:04
LetoThe2ndGuestNew118: well the obvious fix is changing your recipes, because tags are not immutable, and therefore don't guarantee reproducibility08:05
LetoThe2ndGuestNew118: if you are intentionally willing to sacrifice such, then you can do the AUTOREV dance on a given branch08:06
*** florian <florian!> has joined #yocto08:07
GuestNew118LetoThe2nd I understand, thanks for infos :)08:07
*** gordon1 <gordon1!> has joined #yocto08:07
LetoThe2ndGuestNew118: have fun!08:14
*** river <river!> has left #yocto (WeeChat 3.4.1)08:17
*** Schiller <Schiller!> has joined #yocto08:38
SchillerHello. Is there a file which stores the Buildinformation displayed in the WEB-UI from Buildbot? I have controller and workers running in container and start everything with docker-compose. At the moment I lose all the Buildinformation after i stop the containers.08:44
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 255 seconds)08:46
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto08:48
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto08:48
*** Qorin <Qorin!~Qorin@2001:1c00:f23:2600:7412:8cb3:b465:5ec2> has joined #yocto08:49
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 260 seconds)08:55
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto08:57
*** rfuentess <rfuentess!> has quit IRC (Remote host closed the connection)08:59
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 240 seconds)09:15
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto09:18
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 246 seconds)09:18
*** nemik <nemik!> has joined #yocto09:18
*** nemik <nemik!> has quit IRC (Ping timeout: 272 seconds)09:24
*** nemik <nemik!~nemik@> has joined #yocto09:24
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Ping timeout: 260 seconds)09:27
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto09:28
jclsn[m]I just realized something odd, which is not clear for me from the docs. We have multiple image recipes, like a core-image, a dev-core-image and a dev-core-image-usb-updater etc. In case of the latter, we require the dev-core-image, which requires the core-image. When building an SDK for the dev-core-image-updater though, many packages are missing in the manifest. Is that normal? I can find those packages if I generate an SDK for the core-image,09:29
jclsn[m]but not in the SDK for the dev-core-image or updater. I had assumed that all those packages would be inherited and also land in the SDK for the updater.09:29
jclsn[m]I would really like to have one SDK to rule them all, instead of building several...09:30
RPjclsn[m]: it really depends how you're making dev-core-image differ from core-image09:36
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 256 seconds)09:42
*** jpuhlman <jpuhlman!> has quit IRC (Ping timeout: 255 seconds)09:43
*** jpuhlman <jpuhlman!> has joined #yocto09:43
*** davidinux <davidinux!~davidinux@> has joined #yocto09:44
QorinHas anyone worked with efitools recipe from meta-secure-core together with DigiCert ?09:53
QorinI am using sign-efi-sig-list tool that is built by efitools recipe and the certificates come from digicert.09:53
QorinI have to setup some environment variables and in the end this is the command that is called `sign-efi-sig-list -t "<some_time>" -e pkcs11 -c "/path/to/" -k "private_key_url" PK PK.esl PK.auth`09:53
Qorinthe sign-efi-sig-list is available in the recipe-sysroot-native. however when I used this tool from the recipe-sysroot-native I received this error09:53
Qorin.../poky/build/tmp/work/x86_64-linux/openssl-native/1.1.1l-r0/recipe-sysroot-native/usr/lib/engines-1.1/ cannot open shared object file: No such file or directory09:53
Qorinin the openssl-native work dir, the directory lib/engines1.1 does not exist.09:53
QorinHowever in the core2-64-poky-linux/openssl work dir the lib/engines1.1 directory exists with these files:09:53
Qorin- afalg.so09:53
Qorin- capi.so09:53
Qorin- padlock.so09:53
QorinI tried adding an RDEPEND:${PN}:append = " libp11 libp11-native" in the openssl recipe, but it failed to build due to circular dependency09:53
*** starblue <starblue!> has quit IRC (Ping timeout: 260 seconds)09:55
*** rob_w <rob_w!> has quit IRC (Quit: Leaving)09:55
*** starblue <starblue!> has joined #yocto09:57
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 240 seconds)09:58
*** nemik <nemik!> has joined #yocto09:58
*** te-johan <te-johan!> has quit IRC (Ping timeout: 252 seconds)10:02
*** nemik <nemik!> has quit IRC (Ping timeout: 252 seconds)10:04
*** nemik <nemik!~nemik@> has joined #yocto10:04
*** pgowda_ <pgowda_!> has joined #yocto10:39
jclsn[m]RP: I only append stuff, so I don't know why the packages from the core-image would be missing10:47
*** tre <tre!> has joined #yocto10:51
LetoThe2ndis there a direct way to get the expanded list of packages that go into an image without actually building? like the information from the image manifest?11:04
jclsn[m]Ah, the updater image has its own minimal rootfs and thus it is included in the SDK11:05
*** Schiller <Schiller!> has quit IRC (Ping timeout: 252 seconds)11:12
*** Wouter0100 <Wouter0100!> has joined #yocto11:15
jclsn[m]dropbear is also not compatible with the SDk unfortunately, because it requires openssh which conflicts with dropbear11:31
jclsn[m]The problem is obviously openssh-sftp, which is compatible with dropbear, but not when building the SDK. The SDK somehow requires openssh when having added openssh-sftp.11:53
jclsn[m]RP: Is this a bug? Could a PROVIDES="ssh-server-openssh" in the dropbear recipe or SDK recipe fix it?11:54
jclsn[m]Or does the SDK need some libraries from openssh?11:54
*** Qorin <Qorin!~Qorin@2001:1c00:f23:2600:7412:8cb3:b465:5ec2> has quit IRC (Ping timeout: 252 seconds)12:12
qschulzLetoThe2nd: bitbake -g --parse-only <recipe> maybe?12:13
LetoThe2ndqschulz: thx, will give it a try. but turned out that the non-building was actually not a requirement, so the manifest+buildhistory do the trick.12:15
gordon1having an issue with RRECOMMENDS, so there is this recipe smartmontools from meta-openembedded, it has RRECOMMENDS += "s-nail", but no matter what i do it still installs it, i tried adding "s-nail" to BAD_RECOMMENDATIONS or even PACKAGE_EXCLUDE in my local.conf, and if i add it to BBMASK bitbake fails with an error that smartmontools RDEPENDS on it, which it clearly isn't according to the recipe12:24
gordon1file, is there a way to see _why_ exactly certain package is pulled?12:24
gordon1i'm using kirkstone if it matters12:26
qschulzgordon1: bitbake -g <image-recipe> will give you a few dot files expliciting the dependencies between packages12:29
RPjclsn[m]: there is an open bug about some aspect of the openssh/dropbear overlap. I'm not sure we did come up with a good plan for all of that12:37
RPjclsn[m]: dropbear certainly should not PROVIDES openssh though12:37
jclsn[m]RP: Yeah I guess so12:38
jclsn[m]I have kicked out openssh-sftp for now. It is only needed for QtCreator and there are workarounds12:38
jclsn[m]Out of curiosity: I just wonder how much more performant dropbear really is. I could not find any benchmarks or info about the openssh memory footprint12:39
gordon1qschulz: well, it shows me all the dependencies but it doesn't show me why this dependency exists =/12:39
gordon1or i'm not good at interpreting it12:40
qschulzgordon1: at least knowing which package depends on which, you can look into the recipe and try to figure out if it's a dependency you can remove or not (e.g. via BAD_RECOMMENDATIONS or a modified PACKAGECONFIG)12:40
*** kroon_ <kroon_!> has joined #yocto12:40
*** kroon <kroon!> has quit IRC (Ping timeout: 255 seconds)12:41
gordon1well, that's the problem that i'm having, i already know the recipe that pulls s-nail - smartmontools, and the recipe has _only_ RRECOMMENDS:${PN} += "s-nail" (if i comment out this line it doesn't pull s-nail into resulting image)12:41
gordon1but for some reason this RRECOMMENDS isn't affected by BAD_RECOMMENDATIONS12:42
qschulzgordon1: are you sure it's the ONLY one pulling s-nail is smartmontools?12:42
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)12:42
qschulzthat was what I had in mind but I realize I didn't vocalize this idea :)12:43
qschulzgordon1: remember that there's an auto-magic RDEPENDS in packages12:43
qschulzwhich adds packages of shared libraries used in a given package by using objdump/readelf12:43
qschulzand add them directly without you knowing12:43
gordon1i can comment the line with RRECOMMENDS:${PN} += "s-nail" and add BBMASK += "s-nail" in my local.conf and it does not result in error and bitbake builds the image correctly w/o s-nail12:44
gordon1*can comment the line out from smartmontools.bb12:45
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto12:45
qschulzgordon1: ok seems like a pretty solid test and confirmation it's the only one adding s-nail12:45
gordon1i doubt that smartmontools use any kind of shared lib from s-nail since latter one is just mail implementation12:46
qschulzgordon1: which package manager are you uising?12:46
qschulzbecause deb does not support BAD_RECOMMENDATIONS12:46
qschulz(but you should have gotten a warning when building)12:47
gordon1i think its rpm, gimme a moment12:47
gordon1PACKAGE_CLASSES ?= "package_rpm"12:47
gordon1but i'm building initramfs so i doubt it has package manager there12:47
qschulzgordon1: the rootfs is created by a package manager running on your building machine12:48
gordon1so i guess it's rpm then12:48
qschulzgordon1: which is a different thing than having a package manager on your target12:48
qschulzyup, seems reasonable (you can always check with bitbake-getvar -r <image-recipe> PACKAGE_CLASSES12:49
qschulztbh, i'm out of ideas where to look for next, so i'll let others chime in12:49
gordon1yep, it's rpm12:49
gordon1i mean i guess i could just make bbappend for smartmontools modifying this RRECOMMENDS, but i'm pretty sure it's not how RRECOMMENDS should behave12:50
qschulzgordon1: BAD_RECOMMENDATIONS should work indeed12:51
qschulzgordon1: check BAD_RECOMMENDATIONS with bitbake-getvar too12:51
*** kroon__ <kroon__!> has joined #yocto12:52
gordon1but if i add s-nail to PACKAGE_EXCLUDE should it fail instead of trying to install it?12:53
gordon1because it doesn't for me12:53
*** kroon_ <kroon_!> has quit IRC (Ping timeout: 272 seconds)12:55
qschulzit should except for deb pkg manager12:56
gordon1hmm, it's weird, it shows me following dependency chain:12:57
gordon1Missing or unbuildable dependency chain was: ['wireguard-tools-dev', 'kernel-module-wireguard', 'core-image-gnubee', 'smartmontools', 's-nail']12:57
gordon1i have initramfs that is bundled into the kernel12:58
gordon1so i wonder if it ignores BAD_RECOMMENDATIONS while it's building the image as a dependency for kernel maybe?12:58
qschulzgordon1: that's actually  a good question13:02
qschulzI'm building core-image-minimal with smartmontools - s-nail to see if I can reproduce (top of kirkstone branch)13:03
qschulzif it does not, maybe checking that this mechanism works for bundled initramfs is a good idea13:03
gordon1if so i wonder is there a way to specify BAD_RECOMMENDATIONS for an image instaed of local.conf? should it work if i put it into my image's recipe?13:03
gordon1qschulz: i based my image in core-image-tiny-initramfs if that is important13:04
gordon1so i put BAD_RECOMMENDATIONS = "s-nail" into my image recipe but it didn't help13:06
qschulzgordon1: ahah!13:07
qschulzPACKAGE_INSTALL needs to be used instead of IMAGE_ISNTALL for initramfs images13:07
qschulzmaybe BAD_RECOMMENDATIONS does not apply to PACKAGE_INSTALL but only IMAGE_INSTALL?13:08
gordon1oh, hmm13:08
gordon1is there unintended consequences if i'll just replace PACKAGE_INSTALL with IMAGE_INSTALL ?13:09
qschulzgordon1: i think it just won;'t work13:09
gordon1well, i replaced it and it looks like it still complains about s-nail since it's in BBMASK13:09
jclsn[m]I have an issue that a dependency is not landing in the SDK unless I explicitly list. So to be clear: If I list some package explicitly eveerything lands in the SDK, if I only let it get installed as dependency, it still works in the image, but libraries are missing the SDK. Is there something like DEBUGDEPENDS? Haven't found anything13:24
jclsn[m]EXTRA_IMAGEDEEPENDS maybe13:27
qschulzjclsn[m]: the SDK is like a toolchain, minimal stuff by default13:28
qschulzmaybe you'd be more interested in eSDK?13:28
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 246 seconds)13:28
qschulzwhich is like a complete development environment based on an image (IIRC, have never used it)13:28
jclsn[m]qschulz: The eSDK is huge13:28
jclsn[m]I could fix it by listing the package as RDEPENDS, but not sure if that is the right way to do13:29
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 260 seconds)13:29
*** michalkotyla <michalkotyla!> has quit IRC (Quit: michalkotyla)13:29
*** nemik <nemik!> has joined #yocto13:29
gordon1docs don't really explain in details why i must use PACKAGE_INSTALL instead if IMAGE_INSTALL for initramfs, just tell me to =/13:29
jclsn[m]For now we were working okay with the SDK. The eSDK is only needed for devtool afaik13:29
*** xmn <xmn!> has joined #yocto13:29
qschulzjclsn[m]: the eSDK brings the whole sysroot for an image IIRC13:30
ptsnevesgordon1 basically it is to slim it down. Indeed it is not clear.13:30
qschulzthe SDK is literally a toolchain, so basically compiler+libc+some other very basic stuff13:30
qschulzthe eSDK also happens to have some Yocto specfici tools like devtool13:31
jclsn[m]the SDK also contains the sysroot13:31
gordon1ptsneves: yes, but in what way? have to look at the bbclass code for that i guess13:31
qschulzjclsn[m]: not the whole sysroot, otherwise you wouldn';t complain about the missing package?13:31
jclsn[m]Guess I have to read the docs on SDKs again13:31
jclsn[m]Probably yeah. I think I misread something then13:32
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto13:32
*** nemik <nemik!> has quit IRC (Ping timeout: 256 seconds)13:34
ptsnevesgordon1 actually the docs mention the difference and even mention the initramfs case.13:35
*** nemik <nemik!~nemik@> has joined #yocto13:35
jclsn[m]qschulz: This is not really clear from the docs13:35
jclsn[m]The Standard SDK provides a cross-development toolchain and libraries tailored to the contents of a specific image.13:35
jclsn[m]The extensible SDK provides a cross-development toolchain and libraries tailored to the contents of a specific image.13:36
jclsn[m]The only difference the docs mention is devtool13:36
jclsn[m]ou would use the Extensible SDK if you want a toolchain experience supplemented with the powerful set of devtool commands tailored for the Yocto Project environment.13:36
jclsn[m]The installed Standard SDK consists of several files and directories. Basically, it contains an SDK environment setup script, some configuration files, and host and target root filesystems to support usage.13:36
* qschulz shrugs13:37
qschulzI don't use SDKs, so I could bery very much be wrong and shouldn't have said anything13:37
ptsnevesjclsn[m] unfortunately many in the yocto community do not use the SDKs and this may lead to fragilities in it. Do you think you can submit a patch for the docs?13:39
qschulzptsneves: I think the SDK is actually more used than eSDK? but again, just guesses13:40
ptsnevesi have 2 data points and they confirm your experience. I have generated some, but besides correctness never used it13:41
*** tre <tre!> has quit IRC (Remote host closed the connection)13:41
jclsn[m]ptsneves: No idea what patch that would be. I still don't know what the exact differences are. Quentin says that the standard SDK contains "some" sysroot files. That is not clear enough for me.13:42
sotaoverrideive somehow ended up with  modules in /lib/modules for a different kernel, and now get the "disagress about version of symbol module_layout" error. has anyone seen this before? My rootfs updates led to this, and im trying to find a way of fixing it now. clearly the kernel is not on the rootfs or something13:42
qschulzjclsn[m]: opening a bug ticket for the documentation is already great feedback13:42
ptsnevessotaoverride can you paste the whole errror? I assume you get the issue at runtime/boot?13:44
ptsnevesjclsn[m] we are not perfect and the project is huge. Honestly i just read the source when i want something not clearly documented. Even so the docs are amazing compared to a few years ago. If they do not suit it is an opportunity to improve13:45
sotaoverrideptsneves: its jsut when I try to modprobe ovelay
ptsnevescan you try modprobe? also is this the result of a module you manually copied?13:48
sotaoverrideptsneves: so I was getting help from rfs613 earlier and he pointed out my kernel is on a vfat, and the modules sit in rootfs. When i do rootfs updates, the modules somehow get in this mismatch state. I tried modprobe too. and the module is just getting installed by the defconfig that comes with the bsp (i think)13:50
ptsnevessotaoverride what matters is that the kernel sources used to build the kernel and your module match.13:52
ptsnevesWhat do you mean rootfs updates?13:52
*** sakoman <sakoman!> has joined #yocto13:53
sotaoverrideso I have this python utitliy that does a/b partition style updates. you basically give it an ext4 root filesystem and tell the board to boot from the partition with the new ext4 filesystem13:54
sotaoverridethat some how led to this mismatch13:54
sotaoverridewhich got caught when overlay went missing.13:54
sotaoverrideand I wasnt able to modprobe it even13:55
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:fb89:1b33:d2ae:2bf> has quit IRC (Quit: vladest)14:00
ptsnevesehhh nice problem you got there. Just one more question, to give you the diagnostics. The kernel is not in the rootfs but in some other partition. The fat you mentioned right?14:03
*** squid_game <squid_game!> has joined #yocto14:05
qschulzsotaoverride: what about having an initramfs in your kernel with the kernel modules in?14:05
qschulz(and pivot/switch root at boot)14:05
qschulzor, just build them in instead of having them as modules?14:05
ptsnevesyep. That is actually the only choice to not have issues with fallbacks failing due to kernel mismatch14:07
sotaoverrideqschulz: cant you link me to some doc or something that breaks down initramfs. I only know a little about ext4 and how to write them to a parition, run the filesystem resize command and call it a day :P14:09
sotaoverridejust link me to something that explains initramfs a little and the pivot/switch idea, or just give like the top line explanation here14:10
qschulzsotaoverride: basically, you insert an initramfs/initrd inside the kernel at compile time of the kernel14:11
qschulzwhen the kernel will boot, it'll load this initramfs in RAM and mount it as rootfs14:11
rfs613ptsneves, sotaoverride: the issue is that rootfs (containing modules) has gotten updated, while the kenrel+dtb+overlays are on separate partition (VFAT) and did not update. hence the mismatch.14:11
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:1cba:aa1b:109:9184> has joined #yocto14:11
rfs613the fix is to eiterh update the VFAT to match, or to revert the rootfs update.14:11
qschulzsotaoverride: but since you don't want the rootfs fully in RAM (very limited in size, and also yuou lose all data between reboots)14:12
ptsnevesrfs613 yep, got it.14:12
rfs613let's not make it more complicated by adding initramfs to the mix...14:12
qschulzsotaoverride: you need to mount another filesystem and replace the rootfs with it at runtime, that's what pivot_root/switch_root does14:12
sotaoverridethank you thank you14:12
qschulzthe kernel modules would be loaded from the initramfs14:12
ptsnevesrfs613 actaull what you suggest breaks the fallback ability. Unless you also have A/B kernel-dtb partition14:13
qschulzand still loaded in the kernel after doing the switch root14:13
qschulzI **think** that's what PC distros do? i don't remember exactly14:13
qschulzthat's the theory14:13
*** kroon__ <kroon__!> has quit IRC (Quit: Leaving)14:13
rfs613ptsneves: yes, true, because there is only one VFAT partition while there are two A/B rootfs... but it's not my design to fix ;-)14:13
qschulzI'm not saying it's actually the best idea for you14:13
qschulzand I also have no idea how to implement this in Yocto14:14
qschulzbut I know it's possible14:14
qschulzbecause thatr's one of the ways for doing secure boot14:14
qschulzand I worked a bit on the implementation about 6 years ago14:14
qschulzbut the kernel and yocto has changed a lot since :)14:14
ptsnevesi would just inline the module and be done with it14:14
qschulzyup same14:15
ptsnevesno more initramfs nor fallback issues14:15
qschulzi don't expect embedded platforms with the nouveau driver built-in :D14:15
qschulzso the kernel size should be reasonable14:15
squid_gamewhat is _${PN} on RDEPENDS_${PN} += "bash"?14:15
ptsnevesunless you cant do that due to license issues, you just found yourself exra work14:15
qschulzsquid_game: PN is for "package name" but it happens to actually be the recipe name14:16
qschulzso if your recipe is named my-recipe_0.5.bb14:16
rfs613ptsneves: compilng the module into kernel was also my first thought, but they use a vendor layer for the kernel, it has a defconfig (not config fragments), so he'd have to clone the defconfig and modify... and then update it it when the vendor does.14:16
qschulzRDEPENDS_${PN} will basically be RDEPENDS_my-recipe14:16
squid_gameqschulz, thanks a lot!14:17
qschulzsquid_game: the catch being, that the name of the recipe is actually also the name of the main package (by default at least)14:17
ptsnevesrfs613 still feels the easiest way out14:17
qschulzsquid_game: hence the confusion. recipe vs package is a very important difference (recipe is the input of a build, packages are the output in very very big overview of how bitbake works)14:18
rfs613ptsneves: for a quick test yes, in the long term - they'll need to figure out how to deal with keepng the boot partition in sync wiht rootfs.14:19
*** kscherer <kscherer!> has joined #yocto14:19
squid_gamethanks for the explanation14:20
ptsnevesrfs613 i politely disagree. Any toil work just inlining the vendor code is much simpler and less error prone than whatever is required to keep the boot partition in sync. I have seen this "toil" and it is programmed into the schedule and manageable14:22
ptsnevesas vendor layer upgrades always require integration anyways14:23
qschulzvendor code exists to be removed anyways14:23
qschulzso just ditch it :D14:23
qschulz(only half joking)14:23
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 256 seconds)14:24
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)14:24
ptsnevesqschulz bad vendor integrations cost money and let the bean counters see and pressure sales peoples. If you come up with your own sync solution and it bricks devices in the field it will be your ass on the platter14:24
*** florian_kc <florian_kc!> has joined #yocto14:26
gordon1well, i changed class to inherit image instead of inherit core-image, changed PACKAGE_INSTALL to IMAGE_INSTALL but it still completely ignores BAD_RECOMMENDATIONS14:26
qschulz(I was more in favor of removing the vendor layer and only hand pick what you actually need from it)14:26
*** sakoman <sakoman!> has joined #yocto14:27
gordon1is here a particular IMAGE_FEATURE requred for BAD_RECOMMENDATIONS to work?14:27
qschulzgordon1: not that i know. slow PC here, waiting for it to finish building core-image-minimal with smartmontools enabled since I told you about 2 hours ago :D14:28
qschulzgordon1: you can always open a bug entry on our bugzilla14:28
gordon1oh, thanks14:28
qschulzif you continue investigating or not does not matter, it's always nice to know there was a bug and it's fixed some time in the future14:28
gordon1yes i could, just want to make sure it's a bug and not me being dumb14:28
qschulzgordon1: vanilla poky in kirsktone + vanilla meta-openemmebded/meta-oe14:29
qschulznothing in local.conf except IMAGE_INSTALL:append and BAD_RECOMMENDATIONS14:29
qschulzif it reproduces, it's a bug I'm pretty certain14:29
gordon1yes, that's pretty much that i have + my own small layer with kernel and machine definition14:29
gordon1oh, and a distro, but it pretty much copy-pasted poky-tiny14:30
qschulzshouldn't take too long to test on vanilla everything14:30
qschulzpoky + some qemu machine14:30
qschulzand at least we would know for sure14:30
qschulzand even better for the bug report, if it's reproducible on master stil14:30
*** frieder <frieder!> has quit IRC (Remote host closed the connection)14:31
gordon1yeah, that might be the case14:31
*** squid_game <squid_game!> has quit IRC (Remote host closed the connection)14:31
rfs613ptsneves: in this particular case, it probably makes sense to investigate if the separate VFAT partiton can be eliminated, have the kernel+dtb+overlays on the rootfs (of which there are two A/B copies). That way each one is self contained. As they are using u-boot on arm64, I would not expect any difficulties (there's no CHS limits from a BIOS etc). Just a bit of effort to change the bootcmd to load from14:32
rfs613ext4 rather than FAT, etc.14:32
qschulzrfs613: the issue with the same partition for kernel+rootfs is when you just need to fix something quick in the kernel14:32
qschulzthen the whole update is the full rootfs14:33
qschulzpretty demanding on update servers14:33
rfs613qschulz: yeah for development it is a different story14:33
qschulznot even development14:33
qschulze.g. a security fix for production14:33
qschulza small one-liner patch in the kernel or even a small fix in the dtb14:33
qschulzand you go from a few MB to a few hundreds of MB (or GB depending on your rootfs)14:34
qschulzanyways :)14:34
qschulzno perfect solution, hence why there are so many14:34
rfs613qschulz: indeed14:34
*** frieder <frieder!> has joined #yocto14:35
ptsneveslike i said. a very interesting issue. Well if the bootloader supports non fat it is also a good choic14:39
*** GuestNew118 <GuestNew118!~GuestNew1@> has quit IRC (Ping timeout: 252 seconds)14:45
jclsn[m]qschulz: God, 22 emails from the patch from Steve Sakoman. This is where I really don't understand your approach on sending patches via email....14:50
ptsnevesjclsn[m] heh i just disable the digest. It is awful14:51
sakomanjclsn[m]: and don't forget the 14 dunfell patches that followed the kirkstone set :-)14:51
qschulzjclsn[m]: you can disable the sending of mails on lists.yoctoproject.org14:52
qschulzI mean, receiving of mails14:52
qschulzand still be able to send some14:52
qschulzjclsn[m]: also, does not matter to me because I have collapsible threads enabled by default14:53
*** bps <bps!> has joined #yocto14:53
qschulzso it literally takes only one line on my mail client14:53
* JaMa was happy to receive them and review what's comming14:53
ptsnevesqschulz and then dont you lose the ability to see when there are updates?14:53
JaMabetter than useless e-mail notification from github that something was changed in some PR14:54
qschulzptsneves: not sure to understand your question?14:54
ptsnevesif everything is collapsed i guess the only line visible in your email client, is the thread start. All others are folded and you do not see them14:55
qschulzptsneves: yup14:56
qschulzbut when I receive an answer to any of the mails of that thread, it pushes the thread at the top of my mailbox14:56
qschulzalso, there's alittle arrow next to the first email in the thread, to uncollapse the whole thing and see each mail in the thread14:58
qschulzjclsn[m]: and we say thank you to sakoman for maintaing the lts branches :)14:58
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)15:00
sakomanqschulz: you're welcome :-)15:00
ptsnevessakoman Thanks! A task whose fruit is mostly enjoyed by for profits15:00
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 276 seconds)15:04
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 252 seconds)15:06
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 244 seconds)15:09
*** nemik <nemik!> has joined #yocto15:09
*** nemik <nemik!> has quit IRC (Ping timeout: 258 seconds)15:13
*** nemik <nemik!~nemik@> has joined #yocto15:14
*** m4ho <m4ho!~m4ho@> has quit IRC (Ping timeout: 244 seconds)15:14
*** m4ho <m4ho!~m4ho@> has joined #yocto15:15
*** m4ho <m4ho!~m4ho@> has quit IRC (Ping timeout: 240 seconds)15:19
*** pgowda_ <pgowda_!> has quit IRC (Quit: Connection closed for inactivity)15:20
qschulzgordon1: just to be extra super duper sure, you see s-nail INSIDE your rootfs right?15:29
qschulzyou're not complaining it gets built?15:29
qschulz(because those are two different things)15:30
gordon1i do complain about it's being built15:30
qschulzthen it's normal;15:30
qschulzI mean15:30
qschulzI think15:30
qschulzthat's what would make sense to me15:30
gordon1well, the issue is that it doesn't build and i don't care about it so much so i don't want to figure it out so i want to omit it entirely15:31
qschulzbecause BAD_RECOMMENDATIONS can be modified in an image recipe, and recipes cannot access other recipes' metadata (nor change it)15:31
*** Qorin <Qorin!~Qorin@2001:1c00:f23:2600:7412:8cb3:b465:5ec2> has joined #yocto15:31
qschulzit means that in order for bitbake to let the image recipe decide what to include or not, it needs to have created all the packages that might be included in an image15:32
qschulzso a package rrecommends something, means bitbake will build it "just in case15:32
gordon1oh god15:32
qschulzif you don't need it, it'll just not be installed, but still built15:32
gordon1i see now15:32
gordon1so i have to modify the recipe with bbappend for it not to be built?15:33
*** m4ho <m4ho!~m4ho@> has joined #yocto15:33
qschulzfor the same reaon that all packages of a recipe are built even if you don't care about them15:33
qschulzgordon1: yup15:33
gordon1i see15:33
gordon1ok, good that i didn't report the bug then15:33
qschulzgordon1: actually, could you still report one?15:33
qschulzbut for the documentation15:33
qschulzbecause this definitely needs to be explicit15:33
qschulzit's not straightforward15:33
qschulzand you're probably not the first one to ask yourself this question15:34
gordon1i could but i don't have an account and it looks like registration is closed up15:34
qschulz(and considering that I took me that long to figure it out, that makes the two of us actually struggling with it... which is not good)15:34
gordon1tried to register one just a moment ago15:35
qschulzgordon1: mmm I don't think it should be the case15:35
qschulzany specific error15:35
qschulzor are you waiting for your confirmation mail or something?15:35
gordon1you're talking about ?15:35
qschulz(so I know if we ping IT or not)15:35
qschulzgordon1: yes15:35
gordon1>Account creation is disabled due to recent spam attacks.15:35
gordon1i could email to the address it tells me to15:36
gordon1but it looks like it will take a while since it's human processed15:37
qschulzhalstead: is it ok to reopen the registration for bugzilla?15:39
qschulzhalstead: hi :)15:39
gordon1already sent the mail15:39
qschulzsame person behind I assume :)15:40
qschulzso "double" ping :)15:40
gordon1i see15:40
*** florian_kc <florian_kc!> has joined #yocto15:53
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 244 seconds)15:54
*** nemik <nemik!> has joined #yocto15:54
*** camus <camus!~Instantbi@2409:8a1e:9115:40b0:5cba:93d:19c2:1dcb> has joined #yocto15:56
*** TundraMan is now known as marka15:57
*** nemik <nemik!> has quit IRC (Ping timeout: 256 seconds)15:58
*** nemik <nemik!~nemik@> has joined #yocto15:59
fraytrying to help someone, they're getting the PR service error about PRs going backwards.  I know there is a switch they can flip so PRs never go backwards, but I can't find it.. anyone point me to it?16:00
Saur[m]@fray: I actually think it is supposed to be enabled by default. Though it definitely doesn't work as I expect. I went looking for that switch a while ago and I found the code that was added to support it. That code was enabled by default, but no switch was actually added to turn it off...16:03
*** Guest51 <Guest51!~Guest51@> has joined #yocto16:05
*** Guest51 <Guest51!~Guest51@> has quit IRC (Client Quit)16:05
*** Sam47 <Sam47!~Sam@> has joined #yocto16:06
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 255 seconds)16:09
*** Sam47 <Sam47!~Sam@> has quit IRC (Client Quit)16:10
fraythere used to be a setting you could flip that would just always keep the PR going forward... (I'm on Honister BTW)16:10
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)16:10
*** camus <camus!~Instantbi@2409:8a1e:9115:40b0:5cba:93d:19c2:1dcb> has quit IRC (Ping timeout: 240 seconds)16:18
shoraganfray, perhaps ?16:25
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)16:25
*** florian_kc <florian_kc!> has joined #yocto16:26
Saur[m]fray: That's what RP said as well when I asked for this, but the Git logs don't agree. What I can find is commit 379567ee879dcdc09a51f7f1212bde1076147a6f in bitbake. It adds what it calls "no history" mode, which is supposed to prevent the PRs from going backwards. It also enables this mode. However, there is no switch to actually turn it off.16:27
Saur[m]From the wiki page for the PR server:16:31
Saur[m]database wrapper object supports two working modes, "hist: Preserve PR history" and "no_hist: Don't use history (delete old entries from the database)"16:31
Saur[m]currently the server forces the no_hist=True value, forcing no_hist mode.16:31
shoraganfray, which release are they using?16:32
*** mckoan is now known as mckoan|away16:32
shoraganah, 3795... is from 2012.16:33
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 240 seconds)16:36
RPSaur[m]: regardless of the git logs, we probably should make this possible16:45
Saur[m]RP: Well, the problem I see is: why are the PRs going backwards when they are not supposed to with the current mode?16:46
Saur[m]I know I started digging into it, but then I of course got side tracked and forgot about it.16:47
*** frieder <frieder!> has quit IRC (Remote host closed the connection)16:49
RPSaur[m]: I don't remember enough of the details to comment sensibly16:52
Saur[m]No worries.16:52
frayPRs go backwards when developers are making local changes.  I would never "disable" the warning in a production environment, but for a single developer it can make sense16:52
fraything of it this way.   I'm developing, initial build is PR=0... I try something (change a kernel config) kernel becomes PR=1... I figure out what I did doesn't make sense, and go back to the origina config.. PR=0, error is kicked off..16:53
frayin a "real" production environmnet.. you would want a PR=2, and force it by making a change..16:54
frayin a "dev" environmnet, you just want the system to say "ya, just make it PR=2 for now"16:54
halsteadgordon1: All set. We processed accounts just before your request so there was a delay.16:54
*** florian_kc <florian_kc!> has joined #yocto16:59
Saur[m]Something else related to PRs going backwards is that it seems to happen way more often with Honister and later. So much so that I had to turn the error into a warning (we don't use package feeds so it should not be a real problem). Typically I often get a gazillion packages with PRs going backwards when setscene is running. And no I have not had time to look into this either yet, which is why I just made it a warning.17:02
kergothAny use of sstate in development can result in them going backwards. make a cahnge, do a build, drop the change, do another build, it just went backwards.17:06
kergothI just ignore that qa check entirely during development, just not in our automated builds17:07
Saur[m]kergoth: But according to the (limited) documentation about the no_hist mode indicates that it should still go forward in that case.17:07
RPSaur[m]: kergoth has a good point. pr_serv predates sstate so the docs for prserv wouldn't know anything about this17:08
Saur[m]But obviously it doesn't, so there must be something that I still haven't figured out about how the PR server works.17:08
Saur[m]Hmm, good point.17:08
RPSaur[m]: the key thing is that prserv predates sstate by many years. When we added sstate it probably changed behaviour17:08
RPin fact I'm pretty sure that was what we concluded last time we discussed this17:09
RPkergoth: what a strange world our builds used to be :)17:11
* RP suspects the lack of sstate and rss would drive people insane now17:11
Saur[m]Well, sstate was there before me, so I don't want to think about a world without it. But the lack of RSS I can definitely relate to, and what a pain it was.17:12
RPSaur[m]: imagine pre sysroots where you coded a do_install and a do_stage for the "sysroot" before sysroots were a thing too :)17:13
Saur[m]la la la I'm going to go debug something la la la17:14
* RP probably should tell horror stories17:14
Saur[m]RP, the next Stephen King17:15
RPfray: so short answer is that sstate changed the behaviour and nobody has unwound this17:16
RPI suspect we're not even sure how you unwind that17:17
fraylike hashequiv, prservice really needs to be "built into" sstate IMHO.. they shouldn't be separable..17:18
fraythe "how", I don't know17:18
RPfray: that is the opposite of what you said you want above though17:18
RPfray: sstate is likely restoring the PR to a previous point. You want it to always rebuild17:19
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto17:21
frayI'm saying they're linked..17:27
frayfor the "Dev" case, we just need to deal with it..17:27
fraydeal with it may be error -> warning..  force PR to increment and thus the package_write... sstate to update (somehow)..17:28
frayagain, I have no actual answer..17:28
frayright now we have something that works for the production case (might be somewhat difficult to keep it in sync, but it works)... it's the dev case where "let me know, but I don't care" that we don't have a great answer for..17:29
frayI think I'm going ot tell the person who asked me to move the error to a warning in the buildhistory then.17:29
frayI (think) we all agree it's absolutely an error in the production case.. but could be considered a warning when doing development, unless you are using the packages themselves for on-target updates..17:31
RPfray: that "let me know, I don't care" is pretty much what today's warning is17:35
RPyou can make it a warning, error or ignored by the WARN_QA and ERROR_QA settings17:36
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 256 seconds)17:41
JaMaRP: are you sure prserv predates sstate? I think it predates only rss and hashequiv, but not sstate itself17:57
JaMaRP: thanks for that sre_constants change17:58
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto18:03
JaMa in 2010 and in 201118:04
JaMaand OEBasicHash used by default in oe-core since 2012 a bit sooner in poky since 3a2338607bdd84db5f164801b6c0016226559569 merged in Feb 201218:09
* JaMa feels old without even looking in mtn history18:10
jsbronderAnyone have DL_DIR on nfs and bind-mounting into docker/podman?  Git's new permission checks aren't happy with the way I'm binding and I'm not sure if there's an easy way out.18:32
*** florian_kc <florian_kc!> has joined #yocto18:42
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)18:43
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 272 seconds)18:49
*** nemik <nemik!> has joined #yocto18:49
*** nemik <nemik!> has quit IRC (Ping timeout: 246 seconds)18:53
*** nemik <nemik!~nemik@> has joined #yocto18:54
*** Qorin <Qorin!~Qorin@2001:1c00:f23:2600:7412:8cb3:b465:5ec2> has quit IRC (Quit: Client closed)18:57
*** prabhakarlad <prabhakarlad!> has joined #yocto19:01
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)19:18
jsbronderActually adding GIT_DIR=. or --git-dir=. to FETCHCMD_git appears to work.19:23
jsbronderWhich is the hack I first used before the git intercept was added.19:24
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 255 seconds)19:46
*** kscherer <kscherer!> has quit IRC (Ping timeout: 250 seconds)20:05
*** kscherer_ <kscherer_!> has joined #yocto20:06
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 240 seconds)20:09
*** nemik <nemik!> has joined #yocto20:09
*** nemik <nemik!> has quit IRC (Ping timeout: 246 seconds)20:13
*** nemik <nemik!~nemik@> has joined #yocto20:14
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Read error: Connection reset by peer)20:14
RPJaMa: prserv was written by Intel PRC team iirc20:23
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 246 seconds)20:23
*** nemik <nemik!> has joined #yocto20:23
RPJaMa: looks like sstate was Aug 2010 which is older than I thought, prserv was May 201120:26
RPJaMa: I guess I was thinking prserv in 2010 and siggen hashes in 201220:28
*** bps <bps!> has joined #yocto20:28
*** nemik <nemik!> has quit IRC (Ping timeout: 240 seconds)20:33
*** nemik <nemik!~nemik@> has joined #yocto20:34
*** Bardon_ <Bardon_!~Bardon@user/Bardon> has quit IRC (Ping timeout: 272 seconds)20:39
*** marex <marex!~marex@> has quit IRC (Ping timeout: 256 seconds)21:06
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto21:11
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)21:18
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 244 seconds)21:24
*** nemik <nemik!> has joined #yocto21:24
*** nemik <nemik!> has quit IRC (Ping timeout: 256 seconds)21:29
*** nemik <nemik!~nemik@> has joined #yocto21:29
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)21:41
*** rber|res <rber|res!~rber|> has quit IRC (Ping timeout: 256 seconds)22:38
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)22:38
*** rber|res <rber|res!~rber|> has joined #yocto22:39
*** warthog9 <warthog9!> has quit IRC (Ping timeout: 276 seconds)22:43
*** warthog9 <warthog9!> has joined #yocto22:52
*** xmn <xmn!> has joined #yocto23:07
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 246 seconds)23:12
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 244 seconds)23:13
*** Tokamak <Tokamak!> has joined #yocto23:15
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 258 seconds)23:19
*** mckoan|away <mckoan|away!> has quit IRC (Ping timeout: 255 seconds)23:24
*** rber|res <rber|res!~rber|> has quit IRC (Ping timeout: 255 seconds)23:26
*** kscherer_ <kscherer_!> has quit IRC (Quit: Konversation terminated!)23:27
*** rber|res <rber|res!~rber|> has joined #yocto23:28
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)23:46
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 258 seconds)23:54
*** nemik <nemik!> has joined #yocto23:54
*** nemik <nemik!> has quit IRC (Ping timeout: 240 seconds)23:58
*** nemik <nemik!~nemik@> has joined #yocto23:59

Generated by 2.17.2 by Marius Gedminas - find it at!