Wednesday, 2023-08-30

*** qschulz <qschulz!> has quit IRC (Read error: Connection reset by peer)00:32
*** qschulz <qschulz!> has joined #yocto00:35
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 246 seconds)01:03
*** davidinux <davidinux!~davidinux@> has joined #yocto01:05
*** Ablu <Ablu!~Ablu@user/Ablu> has quit IRC (Ping timeout: 255 seconds)01:34
*** Ablu <Ablu!~Ablu@user/Ablu> has joined #yocto01:36
*** jclsn <jclsn!~jclsn@2a04:4540:6547:d600:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 260 seconds)02:26
*** jclsn <jclsn!~jclsn@2a04:4540:6534:9f00:2ce:39ff:fecf:efcd> has joined #yocto02:28
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto03:02
*** otavio <otavio!> has quit IRC (Ping timeout: 246 seconds)03:28
*** otavio <otavio!~otavio@2804:d51:5956:ac00:3d40:2f9f:c62:7772> has joined #yocto03:33
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)05:03
*** pabigot <pabigot!> has quit IRC (Ping timeout: 240 seconds)05:05
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto05:17
*** pabigot <pabigot!> has joined #yocto05:21
*** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto05:30
*** Thorn_ <Thorn_!~Thorn@2001:8a0:dfe1:a200:5d42:655f:ec2f:63cb> has quit IRC (Ping timeout: 246 seconds)05:32
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto05:44
*** kpo <kpo!> has quit IRC (Ping timeout: 245 seconds)05:44
*** rob_w <rob_w!> has joined #yocto06:00
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:04
*** kayterina <kayterina!~kayterina@> has joined #yocto06:07
*** Kubu_work <Kubu_work!> has quit IRC (Quit: Leaving.)06:24
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:b604:1d94:e5d:10d0> has quit IRC (Ping timeout: 245 seconds)06:28
*** rfuentess <rfuentess!> has joined #yocto06:34
*** frieder <frieder!> has joined #yocto06:36
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:38
*** _lore_ <_lore_!> has joined #yocto06:39
*** brrm <brrm!> has quit IRC (Ping timeout: 245 seconds)06:40
*** brrm <brrm!> has joined #yocto06:41
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 245 seconds)06:44
*** davidinux <davidinux!~davidinux@> has joined #yocto06:46
*** mckoan|away is now known as mckoan06:49
mckoangood morning06:49
alessioigormorning to you06:54
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto06:57
*** zpfvo <zpfvo!> has joined #yocto07:07
*** kayterina <kayterina!~kayterina@> has quit IRC (Ping timeout: 246 seconds)07:08
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 248 seconds)07:14
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto07:21
*** ptsneves <ptsneves!> has joined #yocto07:24
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 246 seconds)07:28
*** varjag <varjag!~user@> has joined #yocto07:31
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto07:32
*** valdemaras <valdemaras!~valdemara@> has joined #yocto07:44
*** olani- <olani-!> has quit IRC (Ping timeout: 240 seconds)07:46
RPkhem: between fb51e196a978d452e6a14a8343832659da97fdc7 and 90801cd8cb23719031aaaba1578a8446e1824cad now. I'm running more builds 8 possible commits if my tests are right07:48
*** nedko <nedko!~nedko@gateway/tor-sasl/nedko> has quit IRC (Remote host closed the connection)07:48
*** valdemaras <valdemaras!~valdemara@> has quit IRC (Remote host closed the connection)07:49
*** olani- <olani-!> has joined #yocto07:52
*** Kubu_work <Kubu_work!> has joined #yocto07:56
*** Guest39 <Guest39!~Guest39@> has joined #yocto07:57
*** Guest23 <Guest23!~Guest23@> has joined #yocto07:57
*** xmn <xmn!~xmn@2600:4040:9390:8c00:1071:8517:82de:4aaf> has quit IRC (Ping timeout: 248 seconds)07:58
*** florian <florian!> has joined #yocto07:58
*** gsalazar <gsalazar!> has joined #yocto08:08
*** mrnuke_ <mrnuke_!> has quit IRC (Ping timeout: 246 seconds)08:15
*** mbulut <mbulut!~mbulut@> has joined #yocto08:38
*** prabhakarlad <prabhakarlad!> has joined #yocto08:38
*** Guest24 <Guest24!> has joined #yocto08:44
*** Guest24 <Guest24!> has left #yocto08:45
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 245 seconds)08:59
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)08:59
*** Guest39 <Guest39!~Guest39@> has quit IRC (Ping timeout: 246 seconds)09:02
*** mrnuke <mrnuke!> has joined #yocto09:06
*** ptsneves <ptsneves!> has joined #yocto09:06
*** amelius__ <amelius__!~quassel@> has joined #yocto09:07
*** zpfvo <zpfvo!> has joined #yocto09:13
*** amelius__ <amelius__!~quassel@> has quit IRC (Quit: - Chat comfortably. Anywhere.)09:17
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 245 seconds)09:20
*** zpfvo <zpfvo!> has joined #yocto09:21
__adhi, any sample on how to use different kernel defconfig based on machine ?09:23
*** dmoseley <dmoseley!> has quit IRC (Ping timeout: 260 seconds)09:32
RPlooking like 12d9280c3de24c1c2b835e80fa1b8be72e9bc63a or earlier which is getting a bit strange09:32
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)09:33
*** alessioigor <alessioigor!~alessioig@> has joined #yocto09:33
*** Guest39 <Guest39!~Guest39@> has joined #yocto09:40
Guest39Hello, Can you please help me in resolving yocto build error while building AGL software. It happens during rootfs packaging time with one of the AGL supported image. agl-linux/agl-demo-platform/1.0-r0/rootfs --gid 989 --system systemd-journal]09:42
Guest39configuration error - unknown item 'SYSLOG_SU_ENAB' (notify administrator)09:42
Guest39configuration error - unknown item 'SYSLOG_SG_ENAB' (notify administrator)09:42
Guest39performing groupadd with [--root /home/yocto/yocto/build-domd/tmp/work/board-agl-linux/agl-demo-platform/1.0-r0/rootfs --gid 989 --system systemd-journal]09:43
Guest39configuration error - unknown item 'SYSLOG_SU_ENAB' (notify administrator)09:43
Guest39configuration error - unknown item 'SYSLOG_SG_ENAB' (notify administrator)09:43
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto09:51
JaMaGuest39: does it fail the same all the time? I'm seeing this randomly in some builds (not AGL) and haven't found what triggers it, so if you have reliable reproducer then I would be interested to see what was causing it09:57
khemRP: libarchive is used by rpm cmake and elfutils so it could also be in picture10:07
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)10:08
RPkhem: seems to be prior to that10:13
LetoThe2ndyo dudX10:18
*** kayterina <kayterina!~kayterina@> has joined #yocto10:27
*** river <river!> has joined #yocto10:27
riverwhen you build a cross compiler toolchain are the files in a sysroot used by the host or the target?10:28
rburtonwell, yocto has host and target sysroots10:29
rburtonbut typically, target10:29
riveri see. thank you10:31
RPrburton: the qemu upgrade breaks x86 and
RPrburton: at least it seems roughly reproducible10:32
rburtonare the TCG warnings new?10:33
RPrburton: not sure10:34
rburtonthey feel new10:34
RPI was wondering. I've struggled just to narrow it down to this so far10:34
RPthis is the second build I've seen this pattern in10:34
rburtonand it says x2apic which was introduced in 200810:34
RPrburton: trouble is on a successful build they're probably just hidden10:35
rburtonor maybe qemu is being a bit more precise10:35
RPI did wonder if it was worker specific but looking at the failing hosts, no pattern jumps out10:36
*** Guest39 <Guest39!~Guest39@> has quit IRC (Ping timeout: 246 seconds)10:56
*** varjag <varjag!~user@> has quit IRC (Quit: ERC (IRC client for Emacs 27.1))11:02
*** varjag <varjag!~user@> has joined #yocto11:03
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto11:07
*** kayterina <kayterina!~kayterina@> has quit IRC (Quit: Client closed)11:13
*** Marian67 <Marian67!> has joined #yocto11:29
Marian67Hi, I'm building a wic image that I dd on /dev/sda  + parted -s $DESTINATION_DEV "resizepart 3 -1" the last partition up to disk size. I'm trying to integrate resize2fs to extend /dev/root up to the partition size. Is exactly the problem described here:11:34
rburtonMarian67: if you use systemd then it can auto-expand on first boot11:36
Marian67yes, I'm using systemd, how can auto-expand on first boot??11:42
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)11:44
*** alessioigor <alessioigor!~alessioig@> has joined #yocto11:44
rburtongoogle is your friend
Marian67I will look also on this, but my installer is running from initramfs and is dd the wic, parted resize and I want also to resize2fs, do you have any input on this?11:46
rburtonsure you could do that from your installer11:48
rburtonas you say, resize the partition then grow the file system11:49
rburtonRP: old qemu doesn't produce those warnings11:49
Marian67dd if=$INSTALLER_FILE of=$DESTINATION_DEV bs=1M status=progress && sgdisk $DESTINATION_DEV -e && parted -s $DESTINATION_DEV "resizepart 3 -1"11:51
Marian67this is what I'm doing11:51
*** Guest23 <Guest23!~Guest23@> has quit IRC (Quit: Client closed)11:51
Marian67    DESTINATION_DEV="/dev/sda"11:51
Marian67    INSTALLER_FILE=$(ls /boot/*wic)11:51
rburtonyou haven't actually asked a question or explained a problem yet11:52
rburtonyou'll missing a filesystem resize call there of course11:52
RPrburton: hmm, so what changed? :/11:54
Marian67yes, I'm missing resize2fs /dev/sda311:54
RPrburton: I was just getting to a position to try and debug it...11:54
rburtonRP: just building qemu 8.1 now to verify.  i suspect our qemu flags are not quite right and new qemu is being pedantic.11:55
RPkhem: qemuppc issue seems to be coming down to - the uninative upgrade11:56
Marian67I'm trying to get resize2fs exactly how it's described here and is not working
RPrburton: why only those two tests though?11:56
rburtongod knows11:56
Marian67IMAGE_iNSTALL:append " e2fsprogs e2fsprogs-resize2fs"11:56
*** dmoseley <dmoseley!> has joined #yocto12:05
rburtongood news is that i can replicate the tcg thing trivially12:09
*** dmoseley <dmoseley!> has quit IRC (Ping timeout: 240 seconds)12:11
RPrburton: I just confirmed the warnings aren't there previously12:14
*** Piraty <Piraty!~irc@user/piraty> has quit IRC (Quit: -)12:15
RPrburton: well, it doesn't show them in the log but it doesn't hang on boot and dump stdout so we can't be sure :(12:17
rburtonrunqemu nographic here has a working boot with master and tcg aborts with 8.112:17
*** Piraty <Piraty!~irc@user/piraty> has joined #yocto12:18
RPrburton: interesting. I wonder why everything else worked :/12:18
rburtoni'll dig12:19
RPI guess this means I can't avoid qemuppc12:20
rburtonthat's basically my plan yes12:20
RPrburton: damnit ;-)12:20
rburtonRP: 'qemu has always emitted those warnings, we suggest you bisect'12:25
RPrburton: that was my worry12:25
RPI think runqemu is only dumping stdout upon failure12:27
*** pidge <pidge!~pidge@> has joined #yocto12:28
RPrburton: it only fails if kvm isn't on the commandline12:32
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 246 seconds)12:36
*** zpfvo <zpfvo!> has joined #yocto12:36
*** Kubu_work <Kubu_work!> has quit IRC (Read error: Connection reset by peer)12:38
*** Kubu_work1 <Kubu_work1!> has joined #yocto12:38
*** vladest <vladest!~Thunderbi@2a02:1210:760b:9500:34b2:ae8a:1730:8158> has quit IRC (Ping timeout: 245 seconds)12:39
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto12:45
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto12:47
*** amitk <amitk!~amit@> has joined #yocto12:54
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 246 seconds)13:05
RPrburton: and without nographic it gets really funky :/13:07
rburtonstop looking at the qemu one13:11
RPrburton: I was mainly curious to see if reverting uninative helped which it doesn't (since that was implicted for qemuppc)13:17
*** zpfvo <zpfvo!> has quit IRC (Ping timeout: 245 seconds)13:21
*** zpfvo <zpfvo!> has joined #yocto13:25
RPrburton: there is something in common here in that non-kvm timing seems messed up :/13:26
rburtonthe x86 one is qemu segfaulting13:28
AbluIs there some support for meson wrap files ( available? QEMU seems to have replaced submodules with it.13:34
*** varjag <varjag!~user@> has quit IRC (Quit: ERC (IRC client for Emacs 27.1))13:41
*** Kubu_work1 <Kubu_work1!> has quit IRC (Ping timeout: 260 seconds)13:48
*** Xagen <Xagen!> has joined #yocto13:50
*** dmoseley <dmoseley!> has joined #yocto14:01
rburtonAblu: there's a qemu 8.1 recipe already on the list, but we generally dislike wrap because it means fetching outside of do_fetch14:05
*** rob_w <rob_w!> has quit IRC (Quit: Leaving)14:05
rburtonwraps are typically a fallback for when libraries are not present: the yocto way has you writing recipes14:05
*** mvlad <mvlad!~mvlad@2a02:2f08:4c00:5d00:7656:3cff:fe3f:7ce9> has joined #yocto14:05
*** dmoseley <dmoseley!> has quit IRC (Ping timeout: 245 seconds)14:06
JaMainteresting if I use SKIP_RECIPE[efivar] = "foo" in local.conf, then it blacklists lib32-efivar as well, but if I add this to DISTRO config then I have to blacklist lib32-efivar as well as efivar, strange14:07
*** xmn <xmn!> has joined #yocto14:11
Ablurburton: Sure, I understand that something may sneak in that should it it's own recipe. But for the downloading, couldn't the download just be done as part of do_fetch (similary how rust crates are loaded)?14:14
rburtonnot trivially, but sure if you want to do that, you can work on it14:15
rburtonRP: got a fix for qemu14:15
rburtonmight be worth trying with the ppc thing as it talks about a race...14:16
*** amitk <amitk!~amit@> has joined #yocto14:17
rburtonRP: see ross/tcg14:17
AbluACK. Sure. Thanks for the pointer to the update.14:17
RPrburton: talks about RCUs in common code too which makes me wonder. I'll try and queue a test14:20
rburtontwo birds with one stone would be good14:20
RPrburton: They felt somehow connected...14:21
marexhey, if things like do_rootfs or do_populate_sdk take too long, is there any way to help those out ? Like build in tmpfs maybe ?14:22
rburtonmarex: sdk generation takes ages as it has to compress a huge filesystem14:22
rburtonfwiw i have SDK_XZ_COMPRESSION_LEVEL = "-5" in my local.conf to speed that up14:22
marexrburton: yep14:23
marexI use --fast14:23
rburtonrootfs is just constructing the rootfs, so arguably not using rpm/dnf might make it noticably faster.  worth a test :)14:24
marexrburton: would tmpfs have any impact ? I suspect it might14:24
marex(I'm just testing that)14:24
RPI have wondered if we should try a non-pkgmanager rootfs build...14:24
marexrburton: it should at least avoid the sync() which I assume happens14:25
RPrburton: test running14:25
RPmarex: pseudo intercepts and drops sync calls ;-)14:25
*** Xagen <Xagen!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)14:25
marexoh :)14:26
marexI didnt know that14:26
*** Kubu_work <Kubu_work!> has joined #yocto14:26
*** Xagen <Xagen!> has joined #yocto14:27
*** sakoman1 <sakoman1!> has joined #yocto14:29
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 255 seconds)14:33
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)14:33
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)14:36
*** dmoseley <dmoseley!> has joined #yocto14:45
*** dmoseley <dmoseley!> has quit IRC (Ping timeout: 246 seconds)14:49
khemRP: maybe build uninative glibc without --enable-fortify-source14:50
khemI doubt it though will be helpful14:50
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)14:54
*** alessioigor <alessioigor!~alessioig@> has joined #yocto14:54
RPkhem: we're going to try the tcg fix ross pointed at14:57
*** Haxxa <Haxxa!> has quit IRC (Remote host closed the connection)15:05
*** Haxxa <Haxxa!> has joined #yocto15:06
*** prabhakarlad <prabhakarlad!> has joined #yocto15:11
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)15:19
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)15:35
*** rfuentess <rfuentess!> has quit IRC (Remote host closed the connection)15:46
*** mckoan is now known as mckoan|away15:50
*** Kubu_work <Kubu_work!> has quit IRC (Quit: Leaving.)15:58
*** frieder <frieder!> has quit IRC (Remote host closed the connection)16:06
*** dmoseley <dmoseley!> has joined #yocto16:14
*** zpfvo <zpfvo!> has quit IRC (Remote host closed the connection)16:23
*** manuel1985 <manuel1985!~manuel198@> has quit IRC (Remote host closed the connection)16:38
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto16:38
RPJPEW: link is live and working :)16:47
*** manuel1985 <manuel1985!~manuel198@> has quit IRC (Ping timeout: 250 seconds)16:48
*** kayterina <kayterina!~kayterina@> has joined #yocto16:49
*** ptsneves <ptsneves!> has quit IRC (Ping timeout: 245 seconds)16:49
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)16:56
*** gsalazar <gsalazar!> has quit IRC (Ping timeout: 255 seconds)17:07
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 250 seconds)17:15
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto17:17
*** Kubu_work <Kubu_work!> has joined #yocto17:18
yates_worki'm having trouble with SRC_URI configuration: i have some files in the standard files/ folder, but i also want to specify all files in a file/images/ folder. how to do?17:21
yates_worksorry, meant files/images subfolder17:22
yates_workdo i have to specify them one-by-one? e.g., file://images/a.png? there are a bunch and i was hoping to just be able to specify the subfolder, but file://images/ didn't work17:23
yates_workit does work. i had a missing space in the previous continuation line. bleh!17:24
*** kpo <kpo!> has joined #yocto17:43
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 246 seconds)17:46
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto17:49
*** Xagen <Xagen!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)17:58
*** Thorn_ <Thorn_!> has joined #yocto18:00
*** Xagen <Xagen!> has joined #yocto18:02
LetoThe2ndok slackers, thats it - i'm finally out for some time, see you all in about 2 weeks.🤘🏽18:02
*** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 244 seconds)18:02
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 246 seconds)18:04
*** kayterina <kayterina!~kayterina@> has quit IRC (Ping timeout: 246 seconds)18:07
*** sudip <sudip!~sudipmukh@> has quit IRC (Quit: ZNC -
*** sudip <sudip!~sudipmukh@> has joined #yocto18:21
*** mbulut <mbulut!~mbulut@> has quit IRC (Ping timeout: 246 seconds)18:26
*** Wenqing <Wenqing!~wenqingzo@> has quit IRC (Remote host closed the connection)18:27
*** Wenqing <Wenqing!~wenqingzo@> has joined #yocto18:30
*** old_boy <old_boy!~old_boy@> has joined #yocto18:44
*** dmoseley <dmoseley!> has quit IRC (Quit: ZNC 1.8.2 -
RPrburton: didn't fix qemuppc and seems to break qemumips/qemumips64: :(18:50
RPkhem: didn't help qemuppc so we still need to track that down18:51
*** dmoseley <dmoseley!> has joined #yocto18:56
RPLetoThe2nd: enjoy :)18:59
*** flom84 <flom84!~flom84@user/flom84> has joined #yocto19:08
RPJPEW: around and have a minute to sanity check something?19:19
RPJPEW: I've logs showing a bitbake client/server timeout and I'm trying to work out what can be going wrong19:20
rburtonRP: damnit!19:21
RPJPEW: the client has sent the "ping" command to the server. After two minutes, the server is tracebacking in  self.command_channel_reply.send() for the ping reply BrokenPipeError: [Errno 32] Broken pipe19:21
RPJPEW: that means the UI probably gave up waiting for the ping reply after 30s19:21
RPer. 60s19:21
*** flom84 <flom84!~flom84@user/flom84> has quit IRC (Quit: Leaving)19:21
JPEWYa makes sense19:21
RPJPEW: what I'm puzzled about is why the UI couldn't have read anything and got the reply19:21
*** flom84 <flom84!~flom84@user/flom84> has joined #yocto19:22
RPJPEW: I was going to say, the UI as I understand it has a separate python thread queuing the events it receives until it can process them. Of course this reply isn't an event, its a reply on the "command" channel :/19:23
RPcan we somehow deadlock the command channel pipe?19:24
*** flom84 <flom84!~flom84@user/flom84> has quit IRC (Read error: Connection reset by peer)19:25
JPEWRP: It should be full duplex19:26
RPWe do have three pipes in play and two of them could in theory deadlock?19:26
*** Xagen <Xagen!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)19:26
JPEWYa maybe19:26
RPconnectProcessServer() in process.py19:26
JPEWIf it's all blocking writes, then yes19:27
JPEW(if the pipes are full)19:27
*** amitk <amitk!~amit@> has joined #yocto19:27
JPEWYou may be relying on the good graces of the pipe's buffer19:28
RPJPEW: I don't know how the pipes could be full :/19:28
JPEWIn my experience, using more threads is never as good as robust non-blocking sockets19:31
*** vladest <vladest!> has joined #yocto19:31
JPEWor non-blocking pipes19:32
RPour event code and the thread it uses is fine. I think these are nonblocking pipes19:32
JPEWThey are created blocking, I haven't found where they are set to non-blocking (yet?) and send_bytes() bascially means blocking19:33
RPJPEW: I think I'm confusing with the runqueue ones19:37
RPso yes, these are blocking19:38
RPbut we're sending something and waiting for a reply, which should work?19:38
*** belgianguy <belgianguy!> has joined #yocto19:40
*** flom84 <flom84!~flom84@user/flom84> has joined #yocto19:40
belgianguyDoes anyone have good suggestion on Embedded Linux books they read themselves? For someone who has quite some Linux experience, just not much of Embedded... :$19:41
belgianguy(Or courses, sites, ...)19:41
RPJPEW: I'm trying to debug this with Crofton, is what I have so far. Would any other logging be helpful?19:41
JPEWRP: Ya, I was going to suggest reporting the time spent blocking on pipes19:42
JPEWThe timestamps19:42
JPEWIf the server is waiting for ~30 seconds before dying with EPIPE, it almost surely a deadlock19:43
*** alessioigor <alessioigor!~alessioig@> has joined #yocto19:43
*** Xagen <Xagen!> has joined #yocto19:47
CroftonI switched bitbake to master-next19:48
*** Xagen <Xagen!> has quit IRC (Client Quit)19:48
*** flom84 <flom84!~flom84@user/flom84> has quit IRC (Ping timeout: 245 seconds)19:54
RPJPEW: I'm struggling to know what else this might be :/19:55
JPEWDeadlock seems likely to be TBH19:55
JPEWIt might be a very complicated deadlock with a lot of threads all circularly locked on each other.... but deadlock all the same19:56
RPJPEW: that is my worry. I was going to ask you to sanity check the threading on the event pipe but I don't think that is where any issue is now I've talked it out loud19:57
Croftondo you mind if I over write filenames in dropbox?19:57
*** Xagen <Xagen!> has joined #yocto19:57
Croftonwhen it comes time19:57
RPCrofton: no19:58
RPrburton: too good to be true really19:58
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 248 seconds)20:02
*** Xagen <Xagen!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)20:04
JPEWRP: I'm having trouble finding where the UI even sends events20:12
JPEWI have the sneaking suspiciion that a some of the "Server" classes run on the actual server side, and some are proxies for the server on the client side20:13
RPJPEW: the UI doesn't, the server sends events to the UI20:13
JPEWSorry commands20:13
RPServerCommunicator.runCommand in process.py20:13
*** Haxxa <Haxxa!> has quit IRC (Quit: Haxxa flies away.)20:15
*** Xagen <Xagen!> has joined #yocto20:15
RPWe really need to merge BitBakeProcessServerConnection, ServerCommunicator and BBUIEventQueue. They used to do a lot of different things but the separation is probably obsolete now20:16
RPcertainly BitBakeProcessServerConnection and ServerCommunicator20:17
*** Haxxa <Haxxa!> has joined #yocto20:18
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)20:21
*** Wouter0100670440 <Wouter0100670440!> has quit IRC (Quit: The Lounge -
*** Wouter0100670440 <Wouter0100670440!> has joined #yocto20:22
*** alessioigor <alessioigor!~alessioig@> has joined #yocto20:22
*** starblue <starblue!> has quit IRC (Quit: WeeChat 3.8)20:23
JaMaFWIW: I'm seeing this timeout as well, I've increased the timeout to 60s/120s and it seems to be triggered as often as when it was 30s/60s, so when it gets stuck, then it's for real, interstingly when I've tried even longer timeout 300s/600s, then it was usually jenkins job getting timeout (as instead of Timeout message from bitbake I get java exception from jenkins:20:26
JaMa+  # NOTE: recipe g-camera-pipeline-1.0.0-gav.40-r14: task do_populate_sysroot: Succeeded20:26
JaMa+  # FATAL: command execution failed20:26
JaMa+  # Socket closed20:26
JaMa+  # java.base/ Method)20:26
JaMa+  # Caused: hudson.remoting.ChannelClosedException: Channel "hudson.remoting.Channel@6acbac8c:c04a-009wgnozd2kyr": Remote call on c04a-009wgnozd2kyr failed. The channel is closing down or has closed down20:26
JaMaand it's more likely to happen on overloaded systems it seems20:27
JPEWCrofton: No "Sending reply" messages?20:28
*** florian_kc <florian_kc!> has joined #yocto20:28
JPEWOr maybe they are in the bitbake server log file20:28
Croftongiv eme a bit, machine machine being stupid20:28
Croftonand need to pack some stuff20:28
JaMainterestingly it happens shortly after "2586 12:57:11.483486 Parse cache invalidated"20:31
JaMaat least in my case above, not sure about Crofton's20:32
Croftonthere you go and afk until Happy hour20:32
RP538490 16:22:34.007760 Running command ['ping'] 538490 16:24:04.273232 Sending reply ('Still alive!', None)20:32
RPwhy on earth did that take two minutes?!20:33
RPthat shows it isn't the pipes anyway20:33
RPlooking at runCommand in, I can see what it might be doing :/20:35
RPI think we special case ping20:35
JPEWRP: stuck in process_inotify_updates_apply()?20:39
JPEWThat's the only place I can see where it might block20:39
RPJPEW:  self.cooker.updateCacheSync and self.cooker.init_configdata might hit IO and block20:41
RPCrofton: new patch in -next for you
Croftongit pull --force?20:41
JPEWAh right20:41
Croftonlol no  force20:42
* JaMa steals it as well20:42
RPJPEW: inotify is the most likely but I'm covering all options :)20:42
RPvmeson: you might like this one ;-)20:43
Croftonyou are so lucky I just didn't update the machine .....20:43
RPCrofton: yes, having someone reproducing this at will is helpful!20:43
JPEWCrofton: Spinny hard drive?20:44
JPEWYa, that makes sense20:44
Croftonnoisy as fuck20:44
RPso old fashioned :)20:44
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 255 seconds)20:44
Croftonthe old ways are the best20:44
Croftondoes the auto builder need some spinny hard drives?20:45
* vmeson reads20:45
Croftonfor better test coverage20:45
JPEWCrofton: Probably better to use cgroups to limit the I/O for a particular test run..... leaves the rest of the capacity for other tests running at the same time20:46
RPvmeson: a patch which might fix your ping timeouts20:47
Croftonlol the machine I do interactive master buids on has nvme20:48
RPJPEW: thanks for giving me someone to talk to, I really did think this was going to be a pipe/thread issue20:48
JPEWIt did quack like that duck20:49
RPJaMa: since you see cache invalidation which is almost certainly from inotify processing, it should help your case20:50
vmesonRP: Nice and just in time for happy hour!20:58
* vmeson pours a glass20:59
* JaMa gets beer as well20:59
*** alessioigor <alessioigor!~alessioig@> has quit IRC (Quit: alessioigor)20:59
CroftonHappy hour, sgw is pouring beer21:00
sgwYup, Homebrew Smoked Porter21:00
JaMaeven with builds on NVME I get some IO pressure :) NOTE: Pressure status changed to CPU: True, IO: None, Mem: None (CPU: 721545.8/200000.0, IO: 11467.0/None, Mem: 1076.6/None)21:02
*** mvlad <mvlad!~mvlad@2a02:2f08:4c00:5d00:7656:3cff:fe3f:7ce9> has quit IRC (Remote host closed the connection)21:09
*** florian_kc <florian_kc!> has joined #yocto21:10
* RP sent the patch to the bitbake list 21:35
*** Xagen <Xagen!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)22:07
*** Kubu_work <Kubu_work!> has quit IRC (Quit: Leaving.)22:11
*** Guest61 <Guest61!> has joined #yocto22:21
*** Guest61 <Guest61!> has quit IRC (Quit: Client closed)22:28
yates_worki have found that using file:// SRC_URI causes the source code to be placed in ${WORKDIR}, whereas the OpenEmbedded build system defaults to ${WORKDIR}/${BPN}-${PV}. thus to use file:// SRC_URIs I must set S in my recipe.22:30
yates_workwhy doesn't the fetcher put file:// files in ${WORKDIR}/${BPN}-${PV}?22:30
yates_workthen it would Just Work(TM)22:33
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)22:38
JaMayates_work: do_unpack unpacks the tarball in ${WORKDIR}, ${BP} is just the typical default for S22:45
JaMayates_work: so file:// works consistently with it22:45
yates_workwhen using a tarball for SRC_URI, what is responsible for moving the files from ${WORKDIR} to ${WORKDIR}/${BPN}-${PV} after do_unpack?23:01
yates_workoh wait,you're saying you have to do that same "S" definition in the recipe when using tarballs?23:02
yates_worki sorta get you, but why not design these oe components such that a redefinition of S is never needed? that would make yocto easier to use, as far as i can tell23:03
yates_workperhaps it's historical.23:03
JaMathere was discussion about that on ML, because there are still some issues with recipes where S = "${WORKDIR}", so instead of unpacking archives in ${WORKDIR} it would unpack them in ${WORKDIR}/source or some directory like that and optionally strip first directory23:39
JaMa"what is responsible for moving the files from ${WORKDIR} to ${WORKDIR}/${BPN}-${PV}" nothing is moving anything, they are _UNPACKED_ in ${WORKDIR}23:40
JaMaif the tarball contains directory "foo", then you need to set S = "${WORKDIR}/foo" to run the tasks inside this directory23:40
JaMaquite common convention is that tarballs do have top level directory which happens to be called ${BPN}-${PV} == ${BP}, so that is the default ${S} value in OE23:41
JaMabut e.g. for git fetcher you always need to change it to ${WORKDIR}/git23:41
JaMaand with file:// which aren't archives there isn't anything to unpack, so they are added to ${WORKDIR} as they are23:42
*** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Quit: Bye)23:49
DvorkinDmitryI need additional file to install with kernel module into /etc/modules-load.d/ (to load it faster). How to do it correctly in Mickledore? kernel module recipe doesn't accept additional FILES +=23:54

Generated by 2.17.2 by Marius Gedminas - find it at!