Tuesday, 2022-05-31

*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 246 seconds)00:04
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto00:04
*** Reto[m] <Reto[m]!~rettichsc@2001:470:69fc:105::5057> has joined #yocto00:05
*** olani <olani!~olani@h83-209-157-187.cust.a3fiber.se> has joined #yocto00:06
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 240 seconds)00:09
*** otavio <otavio!~otavio@191-221-92-247.user3p.brasiltelecom.net.br> has quit IRC (Remote host closed the connection)00:09
*** nemik <nemik!~nemik@> has joined #yocto00:09
*** Herrie <Herrie!~Herrie@110-31-146-85.ftth.glasoperator.nl> has quit IRC (Ping timeout: 258 seconds)00:14
*** zeddii <zeddii!~zeddii@> has quit IRC (Ping timeout: 276 seconds)00:19
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection)00:36
*** bps3 <bps3!~bps@> has quit IRC (Ping timeout: 276 seconds)00:41
*** seninha <seninha!~seninha@user/seninha> has joined #yocto00:44
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 255 seconds)00:54
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto00:54
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 240 seconds)00:59
*** nemik <nemik!~nemik@> has joined #yocto00:59
*** camus <camus!~Instantbi@2409:8a1e:911c:6320:8417:14b0:36d0:7ee7> has joined #yocto01:18
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.)01:22
*** starblue <starblue!~juergen@dslb-088-078-111-185.088.078.pools.vodafone-ip.de> has quit IRC (Ping timeout: 258 seconds)01:53
*** starblue <starblue!~juergen@dslb-094-220-115-211.094.220.pools.vodafone-ip.de> has joined #yocto01:55
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto02:22
*** zeddii <zeddii!~zeddii@> has joined #yocto02:24
*** zeddii <zeddii!~zeddii@> has quit IRC (Ping timeout: 255 seconds)02:46
*** zeddii <zeddii!~zeddii@> has joined #yocto03:26
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Quit: Leaving)04:02
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.)04:30
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 260 seconds)04:45
*** davidinux <davidinux!~davidinux@> has joined #yocto04:47
*** olani <olani!~olani@h83-209-157-187.cust.a3fiber.se> has quit IRC (Ping timeout: 255 seconds)05:15
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:2048:1f56:f4e8:63f1> has quit IRC (Ping timeout: 255 seconds)05:30
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 246 seconds)05:58
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto05:58
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:01
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 246 seconds)06:03
*** nemik <nemik!~nemik@> has joined #yocto06:03
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 258 seconds)06:09
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto06:09
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 258 seconds)06:13
*** nemik <nemik!~nemik@> has joined #yocto06:14
*** Schiller <Schiller!~Schiller@dynamic-002-247-252-241.2.247.pool.telefonica.de> has joined #yocto06:16
*** Schiller <Schiller!~Schiller@dynamic-002-247-252-241.2.247.pool.telefonica.de> has quit IRC (Quit: Client closed)06:25
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto06:31
*** Schiller <Schiller!~Schiller@dynamic-002-247-252-241.2.247.pool.telefonica.de> has joined #yocto06:33
*** frieder <frieder!~frieder@200116b824ec61810000000000002000.dip.versatel-1u1.de> has joined #yocto06:37
*** Herrie <Herrie!~Herrie@110-31-146-85.ftth.glasoperator.nl> has joined #yocto06:42
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto06:49
*** tre <tre!~tre@ip5f5886dd.dynamic.kabel-deutschland.de> has joined #yocto06:58
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection)06:59
*** mckoan|away is now known as mckoan07:01
mckoangood morning07:01
wyreo/ :)07:02
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:06
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto07:14
*** acki_ <acki_!~acki_@2a02:8109:a280:2d8d:1ae:2c48:fcb4:f3b4> has joined #yocto07:14
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto07:25
*** bps3 <bps3!~bps@> has joined #yocto07:33
LetoThe2ndyo dudX07:50
RPjaskij[m]: I was going to sleep too! :)07:50
jaskij[m]RP: Nice one. Having slept on it, I think I'll just report as is, and if they need a more detailed repro, we'll go from there. If you want to chip in with a link to a failing build in Yocto's CI?07:53
RPjaskij[m]: I don't easily have such a thing as yet, I noticed it failing but I didn't dig into it or get any fruther07:54
RPI suspect if they know it can return 0, they'll know how to fix it07:54
jaskij[m]Fair enough. I should send to their mailing list in a few hours07:56
RPjaskij[m]: Sounds good thanks. It could of course be a different issue too :/07:58
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto08:00
jaskij[m]Also, I've seen a mailing list thread about Go fetching in do_compile, with talks about making a generator. Did anything make it into Kirkstone? So far I just enabled network for the task in the few recipes I have.08:00
RPjaskij[m]: nothing merged as yet08:00
landgrafjaskij[m]: I think we have some kind of workaround for this problem. CC zyga[m]08:01
jaskij[m]Oh well.08:01
*** violet <violet!~vi@user/violet> has joined #yocto08:02
zyga[m]good morning08:02
zyga[m]landgraf: nothing fancy, I'm afraid, we wanted to write a proper fetcher but never got around to it08:02
zyga[m]landgraf: the idea is to use go itself, since go can correctly fetch all the deps and be ready for offline builds08:03
landgrafzyga[m]: Oh. Sorry. I'm reading "trick" paragraph in the recipe and it looks tricky :D08:03
zyga[m]landgraf: but we never wrote that code08:04
zyga[m]I mean, ideally it would be little more than `go mod download`08:04
zyga[m]I don't think supporting pre-module code is worth-while08:04
zyga[m]ah :)08:05
landgrafdo_compile[network] = "1"08:05
landgrafjaskij[m]: ^ nvm then. Sorry for false alarm08:05
jaskij[m]landgraf: Yeah, that's what I'm doing now. Thanks for the help anyway.08:06
zyga[m]yeah, that's the hack we do08:07
*** ptsneves <ptsneves!~ptsneves@031011128246.dynamic-3-poz-k-0-2-0.vectranet.pl> has joined #yocto08:13
*** kriive <kriive!~kriive@user/kriive> has joined #yocto08:15
*** acki_ <acki_!~acki_@2a02:8109:a280:2d8d:1ae:2c48:fcb4:f3b4> has quit IRC (Ping timeout: 260 seconds)08:26
ernstpmrybczyn[m]: Any more thoughts on my suggested changes to cve-check?08:26
mrybczyn[m]ernstp: should have a result from the build farm tomorrow. I'm checking the results and would likely suggest adding a switch. But let me analyse the result set08:38
ernstpmrybczyn[m]: Oh you're testing it, nice! Hmm.. the switch would change the "recipies" list to be a longer list in that case.. ?08:40
mrybczyn[m]ernstp: if I have a doubt that we're getting an incomplete list, I'll suggest you to make it optional. It's quite  tedious to check so that's why it is taking time08:43
ernstpmrybczyn[m]: I don't think it's incomplete, but please let me know what you find!08:45
ernstpmrybczyn[m]: with my $company hat and a number of extra layers I want a small list of CVEs to take care of. But from the Yocto project view they probably always want all CVEs always08:45
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Ping timeout: 252 seconds)08:46
mrybczyn[m]ernstp: we're on the same boat here08:49
ernstpmrybczyn[m]: 👍08:49
*** alessioigor <alessioigor!~alessioig@> has joined #yocto08:49
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto08:50
ernstpmrybczyn[m]: but the summary file is always still there!08:50
mrybczyn[m]ernstp: a small secret: I'd like to split the image and sdk reports08:54
ernstpmrybczyn[m]: the sdk is also an image. but the whole sdk build could have another summary...08:58
*** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has quit IRC (Read error: Connection reset by peer)09:02
*** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has joined #yocto09:02
ernstpmrybczyn[m]: I think my initial annoyance was that simply enabling "cve-check" caused sqlite-native to build and include sqlite in the cve list09:03
jclsn[m]Is there a way to add the toolchain and sysroot to CMake without sourcing it?09:06
jclsn[m]I tried this old guide, but it doesn't work https://embeddeduse.com/2017/06/03/cmake-cross-compilation-based-on-yocto-sdk/09:07
jclsn[m]Actually this shouldn't be necessary anymore, shouldn't it? I added09:09
jclsn[m]set(CMAKE_TOOLCHAIN_FILE /opt/fslc-wayland/3.4-snapshot-20220517/sysroots/x86_64-fslcsdk-linux/usr/share/cmake/OEToolchainConfig.cmake) to my CMakeLists.txt, but it doesn't find anything09:09
jclsn[m]s/shouldn't/should/, s/CMAKE_TOOLCHAIN_FILE/CMAKE\_TOOLCHAIN\_FILE/, s/x86_64/x86\_64/09:10
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)09:24
*** alessioigor <alessioigor!~alessioig@> has joined #yocto09:25
SchillerRP: Hey, sorry couldn't respond in time to <<are you using the codebaseGenerator function?>>. Atm i removed the codebaseGenerator and have a normal SingleScheduler which seems to trigger correctly. The Problem is the <<Fetch yocto-autobuilder-helper>> step. It does a git clone from the autobuilder repo into the builddirectory and then tries a <<git09:26
Schillerreset --hard <commit> -->>. I don't quite understand why he even tries to do this as i surely should fail because they are different repos. Can you give me some more intel on how this is meant to work?09:26
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)09:30
RPSchiller: I don't remember the details but I suspect you may need something similar to what we have but tweaked for your repos09:38
*** ptsneves <ptsneves!~ptsneves@031011128246.dynamic-3-poz-k-0-2-0.vectranet.pl> has quit IRC (Quit: Client closed)09:38
*** jpuhlman <jpuhlman!~jpuhlman@99-14-97-149.lightspeed.frokca.sbcglobal.net> has quit IRC (Ping timeout: 246 seconds)09:42
*** jpuhlman <jpuhlman!~jpuhlman@99-14-97-149.lightspeed.frokca.sbcglobal.net> has joined #yocto09:43
*** starblue <starblue!~juergen@dslb-094-220-115-211.094.220.pools.vodafone-ip.de> has quit IRC (Ping timeout: 240 seconds)09:59
*** starblue <starblue!~juergen@dslb-094-220-115-211.094.220.pools.vodafone-ip.de> has joined #yocto10:01
jaskij[m]RP: e2fsprogs seems to have a fallback to 4 threads, so it seems like a quick and dirty patch would be just changing `<` to `<=` here: https://github.com/tytso/e2fsprogs/blob/96185e9bef1dca5a3b7d93f244d65107aad5f37f/lib/ext2fs/rw_bitmaps.c#L55710:05
*** bps2 <bps2!~bps@27-reverse.bang-olufsen.dk> has joined #yocto10:12
*** bps3 <bps3!~bps@> has quit IRC (Ping timeout: 240 seconds)10:14
*** bps2 <bps2!~bps@27-reverse.bang-olufsen.dk> has quit IRC (Read error: Connection reset by peer)10:19
*** bps2 <bps2!~bps@> has joined #yocto10:20
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)10:20
*** JPEW <JPEW!sid500061@helmsley.irccloud.com> has quit IRC (Ping timeout: 276 seconds)10:20
*** JPEW <JPEW!sid500061@helmsley.irccloud.com> has joined #yocto10:21
*** mvlad <mvlad!~mvlad@2a02:2f08:4802:2100:24d7:51ff:fed6:906d> has joined #yocto10:23
jaskij[m]bug filed: https://github.com/tytso/e2fsprogs/issues/11410:23
*** uglyoldbob <uglyoldbob!uid555603@id-555603.hampstead.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)10:28
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto10:31
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 255 seconds)10:33
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto10:34
jaskij[m]RP: I can't file a patch immediately, as I'm at work and we don't have a FOSS policy (although I'm working on it, this will take some time though). Will try to get at least the quick and dirty workaround in later this week (I'm unfortunately busy tonight).10:36
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 255 seconds)10:38
*** nemik <nemik!~nemik@> has joined #yocto10:38
manuel1985Is anyone around here developing yocto on an Apple M1? What's your experience? My boss offers us some and I'm hesitating.10:42
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 244 seconds)10:44
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto10:44
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto10:44
LetoThe2ndmanuel1985: its cool.10:48
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 276 seconds)10:49
*** nemik <nemik!~nemik@> has joined #yocto10:49
LetoThe2ndmanuel1985: given a few assumption: 1) you get a parallels license to run a linux vm 2) you get enough ram 3) you don't try to build "older releases", e.g. those that require syslinux for wic before it was aarch64-enabledä10:50
manuel1985LetoThe2nd: Thanks, it's good to know to keep that in mind.10:51
manuel1985Is parallels supporior to other VMs?10:52
manuel1985I'd say 16gig RAM is enough for now. True?10:53
JaMadepends on the type of images you're regularly building, for me 16gig is terribly small10:53
LetoThe2ndmanuel1985: i'd go for 32GB, and... what other vms do you mean exactly?10:53
manuel1985LetoThe2nd: VirtualBox or VMware. (Don't know if they even support Apple, so perhaps my question was a stupid one)10:56
LetoThe2ndmanuel1985: ;-) good guess, exactly thats the point.10:56
RPjaskij[m]: sounds good thanks!10:58
jaskij[m]<manuel1985> "I'd say 16gig RAM is enough..." <- IME, on a Linux host, running Yocto in a VM, with CLion (IDE) and a browswer open, 32 GB is tight but doable.10:59
jaskij[m]With M1 using the same memory for CPU and GPU personally I'd shoot for 64 gigs11:00
jaskij[m]iirc C++ builds can easily do 1+ GB/thread11:01
LetoThe2ndjaskij[m]: well, it depends.11:01
LetoThe2ndjaskij[m]: i'm on 32 and not noticing any tightness, but again, YMMV11:01
jaskij[m]oh, it sure does, but as a generalization for using Yocto 1 GB/core seems like a decent approximation11:02
* JaMa is regularly triggering OOMK with 2GB/core (128G/64c)11:02
jaskij[m]fair, the tightness started when I added more VMs or launched a second IDE11:02
jaskij[m]when I had a VM, I had it set to 20 GB for a 6c12t CPU11:03
jaskij[m]with a headless Debian running Yocto11:03
LetoThe2ndjaskij[m]: exactly, and i'm usually on one builder VM, and using vscode. so essentially there's only two real workloads: browser(s) and one vm 6c20gb.11:03
LetoThe2ndworks pretty nicely for me.11:04
*** ptsneves <ptsneves!~ptsneves@85-128-83-172.static.ip.netia.com.pl> has joined #yocto11:04
jaskij[m]so yeah, for a 10c M1 32 GB should be enough, if it's just browser, editor and a Yocto VM11:04
JaMaas long as you don't build chromium or nodejs11:05
jaskij[m]Back when Dunfell was latest I gave up on packaging nodejs things11:05
manuel1985Thanks guys! Your field reports are very helpful.11:05
jaskij[m]was a nightmare, especially if your nodejs code had native dependencies (eg. serial)11:05
LetoThe2ndjaskij[m]: i'm "only" doing documentation, demo and talking these days, no more nodejs involved! yes!11:06
* JaMa just bisecting gcc to find out where it breaks webruntime build, as many cores as possible is useful :)11:07
LetoThe2ndhaving said that, i actually like writing js/ts - but not for an embedded target11:07
jaskij[m]Luckily, I left the company before packaging nodejs backends under Yocto became required. And I cursed the day I OKed the nodejs backend for weeks.11:08
jaskij[m]Nowadays I'm firmly in the Python backend camp.11:08
jaskij[m]sure, Python native dependencies can be a pain, and setuptools seems mildly cursed by itself, but it's at least a known quantity with good support in Yocto11:10
neverpanicAt my previous employer, we regularly hit OOM with 2GB per core, compiling lots of C++11:10
neverpanicIIRC we ended up with 192GiB/40c in the end, which may have been a bit overkill11:11
LetoThe2ndthe problem is not nodejs or python per se. the key is using the right tool for the given problem, and understanding that actually deploying through a yocto build is part of the problem, not something that will magically happen.11:11
LetoThe2ndneverpanic: at my last company we actually bought a 256c512gb epyc box, which served as the dev host for the sw people.11:12
jaskij[m]LetoThe2nd: you are right, and because of that I adopted the policy that all dependencies going into Yocto must be okayed by me first (working as the only Yocto, and Linux in general, person in small embedded place has it's perks).11:12
neverpanicShare machine doing Yocto builds was always a bit annoying. It becomes bareable if everbody does their builds in cgroups.11:13
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)11:13
*** td70 <td70!~td@> has joined #yocto11:14
td70is there any way to decrease the build time with sstate-cache disabled? We're having a jobs that test the build from scratch and after update to from Krogoth to Gatesgarth the build time increased from 3-4h to 5-6 hours.11:16
LetoThe2ndtd70: you can try to trace the build and find out if there is any outlier that eats an unusual amount of time, but in the krogoth to gatesgarth history there have been a lot of substantial changes and updates, so i'd expect this to be "normal"11:18
JaMatd70: more cores, more ram11:18
*** otavio <otavio!~otavio@191-221-92-247.user3p.brasiltelecom.net.br> has joined #yocto11:19
LetoThe2ndeven that doesn't always scale11:19
LetoThe2ndtd70: and please note that gatesgarth is EOL and unsupported by now too!11:19
td70yes, I know it's not supported already. when we started the update it was alive but it took a lot of time to update :D11:20
LetoThe2ndtd70: keep on updating then!11:21
JaMawhy didn't you target dunfell as it's LTS?11:21
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 255 seconds)11:21
td70I wasn't at the decision making, but probably  we targeted something more recent and we didn't expect the update to take 1.5 year11:22
*** davidinux <davidinux!~davidinux@> has joined #yocto11:23
td70obviously we will start the next update soon, but we're trying to solve the problems we have now11:23
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 260 seconds)11:24
*** nemik <nemik!~nemik@> has joined #yocto11:24
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection)11:36
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto11:37
*** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has quit IRC (Ping timeout: 258 seconds)11:37
*** Schiller <Schiller!~Schiller@dynamic-002-247-252-241.2.247.pool.telefonica.de> has quit IRC (Quit: Client closed)11:46
*** seninha <seninha!~seninha@user/seninha> has joined #yocto11:46
*** BobPungartnik <BobPungartnik!~Pung@> has joined #yocto11:46
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Remote host closed the connection)11:46
*** seninha <seninha!~seninha@user/seninha> has joined #yocto11:47
*** cmd <cmd!~cmd@user/cmd> has joined #yocto11:47
*** BobPungartnik <BobPungartnik!~Pung@> has quit IRC (Client Quit)11:47
*** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto11:48
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto11:55
*** Schiller <Schiller!~Schiller@dynamic-002-247-252-241.2.247.pool.telefonica.de> has joined #yocto12:00
Guest87anybody have tips on putting toaster behind a reverse proxy?12:20
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto12:50
JPEWderRichard: We bind mount in the entire working directory into the docker container and it seems to work just fine12:58
derRichardJPEW: so do i here too. i still have no idea why i'm facing these problems12:59
JPEWderRichard: Do you have builds that get interrupted (e.g. stopped in the middle)13:01
derRichardnot that i know of.13:01
JPEWderRichard: Sometimes it happens without realizing; anyway pseudo does heavy in-memory caching and if it get killed for some reason (esp. if the container it's running in dies because the kernel will SIGKILL all processes), it won't write out database. This causes things to get out of sync if you build again13:02
JPEWderRichard: See the FAQ about cleanup.py: https://github.com/garmin/pyrex#faq13:03
JPEWderRichard: We mostly saw that problem with local development (when someone did a CTRL+C) instead of CI though13:04
derRichardi see it only on the ci of my customer. on my own ci all id good ;-\13:04
derRichardbut i use gitlab, and they have jenkins13:04
JPEWNot sure if that matters13:05
qschulzderRichard: we had issues with rootless podman containers on Jenkins, but that is stuff specific to rootless podman IIRC13:05
qschulzderRichard: worked around by mounting a tmpfs, see https://github.com/siemens/kas/pull/76/commits/eb8f5c90804dee5a1a649883e1d400d1058639b313:07
derRichardqschulz: how is this realated to my problem?13:08
derRicharddid psudo also fail randomly?13:09
qschulzderRichard: don't know, but reading pseudo+container failing I always bring this up13:09
qschulzI think it consistently crashed on ncurses or icu native recipes13:09
qschulzhowever, I never have sstate-cache enabled13:09
qschulzso YMMV13:09
qschulz(will enable sstate-cache but don't have the time to set it up across jenkins nodes atm)13:10
sotaoverrideso my recipe only has a bunch of install -d under do_install, why do i get this "Recipe file fetches files and does not have license file information (LIC_FILES_CHKSUM) [license-checksum]"13:10
sotaoverridenot fetching anything, just creating directories13:11
qschulzsotaoverride: interesting kind of recipe.. what's the need for this? can't you just install the directories in the recipes that need it?13:12
qschulzderRichard: for the whole discussion (still don't know if it's relevant to you :) ) https://groups.google.com/g/kas-devel/c/Dm3OcBS-yao/m/opcyEKhEAwAJ13:13
SchillerRP Hey. When i do a commit in the repo on a branch other then master i get the Error: <<Target not present in branch configuration>>, when the autobuilder runs the <<target-present>> script. Where do i make the target present in the config.json?13:14
sotaoverrideqschulz: it's just for my filesystem overlay stuff, I dont need to fetch anything but just setup the directory structure for the upper/lower dir13:14
sotaoverrideand im on older yocto so i cant use the fsoverlay bb class either13:15
*** Net147 <Net147!~Net147@user/net147> has quit IRC (Quit: Quit)13:15
derRichardqschulz: thx13:15
ptsnevesqschulz it uses an incomplete fuse implementation incompatible with pseudo. The nightmare13:15
sotaoverrideqschulz: is there some sort of  ruling against against straight up recipes for just setting up directories and such?13:16
*** Net147 <Net147!~Net147@167-179-157-192.a7b39d.syd.nbn.aussiebb.net> has joined #yocto13:16
ptsnevessotaoverride maybe you can just do a rootfs post process where you add those directories. It is a bit strange to have a package with empty directories and i am not sure package managers even "like" that13:17
qschulzsotaoverride: all recipes have a license, that's the issue BitBake is reporting. I don't know if there's a default license (or was), because it probably should have failed on LICENSE missing. If LICENSE is set to something common, you could reuse one from the common-licenses directory (you probably have some recipes using COMMON_LIC_DIR or something like that in LIC_FILES_CHKSUM somewhere)13:17
qschulzsotaoverride: or follow what ptsneves just suggested :)13:18
ptsnevesLICENSE="closed" will make that requirement go away13:18
*** MWelchUK1 <MWelchUK1!~MWelchUK@static.> has joined #yocto13:19
ptsnevesNotice the text at the end13:19
qschulzptsneves: yeah but it's also too easy to have everything use LICENSE = CLOSED instead of taking 5min to do things properly (does not apply to this uncommon recipe of sotaoverride though)13:19
ptsnevesqschulz definitely agree. I have seen projects doing that and then needing to go through lots of recipes to fix the licenses13:20
sotaoverrideyeah, I think ill go with what ptsneves suggested, I was getting crap for setting LICENSE = CLOSED when on a PR I had up for it :P ill find out the right rootfs post porcess13:20
ptsnevessotaoverride the Yocto inquisition13:22
qschulzderRichard: also, we had to drastically increase containers.pids_limit in /etc/containers/containers.conf for podman to not kill the process (we have it set to 100000 instead of the default 1024)13:22
sotaoverrideptsneves: I can just append the directory creation function to ROOTFS_POSTPROCESS_COMMAND ? does that sound good enough?13:22
qschulzderRichard: sharing all my "knowledge" of container work-arounds :)13:23
derRichardqschulz: well, we don't see sporadic deaths of pseudo (or other programs in the container). we see that pseudo aborts itself due to inode mismatches13:23
derRichardwe run yocto in docker for years, all good so far.13:23
qschulzsotaoverride: I'd create a function that rootfs_postprocess_cmd would then contain. but yes13:23
*** Guest21 <Guest21!~Guest21@> has joined #yocto13:23
qschulzderRichard: yeah, couldn't rarely finish a build with rootless podman with jenkins (but for some reason, on the same server, manually it worked sometimes...)13:24
qschulzand it was pseudo inode mismatches, fixed with --tmpfs /tmp13:24
Guest21After bumping to kirkstone version I got  "python -m installer: error: unrecognized arguments: --interpreter /home/builder/yocto-kirkstone-next/builddir/tmp/work/x86_64-linux/python3-wheel-native/0.37.1-r0/dist/wheel-0.37.1-py3-none-any.whl" any idea to fix? (I'm not Yocto expert sorry:(  )13:24
qschulzalso, rootless podman does not behave the same as podman (it worked on "root" podman)13:25
derRichardqschulz: hmmm, i need to dig into this in detail. so far it makes no sense to my why /tmp plays a role13:25
qschulzderRichard: explained in the link I sent you earlier IIRC13:25
qschulzwas not involved in the discussion, tlwoerner was with folks from KAS13:25
derRichardas i said, i need to dig into this in detail13:25
qschulzsomething about the filesystem storage being different13:25
qschulzand also changes of tech between podman versions13:25
ptsnevessotaoverride sounds good but you need to add a function to that variable not the commands themselves. See https://docs.yoctoproject.org/singleindex.html#term-ROOTFS_POSTPROCESS_COMMAND13:26
RPderRichard: Is it possible you upgraded to a new glibc version and we don't intercept some function call there that we should13:26
qschulzderRichard: maybe you'll be able to help :) you surely have more clues than I do about filesystems :)13:26
qschulzso I'll just shut up now since I really don't have anything else to add :)13:26
ptsnevessotaoverride also have a look at an example in poky/meta/classes/license_image.bbclass13:26
RPderRichard: it is possible that the files are being manipulated outside pseudo context too13:26
derRichardRP: yeah, but on the ci pipeline this really should not happen13:27
derRichardi'd expect so on a developer workstation13:27
derRichardbut not on jenkins13:27
RPderRichard: bitbake does run tasks which are not under pseudo though13:27
RPderRichard: so it is possible even in CI if there is a recipe fault13:27
tlwoernerperhaps more info here? https://groups.google.com/g/kas-devel/c/Dm3OcBS-yao?pli=113:28
qschulztlwoerner: thanks :)13:29
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 250 seconds)13:34
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto13:34
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC (Quit: Leaving)13:37
ptsnevesRP did you explore the idea of git subtree for poky ?13:38
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 246 seconds)13:39
*** nemik <nemik!~nemik@> has joined #yocto13:39
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto13:53
hushmoneyi'm trying to use a layer provided to me that list both dunfell and honisterin LAYERSERIES_COMPAT. is there a bitbake config to make it tolerate the old style override syntax, or is it wrong for a layer to advertise compatibility with both?13:55
JaMahushmoney: the new syntax is backwards compatible, so it can be compatible with both, but then it should be using the new syntax13:58
*** kscherer <kscherer!~kscherer@dsl-173-206-15-108.tor.primus.ca> has joined #yocto13:59
qschulzhushmoney: or said another way, dunfell (since 3.1.11 I think?) supports both syntaxes14:00
qschulzso using the new syntax for a layer that supports dunfell and honister is ok14:00
qschulzprovided your users are on dunfell >= 3.1.11 (and if they are not, they should upgrade (we're on 3.1.16 now))14:00
RPptsneves: yes, we'd have to change the layout :/14:02
ptsnevesRP oh. So no free lunch14:02
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection)14:07
RPptsneves: of course not14:08
*** MWelchUK1 <MWelchUK1!~MWelchUK@static.> has quit IRC (Ping timeout: 240 seconds)14:16
hushmoneyJaMa: qschulz: ah-ha, thanks i didn't consider it that way. in that case i should revise my question to say they also advertise compat with zeus. maybe they haven't updated the syntax yet because some of their users still use zeus, but then it seems they shouldn't advertise honister14:33
qschulzhushmoney: there's actually patches in zeus branch for the old override syntax I think14:39
qschulz(at least thud has it, and it predates zeus)14:39
hushmoneydid you mean to say for the new syntax?14:47
qschulzhushmoney: yes14:47
hushmoneyi see, thanks14:48
qschulzso if you update to latest commit in zeus branch you might have support for the new syntax too14:48
qschulzhushmoney: but I'd triple check, i'm not entirely sure the patch is there14:49
hushmoneyi sure wish we would just refer to these by version number, i keep having to look it up what release comes before or after another release14:49
*** Schiller <Schiller!~Schiller@dynamic-002-247-252-241.2.247.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds)14:50
RPhushmoney: they do sort alphabetically FWIW14:50
RPwithin a name series anywah14:51
jaskij[m]Speaking of licensing, if upstream's licensing is a mess my only recourse is to bug them to fix it, right?14:54
hushmoneyRP: thank you i was too stupid to notice that14:54
*** mckoan is now known as mckoan|away14:55
*** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)14:55
*** ThomasRoos <ThomasRoos!~ThomasRoo@ip4d1567a2.dynamic.kabel-deutschland.de> has joined #yocto14:57
RPjaskij[m]: probably, depends what the mess is I guess14:58
*** tre <tre!~tre@ip5f5886dd.dynamic.kabel-deutschland.de> has quit IRC (Remote host closed the connection)14:59
jaskij[m]RP: The package has an overarching license, but a lot of submodules or individual files are under different licenses. They do have a combined licenses file, but it's woefully out of date.15:00
*** zwelch_ <zwelch_!~zwelch@fluffy.mandolincreekfarm.com> has joined #yocto15:00
jaskij[m]Referring nonexistent files and similar15:01
RPjaskij[m]: you can either try and untangle it or ask them to15:01
jaskij[m]Mhm... I might try looking through if some files were simply moved. The lack of a FOSS policy means anything I want to commit I have to do on my own time :/15:02
*** ptsneves <ptsneves!~ptsneves@85-128-83-172.static.ip.netia.com.pl> has quit IRC (Ping timeout: 252 seconds)15:16
*** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has joined #yocto15:20
*** ThomasRoos <ThomasRoos!~ThomasRoo@ip4d1567a2.dynamic.kabel-deutschland.de> has quit IRC (Remote host closed the connection)15:21
*** ThomasRoos <ThomasRoos!~ThomasRoo@ip4d1567a2.dynamic.kabel-deutschland.de> has joined #yocto15:21
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 258 seconds)15:24
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto15:24
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 255 seconds)15:29
*** nemik <nemik!~nemik@> has joined #yocto15:29
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Ping timeout: 256 seconds)15:39
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 240 seconds)15:39
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto15:39
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 272 seconds)15:44
*** nemik <nemik!~nemik@> has joined #yocto15:44
*** ThomasRoos <ThomasRoos!~ThomasRoo@ip4d1567a2.dynamic.kabel-deutschland.de> has quit IRC (Remote host closed the connection)15:52
*** seninha <seninha!~seninha@user/seninha> has joined #yocto16:00
*** bps2 <bps2!~bps@> has quit IRC (Ping timeout: 272 seconds)16:01
*** Guest21 <Guest21!~Guest21@> has quit IRC (Quit: Client closed)16:07
*** Schiller <Schiller!~Schiller@p200300efa70ea901e4eb2715a01c330e.dip0.t-ipconnect.de> has joined #yocto16:08
*** Schiller <Schiller!~Schiller@p200300efa70ea901e4eb2715a01c330e.dip0.t-ipconnect.de> has quit IRC (Client Quit)16:08
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 256 seconds)16:10
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)16:14
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat)16:15
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto16:15
*** Tokamak <Tokamak!~Tokamak@mobile-166-170-35-2.mycingular.net> has joined #yocto16:16
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 244 seconds)16:19
*** kevinrowland <kevinrowland!~kevinrowl@> has quit IRC (Quit: Client closed)16:30
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving)16:32
JaMahushmoney: qschulz: neither zeus (bitbake 1.44) nor thud (1.40) supports new syntax AFAIK16:33
JaMaclaiming support for zeus and honister is usually just wrong, some people prefer to claim the compatibility with the next release while it's still far from release (so they might have added honister before it required new syntax to be used), that's why I hate this premature claim16:34
JaMaFWIW: the necessary commits for each branch which supports new syntax are linked from https://github.com/ros/meta-ros/pull/90216:35
qschulzJaMa: I thought RP backported it til thud? Probably have misunderstood :/16:35
JaMahttps://git.openembedded.org/bitbake/log/?h=1.40 https://git.openembedded.org/bitbake/log/?h=1.4416:35
*** td70 <td70!~td@> has quit IRC (Quit: Client closed)16:35
JaMaonly til dunfell16:35
smurrayit was the github git:// fetcher workaround that got backported further16:36
JaMamaybe you were thinking about git:// protocol changes16:36
RPqschulz: you're thinking of the git protocol changes16:36
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Quit: Leaving)16:36
RPJaMa: snap :)16:36
qschulzdoes a fourth person want to tell me I'm thinking of something else?16:36
qschulzLetoThe2nd: maybe?16:36
qschulzthanks, mixed things up16:37
qschulzhushmoney: sorry, no new syntax before dunfell, got confused16:37
qschulzso definitely is a layer that is not correctly tested for them to claim compatibility with zeus + dunfell + honister16:38
JaMakhem: does this look scary for backport? https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=bb2a7f80a98de3febefbb32b1e4898062bdb6af8 that's the 2nd piece for gcc-11 backport, looks too invasive to fix small corner cases (which I've found only in fork of chromium)16:41
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Ping timeout: 246 seconds)16:52
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)16:54
*** seninha <seninha!~seninha@user/seninha> has joined #yocto16:59
sakomanJaMa: still struggling trying to understand the webkit-gtk reproducibility breakage with the gcc version bump.  The files are so huge it really makes analysis difficult :-(17:14
sakomanthe .so is more than a gigbyte!17:16
*** florian_kc <florian_kc!~florian@dynamic-093-131-164-107.93.131.pool.telefonica.de> has joined #yocto17:23
*** florian_kc <florian_kc!~florian@dynamic-093-131-164-107.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 244 seconds)17:28
JaMasakoman: I was trying to find if there was some fix for webkit-gtk in master (after the upgrade to 11.4) but haven't found any, it's strange that it wouldn't be an issue in master before the upgrade to gcc-12 as well (unless it was an issue, but disappeared before someone tried to tackle it)17:34
*** goliath <goliath!~goliath@user/goliath> has joined #yocto17:34
JaMasakoman:  the 2nd part of the fix I wanted to backport (from gcc-12) is starting to be more and more messy, so no rush to get 11.4 in kirkstone now (at least from me)17:35
sakomanJaMa: yeah, I looked for fixes in master too, and it is quite possible it was there for a bit and disappeared because something else changed17:38
sakomanJaMa: master upgraded to 12.1 a couple of weeks after the 11.3 update, so that may explain why no one put much energy into it17:43
sotaoverridehey fsoverlay pros here, is there a way to prevent deletes from the lowerdir, (for directories / files ovelayed)17:52
sotaoverrideI want write reads to happen normally, but for stuff thats in the lower dir, I want to prevent lowerdir contents from ever getting deleted17:53
JaMasakoman: do you have a handy oneliner to run reproducibility test just for webkit-gtk? I would test it on master with 11.4 just to see if it was reproducible there17:57
sakomanJama: master never had 11.4, just 11.317:59
JaMasakoman: ah sorry I was thinking about 11.3 in all my messages about it18:00
sakomanJaMa: :-)18:00
sakomanJaMa: I haven't tried doing reproducible builds locally, just on the autobuilder.  Let me take a look and see what it is doing there18:02
JaMaok, will try locally18:03
sakomanJaMa: looks like it is doing oe-selftest -r reproducible18:04
sakomanJaMa: I don't think you can limit that script to do just a single package18:06
*** Tokamak <Tokamak!~Tokamak@mobile-166-170-35-2.mycingular.net> has quit IRC (Ping timeout: 244 seconds)18:07
sakomanBut basically it does one build allowing sstate to be used, and then another build with no sstate usage, and compares the outputs of the two builds18:07
sakomanJaMa: if you want to take a crack at examining the two outputs on the autobuilder you can find the results here: https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20220527-zy85edi0/packages/18:09
sakomanreproducibleA is the output w/sstate, reproducibleB is without18:10
sakomannormally the diffoscope output would be in diff-html18:10
*** Tokamak <Tokamak!~Tokamak@mobile-166-170-35-2.mycingular.net> has joined #yocto18:11
sakomanbut diffoscope crashed in this case due to the size of webkit-gtk18:11
sakomanwhat I did was grab the .debs from reproducibleA and reproducibleB, extract the files, and compare them to see what changed.  Everything looked the same except the .so files18:12
JaMaI'm testing locally with cee443ae75f (last commit in master before the upgrade to 12.1)18:13
sakomanOK, good luck!18:14
JaMatargets = ['core-image-minimal', 'core-image-sato', 'core-image-full-cmdline', 'core-image-weston', 'world']18:27
JaMais the default, don't see how to restrict it just to webkit-gtk, but I guess webkit-gtk is the heaviest one in core anyway, so will let it continue to run with defaults18:28
hushmoneyqschulz: thanks, good to know18:34
sakomanJaMa: yeah, I didn't see an easy way to restrict it either. It will take quite a few hours . . .18:38
JaMasakoman: in the meantime please consider https://git.openembedded.org/openembedded-core/commit/?id=c9d36882044b1c633d8611a77df54cd68c9bee25 for kirkstone as well18:40
* JaMa has more build power than energy right now, so longer build time won't be an issue18:41
sakomanJaMa: yes, that patch will be in my next-next set of patches :-)  I usually let them age in master for 2-3 days to see if they cause any issues ;-)18:43
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto18:43
JaMacool, makes sense18:44
sakomanJaMa: I can relate to the build_power/personal energy equation!18:44
*** florian_kc <florian_kc!~florian@dynamic-093-131-164-107.93.131.pool.telefonica.de> has joined #yocto18:45
JaMadidn't take that long to get first failure from ovmf-native which doesn't like gcc-12 on my host :)18:47
derRichardqschulz: i'm digging now into that tmpfs podman issue. my case seems to be a little different. i'm not using an unprivileged podman. so no fuse-overlayfs here.18:47
*** gsalazar <gsalazar!~gsalazar@> has joined #yocto19:02
*** gsalazar <gsalazar!~gsalazar@> has quit IRC (Ping timeout: 256 seconds)19:07
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:edae:74cc:3946:483b> has quit IRC (Remote host closed the connection)19:07
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:c3a5:c748:9558:869a> has joined #yocto19:07
*** seninha <seninha!~seninha@user/seninha> has quit IRC (Quit: Leaving)19:14
*** Tokamak <Tokamak!~Tokamak@mobile-166-170-35-2.mycingular.net> has quit IRC (Ping timeout: 250 seconds)19:38
*** florian_kc is now known as florian19:39
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto19:39
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 246 seconds)19:50
sakomanJaMa: I just ran into an ovmf-native issue on kirkstone too: GenFfs.c:545:5: error: pointer ‘InFileHandle’ used after ‘fclose’ [-Werror=use-after-free]19:52
jaskij[m]derRichard: it's a build issue, right? Does Podman use lxcfs? I've had build failures (most notably in fsck.ext4) because of a bug in lxcfs. Probably unrelated, but I thought to mention it19:53
derRichardjaskij[m]: well, i see sporadic pseudo aborts on a ci pipeline. builds happen in docker, no lxcfs there19:55
jaskij[m]Ah, so most likely unrelated19:55
jaskij[m]Can't help here. Only similar issues I've had was OOM kills19:56
JaMasakoman: there is a fix in master, I've already cherry-picked that and re-run, then it was failing in vulkan-samples19:58
JaMaso I've changed the targets to build just webkit-gtk19:58
JaMasakoman: https://git.openembedded.org/openembedded-core/commit/?id=7b67f19d353d88107f52cceda3c858730ac1db5419:58
JaMasakoman: vulkan-samples failure https://pastebin.com/SaJG9GC719:59
sakomanJaMa: I already grabbed the ovmf-native fix into kirkstone20:00
JaMa"lookup github.com: Temporary failure in name resolution" failed twice with 10 mins between while github.com works for me, so probably something else is going on20:00
sakomanJaMa: sounds like my life :-(20:01
derRichardjaskij[m]: no need to worry. :-)20:02
jaskij[m]JaMa:  Go package? `do_compile[network]=1`20:03
*** florian <florian!~florian@dynamic-093-131-164-107.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds)20:03
jaskij[m](if you're one of the people who helped me with that, sorry, I have trouble remembering who talked with me in chats)20:04
JaMajaskij[m]: this is git lfs in do_unpack20:05
jaskij[m]Iirc Kikrstone blocks networking in any tasks other than do_fetch20:05
JaMathat's correct20:05
jaskij[m]Ah, I'll just shut up :P not taking it hard, just know too little to actively help in here.20:08
JaMait was good advice, just in this cases lfs should work and it's surprising that this issue doesn't happen on autobuilder as well whole log http://errors.yoctoproject.org/Errors/Details/657552/20:13
JaMamaybe it's the combination of gitsm + lfs which isn't so common20:14
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)20:20
*** mvlad <mvlad!~mvlad@2a02:2f08:4802:2100:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)20:58
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto21:16
RPJaMa: there may be an open bug for something like that21:23
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Read error: Connection reset by peer)21:40
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto21:42
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 244 seconds)21:48
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto21:48
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Read error: Connection reset by peer)21:50
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto21:51
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 246 seconds)21:53
*** nemik <nemik!~nemik@> has joined #yocto21:54
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Remote host closed the connection)22:07
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto22:08
zwelch_looks like the downloads.yoctoproject.org certificate expired a couple of hours ago22:09
zwelch_halstead: ^^^ is that your bailiwick?22:10
sakomanzwelch: I sent a note to the help desk about that22:10
sakomanzwelch: yes, it will end up with halstead22:11
halsteadzwelch_: Yes. And thank you sakoman.22:11
halsteadzwelch_: sakoman: I've forced the renewal.22:14
*** dev1990 <dev1990!~dev@77-254-254-204.adsl.inetia.pl> has quit IRC (Quit: Konversation terminated!)22:16
*** seninha <seninha!~seninha@user/seninha> has joined #yocto22:20
sakomanhalstead: thanks for the quick service!22:21
zwelch_halstead: Thanks, that did the trick.  Curious why it didn't autorenew, but happy that it works.22:22
halsteadzwelch_: The renewal cronjob wasn't created correctly during the server install in March when we moved downloads.yp.org to the new data center.22:23
*** florian <florian!~florian@dynamic-093-131-164-107.93.131.pool.telefonica.de> has joined #yocto22:28
halsteadzwelch_: More specifically it was converted to a job handled by periodic instead of cron directly and not enabled.22:29
zwelch_halstead: it's always the little things, eh? :)22:30
halsteadOften the easy fixes are... :)22:31
*** florian <florian!~florian@dynamic-093-131-164-107.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 256 seconds)22:44
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 246 seconds)23:09
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto23:09
*** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 240 seconds)23:13
*** nemik <nemik!~nemik@> has joined #yocto23:14
*** nemik <nemik!~nemik@> has quit IRC (Ping timeout: 276 seconds)23:30
*** nemik <nemik!~nemik@> has joined #yocto23:35

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!