| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 00:17 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Client Quit) | 00:20 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 246 seconds) | 00:23 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 00:23 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 246 seconds) | 00:34 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 00:40 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 00:50 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 246 seconds) | 01:01 | |
| *** BCMM <BCMM!~BCMM@user/bcmm> has quit IRC (Quit: Konversation terminated!) | 01:06 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:07 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!) | 01:08 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 260 seconds) | 01:12 | |
| *** bonalais <bonalais!uid502939@id-502939.tinside.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 01:13 | |
| *** otavio <otavio!~otavio@201-3-135-79.user3p.brasiltelecom.net.br> has quit IRC (Remote host closed the connection) | 01:14 | |
| tlwoerner | RP: good! an go ahead and remove recipes-core/initscripts/initscripts-1.0/GPLv2.patch and recipes-kernel/modutils-initscripts/files/PD.patch too ;-) | 01:16 |
|---|---|---|
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:17 | |
| *** otavio <otavio!~otavio@201-3-135-79.user3p.brasiltelecom.net.br> has joined #yocto | 01:17 | |
| *** lowfi <lowfi!~lowfi@user/lowfi> has joined #yocto | 01:19 | |
| *** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Read error: Connection reset by peer) | 01:24 | |
| *** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto | 01:24 | |
| *** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has quit IRC (Quit: reboot) | 01:26 | |
| *** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has joined #yocto | 01:27 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 260 seconds) | 01:28 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:33 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds) | 01:40 | |
| *** geoff_ <geoff_!~geoff@207.154.79.70> has quit IRC (Ping timeout: 246 seconds) | 01:42 | |
| *** jsbronder <jsbronder!jsbronder@user/jbronder> has quit IRC (Quit: WeeChat 3.3) | 01:45 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:45 | |
| *** camus <camus!~Instantbi@183.192.143.37> has joined #yocto | 01:46 | |
| *** jsbronder <jsbronder!jsbronder@user/jbronder> has joined #yocto | 01:55 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 01:55 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:01 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 02:04 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds) | 02:06 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:11 | |
| *** jclsn1007 <jclsn1007!~jclsn@46.59.216.93.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 246 seconds) | 02:19 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 02:22 | |
| *** jclsn1007 <jclsn1007!~jclsn@213.21.33.208.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:27 | |
| *** jclsn1007 <jclsn1007!~jclsn@213.21.33.208.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 02:34 | |
| *** jclsn1007 <jclsn1007!~jclsn@213.21.33.208.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:40 | |
| *** jclsn1007 <jclsn1007!~jclsn@213.21.33.208.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 246 seconds) | 02:57 | |
| *** jclsn1007 <jclsn1007!~jclsn@213.21.33.208.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:03 | |
| *** bonalais <bonalais!uid502939@id-502939.tinside.irccloud.com> has joined #yocto | 03:49 | |
| *** lowfi <lowfi!~lowfi@user/lowfi> has quit IRC (Quit: Leaving) | 03:51 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 04:27 | |
| *** lowfi <lowfi!~lowfi@user/lowfi> has joined #yocto | 04:36 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 256 seconds) | 05:16 | |
| *** amitk <amitk!~amit@103.208.69.6> has joined #yocto | 05:33 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 05:50 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 05:51 | |
| *** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto | 05:52 | |
| *** Circuitsoft <Circuitsoft!uid393878@id-393878.lymington.irccloud.com> has joined #yocto | 06:03 | |
| *** lowfi <lowfi!~lowfi@user/lowfi> has quit IRC (Quit: Leaving) | 06:08 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 06:51 | |
| *** mckoan|away is now known as mckoan | 06:52 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 06:57 | |
| *** bonalais <bonalais!uid502939@id-502939.tinside.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 06:58 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto | 07:02 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 07:07 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Read error: Connection reset by peer) | 07:11 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 07:12 | |
| *** selff <selff!~selff@46.221.0.162> has joined #yocto | 07:18 | |
| selff | hello everyone, have a nice day. i asked a question about ap and wpa yesterday, but i couldnt find an answer. im sharing it again today, maybe someone can help. | 07:26 |
| selff | i want to use both wpa and ap in my image. when i run hostapd service in runtime, it switches to AP mode without any problems and read the "hostapd.network" settings. when i want switch to wpa, i follow these steps: | 07:26 |
| selff | enable "wpa_supplicant@wlan0" and disable "hostapd", reboot. when i run the "wpa_supplicant@wlan0" service, it does not switch to wpa mode. | 07:26 |
| selff | even though hostapd is closed, wpa uses the "hostapd.network" file which is contain ap ip etc. idk why but wpa is reading "hostapd.network" instead of "wlan.network". | 07:26 |
| selff | in short wpa_supplicant@wlan0 service reads hostapd.network instead of wlan.network. | 07:27 |
| *** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has joined #yocto | 07:31 | |
| *** dacav <dacav!~dacav@h94-245-9-200.cust.a3fiber.se> has quit IRC (Ping timeout: 256 seconds) | 07:41 | |
| *** camus <camus!~Instantbi@183.192.143.37> has quit IRC (Read error: Connection reset by peer) | 07:41 | |
| *** camus <camus!~Instantbi@2409:8a1e:9115:e190:5138:5b88:8215:a434> has joined #yocto | 07:42 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 07:47 | |
| *** GillesM <GillesM!~gilles@105.61.128.77.rev.sfr.net> has joined #yocto | 07:49 | |
| *** selff <selff!~selff@46.221.0.162> has quit IRC (Ping timeout: 250 seconds) | 07:50 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 07:52 | |
| LetoThe2nd | yo dudX | 07:55 |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Ping timeout: 246 seconds) | 07:57 | |
| *** selff <selff!~selff@46.221.0.162> has joined #yocto | 08:05 | |
| qschulz | o/ | 08:10 |
| rburton | sielicki: it got renamed https://git.yoctoproject.org/poky/tree/meta/classes/python_pep517.bbclass. you only need to use it if youre writing support for a new build system, otherwise use the setuptools/flit/poetry classes | 08:13 |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto | 08:19 | |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Ping timeout: 252 seconds) | 08:25 | |
| selff | does anyone have any idea about my problem with ap and wpa? :'( | 08:32 |
| rburton | obviously not. try talking to the wpa/hostap maintainers? | 08:33 |
| selff | I dont even know where to contact. need to some research, thank you. | 08:37 |
| rburton | http://lists.infradead.org/mailman/listinfo/hostap | 08:37 |
| selff | rburton again an again ty | 08:40 |
| LetoThe2nd | need to decide on the correct permutation of these: "work on u-boot for an iMX7 board", "drink", "curse each and everything". suggestions? | 08:46 |
| *** janvermaete[m] <janvermaete[m]!~vermaetem@2001:470:69fc:105::ee7> has quit IRC (Quit: You have been kicked for being idle) | 09:00 | |
| *** gsalazar_ <gsalazar_!~gsalazar@132.120.90.149.rev.vodafone.pt> has joined #yocto | 09:03 | |
| *** gsalazar_ <gsalazar_!~gsalazar@132.120.90.149.rev.vodafone.pt> has quit IRC (Remote host closed the connection) | 09:03 | |
| *** gsalazar <gsalazar!~gsalazar@194.38.148.130> has quit IRC (Ping timeout: 272 seconds) | 09:06 | |
| *** tomzy <tomzy!~tomzy@84-10-27-202.static.chello.pl> has joined #yocto | 09:37 | |
| *** tomzy <tomzy!~tomzy@84-10-27-202.static.chello.pl> has quit IRC (Client Quit) | 09:37 | |
| *** tomzy72 <tomzy72!~tomzy@84-10-27-202.static.chello.pl> has joined #yocto | 09:37 | |
| *** tomzy72 <tomzy72!~tomzy@84-10-27-202.static.chello.pl> has quit IRC (Client Quit) | 09:38 | |
| *** tomzy <tomzy!~tomzy@84-10-27-202.static.chello.pl> has joined #yocto | 09:38 | |
| *** tomzy <tomzy!~tomzy@84-10-27-202.static.chello.pl> has quit IRC (Client Quit) | 09:40 | |
| *** mojuser <mojuser!~mojuser@84-10-27-202.static.chello.pl> has joined #yocto | 09:45 | |
| *** bonalais <bonalais!uid502939@id-502939.tinside.irccloud.com> has joined #yocto | 09:50 | |
| *** ardo <ardo!~ardo@host-188-10-58-99.business.telecomitalia.it> has quit IRC (Read error: Connection reset by peer) | 09:54 | |
| *** ardo <ardo!~ardo@host-188-10-58-99.business.telecomitalia.it> has joined #yocto | 09:54 | |
| *** arturkow <arturkow!~arturkow@84-10-27-202.static.chello.pl> has joined #yocto | 09:56 | |
| *** arturkow <arturkow!~arturkow@84-10-27-202.static.chello.pl> has quit IRC (Client Quit) | 09:58 | |
| *** ardo <ardo!~ardo@host-188-10-58-99.business.telecomitalia.it> has quit IRC (Read error: Connection reset by peer) | 09:59 | |
| *** bonalais <bonalais!uid502939@id-502939.tinside.irccloud.com> has quit IRC () | 10:02 | |
| *** bonalais <bonalais!uid502939@id-502939.tinside.irccloud.com> has joined #yocto | 10:03 | |
| *** ardo <ardo!~ardo@host-188-10-58-99.business.telecomitalia.it> has joined #yocto | 10:03 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 10:10 | |
| LetoThe2nd | what flag does wic need in order to create an empty FS? | 10:24 |
| LetoThe2nd | something like --fixed-size 50M --fstype=ext4 ? | 10:27 |
| *** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto | 10:36 | |
| *** selff <selff!~selff@46.221.0.162> has quit IRC (Quit: Client closed) | 10:50 | |
| *** amitk <amitk!~amit@103.208.69.6> has quit IRC (Ping timeout: 260 seconds) | 10:56 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Ping timeout: 250 seconds) | 11:02 | |
| *** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC (Ping timeout: 260 seconds) | 11:08 | |
| *** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto | 11:09 | |
| LetoThe2nd | have you ever seen a situation where u-boot , specifically u-boot-fslc happily builds, no errors, no nothing, but no artifacts are generated in the Yocto build? Manually building outside works nicely | 11:10 |
| *** amitk <amitk!~amit@103.208.71.41> has joined #yocto | 11:13 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 11:14 | |
| qschulz | LetoThe2nd: wdym by "no artifacts are generated"? | 11:21 |
| qschulz | nothing in the deploy directory or nothing in the build directory? | 11:21 |
| LetoThe2nd | qschulz: the former, primarily. still investigating. | 11:25 |
| qschulz | LetoThe2nd: are you sure there's a do_deploy task? | 11:25 |
| qschulz | is the deploy task called? | 11:25 |
| *** arturkow <arturkow!~arturkow@84-10-27-202.static.chello.pl> has joined #yocto | 11:26 | |
| LetoThe2nd | will try to find out | 11:28 |
| *** arturkow <arturkow!~arturkow@84-10-27-202.static.chello.pl> has quit IRC (Quit: Client closed) | 11:37 | |
| *** arturkow <arturkow!~arturkow@84-10-27-202.static.chello.pl> has joined #yocto | 11:37 | |
| *** arturkow <arturkow!~arturkow@84-10-27-202.static.chello.pl> has quit IRC (Client Quit) | 11:37 | |
| *** arturkow <arturkow!~arturkow@84-10-27-202.static.chello.pl> has joined #yocto | 11:37 | |
| *** arturkow <arturkow!~arturkow@84-10-27-202.static.chello.pl> has quit IRC (Client Quit) | 11:37 | |
| LetoThe2nd | what do people buy for personal builders these days? still threadrippers? | 11:49 |
| rburton | most likely the best bang-per-buck still | 11:50 |
| rburton | but you know you want to get a mac studio and boot asahi on it to benchmark that ;) | 11:50 |
| LetoThe2nd | k | 11:50 |
| LetoThe2nd | nope. | 11:50 |
| rburton | bah | 11:51 |
| LetoThe2nd | been using an old phenom x2 at the moment, but that really needs upgrading | 11:51 |
| LetoThe2nd | 1) looked at prices. 2) decided it will probably be just a run of the mill ryzen | 11:57 |
| rburton | yeah prices are not great | 11:59 |
| qschulz | LetoThe2nd: if you're going for overkill, I've read that the new i9 12th gen are pretty good | 12:00 |
| LetoThe2nd | qschulz: the overkill days are gone, i'm back to common sense ;-) | 12:01 |
| qschulz | LetoThe2nd: then probably Ryzen product line which should have more cores than Intel at similar price points | 12:01 |
| qschulz | (note that Intel MB are notably more expensive than Ryzen compatible ones for some reason) | 12:02 |
| *** camus <camus!~Instantbi@2409:8a1e:9115:e190:5138:5b88:8215:a434> has quit IRC (Ping timeout: 260 seconds) | 12:03 | |
| qschulz | LetoThe2nd: though note that most Ryzen CPUs don't have integrated GPU (the G and GE product line does have it though, AMD calls them APUs) | 12:03 |
| *** camus1 <camus1!~Instantbi@183.192.143.37> has joined #yocto | 12:03 | |
| *** dvorkindmitry <dvorkindmitry!~dv@5.167.98.73> has quit IRC (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/) | 12:03 | |
| LetoThe2nd | qschulz: yeah, 5700g sounds like a good one to get. | 12:03 |
| qschulz | so either go for G product line (last letter in the CPU product ID) or think about buying a small graphics card | 12:03 |
| *** camus1 is now known as camus | 12:05 | |
| LetoThe2nd | I even have one lying around here. but that means more hw, e.g. more power consumption. | 12:07 |
| qschulz | LetoThe2nd: I know I know, been looking for CPUs to replace my old server at home but don't want to increase the power consumption really.. | 12:09 |
| qschulz | quite a difficult task to find 35W CPUs with integrated graphics today :) | 12:09 |
| rburton | get a mac mini and boot asahi on it ;) | 12:20 |
| rburton | i wonder if anyone makes thunderbolt sata docks that take four disks | 12:20 |
| qschulz | rburton: no thank you :) | 12:25 |
| qschulz | don't have time to debug things on my server, it needs to work :) | 12:25 |
| qschulz | and I had a Mac mini at work running Linux (intel based, old one), graphics glitches every now and then | 12:26 |
| rburton | well if its a server it will be headless, right? :) | 12:27 |
| qschulz | rburton: well.. no :p | 12:28 |
| qschulz | want to replace my RPi running Kodi/LibreElec with the server | 12:28 |
| qschulz | and also hope to be able to replace my desktop (which I very rarely use) with it | 12:28 |
| qschulz | but I've yet to understand if it is possible and how to share GPU+VPU among different containers/KVM | 12:29 |
| qschulz | and now the 5600GE I'm after is impossible to find | 12:30 |
| qschulz | rburton: is it you who has a microserver gen8 too? | 12:31 |
| qschulz | I remember reading a tweet, either you or paul | 12:31 |
| qschulz | and looking for ARM based replacement | 12:31 |
| qschulz | well.. maybe #yocto isn't the best place for this kind of discussion but it's rather calm today :) | 12:31 |
| LetoThe2nd | everybody is busy day drinking and preparing bad jokes for tomorrow. | 12:34 |
| *** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC (Quit: Leaving) | 12:40 | |
| *** MrSaturn <MrSaturn!~sam@cpe-72-224-69-22.maine.res.rr.com> has joined #yocto | 13:02 | |
| MrSaturn | silly question: If I do a "devtool build" where does the binary go? | 13:02 |
| qschulz | MrSaturn: ${B} | 13:04 |
| *** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:2cf5:51cb:fa23:24f8> has quit IRC (Quit: vladest) | 13:07 | |
| *** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:d6d6:7366:5da8:23b6> has joined #yocto | 13:08 | |
| MrSaturn | Alright, odd. I think something isn't working quite right in the recipe. | 13:09 |
| MrSaturn | Is there a way I can make this work with both bitbake and devtool? https://pastebin.com/xPgS5PGc When I do a devtool modify, then a bitbake build it can not find the logo. | 13:10 |
| rburton | MrSaturn: don't use a task, just tell the fetcher where to put the file in the SRC_URI: https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-fetching.html#the-unpack | 13:12 |
| rburton | qschulz: yeah thats me | 13:12 |
| qschulz | rburton: the only Aarch64 consumer board that was "suitable" for NAS was the Helios64 IIRC, but they shutdown last year | 13:14 |
| MrSaturn | rburton: The layer already has a 'SRC_URI += "file://company.bmp"' line. It looks like that task is move the logo to a specific location. This isn't my layer, so I am guessing at intention. | 13:20 |
| MrSaturn | In devtool, "company.bmp" is in a directory called "oe-local-files" | 13:22 |
| *** ar__ <ar__!~akiCA@user/akica> has joined #yocto | 13:33 | |
| *** codavi <codavi!~akiCA@user/akica> has joined #yocto | 13:37 | |
| *** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 250 seconds) | 13:40 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 13:43 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 13:49 | |
| rburton | MrSaturn: someone didn't know that you can tell the fetcher where to put a file, that's all | 13:55 |
| rburton | a new task is overkill | 13:55 |
| LetoThe2nd | qschulz: the u-boot boot is weird. builddir is empty other than the .scmversion file. | 14:56 |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:3958:796d:6d52:6def> has joined #yocto | 15:14 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 272 seconds) | 15:26 | |
| RP | kergoth: do you think the failure in https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/3382/steps/15/logs/stdio might be related to the sys.modules reset? :/ | 15:36 |
| RP | JPEW: there is also an asyncio event loop issue in there :( | 15:36 |
| RP | kergoth: I mean the KeyError re: sys.modules | 15:37 |
| kergoth | I'm wondering if sys.modules and sys.path are actually just dicts or another type, if assignment could cause an issue vs clearing and updating the dict | 15:54 |
| kergoth | RP: ^ | 15:54 |
| kergoth | don't really know | 15:54 |
| *** gsalazar <gsalazar!~gsalazar@132.120.90.149.rev.vodafone.pt> has joined #yocto | 15:56 | |
| RP | kergoth: Yes, that is what I'm wondering too. I'm pretty sure sys.path is just a list but sys.modules' contents might not copy well :/ | 15:57 |
| kergoth | Module import handling is voodoo to me, I should probably read up on that more | 15:57 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 16:02 | |
| kergoth | I'd try clearing and updating sys.modules and see if that changes the behavior | 16:03 |
| kergoth | I do wonder how these things are affected by multiconfig builds, since it's global state set by metadata which isn't global | 16:04 |
| kergoth | guessing layers wouldn't change with that so probably fine | 16:04 |
| *** dvorkindmitry <dvorkindmitry!~dv@5.167.98.73> has joined #yocto | 16:06 | |
| dvorkindmitry | Is there a way to install SYSTEMD_SERVICE machine-specific, like SYSTEMD_SERVICE:${PN}:myarch = "ssss.service" ? | 16:06 |
| qschulz | dvorkindmitry: if this does not work you can always do SYSTEMD_SERVICE:${PN} = "${SSSS_SERVICE}" and have SSSS_SERVICE:myarch = "ssss.service" | 16:09 |
| kergoth | overrides work fine with any variable. they don't work on flags, but variables are fine | 16:10 |
| kergoth | Hmm when will kirkstone be branching? Wonderinga bout submitting stuff that doesn't belong in the release | 16:13 |
| dvorkindmitry | qschulz, kergoth, thank you to both of you. looks like it work | 16:13 |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Remote host closed the connection) | 16:13 | |
| RP | kergoth: not sure I want to think about multiconfig in this context! | 16:14 |
| dvorkindmitry | why machine-specific SRC_URI should be written like SRC_URI:append:mymachine, while SYSTEMD_SERVICE:${PN}:mymachine ? | 16:15 |
| smurray | the latter isn't an append? | 16:19 |
| smurray | i.e. it overrides the definition. If you did that for SRC_URI you'd lose the presumably non-machine-specific default value | 16:21 |
| RP | kergoth: going to give https://git.yoctoproject.org/poky/commit/?h=master-next&id=f8acc250920fc7b1c1a1703b640ebff07d16ef89 a try | 16:24 |
| manuel1985 | 'Subprocess output:x86_64-poky-linux-objcopy: Unable to recognise the format of the input file' <--- how can I skip this check? The file in question is a downloaded rust executable | 16:25 |
| kergoth | RP: looks reasonable | 16:28 |
| kergoth | I wonder if we couldn't subclass and use importlib.machinery.PathFinder to search our own bbpath-based-path directly rather than mucking about with sys.path. I also wonder if we could change sys.modules or import behavior in our python eval so it doesn't persist in bitbake's global sys.path and sys.modules. | 16:29 |
| kergoth | long term | 16:29 |
| RP | kergoth: yes, I think we do need to improve this longer term, probably with layer.conf syntax too | 16:31 |
| * RP notes kirkstone branches are now available | 16:41 | |
| RP | they're not diverging yet but available | 16:42 |
| kergoth | ah, okay, so no need to hold off on post-kirkstone submissions? | 16:42 |
| RP | kergoth: just make them clearly not for kirkstone | 16:43 |
| *** dvorkindmitry <dvorkindmitry!~dv@5.167.98.73> has quit IRC (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/) | 16:51 | |
| amahnui[m] | Hello rburton: I have set up freebsd tho I never successfully set up a de but I will begin setting up my coding environment while trying to set it up the de | 16:55 |
| *** mckoan is now known as mckoan|away | 16:57 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:59 | |
| *** ykrons <ykrons!~guillaume@62.192.23.101> has quit IRC (Ping timeout: 240 seconds) | 17:20 | |
| *** ykrons <ykrons!~guillaume@62.192.23.101> has joined #yocto | 17:32 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 245 seconds) | 17:33 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto | 17:49 | |
| MrSaturn | 2~2~ https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-fetching.html#the-unpack | 17:57 |
| MrSaturn | Sorry about the accidental paste. Just to make sure I understand: to fetch a file and put it in a specfic location, you do "SRC_URI +=..." then you need to put something in do_unpack? | 18:01 |
| rfs613 | MrSaturn: only if you have some very esoteric unpacking needs. Normally the existing yocto handles all formats you're likely to encounter. | 18:08 |
| MrSaturn | rfs613: I have a file that I need to put in ${S}/tools/logos. Can this be accomplished without a do_unpack_append? | 18:09 |
| rfs613 | MrSaturn: I think you may be confusing the unpack with the install | 18:10 |
| MrSaturn | rfs613: Perhaps. The file needs to be inplace before compilation | 18:12 |
| rburton | MrSaturn: yes it can. i pointed you at the precise bit of the documetation that tells you how earlier today | 18:12 |
| rburton | the default location is WORKDIR | 18:13 |
| rburton | but you can change that, to ${S}/tools/logos | 18:13 |
| MrSaturn | rburton: oh shoot. I think I understand. I had to read it a third time. SRC_URI += "file://mfg.bmp;subdir=${S}/tools/logos" | 18:17 |
| rburton | yes | 18:17 |
| MrSaturn | Sorry I am daft. I missed that it was a parameter in the URL | 18:19 |
| MrSaturn | Holy cow that worked. Let's see if devtool does the trick now. | 18:20 |
| MrSaturn | Ok, this is madness. I am going to reach out to them and ask them their workflow. | 18:22 |
| MrSaturn | Now when I do a devtool build I get a "subdir argument isn't a subdirectory of unpack root" | 18:23 |
| amahnui[m] | <amahnui[m]> "Hello rburton: I have set up..." <- Hello rburton: please I can't find the issue tracker for yocto project | 18:25 |
| rburton | bugzilla.yoctoproject.org | 18:25 |
| amahnui[m] | rburton: Thank you | 18:29 |
| *** ferlzc <ferlzc!~ferlzc@177.52.29.172> has joined #yocto | 18:30 | |
| ferlzc | Hi, I created a recipe that's builds a library. I compile the library on the do_compile() and afterward I installed it using the following:do_install () { | 18:32 |
| ferlzc | install -p ${D}${libdir} | 18:32 |
| ferlzc | install -d ${D}${includedir} | 18:32 |
| ferlzc | install ${S}/libulf.so ${D}${libdir}/libulf.so | 18:32 |
| ferlzc | 18:32 | |
| ferlzc | install ${S}/lib-ulf.h ${D}${includedir} | 18:32 |
| ferlzc | } | 18:32 |
| rburton | version your library | 18:32 |
| rburton | that's why you get insane errors | 18:32 |
| rburton | if you really don't want to version your library then https://docs.yoctoproject.org/dev-manual/common-tasks.html#working-with-pre-built-libraries covers how to work around it | 18:33 |
| rburton | but version your library (i.e. libulf.so.1) | 18:33 |
| rburton | I'm assuming I'm right as to what the problem is ;) | 18:33 |
| ferlzc | rburton that's one problem and you nailed | 18:34 |
| rburton | https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html talks about the library naming convention | 18:34 |
| ferlzc | the other one is: I need to use this library in another recipe, but during the makefile I can seem to find the .h that I link for | 18:35 |
| rburton | did you DEPEND on ulf or whatever you named the library recipe? | 18:36 |
| ferlzc | for some reason the only way I found .h was using -I${TMPDIR}/sysroots-components/core2-64/lib-omneulf-client/usr/include, which is not a good solution | 18:36 |
| rburton | yeah don't do that | 18:36 |
| rburton | if you DEPENDed on ulf then its in the recipe's private sysroot | 18:37 |
| ferlzc | I did DEPEND the library on the new recipe | 18:37 |
| rburton | are you manually compiling the app? | 18:37 |
| rburton | because you're probably driving the compiler wrong | 18:37 |
| ferlzc | no I'm patching an Makefile | 18:38 |
| rburton | even worse: the makefile is probably terrible | 18:38 |
| rburton | makefiles are typically terrible and wrong | 18:38 |
| rburton | specifically, its probably ignoring LDFLAGS from the environment | 18:38 |
| rburton | writing a proper makefile is hard. people think its easy, hack one up, and then wonder why people building distributions get annoyed at the makefiles. | 18:39 |
| ferlzc | this an example of the Makefile | 18:39 |
| ferlzc | LDLIBSOPTIONS=-L/opt/omne/lib -L/opt/addons/lib -lulf -lcrypto -lpq -lpcrecpp | 18:39 |
| ferlzc | # Build Targets | 18:39 |
| ferlzc | .build-conf: ${BUILD_SUBPROJECTS} | 18:39 |
| ferlzc | "${MAKE}" -f nbproject/Makefile-${CND_CONF}.mk ${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM}/libomnecpp.so | 18:39 |
| ferlzc | ${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM}/libomnecpp.so: ${OBJECTFILES} | 18:39 |
| ferlzc | ${MKDIR} -p ${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM} | 18:39 |
| ferlzc | ${LINK.cc} -o ${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM}/libomnecpp.so ${OBJECTFILES} ${LDLIBSOPTIONS} -shared -fPIC | 18:39 |
| ferlzc | ${OBJECTDIR}/OmneAuth.o: OmneAuth.cpp | 18:39 |
| ferlzc | ${MKDIR} -p ${OBJECTDIR} | 18:39 |
| ferlzc | ${RM} "$@.d" | 18:39 |
| ferlzc | $(COMPILE.cc) -O2 -I/opt/addons/include -I/opt/omne/include -fPIC -MMD -MP -MF "$@.d" -o ${OBJECTDIR}/OmneAuth.o OmneAuth.cpp | 18:39 |
| ferlzc | ${OBJECTDIR}/OmneCrypto.o: OmneCrypto.cpp | 18:39 |
| ferlzc | ${MKDIR} -p ${OBJECTDIR} | 18:39 |
| ferlzc | ${RM} "$@.d" | 18:39 |
| ferlzc | $(COMPILE.cc) -O2 -I/opt/addons/include -I/opt/omne/include -fPIC -MMD -MP -MF "$@.d" -o ${OBJECTDIR}/OmneCrypto.o OmneCrypto.cpp | 18:39 |
| ferlzc | ${OBJECTDIR}/OmneStrings.o: OmneStrings.cpp | 18:39 |
| ferlzc | ${MKDIR} -p ${OBJECTDIR} | 18:39 |
| ferlzc | ${RM} "$@.d" | 18:39 |
| ferlzc | $(COMPILE.cc) -O2 -I/opt/addons/include -I/opt/omne/include -fPIC -MMD -MP -MF "$@.d" -o ${OBJECTDIR}/OmneStrings.o OmneStrings.cpp | 18:39 |
| ferlzc | ${OBJECTDIR}/OmneULF.o: OmneULF.cpp | 18:39 |
| ferlzc | ${MKDIR} -p ${OBJECTDIR} | 18:39 |
| ferlzc | ${RM} "$@.d" | 18:39 |
| ferlzc | $(COMPILE.cc) -O2 -I/opt/addons/include -I/opt/omne/include -fPIC -MMD -MP -MF "$@.d" -o ${OBJECTDIR}/OmneULF.o OmneULF.cpp | 18:40 |
| ferlzc | i'm patching those /opt/omne/lib which is bad | 18:40 |
| rburton | I'm assuming it doesn't define COMPILE.cc itself? | 18:40 |
| ferlzc | can you tell me more on how not to ignore the LDFLAGS on this Makefile ? | 18:41 |
| rburton | well, does it define COMPILE.cc or does it use the default? | 18:41 |
| ferlzc | it uses the default | 18:41 |
| rburton | the default COMPILE.cc does respect CXX CXXFLAGS CPPFLAGS so it *should* work | 18:42 |
| rburton | read the tmp/****/recipename/temp/log.do_compile to see what compiler flags are being passed. | 18:42 |
| rburton | it should be passing --sysroot pointing at the recipe sysroot for the recipe, which should contain an include/ulf.h | 18:43 |
| rburton | its its now quarter to 8 so im going to see my kids. hope someone else can help when you have more info. always hard to debug secret recipes though. | 18:43 |
| ferlzc | is like this: | 18:44 |
| ferlzc | g++ -c -O2 -I/usr/include -fPIC -MMD -MP -MF "build/Release/GNU-Linux-x86/OmneAuth.o.d" -o build/Release/GNU-Linux-x86/OmneAuth.o OmneAuth.cpp | 18:44 |
| ferlzc | g++ -c -O2 -I/usr/include -fPIC -MMD -MP -MF "build/Release/GNU-Linux-x86/OmneCrypto.o.d" -o build/Release/GNU-Linux-x86/OmneCrypto.o OmneCrypto.cpp | 18:44 |
| ferlzc | g++ -c -O2 -I/usr/include -fPIC -MMD -MP -MF "build/Release/GNU-Linux-x86/OmneULF.o.d" -o build/Release/GNU-Linux-x86/OmneULF.o OmneULF.cpp | 18:44 |
| ferlzc | In file included from OmneAuth.cpp:1: | 18:44 |
| ferlzc | OmneAuth.h:8:10: fatal error: libpq-fe.h: No such file or directory | 18:44 |
| ferlzc | 8 | #include <libpq-fe.h> | 18:44 |
| ferlzc | | ^~~~~~~~~~~~ | 18:44 |
| ferlzc | compilation terminated. | 18:44 |
| *** agners <agners!~ags@2a02:169:3df5:10:5232:3053:9692:978b> has joined #yocto | 18:44 | |
| rburton | that's using the host compiler, not a cross compiler | 18:44 |
| ferlzc | rburton thank you very much for the help so far | 18:45 |
| khem | where is COMPILE.cc being set ? | 18:45 |
| rburton | its a default make rule | 18:45 |
| khem | perhapps EXTRA_OEMAKE += "COMPILE.cc='${CC}'" | 18:45 |
| khem | might be a good thing to do in recipe | 18:45 |
| rburton | $ make -f /dev/null -p|grep COMPILE.cc | 18:45 |
| ferlzc | is not defining the COMPILE.cc | 18:45 |
| rburton | COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c | 18:45 |
| khem | OK is there some hard define for CXX in makefile ? | 18:46 |
| rburton | oh do you need EXTRA_OEMAKE = "-e"? | 18:47 |
| rburton | to force it to pull from the environment | 18:47 |
| rburton | always forget that we don't force make to do that anymore | 18:49 |
| rburton | its only been what, five years | 18:49 |
| *** bonalais <bonalais!uid502939@id-502939.tinside.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 19:00 | |
| ferlzc | yes there is some hard define for CXX on the file, like so:CC=gcc | 19:09 |
| ferlzc | CCC=g++ | 19:09 |
| ferlzc | CXX=g++ | 19:09 |
| rfs613 | sakoman: available for a quick chat about CVE backports in dunfell? | 19:10 |
| sakoman | rfs613: yes | 19:10 |
| rfs613 | great! so I notice there are a lot (92 according to last metrics email) | 19:11 |
| rfs613 | quite a few of them also exist in other branches | 19:11 |
| rfs613 | do we have a requirement to fix them in newer branches before they can go in dunfell? | 19:12 |
| rfs613 | I'm finding it challenging to switch between branches, to verify a fix works in all of them | 19:12 |
| sakoman | There is a requirement that fixes go first to master before dunfell and the other branches | 19:13 |
| sakoman | Then it is up to the branch maintainers to take them if possible | 19:13 |
| sakoman | In reality, with different versions in the various branches it is pretty rare to be able to cherry-pick | 19:14 |
| khem | master is must as sakoman says | 19:15 |
| sakoman | When kirkstone is out and I am maintaining two LTS branches I'll probably try really hard to get the fixes in both after master | 19:15 |
| khem | we need to ensure its either fixed in master via virtue of new version being in master or apply the patch to master and ask for a backport to related branches | 19:15 |
| rfs613 | indeed, but the effort of finding the patch, applying it, adding the approprate tags etc, sort of makes sense to try and do it for all branches. Otherwise I end up re-doign the same work again. | 19:16 |
| khem | yeah LTSs would matter | 19:16 |
| sakoman | But the reality is that many CVEs only exist in older branches and not in master since they have more recent package versions | 19:16 |
| sakoman | So more often than not CVE fixes for dunell don't have a master fix since they don't exist there | 19:16 |
| zeddii | That's always fine as well. AS long as someone shows the version in master doesn't have a given problem, a cherry-pick/patch to an older branch is fine. | 19:17 |
| sakoman | rfs613: I and other maintainers would love to see you do the patches for all currently supported branches | 19:17 |
| sakoman | But please test that the patches not only apply but build in those older branches :-) | 19:18 |
| rfs613 | sakoman: my only challenge is workflow, keeping multiple branches up-to-date, testing that the CVE fix at least builds on each branch... it slows down the cycle significantly. And I find it mentally challenging to jump between branches a lot, get my wires crossed. | 19:19 |
| rfs613 | having fewer active branches would of course help... dunfell, kirkstone, master would be nice ;-) | 19:19 |
| sakoman | rfs613: I totally understand! The important branches at this point would be master, kirkstone, and dunfell | 19:20 |
| khem | practically yes | 19:20 |
| rfs613 | ok, so as I am focused on dunfell for now, maybe I'll just note which other branches a fix might be applicable to (it's pretty easy to check while I'm in there), but leave the actual work of fixing honister/hardknott (if applicable) to someone else. | 19:21 |
| khem | yeah knowing that other branches would need this fix too would be good atleat release maintainer will know | 19:22 |
| rfs613 | the patches would have [dunfell] tag, so other branch maintainer might not look at them | 19:23 |
| sakoman | rfs613: honister and hardknott just have one to two months of active maintenance left so it is a short term problem | 19:23 |
| sakoman | rfs613: I know that for dunfell I look at all CVE patches in master and do a quick evaluation as to whether they exist in dunfell and whether a cherry-pick is possible | 19:24 |
| rfs613 | my other question relates to timing w.r.t releases, do we have a preference on when to submit (esp) CVE fixes? | 19:25 |
| sakoman | rfs613: for CVEs the answer is always ASAP :-) | 19:25 |
| sakoman | I try to do some each week independent of whether a release is imminent or not | 19:26 |
| sakoman | Though at release time it does go to zero since I'm occupied with the release | 19:26 |
| khem | sakoman: on this note when is 3.1.16 planned ? there are some important openssl fixes on dunfell since 3.1.15 | 19:34 |
| sakoman | khem: from the weekly status update: | 19:35 |
| sakoman | YP 3.1.16 build date 2022/04/25YP 3.1.16 Release date 2022/05/06 | 19:35 |
| khem | ok thanks | 19:36 |
| rfs613 | i've just posted CVE-2022-0204 for dunfell. In the comments after the shortlog, I put info about the other branches. Feedback on the formatting, usefulnes, etc welcomed. | 19:40 |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Quit: Ping timeout (120 seconds)) | 19:41 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 19:41 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 20:04 | |
| RP | Nice, first ever oe-selftest pass with BB_SERVER_TIMEOUT set | 20:06 |
| rfs613 | hmm, this is odd, I used "b4" to download my patch (in another copy of poky). It said it applies clean to current tree, and yet when I do the 'git am' on the .mbx file, it complains that the patch is corrupt. | 20:07 |
| khem | rfs613: there patchwork too https://patchwork.yoctoproject.org/project/oe-core/list/ | 20:09 |
| khem | I have had more success with pw | 20:09 |
| rfs613 | khem: there was a commandline tool for patchwork too, I seem to recall... | 20:10 |
| khem | git-pw yes | 20:17 |
| khem | https://github.com/getpatchwork/git-pw | 20:17 |
| abelloni | RP: so you started a master-next build to celebrate? :) | 20:18 |
| RP | abelloni: using server_timeout so it may explode | 20:19 |
| RP | abelloni: I saw the system had space and was curious to see how bad the issues are now | 20:19 |
| RP | abelloni: it isn't causing an issue is it? | 20:20 |
| *** GillesM <GillesM!~gilles@105.61.128.77.rev.sfr.net> has quit IRC (Quit: Leaving) | 20:21 | |
| abelloni | nope, I'm waiting for my build to finish, that's all | 20:23 |
| abelloni | and then I'll send the series from rburton which I'm not really sure will be successfull ;) | 20:23 |
| *** ferlzc_ <ferlzc_!~ferlzc@177.52.29.172> has joined #yocto | 20:26 | |
| RP | abelloni: I hadn't seen that series. Hmm ;-) | 20:27 |
| rfs613 | khem: oh, it looks like I corrupted the patch before sending it. Oops. | 20:29 |
| *** Circuitsoft <Circuitsoft!uid393878@id-393878.lymington.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 20:29 | |
| rfs613 | I'll do a v2 later, time to pick up the little ones. | 20:29 |
| *** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:d6d6:7366:5da8:23b6> has quit IRC (Remote host closed the connection) | 20:30 | |
| *** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:d6d6:7366:5da8:23b6> has joined #yocto | 20:31 | |
| *** ferlzc_ <ferlzc_!~ferlzc@177.52.29.172> has quit IRC (Remote host closed the connection) | 20:40 | |
| *** ferlzc <ferlzc!~ferlzc@177.52.29.172> has quit IRC (Remote host closed the connection) | 20:40 | |
| *** amitk <amitk!~amit@103.208.71.41> has quit IRC (Ping timeout: 246 seconds) | 20:44 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:3958:796d:6d52:6def> has quit IRC (Remote host closed the connection) | 20:53 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto | 20:53 | |
| RP | abelloni: I'm worried that build is hanging :( | 21:15 |
| abelloni | RP: mine seems to be stuck too: https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/3379/steps/14/logs/stdio | 21:28 |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 245 seconds) | 21:29 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection) | 21:30 | |
| RP | abelloni: I was referring to yours! | 21:30 |
| abelloni | Ah! | 21:32 |
| abelloni | then yes, it seems stuck, I've started another one just to see | 21:32 |
| RP | abelloni: I logged into alma8 and it is inside a linux-yocto kernel build. I think it is the make hang | 21:34 |
| RP | $ pstree -p 3415749 | 21:34 |
| RP | run.do_compile.(3415749)───make(4031649)───make(4041617)───make(4044688)───make(4044694)───sh(4044706) | 21:34 |
| RP | and 4044706 is a zombie | 21:34 |
| RP | abelloni: I think I can unblock it if you want. Or if anyone wants to study a make/signal bug... | 21:35 |
| abelloni | ah, I'm pretty sure you'd love to do that before going to sleep ;) | 21:36 |
| RP | abelloni: unblock it or study it? I did study one of these before. I don't know what the issue is :( | 21:37 |
| abelloni | I'm not quite sure what would make that centos specific | 21:38 |
| RP | abelloni: make version? | 21:38 |
| RP | abelloni: something like https://git.savannah.gnu.org/cgit/make.git/commit/?id=88713683fed38fa5a7a649d065c73f4d945bade7 maybe? | 21:40 |
| RP | although that should be in 4.2.1 | 21:41 |
| abelloni | from 2014? | 21:41 |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 21:42 | |
| RP | abelloni: https://savannah.gnu.org/bugs/?51400 i.e. https://git.savannah.gnu.org/cgit/make.git/commit/?id=78b5fec6898c26956d00548427cda1101cb80f8a | 21:44 |
| RP | abelloni: I suspect something like this | 21:44 |
| RP | abelloni: to be clear I think it is bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=14712 on our side | 21:45 |
| RP | abelloni: I updated the bug | 21:48 |
| abelloni | ok, I guess you can kill this build then | 21:48 |
| RP | abelloni: not quite sure what I did there but it has died | 21:50 |
| *** alimon <alimon!~alimon@189.174.2.174> has quit IRC (Quit: Leaving.) | 21:51 | |
| *** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 250 seconds) | 21:58 | |
| RP | JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/3352/steps/14/logs/stdio - second time I've hit this despite the patches in -next and on the list :( | 22:00 |
| JPEW | RP: Weird, is that new? did something change? | 22:01 |
| RP | JPEW: it is memres bitbake | 22:01 |
| RP | JPEW: BB_SERVER_TIMEOUT=60 | 22:02 |
| RP | I'm really tempted to just error if make 4.2.1 is present | 22:09 |
| *** dgriego <dgriego!~dgriego@user/dgriego> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 22:09 | |
| JPEW | Is it warning in all the tests and we just don't see it? | 22:10 |
| abelloni | RP: wouldn't that just disable all the centos based workers? | 22:22 |
| *** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!) | 22:26 | |
| *** gsalazar <gsalazar!~gsalazar@132.120.90.149.rev.vodafone.pt> has quit IRC (Ping timeout: 250 seconds) | 22:29 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection) | 22:32 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 22:50 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 22:59 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!