*** ahs3 <ahs3!~ahs3@user/ahs3> has joined #yocto | 00:10 | |
*** GillesM <GillesM!~gilles@115.188.198.77.rev.sfr.net> has quit IRC (Ping timeout: 240 seconds) | 00:34 | |
vmeson | ah, here I went and dug up the origin of decafbadbeef for Guest11 and they're gone. Oh, well, if they are searching archives: https://git.yoctoproject.org/poky/commit/?id=d0f0e5d9e69cc22f0c6635c7e416de93660c6bca | 00:50 |
---|---|---|
vmeson | I started manualy wget'ing the opencv tarball. It's 1.9 GB and downloading on my lowly home connection is going to take almost an hour! Speed is varying b/w 250 KB/s and 1.2 MB/s. I think I'll make a graph of it! | 00:52 |
vmeson | There: Not so shocking that YP dlds are much slower than github downloads: https://postimg.cc/94H4zQ6p | 01:07 |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 260 seconds) | 01:08 | |
vmeson | halstead: the variation in dl speed does seem larger than expected but I honestly haven't been making enough graphs of t-put variation recently to know if this is expected. | 01:08 |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:12 | |
* vmeson notes frequent TCP "Errors" in the dl from YP but decides to use the bandwidth for Netflix rather than more tests. | 01:17 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 01:18 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:24 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 01:32 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:39 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 01:45 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds) | 01:47 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:52 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Client Quit) | 01:56 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:57 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds) | 02:07 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:09 | |
*** starblue <starblue!~juergen@dslb-188-100-128-085.188.100.pools.vodafone-ip.de> has quit IRC (Ping timeout: 272 seconds) | 02:13 | |
*** starblue <starblue!~juergen@dslb-188-100-133-133.188.100.pools.vodafone-ip.de> has joined #yocto | 02:14 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 02:16 | |
*** Tokamak <Tokamak!~Tokamak@166.205.152.51> has quit IRC (Ping timeout: 260 seconds) | 02:19 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:21 | |
*** Tokamak <Tokamak!~Tokamak@172.58.188.218> has joined #yocto | 02:22 | |
*** rber|res <rber|res!~rber|res@94.71.69.57> has joined #yocto | 02:32 | |
*** RobertBerger <RobertBerger!~rber|res@94.71.69.57> has quit IRC (Ping timeout: 240 seconds) | 02:34 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 02:38 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 02:43 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:49 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds) | 03:01 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:03 | |
*** jclsn1 <jclsn1!~jclsn@149.233.201.67.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:13 | |
*** jclsn <jclsn!~jclsn@149.224.247.61.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds) | 03:15 | |
*** jclsn1 <jclsn1!~jclsn@149.233.201.67.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds) | 03:20 | |
*** Tokamak <Tokamak!~Tokamak@172.58.188.218> has quit IRC (Ping timeout: 240 seconds) | 03:22 | |
*** jclsn1 <jclsn1!~jclsn@149.233.201.67.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:25 | |
*** Tokamak <Tokamak!~Tokamak@166.205.152.97> has joined #yocto | 03:25 | |
*** jclsn1 <jclsn1!~jclsn@149.233.201.67.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds) | 03:31 | |
*** jclsn1 <jclsn1!~jclsn@149.233.201.67.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:35 | |
*** jclsn1 <jclsn1!~jclsn@149.233.201.67.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds) | 03:41 | |
*** jclsn1 <jclsn1!~jclsn@149.233.201.67.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:46 | |
*** amitk <amitk!~amit@103.208.69.77> has joined #yocto | 03:47 | |
*** amitk <amitk!~amit@103.208.69.77> has quit IRC (Quit: leaving) | 03:55 | |
*** amitk <amitk!~amit@103.208.69.77> has joined #yocto | 04:04 | |
*** amitk <amitk!~amit@103.208.69.77> has quit IRC (Ping timeout: 240 seconds) | 04:11 | |
*** amitk <amitk!~amit@103.208.69.77> has joined #yocto | 04:12 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Read error: Connection reset by peer) | 04:20 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto | 04:30 | |
halstead | that server is on AWS euro network I believe. Let's run some tests in the morning. | 04:50 |
halstead | git.yoctoproject.org is anyway. Seeing the IP would help since there are multiple. downloads.yoxtoproject.org is in Portland Oregon USA. | 04:51 |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 04:52 | |
*** sstiller <sstiller!~sstiller@p200300f07f1383006ea5d3f959e43361.dip0.t-ipconnect.de> has joined #yocto | 06:34 | |
dirtyflag | hi working porting an old BSP (Mentor) to dunfell, i gat this error | 06:38 |
dirtyflag | ERROR: Nothing RPROVIDES 'nativesdk-qtbase-tools' | 06:38 |
dirtyflag | there is no recipe for qtbase-tools btw | 06:39 |
dirtyflag | only a "qtbase" | 06:39 |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds) | 06:57 | |
*** camus <camus!~Instantbi@183.192.142.149> has quit IRC (Ping timeout: 256 seconds) | 07:11 | |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 07:15 | |
hmw[m] | <dirtyflag> "hi working porting an old BSP (..." <- in what layer is the old nativesdk-qtbase-tools | 07:23 |
dirtyflag | hmw[m]: unfortunately i have been provided only with a customer layer, where it's not | 07:25 |
dirtyflag | looks like i have found a nativesdk-qttools | 07:26 |
hmw[m] | dirtyflag: if i quick search https://layers.openembedded.org/layerindex/branch/dunfell/recipes/ i can´t find it for you ( also not on older branches) | 07:27 |
dirtyflag | hmw[m]: thanks, i have found a "nativesdk-packagegroup-qt5-toolchain-host" | 07:27 |
dirtyflag | that seems ok for my case. | 07:28 |
dirtyflag | anyway, it brings in perl too, that gives a new romantic error "maximum shebang size exceeded, the maximum size is 128" | 07:30 |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has quit IRC (Read error: Connection reset by peer) | 07:33 | |
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto | 07:33 | |
*** mckoan|away is now known as mckoan | 07:39 | |
*** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 07:43 | |
hmw[m] | shebang is the first line of a script that starts with !# that may not be longer as 128 | 07:47 |
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has joined #yocto | 08:02 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 08:15 | |
*** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has joined #yocto | 08:23 | |
*** matthewcroughan <matthewcroughan!~quassel@static.211.38.12.49.clients.your-server.de> has quit IRC (Remote host closed the connection) | 08:33 | |
*** matthewcroughan <matthewcroughan!~quassel@static.211.38.12.49.clients.your-server.de> has joined #yocto | 08:33 | |
*** iokill_ <iokill_!~dave@static.16.105.130.94.clients.your-server.de> has quit IRC (Ping timeout: 240 seconds) | 08:35 | |
*** iokill <iokill!~dave@static.16.105.130.94.clients.your-server.de> has joined #yocto | 08:36 | |
*** alex_b <alex_b!~alex_b@62.26.159.81> has joined #yocto | 08:46 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 08:47 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 08:48 | |
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto | 09:08 | |
*** kroon_ <kroon_!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto | 09:14 | |
*** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC (Ping timeout: 252 seconds) | 09:14 | |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:20 | |
*** camus <camus!~Instantbi@183.192.142.149> has joined #yocto | 09:30 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 09:35 | |
LetoThe2nd | yo dudX | 09:37 |
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:601a:fd8e:29b:1901> has joined #yocto | 09:43 | |
hmw[m] | how do i force debug compile when compiling applications whit an yocto sdk | 09:43 |
kroon_ | hmw[m], what build system is your application using ? | 09:44 |
kroon_ | cause i would it say, it depends on the build system used | 09:45 |
hmw[m] | qmake | 09:45 |
kroon_ | I don't know much about qmake, but I would assume the same tricks apply even when building with a yocto sdk as when doing a native build with the host compiler | 09:47 |
hmw[m] | my code crashes on call x when i have something that is "not executed yet " if i comment the newly added line way below it is not crashing | 09:47 |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 09:48 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:52 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 10:16 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 10:29 | |
wyre | should the .dtb filename in the dts/Makefile match exactly the filename of your custom .dts file? 🤔 | 11:05 |
wyre | I mean ... I've got this inside meta-mylayer/recipes-kernel/linux folder https://bpa.st/2JLA | 11:09 |
wyre | and I'm not sure if I'm patching properly the Makefile, as my dts is actually called imx6ull-microgea-joifi.dts 🤔 | 11:10 |
wyre | so I'm not sure if I should patch the kernel Makefile with `imx6ull-microgea-joifi.dtb` | 11:10 |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 11:21 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Remote host closed the connection) | 11:24 | |
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 11:25 | |
*** alex_b <alex_b!~alex_b@62.26.159.81> has quit IRC (Quit: Client closed) | 11:35 | |
mckoan | wyre: the names have to be identical | 11:35 |
pasherring | Hey yoctoers! I have a quirky make based project, in which the Makefile is not in the root dir. Is there a proper way to append the do_compile[dirs] variable from the recipe itself? | 11:36 |
pasherring | tried do_compile[dirs] =+ " ${B}/path/to/Makefile" to no avail | 11:38 |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 11:44 | |
qschulz | pasherring: just set B variable accordingly? | 11:44 |
rburton | pasherring: worst case, do_compile() { oe_runmake -C ${B}/path/to/makefile } | 11:45 |
rburton | default do_compile is just oe_runmake, so just pass -C | 11:46 |
rburton | adding that -C to OE_EXTRAMAKE should work nicely | 11:46 |
rburton | erm EXTRA_OEMAKE | 11:47 |
rburton | its early ;) | 11:47 |
LetoThe2nd | rburton: its always beer o'clock! | 11:47 |
rburton | but as qschulz said, if *all* of the build happens under a directory, setting B works just as well | 11:47 |
pasherring | Alright! Both easier than getting an extra compile dir :) Thanks a bunch! | 11:50 |
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto | 11:54 | |
*** Guest11 <Guest11!~Guest11@137.220.68.120> has joined #yocto | 12:13 | |
Guest11 | Hello! | 12:13 |
Guest11 | Still here:/ | 12:13 |
Guest11 | Is no one else seeing issues with the mirror? | 12:13 |
Guest11 | http://downloads.yoctoproject.org/mirror/sources/git2_github.com.opencv.opencv_3rdparty.git.tar.gz | 12:13 |
*** ilunev <ilunev!~koolkhel@80.72.17.178> has joined #yocto | 12:14 | |
ilunev | Hello! Is there a way to enable pretty-print support for gcc@yocto? So that gdb prints std::vector etc nicely? I found some gdb scripts but they are really slow | 12:15 |
rburton | Guest11: known infra problems. set PREMIRRORS="" to not use it. | 12:16 |
ilunev | ah, looks like I can just use python for this | 12:25 |
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 12:25 | |
wyre | would it be possible to include a custom U-Boot env in the .wic image file? 🤔 I'm not sure if I should do also a .bbappend for the u-boot recipe .. | 12:34 |
*** kroon_ <kroon_!~kroon@89-253-118-72.customers.ownit.se> has quit IRC (Remote host closed the connection) | 12:39 | |
*** kroon_ <kroon_!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto | 12:39 | |
*** cambrian_invader <cambrian_invader!~cambrian_@50-195-82-171-static.hfc.comcastbusiness.net> has quit IRC (Ping timeout: 252 seconds) | 12:40 | |
Guest11 | rburton Thank you for confirming! I PREMIRROR and MIRROR set to "" 🙇 | 12:43 |
*** alex_b <alex_b!~alex_b@62.26.159.81> has joined #yocto | 12:45 | |
*** alex_b <alex_b!~alex_b@62.26.159.81> has quit IRC (Quit: Client closed) | 12:52 | |
hmw[m] | how do i add libmysqlclient.so to my target ? | 12:53 |
qschulz | hmw[m]: oe-pkgdata-util find-path '*libmysqlclient.so*' | 12:54 |
qschulz | if nothing's returned by this command | 12:54 |
qschulz | you need to find out which recipe builds this file | 12:55 |
qschulz | likely mysql/mariadb? | 12:55 |
hmw[m] | returns libmysqlclient-dev : /usr/lib/libmysqlclient.so | 12:55 |
hmw[m] | so IMAGE_INSTALL += " libmysqlclient-dev " | 12:55 |
rburton | yes | 12:56 |
qschulz | hmw[m]: mmmm | 12:56 |
qschulz | likely not what you want | 12:56 |
rburton | well | 12:56 |
qschulz | you would want the versioned library in your image | 12:56 |
rburton | are you asking as you want to compile code and link | 12:56 |
qschulz | which is libmysqlclient.so.X.Y.Z | 12:56 |
qschulz | (replace X,Y,Z) | 12:56 |
qschulz | except if some other prebuilt binary/lib is requesting this unversioned lib | 12:57 |
hmw[m] | don´t cair (qt sql is not working without it ) | 12:57 |
rburton | you'll want the runtime version, libmysqlclient, probably | 12:57 |
rburton | if qtsql opens the development link then its very, very stupid | 12:57 |
*** selff <selff!~selff@static.171.105.217.95.clients.your-server.de> has joined #yocto | 12:58 | |
selff | Hi, guys. I have been dealing with this problem for 2 weeks, do you have any ideas or suggestions? https://stackoverflow.com/questions/71335803/executable-gives-different-fps-values-in-yocto-and-raspbianeverything-looks-th | 12:58 |
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto | 12:59 | |
rburton | try building opencv manually on the rpi to see if its being cross compiled that is the problem | 12:59 |
rburton | building opencv properly is non-trivial and its possible that nobody cared enough to check that opencv is configured right on rpi | 13:00 |
*** akiCA <akiCA!~akiCA@user/akica> has joined #yocto | 13:00 | |
hmw[m] | qschulz tnx rburton tnx | 13:01 |
*** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 240 seconds) | 13:03 | |
selff | rburton did you write the comment for me? | 13:04 |
rburton | selff: yes | 13:04 |
*** codavi <codavi!~akiCA@user/akica> has joined #yocto | 13:07 | |
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 13:08 | |
selff | rburton i didnt fully understand what you meant. the yocto image contains opencv. do i have to install it in runtime and try? | 13:09 |
rburton | if you want to debug where the performance difference comes from, that's what I suggest | 13:10 |
*** akiCA <akiCA!~akiCA@user/akica> has quit IRC (Ping timeout: 240 seconds) | 13:10 | |
selff | rburton thanks for the help, i will share the latest status after installing and testing opencv in runtime on yocto side. | 13:12 |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 13:13 | |
*** rsalveti <rsalveti!uid117878@id-117878.uxbridge.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 13:16 | |
*** argonautx <argonautx!~argonautx@i5E867343.versanet.de> has joined #yocto | 13:27 | |
*** kroon_ <kroon_!~kroon@89-253-118-72.customers.ownit.se> has quit IRC (Quit: Leaving) | 13:35 | |
Guest11 | Is there a way to enable timestamps for bitbake console-latest.log ? | 13:37 |
*** grma <grma!~gruberm@80.93.38.128> has quit IRC (Ping timeout: 256 seconds) | 13:38 | |
*** Guest11 <Guest11!~Guest11@137.220.68.120> has quit IRC (Quit: Connection closed) | 13:43 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 13:50 | |
*** Guest11 <Guest11!~Guest11@137.220.68.120> has joined #yocto | 13:51 | |
Guest11 | rburton ah I didn't think this through. Now a number of other dependencies are failing because they don't exist upstream anymore | 13:52 |
*** Guest11 <Guest11!~Guest11@137.220.68.120> has quit IRC (Client Quit) | 13:54 | |
*** selff <selff!~selff@static.171.105.217.95.clients.your-server.de> has quit IRC (Quit: Client closed) | 13:56 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 272 seconds) | 13:59 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 14:12 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 14:21 | |
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Client Quit) | 14:21 | |
*** chep <chep!~chep@82-65-36-115.subs.proxad.net> has quit IRC (Read error: Connection reset by peer) | 14:25 | |
*** chep <chep!~chep@82-65-36-115.subs.proxad.net> has joined #yocto | 14:26 | |
*** chep <chep!~chep@82-65-36-115.subs.proxad.net> has quit IRC (Read error: Connection reset by peer) | 14:28 | |
*** chep <chep!~chep@82-65-36-115.subs.proxad.net> has joined #yocto | 14:29 | |
*** ilunev <ilunev!~koolkhel@80.72.17.178> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 14:56 | |
*** Tokamak <Tokamak!~Tokamak@166.205.152.97> has quit IRC (Ping timeout: 240 seconds) | 15:00 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Ping timeout: 240 seconds) | 15:03 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 15:06 | |
*** Tokamak <Tokamak!~Tokamak@166.205.152.97> has joined #yocto | 15:07 | |
*** ahs3 <ahs3!~ahs3@user/ahs3> has quit IRC (Quit: Ex-Chat) | 15:08 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Ping timeout: 252 seconds) | 15:10 | |
*** sstiller <sstiller!~sstiller@p200300f07f1383006ea5d3f959e43361.dip0.t-ipconnect.de> has quit IRC (Remote host closed the connection) | 15:13 | |
*** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 15:14 | |
*** Tokamak <Tokamak!~Tokamak@166.205.152.97> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 15:18 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 15:37 | |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 15:45 | |
*** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Read error: Connection reset by peer) | 15:45 | |
*** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 15:45 | |
*** cambrian_invader <cambrian_invader!~cambrian_@50-195-82-171-static.hfc.comcastbusiness.net> has joined #yocto | 15:46 | |
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 15:53 | |
*** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Ping timeout: 240 seconds) | 15:55 | |
vvn | Shouldn't we include packagegroup-machine-base in INITRAMFS_SCRIPTS by default? | 15:59 |
vvn | like if a machine has an encrypted rootfs partition, one would likely add cryptsetup to MACHINE_EXTRA_RDEPENDS if they follow the guidelines | 16:01 |
khem | that will suck-in all kernel modules etc. which might be too much for a initramfs kernel | 16:01 |
vvn | khem: only the modules described by the machine as necessary to boot such critical partitions | 16:02 |
vvn | that you do want in the initramfs | 16:02 |
vvn | if I have a luks2+btrfs rootfs, I am supposed to set MACHINE_EXTRA_RDEPENDS = "cryptsetup" MACHINE_EXTRA_RRECOMMENDS = "kernel-module-btrfs", these are part of packagegroup-machine-base and I do need to duplicate that in the initramfs | 16:03 |
vvn | one could argue that this is a distro choice, but it becomes critical to successfully boot a system | 16:06 |
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:601a:fd8e:29b:1901> has quit IRC (Remote host closed the connection) | 16:18 | |
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:4d1e:9f71:7a24:92e> has joined #yocto | 16:18 | |
*** nerdboy <nerdboy!~nerdboy@47.143.129.141> has joined #yocto | 16:23 | |
*** geoffhp <geoffhp!~geoff@cpe-107-185-48-203.socal.res.rr.com> has quit IRC (Remote host closed the connection) | 16:24 | |
khem | you want those called out explicitly in initramfs image with PACKAGE_INSTALL | 16:27 |
khem | these images should be minimal | 16:28 |
khem | its easy to build ground up. | 16:30 |
*** amitk <amitk!~amit@103.208.69.77> has quit IRC (Ping timeout: 240 seconds) | 16:31 | |
vvn | khem: I think what's missing is DISTRO_ESSENTIAL_EXTRA_RDEPENDS/RRECOMMENDS and have packagegroup-core-boot depends on split packagegroup-machine-boot and packagegroup-distro-boot. | 16:34 |
khem | introducing another abstraction and variable does need to have some benefits. So If I can blindly build a common initramfs image that will boot every board and is lean and mean, I do see benefits but I think we are not there | 16:39 |
smurray | there's also room for some potential for wackiness with vendor BSPs throwing piles of stuff into MACHINE_EXTRA* that you might not want in an initramfs | 16:41 |
smurray | s/potential for/potential/ | 16:41 |
vvn | I see | 16:46 |
vvn | that ends up being a distro configuration in fact | 16:47 |
vvn | and thus only packagegroup-distro-base may be safe to rely on, if the distro wants to add it to INITRAMFS_SCRIPTS | 16:47 |
vvn | The confusing part is that most of the packagegroup-*base* groups are in fact machine specific | 16:48 |
vvn | or packagegroup-machine-base, assuming the distro carefully control what the BSP layer put in there | 16:52 |
*** kevinrowland <kevinrowland!~kevinrowl@104.129.199.51> has joined #yocto | 16:52 | |
*** rfuentess <rfuentess!~rfuentess@static-5-51-117-151.ftth.abo.bbox.fr> has quit IRC (Remote host closed the connection) | 16:59 | |
smurray | vvn: the choice of luks2+btrfs is not a machine thing in my mind, so tying it to the distro somehow would be the way to go | 17:00 |
vvn | smurray: definitely | 17:01 |
vvn | I think I'm trying to hard to rely on a well configured distro in order to simply build core-image-minimal-initramfs and core-image-base for my machines, but it looks like explicit images are always preferred. | 17:02 |
vvn | But specific image recipes tend to introduce machine-specific bits and I don't like this much | 17:03 |
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 17:05 | |
*** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 240 seconds) | 17:09 | |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 17:10 | |
*** mckoan is now known as mckoan|away | 17:10 | |
smurray | vvn: poky is an example/sample, at some point defining your own packagegroups for your own distro is perfectly reasonable. I suspect there a lot of downstream distros that don't use core-base and its packagroups | 17:11 |
alejandrohs | I got someone asking me about running the mount command inside a bitbake task, which returns some permission error, my guess is its because of pseudo, the only thing I can think of is sort of removing pseudo from the environment and run sudo, which sounds like a bad idea, Does anyone have any good ideas on how to achieve something like that? | 17:14 |
rburton | i'm terrified to ask why you'd mount in a task | 17:20 |
rburton | remember even if you call sudo you can't enter a password | 17:20 |
fray | Ya, equally terrified | 17:20 |
*** peoliye <peoliye!~peoliye@54-240-198-36.amazon.com> has joined #yocto | 17:20 | |
fray | you can avoid pseudo in specific tasks.. but mounting a disk requires specific permissions, ones that you really shouldn't trust in the build environment | 17:21 |
peoliye | I have two kernel modules A & B which I am building using separate recipes. I am able to build A successfully but B is failing. It is failing because it is not able to find the exports symbols from A. I tried this https://stackoverflow.com/questions/68567412/how-to-use-exported-symbol-on-another-kernel-module but that doesn't help. Any clues? I | 17:22 |
peoliye | also tried giving explicit KBUILD_EXTRA_SYMBOLS to the exact path of Module.symvers but that didn't help either. | 17:22 |
peoliye | It is failing during MODPOST. | 17:22 |
*** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has quit IRC (Ping timeout: 240 seconds) | 17:24 | |
rburton | alejandrohs: and pseudo isn't enabled so is basically passthrough in most tasks, so it shouldn't get in the way if the user has rights to mount without any ACLs involved | 17:26 |
RP | Anyone around who fancies talking through a parser multiprocessing deadlock? | 17:27 |
vvn | smurray: really? wouldn't that seem weird to reinvent the wheel and define your own base package groups? Like the init manager, all modules, etc. | 17:31 |
Saur[m] | RP: Happy to listen, but not sure how much help I can be. | 17:31 |
*** rsalveti <rsalveti!uid117878@id-117878.uxbridge.irccloud.com> has joined #yocto | 17:33 | |
alejandrohs | hahaha believ me I dont like it either | 17:34 |
alejandrohs | thanks rburton fray | 17:35 |
smurray | vvn: sttuf like that is in core-boot. It's the base/base-extended packagegroups that I suspect are perhaps not widely used. e.g. we don't use them in AGL | 17:35 |
vvn | alejandrohs: what are you trying to achieve with mount exactly? | 17:35 |
alejandrohs | vvn: not sure what theyre trying to do tbh, I think they want to mount an image and modify it in some way | 17:36 |
vvn | alejandrohs: you should ask, because you might actually be able to add the tweak before of after depending on the tool, filesystem type, etc. | 17:37 |
RP | Saur[m]: There is basically a race/hang in the parsing code if there is any kind of unclean shutdown (i.e. force=True in the code). The reason is the lock for the event pipe to the event handlers since the parsing processes write directly to the UIs | 17:37 |
vvn | smurray: I see. So basically your AGL image recipes have IMAGE_INSTALL = "packagegroup-core-boot packagegroup-agl-foo packagegroup-agl-bar" I presume | 17:39 |
RP | Saur[m]: the issue is the self.wlock in ConnectionWriter. If we call .terminate on a parsing process that happens to be in the log writer, game over, everything hangs | 17:39 |
RP | We can remove the terminate codepath but then we can't Ctrl+C out of parsing | 17:39 |
smurray | vvn: yep | 17:39 |
fray | Is there any way to make the lock 'clear' on exit (of the process that holds the lock)? | 17:40 |
smurray | vvn: though there are a couple of image's that are included to act as a base. It's on my todo list to redo some of it to have an e.g. agl-image.bbclass | 17:40 |
alejandrohs | RP: does that mean that cntrl+c wont have an immediate effect while parsing? or that cntrl+c would just be ignored? | 17:40 |
RP | alejandrohs: at the moment the UI sees it and sends commands to the server to say "stop parsing" | 17:41 |
fray | Or is the issue the process trying to exit holds the lock already? | 17:41 |
RP | fray: given the locks python is using, even if the processes are totally gone, the lock is locked | 17:41 |
RP | and even if we could unlock it, the pipe would have corruption potentially | 17:42 |
fray | any way for the terminating process to clear the lock just before exit (if held by itself)? | 17:42 |
RP | fray: the worry is if it is in the middle of a write | 17:42 |
fray | anyway to declare something a critical section, not permit (ctrl-c) termination during a _short_ window? | 17:43 |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 17:44 | |
fray | something like a signal handler, catch teh sigint, and if a 'critical seciton' bit is selected, return back to the code -- otherwise complete the exit.. then inside the program set/clear the flag (quickly)? | 17:44 |
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 17:45 | |
RP | fray: I'm wondering if we can do the opposite. Rewire SIGINT so that breaks out the parse but would be deferred in the locked section | 17:45 |
RP | (and then send SIGINT to the child parsers if we need to shutdown) | 17:46 |
fray | ok | 17:46 |
RP | The trouble is we only want this behaviour in the parsing child processes which makes things ugly code wise | 17:49 |
*** Minvera2 <Minvera2!~Minvera@user/Minvera> has joined #yocto | 17:51 | |
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection) | 17:51 | |
RP | A reproducer: https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/t222&id=105631fc314fe8a236496cebae680e344f13f251 then put something like INCOMPATIBLE_LICENSE += "*" in local.conf | 17:52 |
RP | all that does is puts a really slow event at the end of parsing | 17:52 |
RP | so the slow events + parsing error == hang | 17:52 |
RP | out the box there are a load of zombies but even with that cleaned up, the lock isn't freed and still game over | 17:53 |
Saur[m] | RP: Is the problem that the ConnectionWriter.close() method closes the pipe under the .send() method? I.e., shouldn't the .close() method take the wlock before doing the close? | 17:56 |
Saur[m] | (I have absolutely no idea how the multiprocessing class works, so just ignore if it is too stupid a question.) | 17:57 |
RP | Saur[m]: closing it should be fine, you shouldn't need a lock for that | 17:57 |
Saur[m] | Ok. | 17:58 |
RP | the lock is just stopping writes being interleaved on the pipe | 17:58 |
vvn | smurray: you mean that you have agl-image-base.bb and agl-image-foo.bb which require agl-image-base.bb? | 18:05 |
smurray | vvn: sort of, we have a agl-image-minimal.bb and agl-image-weston.bb that are used as the base of the more featured agl-demo-*bb images | 18:06 |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 18:07 | |
*** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 18:08 | |
vvn | smurray: I'm pretty sure an agl.bbclass with IMAGE_CLASSES += "agl" would be more than enough to pull in packagegroups via agl-* image features, like agl-ui. | 18:08 |
smurray | vvn: we had a lot of packagegroups for various profiles and functionality things, but we've started reducing those as they weren't really providing enough value | 18:08 |
smurray | vvn: yeah, we'll likely end up with a bbclass, but it's somewhat of a low priority just atm. Downstream use by AGL members is pretty opaque to us, my current assumption is they all build their own images up, so we can be wasting our time trying to overbuild packagegroups | 18:10 |
vvn | smurray: true, so far the packagegroup seems nice just to centralize the view of your complete software stack in a simple packagegroup-foo.bb file, and eventually making it easy to pull them in and declare conflicts with image features. | 18:10 |
fray | Looking for an idea. I've got a package (lm_sensors) that I want the systemd service enabled by default on _one_ board, but not another.. and I'd rather not make the package machine specific. Is there any standard way (in the machine) to enable a service by default? | 18:11 |
smurray | vvn: yeah, that seems a reasonable take | 18:12 |
*** pasherring_ <pasherring_!~pasherrin@37.189.72.207> has joined #yocto | 18:12 | |
*** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:4d1e:9f71:7a24:92e> has quit IRC (Remote host closed the connection) | 18:14 | |
Saur[m] | fray: ROOTFS_POSTPROCESS_COMMAND? | 18:14 |
fray | I wasn't aware of a way to use a rootfs postprocess toc ontrol a service.. | 18:15 |
smurray | rm the preset file? | 18:15 |
smurray | or change it to say disabled | 18:16 |
fray | ya, service file is disabled by default... so all the boards, except one should have it that way.. | 18:17 |
smurray | it might be possible to drop in an override for the systemd presets under /etc/systemd, could do that for the different machine | 18:17 |
fray | which is why I'm struggling for the one board where I want it enabled | 18:17 |
Saur[m] | I haven't tried it myself, but I think it should be possible to run the native systemctl from a postprocess for the board you want. | 18:17 |
Saur[m] | Or what smurray said. | 18:18 |
smurray | perhaps easier to just make the symlink in the rootfs postprocess | 18:18 |
fray | I'll see if I can do it on the rootfs side.. thanks | 18:19 |
smurray | fray: another option that comes to mind, though likely a bit messy, would be to enable the service by default, but split the bit(s?) for that out via an extra package | 18:21 |
*** argonautx <argonautx!~argonautx@i5E867343.versanet.de> has quit IRC (Quit: Leaving) | 18:24 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 18:34 | |
*** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 18:38 | |
*** pasherring_ <pasherring_!~pasherrin@37.189.72.207> has quit IRC (Quit: Leaving) | 18:43 | |
*** Mike23 <Mike23!~Mike23@cpe90-146-41-24.liwest.at> has joined #yocto | 19:12 | |
*** geoffhp <geoffhp!~geoff@cpe-107-185-48-203.socal.res.rr.com> has joined #yocto | 19:15 | |
*** sgw <sgw!~swold_loc@user/sgw> has quit IRC (Remote host closed the connection) | 19:15 | |
*** Mike23 <Mike23!~Mike23@cpe90-146-41-24.liwest.at> has quit IRC (Quit: Client closed) | 19:36 | |
*** florian_kc <florian_kc!~florian@dynamic-093-131-007-203.93.131.pool.telefonica.de> has joined #yocto | 19:43 | |
vvn | fray: the less hacky is indeed SYSTEMD_AUTO_ENABLE:${PN}:machinefoo = "enable", or as Saur[m] suggested, maybe make it image specific with a ${IMAGE_ROOTFS}/etc/systemd/system/default.target.wants/lm_sensors.service -> /usr/lib/systemd/system/lm_sensors.service symlink via ROOTFS_POSTPROCESS_COMMAND. | 19:50 |
vvn | fray: you might as well append the lm_sensors package to add a drop-in file to make the service run conditionally on the presence of a kernel command line or whatever can identity your machine, then enable the service by default | 19:52 |
vvn | e.g. ConditionKernelCommandLine=foobar in the [Unit] section or ExecCondition=/some/id-script in the [Service] section. | 19:53 |
vvn | this way you don't make the package machine-specific, but you make the service "smarter" to run under your conditions | 19:54 |
fray | I'm losing my mind, where is the systemctl binary that is used to enable things? If I try to use the qemu_wrapper_cmdline in the ROOTFS_POSTPROCESS_COMMAND function, it fails every time | 20:16 |
fray | complains that it can't get root for a chroot?! | 20:17 |
fray | So my question, how do I run 'systemctl enable fancontrol.service' in a ROOTFS_POSTPROCESS_COMMAND properly? (Premably I need --root=${IMAGE_ROOTFS} as well | 20:18 |
fray | I can't figure out how this even works in the package installs | 20:18 |
vvn | fray: you don't. systemctl is for runtime, for compile time systemd is file based, just do a standard symlink. You might prefer to add a drop-in file in the package to run the service conditionally. Read the documentation for SYSTEMD_AUTO_ENABLE and maybe man systemd.unit as well. | 20:37 |
fray | No systemctl _IS_ available, it's used by postinstall scriptlets | 20:39 |
fray | I think I have ti working now.. I've no idea what I did wrong the first time, but now just calling systemctl --root=${IMAGE_ROOTFS} enable fancontrol.service is working fine | 20:41 |
vvn | whatever suits you, it's essentially doing the same thing | 20:44 |
zeddii | It's always better to not poke directly at systemd's symlinks if possible. chaos and madness. | 20:47 |
*** Minvera2 <Minvera2!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection) | 21:00 | |
*** behanw <behanw!uid110099@id-110099.uxbridge.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 21:04 | |
*** florian_kc <florian_kc!~florian@dynamic-093-131-007-203.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 21:08 | |
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 21:25 | |
*** florian_kc <florian_kc!~florian@dynamic-093-131-007-203.93.131.pool.telefonica.de> has joined #yocto | 21:35 | |
*** goliath <goliath!~goliath@user/goliath> has joined #yocto | 22:09 | |
*** florian_kc <florian_kc!~florian@dynamic-093-131-007-203.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 22:10 | |
*** grma <grma!~gruberm@80.93.38.128> has joined #yocto | 22:36 | |
*** otavio <otavio!~otavio@201-3-135-79.user3p.brasiltelecom.net.br> has quit IRC (Remote host closed the connection) | 23:58 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!