| *** GillesM <GillesM!~gilles@228.100.5.84.rev.sfr.net> has joined #yocto | 00:25 | |
| *** GillesM <GillesM!~gilles@228.100.5.84.rev.sfr.net> has quit IRC (Remote host closed the connection) | 00:25 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 00:41 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 00:44 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 256 seconds) | 00:59 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 00:59 | |
| *** Guest23 <Guest23!~Guest23@103.126.24.15> has joined #yocto | 01:02 | |
| *** Guest23 is now known as zw | 01:02 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Ping timeout: 250 seconds) | 01:04 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #yocto | 01:05 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 01:15 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:21 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Remote host closed the connection) | 01:32 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 01:35 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Remote host closed the connection) | 01:42 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 01:42 | |
| tlwoerner | i'm seeing quilt errors: "File series fully applied, ends at patch <patch>" | 01:49 |
|---|---|---|
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds) | 01:50 | |
| tlwoerner | i can clear them out by doing a cleaning, but they come back again a day or so later | 01:50 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 01:51 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 01:55 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 02:01 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:07 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 02:17 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 02:18 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 256 seconds) | 02:19 | |
| *** camus1 is now known as camus | 02:19 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 02:20 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 256 seconds) | 02:21 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:26 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 02:28 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 02:47 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 02:54 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 02:58 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 240 seconds) | 03:00 | |
| *** camus1 is now known as camus | 03:00 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 03:01 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:02 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Quit: Ping timeout (120 seconds)) | 03:11 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:11 | |
| *** kanavin_ <kanavin_!~Alexander@62.117.23.44> has joined #yocto | 03:17 | |
| *** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Ping timeout: 240 seconds) | 03:18 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Quit: Ping timeout (120 seconds)) | 03:20 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:20 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 240 seconds) | 03:26 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:28 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Quit: Ping timeout (120 seconds)) | 03:35 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:35 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Quit: Ping timeout (120 seconds)) | 03:46 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:46 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Quit: Ping timeout (120 seconds)) | 03:53 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:53 | |
| *** jclsn74 <jclsn74!~jclsn@213.21.36.205.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:59 | |
| *** jclsn7 <jclsn7!~jclsn@149.224.120.218.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 260 seconds) | 04:01 | |
| *** jclsn74 is now known as jclsn7 | 04:01 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 04:24 | |
| *** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has quit IRC (Ping timeout: 240 seconds) | 04:34 | |
| *** amitk <amitk!~amit@103.59.74.129> has joined #yocto | 04:53 | |
| *** zw <zw!~Guest23@103.126.24.15> has quit IRC (Quit: Client closed) | 05:14 | |
| *** nemik <nemik!~nemik@162-245-20-117.PUBLIC.monkeybrains.net> has joined #yocto | 05:19 | |
| *** geoffhp <geoffhp!~Geoff@207.154.79.70> has quit IRC (Ping timeout: 250 seconds) | 05:52 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 06:01 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Quit: alessioigor) | 06:07 | |
| *** cb5r <cb5r!~cb5r@user/cb5r> has joined #yocto | 06:22 | |
| *** mixfix41 <mixfix41!~homefame@user/mixfix41> has quit IRC (Ping timeout: 240 seconds) | 06:24 | |
| *** mixfix41 <mixfix41!~homefame@user/mixfix41> has joined #yocto | 06:36 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Remote host closed the connection) | 06:49 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 06:49 | |
| jclsn[m] | Morning, any idea how to fix this?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/471b495473034c10159381c10926ab6511c7c836) | 07:01 |
| jclsn[m] | Think this happens since I fetched the latest commits from linux-fslc | 07:01 |
| *** hoba <hoba!~hoba@165.225.72.86> has joined #yocto | 07:02 | |
| jclsn[m] | I already tried `bitbake -c cleanall libxkbcommon` | 07:02 |
| *** tre <tre!~tre@ip5f5886dd.dynamic.kabel-deutschland.de> has joined #yocto | 07:03 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 07:04 | |
| *** hoba <hoba!~hoba@165.225.72.86> has quit IRC (Quit: Client closed) | 07:15 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 07:19 | |
| *** Etheryon <Etheryon!~textual@79.113.77.204> has joined #yocto | 07:24 | |
| *** frieder <frieder!~frieder@i59F72694.versanet.de> has joined #yocto | 07:33 | |
| *** mckoan|away is now known as mckoan | 07:42 | |
| mckoan | good morning | 07:42 |
| *** rob_w <rob_w!~rob@2001:a61:605d:cd01:d44e:13ad:7b79:ce8d> has joined #yocto | 07:43 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 07:49 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds) | 07:51 | |
| *** camus1 is now known as camus | 07:51 | |
| *** tgamblin_ <tgamblin_!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has joined #yocto | 07:57 | |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has quit IRC (Ping timeout: 240 seconds) | 07:58 | |
| *** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto | 08:12 | |
| jclsn[m] | Really weird error. Happens with mesa and wayland-utils as well. Something must have changed in meta-freescale again | 08:12 |
| jclsn[m] | If I interpret it right, something in the SDK is missing | 08:12 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has joined #yocto | 08:14 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.254> has quit IRC (Client Quit) | 08:15 | |
| kroon | huh. just got "ERROR: Worker process (943374) exited unexpectedly (1), shutting down..." in up2date dunfell | 08:23 |
| *** dev1990 <dev1990!~dev@78.9.136.196> has joined #yocto | 08:25 | |
| *** michalkotyla <michalkotyla!~quassel@84-10-27-202.static.chello.pl> has quit IRC (Quit: michalkotyla) | 08:28 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.45> has quit IRC (Ping timeout: 240 seconds) | 08:31 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.62> has joined #yocto | 08:33 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 08:37 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 08:45 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Remote host closed the connection) | 08:54 | |
| dwagenk | jclsn: when packaging shows weird errors I usually get rid of TMPDIR and rebuild from sstate. I remember one occasion where even that wasn't enough and I switched from `PACKAGE_CLASSES = "package_rpm"` to `PACKAGE_CLASSES = "package_deb"`, rebuild and then switched back to fix it. I couldn't reproduce that Issue, otherwise I'd have written a bug-report. | 08:56 |
| dwagenk | ^ jclsn | 08:56 |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.62> has quit IRC (Ping timeout: 250 seconds) | 08:58 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 08:58 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.134> has joined #yocto | 09:00 | |
| *** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has joined #yocto | 09:08 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:10 | |
| *** Habbie <Habbie!peter@lorentz.7bits.nl> has joined #yocto | 09:28 | |
| *** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:228d:ee61:fbb7:9bb8> has joined #yocto | 09:35 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4b12:b100:24d7:51ff:fed6:906d> has joined #yocto | 09:52 | |
| jclsn[m] | <dwagenk> "jclsn: when packaging shows..." <- Thanks, I tried deleting tmp | 10:21 |
| jclsn[m] | Currently I am having device tree issues with linux-fslc though. It reports syntax errors, although the same tree has always worked in the past | 10:22 |
| jclsn[m] | Seems that the device tree include syntax with `#include` is not accepted anymore | 10:32 |
| jclsn[m] | Has something in `devicetree.bbclass` changed? | 10:35 |
| kroon | the dts needs to go through cpp for "#include" to work | 10:45 |
| *** osama3 <osama3!~osama@eth1-fw1-nbg6.eb.noris.de> has joined #yocto | 10:48 | |
| jclsn[m] | kroon: Yes, I read that, but haven't really changed anything | 11:09 |
| jclsn[m] | Also the imx8mm.dtsi uses this syntax | 11:10 |
| jclsn[m] | So it seems to be normal syntax in meta-freescale | 11:11 |
| jclsn[m] | or linux-fslc | 11:11 |
| *** meego <meego!~meego@2001:41d0:fe7e:c800:ac5a:af08:91fd:3db3> has joined #yocto | 11:20 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 11:24 | |
| jclsn[m] | I recently fetched the upstream changes from linux-fslc. Something must have changed there | 11:26 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 11:27 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 11:36 | |
| RP | Saur[m]: I merged your changes but sadly a test failure slipped through in all the patch juggling. I'm hoping my tweaks help resolve it | 11:37 |
| Etheryon | Hello, I'm trying to install a local RPM, but I get this error when running the recipe. cpio: /opt: Cannot change mode to rwxr-xr-x: Operation not permitted (in additino to others Permission denied) any idea how I can investigate this? | 11:39 |
| kanavin_ | Etheryon, where is the rpm coming from? | 11:45 |
| Etheryon | downloaded from a website | 11:50 |
| Etheryon | it's an external tool for which the company provides rpm for installation | 11:51 |
| kanavin_ | Etheryon, you can't install random rpms onto yocto images | 11:53 |
| kanavin_ | Etheryon, that rpm was build for a specific distribution, probably RHEL or Fedora, and isn't meant for yocto | 11:53 |
| kanavin_ | Etheryon, is the source code for the tool available? | 11:54 |
| Etheryon | nop, commercial tool | 11:54 |
| Etheryon | OK, thanks, I'll look into another way of installing it | 11:55 |
| pgowda_ | Downloaded latest master sources and ran bitbake meta-toolchain | 12:00 |
| pgowda_ | binutils-cross-x86_64-2.38-r0 do_fetch is running for more than 2 hrs (unusually) | 12:00 |
| pgowda_ | Tried on 2 machines with same issue | 12:00 |
| pgowda_ | Plz let me know if anyone else is facing same issue | 12:00 |
| *** otavio <otavio!~otavio@201-3-135-79.paemt705.dsl.brasiltelecom.net.br> has joined #yocto | 12:03 | |
| Etheryon | If I have a shell script that's an installer, should I run it in my recipe in do_install ? | 12:07 |
| kanavin_ | Etheryon, yes, if the shell script can be directed to install to ${D} | 12:14 |
| kanavin_ | otherwise, run the script outside of yocto, then make a tarball of what it writes out | 12:14 |
| kanavin_ | then put the tarball to SRC_URI | 12:14 |
| kanavin_ | Etheryon, even then, the tool is probably using specific shared libraries, which yocto may not be able to provide | 12:15 |
| Etheryon | I've looked in the rpm, and it seems it's a java app, so I'm hoping it's fairly self-contained? | 12:15 |
| Etheryon | ugh, seems like the shellscript also ends up trying to install an rpm package | 12:20 |
| rburton | see if it has a 'just unpack the contents' option | 12:21 |
| *** tre <tre!~tre@ip5f5886dd.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 240 seconds) | 12:21 | |
| rburton | (installers are the worst) | 12:21 |
| Etheryon | seems to do this eventually. - installCmd="rpm -U --replacepkgs --oldpackage '$packageFilePath'" | 12:22 |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 12:22 | |
| Etheryon | and runs it | 12:22 |
| rburton | *worst case* create a 'rpm' script that just does exit 0, and put it in PATH before running the installer | 12:22 |
| rburton | is this a hand-written installer, or is it generated by a tool? | 12:23 |
| Etheryon | can I reverse engineer the rpm and install it manually? Sorry I haven't worked with packages before | 12:23 |
| rburton | i'm guessing the installer is one of those where its a giant shell script with the binaries embedded in it | 12:23 |
| Etheryon | I'm guessing by a tool | 12:23 |
| Etheryon | yeah seems so | 12:23 |
| Etheryon | .pkg__commencement | 12:23 |
| Etheryon | xar! | 12:24 |
| Etheryon | � | 12:24 |
| Etheryon | contains that | 12:24 |
| Etheryon | so I'm back to square one | 12:24 |
| rburton | is this public? | 12:24 |
| RP | Etheryon: if you have an rpm, I'd just try and extract the files manually and see if they're usable | 12:24 |
| Etheryon | so the rpm has got 2 jars in it and a shell script file | 12:25 |
| RP | I think the rpm2cpio.sh script in scripts/ in oe-core may help create something you can get files from out of an rpm | 12:25 |
| rburton | put the rpm in src_uri, bitbake will unpack it for you, ignore the installer, just put the jars in the right place | 12:26 |
| Etheryon | when I tried that I got that permission error I mentioned earlier | 12:29 |
| Etheryon | cpio: /opt: Cannot change mode to rwxr-xr-x: Operation not permitted | 12:29 |
| Etheryon | cpio: Cannot mkdir: Permission denied | 12:30 |
| RP | It sounds like it is is trying to extract the files into the main host OS root filesystem :( | 12:30 |
| Etheryon | eventually cpio -id failed with return value 2 | 12:30 |
| RP | Etheryon: you could try manually extracting the files using the rpm2cpio.sh script. It is possible the rpm extraction code isn't working properly :/ | 12:30 |
| RP | Etheryon: it doesn't get used often and problbably doesn't have good tests :( | 12:31 |
| landgraf | rpm2cpio *rpm | cpio -id should work | 12:31 |
| landgraf | if it doesn't... something wrong with the rpm I guess | 12:31 |
| RP | something like an ;unpack=0 in the SRC_URI should stop bitbake trying to do it for you which may be where the error comes from | 12:32 |
| Etheryon | should that extract it in the local folder? | 12:32 |
| RP | check the manual for the right param, I'm not 100% sure | 12:32 |
| landgraf | yes, it should extract under curdir | 12:33 |
| * landgraf uses it almost daily | 12:33 | |
| *** tre <tre!~tre@ip5f5886dd.dynamic.kabel-deutschland.de> has joined #yocto | 12:33 | |
| landgraf | Etheryon: https://dpaste.com/9JVAGELC7 like this | 12:35 |
| Etheryon | same error, I'm guessing they hard-coded the paths? | 12:35 |
| landgraf | is it public rpm? | 12:35 |
| landgraf | I mean can I find it somewhere? | 12:36 |
| * landgraf is interested how it's possible | 12:36 | |
| landgraf | Etheryon: rpm2tgz should create tgz archive and then you can take a look what's inside | 12:37 |
| landgraf | Etheryon: or maybe rpm -qpl <name>.rpm will give you some clues. | 12:38 |
| Etheryon | ok - rpm2archive + extract gave me the tree which is supposed to be installed I guess | 12:42 |
| Etheryon | seems to contain the same paths as the error messages I was getting earlier | 12:42 |
| Etheryon | I guess I can use that via bitbake? | 12:43 |
| Etheryon | and rpm -qpl lists the file tree | 12:44 |
| smurray | my guess is that rpm has a post-install that's trying to touch /opt, so you'll likely always have issues with it | 12:44 |
| *** mckoan is now known as mckoan|away | 12:45 | |
| Etheryon | it had files that it wants to put in /opt | 12:45 |
| Etheryon | how could I check for this post-install script? | 12:45 |
| landgraf | smurray:: rpm -qp --scripts ? | 12:45 |
| landgraf | Etheryon: ^ | 12:46 |
| landgraf | smurray: sorry | 12:46 |
| smurray | or look at the .spec file after rpm2cpio or the like | 12:46 |
| landgraf | smurray: it can be a problem if you don't have spec :) | 12:46 |
| smurray | is it possible to not have a spec file in a rpm? | 12:47 |
| smurray | I've never pulled one apart that didn't have one, I've always believed rpm needed it | 12:48 |
| Etheryon | the archive extracted doesn't contain one | 12:48 |
| smurray | that seems odd to me | 12:48 |
| smurray | anyways, I'd say just take jar files and install them yourself with your own recipe as has been suggested by others | 12:48 |
| RP | smurray: do the rpms we generate contain the spec? that seems odd to me FWIW | 12:48 |
| smurray | RP: yes? There's always a generated one in the workdir | 12:49 |
| landgraf | smurray: iirc spec is part of src.rpm not the binary one | 12:49 |
| landgraf | smurray: for proprietary rpms you may not have spec (zoom, chrome etc) | 12:50 |
| smurray | hrm, true, it could be that only RedHat/Fedora/etc. include them | 12:50 |
| Etheryon | so this is that rpm2archilve + unarchinve resulted in: https://dpaste.com/3N6MX83QS | 12:50 |
| Etheryon | so is it enough to copy over the contents of this archive? | 12:51 |
| RP | smurray: we generate one and use it to build the rpm but it isn't included in the rpms themselves | 12:51 |
| smurray | RP: okay, TIL ;) | 12:52 |
| smurray | Etheryon: you'll have to see what all those shared libraries expect to be able to link to, as kanavin_ mentioned earlier | 12:53 |
| landgraf | Etheryon: most likely your rpm tries to own /opt and chmod it which is not good idea obviously. If it's done in %files section it's a problem. if it's %post you can try to install with noscript option (man page should mention this, iirc there's posibility) | 12:53 |
| landgraf | it's --noscripts | 12:54 |
| Etheryon | postinstall scriptlet (using /bin/sh): <- is this what I'm looking for? from the rpm -qp --scripts ouput | 12:57 |
| cb5r | How do I get the correct compiler flag values for -march and -mcpu? I am trying to compile an old project with newer SDK and am getting the following error now: "switch '-mcpu=cortex-a9' conflicts with '-march=armv7-a' switch" | 12:59 |
| landgraf | Etheryon: yes | 12:59 |
| smurray | RP: heh, I need coffee, thinking about it, it's been src.rpm's from RedHat/Fedora/etc. that I've pulled apart with rpm2cpio in the past | 13:01 |
| landgraf | smurray: yup. it was | 13:04 |
| landgraf | :) | 13:04 |
| cb5r | NVM - I found the solution: Remove -march because its redundant anyway if compiling for a specific -mcpu. Nevertheless, I find the error message confusing... | 13:05 |
| pasherring | Hey there! Is it possible to clean sstate for recipes from a given layer? | 13:05 |
| qschulz | pasherring: why would you need to do this? cleansstate is the last resort and should rarely be used. If something breaks the sstate-cache, it needs to be fixed :) | 13:10 |
| pasherring | qschulz, probably this has to do with my messed up workflow. I am trying to understand the meta-virtualization for rpi4, and I need to "swap" layers, from stock to some custom layer. And whenever I swap them, I notice that the changes go unoticed. :/ | 13:12 |
| pasherring | Also, I know I am probably doing something wrong xD But, I really want to understand the meta-virt and xen for the rpi4. So, probing is really the only way I found to "move forward" | 13:13 |
| qschulz | pasherring: if the change in the metadata (layers) is undetected, cleaning the sstate-cache won't help you | 13:16 |
| pasherring | oh well :/ | 13:17 |
| qschulz | pasherring: how do you do the swap of layers? | 13:18 |
| pasherring | qschulz, changing the bblayers.conf | 13:18 |
| qschulz | pasherring: the bblayers from which directory? | 13:20 |
| qschulz | I seem to recall that some vendor provide their own bblayers.conf file with an install script to run before starting a build, hence the question | 13:20 |
| *** tgamblin_ <tgamblin_!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has quit IRC (Quit: Leaving) | 13:20 | |
| pasherring | qschulz, right, from build/conf/bblayers.conf | 13:20 |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has joined #yocto | 13:21 | |
| *** lorenzo <lorenzo!~lorenzo@host-178-107-253-87.isiline.org> has joined #yocto | 13:28 | |
| lorenzo | Hi! I want to append a recipe that has a do_install_append that install some sample application. I am now compiling without these sample applications, so my objective is to create a .bbappend that changes that do_install_append. Is there a way to stop it from trying to install files that do no exists? | 13:31 |
| lorenzo | Have you ever faced a similar situation? | 13:32 |
| smurray | lorenzo: my usual approach there is to rm the files from ${D} in my own bbappend | 13:40 |
| lorenzo | smurray: sorry i was not clear. the issue is that the original recipe is installing also the samples like this "cp -f bin/example_* ${D}${datadir}/samples/bin/". The issue is that i have modified the compilation flags so that the samples are not created, thus the install task fails because it cannot find them. | 13:44 |
| lorenzo | While i was writing, i realized that instead of changing the compile flags and can simply delete them after they have been installed (as you suggested) | 13:44 |
| lorenzo | Thank you | 13:44 |
| Etheryon | theoretically if I copy over the files, and all dependencies are met, and I do in do_install what the script for postinstall does, it should work? | 13:45 |
| smurray | lorenzo: the other hack I could maybe see is to do_install_prepend to touch those files so the rm doesn't fail | 13:46 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 13:51 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 13:56 | |
| lorenzo | smurray: I ended up touching a dummy file in the _prepend() and later deleting the whole folder in _append(). THank you very much! | 13:57 |
| smurray | lorenzo: you're welcome, good luck with your project | 14:00 |
| meego | apologies if this question already pops up often here: anyone knows where i could buy a few CM4? I've already checked a dozen distributors and they're all out of stock | 14:02 |
| meego | arf, wrong irc channel sorry :p | 14:03 |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC (Remote host closed the connection) | 14:17 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 14:18 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 14:24 | |
| *** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 14:27 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 14:27 | |
| *** SSmoogen is now known as Ebeneezer_Smooge | 14:29 | |
| *** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC (Quit: Leaving) | 14:29 | |
| smurray | meego: I check this now and again: https://rpilocator.com/ | 14:43 |
| meego | smurray: that's super helpful, thanks! | 14:44 |
| *** emrius_the_secon <emrius_the_secon!~emrius_th@93-35-191-21.ip56.fastwebnet.it> has joined #yocto | 14:52 | |
| emrius_the_secon | and here I am | 14:52 |
| emrius_the_secon | Strange, when using limechat OSX IRC client I'm getting an error... see #oe channel. However it seems to work from the web client *shrug* | 14:56 |
| smurray | that error indicates the channel has the flag set that only clients coming in over a SSL/TLS connection can join, I assume you need to change the server connection settings in your client | 14:59 |
| *** lorenzo <lorenzo!~lorenzo@host-178-107-253-87.isiline.org> has quit IRC (Quit: Client closed) | 14:59 | |
| emrius_the_secon | smurray thanks! I tried enabling SSL but the error persists. Hmm... nevermind, it works through the browser client | 15:01 |
| emrius_the_secon | Anyways, the cause that brought me here is the `pip_install_wheel` class which I tried to port back to dunfell. You may have seen this issue already so, I'm really sorry to bother again but I'd love to see this working and I feel that I'm just missing a detail <3 | 15:02 |
| emrius_the_secon | https://stackoverflow.com/questions/71268956/bitbake-recipe-pulling-from-pypi-runs-into-timeout/71274111?noredirect=1#comment126037788_71274111 | 15:02 |
| *** cb5r <cb5r!~cb5r@user/cb5r> has quit IRC (Quit: cb5r) | 15:07 | |
| *** cb5r <cb5r!~cb5r@user/cb5r> has joined #yocto | 15:08 | |
| moto-timo | emrius_the_secon: you need DEPENDS += “python3-aiohttp-native” if it is a build error | 15:08 |
| emrius_the_secon | So, the issue I'm having is that the fetcher exists just fine. So, I'm guessing the wheel file has been fetched. I tried to grep the problem and find the wheel but couldn't. I'm wondering if somebody knows where it should be located | 15:08 |
| emrius_the_secon | moto-timo thanks! I tried that but that didn't get me further. | 15:09 |
| moto-timo | You will not be able to backport wheels to dunfelll… way to invasive | 15:09 |
| *** rob_w <rob_w!~rob@2001:a61:605d:cd01:d44e:13ad:7b79:ce8d> has quit IRC (Quit: Leaving) | 15:09 | |
| emrius_the_secon | ok! Now, that is a clear perspective that I\ve been waiting for :) | 15:10 |
| moto-timo | this is why we are working so hard to get wheels into kirkstone (the next LTS) | 15:10 |
| emrius_the_secon | ah ok! I'm really looking forward to that as it will be a great improvement! Thanks for the hard work!!! | 15:11 |
| emrius_the_secon | The alternative approach I was taking is this https://stackoverflow.com/questions/71268618/how-to-create-recipe-from-sourcebranch-other-than-master-using-recipetool/71276365?noredirect=1#comment126030823_71276365 | 15:12 |
| emrius_the_secon | see the comments beneath the answer by rober.berger | 15:12 |
| emrius_the_secon | Especially this error stack trying to apply the auto-generated recipe (after some minor modifications) | 15:12 |
| emrius_the_secon | https://pastebin.com/nf0FY9sZ | 15:12 |
| *** alimon <alimon!~alimon@189.172.89.153> has quit IRC (Ping timeout: 252 seconds) | 15:13 | |
| emrius_the_secon | Apparently, during installation `view.py` from the sources is executed which then attempts to import `aiohttp`. At installation time. Which left me a bit confused. Does anybody have a hint how to move forward with this? | 15:14 |
| emrius_the_secon | Let me add the `pytyhon3-aiohttp-native` again to see the exact error stack... wait a sec | 15:15 |
| emrius_the_secon | Ah right (sorry about the confusion - there has been quite a bit of back and forth trying to make this work). When adding `DEPENDS += "python3-aiohttp-native"` this dependency can't be found. So, I'm not sure if I can just add a `PROVIDES += "python3-aiohttp-native"` to my python3-aiohttp recipe. But what actually surprises me is that this is a | 15:21 |
| emrius_the_secon | hard installation dependency. I'm really wondering why | 15:21 |
| moto-timo | BBCLASSEXTEND = “native” | 15:24 |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 15:24 | |
| moto-timo | Not PROVIDES | 15:25 |
| emrius_the_secon | Dang! right! | 15:25 |
| emrius_the_secon | Hang on | 15:25 |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto | 15:26 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 15:27 | |
| *** alimon <alimon!~alimon@189.172.33.189> has joined #yocto | 15:28 | |
| *** Thorn <Thorn!~Thorn@user/thorn> has quit IRC (Ping timeout: 260 seconds) | 15:30 | |
| *** vladest1 <vladest1!~Thunderbi@2001:1715:9d9c:c530:4f40:1f28:c9e1:8a81> has joined #yocto | 15:30 | |
| *** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:212c:b736:642c:42b7> has quit IRC (Ping timeout: 240 seconds) | 15:32 | |
| *** vladest1 is now known as vladest | 15:32 | |
| *** Thorn <Thorn!~Thorn@user/thorn> has joined #yocto | 15:33 | |
| emrius_the_secon | Ok, that seems to slowly let me proceed. I need to go through a couple of python dependencies and add the BBCLASSEXTEND="native". What I'm wondering however is: Why aren't all recipes extending bbclass "native" by default? | 15:38 |
| moto-timo | No one needed it yet | 15:38 |
| emrius_the_secon | Ah ok. That adds to my strange gut feeling wondering why this recipe needs that. Anyways, I'll patch a couple of recipes accordingly to see where this will take me | 15:39 |
| emrius_the_secon | moto-timo thank you! | 15:39 |
| moto-timo | And native and nativesdk can add complexity, so not guaranteed to just work | 15:39 |
| emrius_the_secon | Ok I'll give it a first try then I guess | 15:40 |
| moto-timo | Upstream module devs do some very strange things sometimes… this might be one of thos odd corner cases | 15:42 |
| tlwoerner | RP: i've been seeing lots of quilt errors on master lately: "File series fully applied, ends at patch <patch>" | 15:45 |
| tlwoerner | is that the openSUSE issue you've been seeing on the AB? | 15:45 |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC (Remote host closed the connection) | 15:46 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 15:46 | |
| emrius_the_secon | moto-timo that seems to work! I need to patch about 10 other recipes to provide the native packages but seems to do the job. Thanks! | 15:49 |
| RP | tlwoerner: no :/ | 15:50 |
| dwagenk | Hi. I'm currently trying to build an ext-sdk and it fails due to some of the layers not being in the same parent directory as COREBASE. The file doing the layer-copying (meta/lib/oe/copy_buildsystem.py) uses paths relative to COREBASE and seems to assume all layers are either in TOPDIR or in the same parent directory as COREBASE. Is my layer structure wrong, or is copy_buildsystem.py to narrow in what it accepts? | 15:50 |
| RP | not sure which suse issue you mean :/ | 15:50 |
| RP | but I've not seen that error | 15:50 |
| tlwoerner | RP: okay i'll investigate/bisect. it's intermittent so... you know | 15:51 |
| RP | dwagenk: nobody has generalised that code I suspect, an eSDK needs to combine everything together which is tricky | 15:51 |
| RP | tlwoerner: all too well | 15:51 |
| tlwoerner | RP: also, so far i've only seen it in my jenkins builds, i haven't seen it on the cmdline, but that might just be a coincidence | 15:51 |
| moto-timo | emrius_the_secon: please send patches for master to fix those recipes | 15:52 |
| moto-timo | emrius_the_secon: after that , backport can be considered | 15:53 |
| *** emrius_the_secon <emrius_the_secon!~emrius_th@93-35-191-21.ip56.fastwebnet.it> has quit IRC (Ping timeout: 256 seconds) | 15:55 | |
| dwagenk | @RP Yes, I see that. I've got a patch that would fix my problems and be more general, but at the cost of flattening the directory-structure, e.g. sdk/layers/meta-openembedded/meta-oe -> sdk/layers/meta-oe and sdk/layers/meta-openembedded/meta-networking -> sdk/layers/meta-networking, basically reverting OE-Core rev: 5a59a6997f41e606d088e3e86812de56f72f543b | 15:55 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 15:58 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC (Remote host closed the connection) | 15:58 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 15:58 | |
| *** Dhruvag2000[m] <Dhruvag2000[m]!~dhruvag2k@2001:470:69fc:105::1:784> has quit IRC (Quit: You have been kicked for being idle) | 16:00 | |
| *** alvaropg[m] <alvaropg[m]!~alvaropgm@2001:470:69fc:105::1:1996> has quit IRC (Quit: You have been kicked for being idle) | 16:00 | |
| *** grembeter[m] <grembeter[m]!~grembeter@2001:470:69fc:105::1:4e8e> has quit IRC (Quit: You have been kicked for being idle) | 16:00 | |
| *** osama3 <osama3!~osama@eth1-fw1-nbg6.eb.noris.de> has quit IRC (Ping timeout: 272 seconds) | 16:01 | |
| *** meego <meego!~meego@2001:41d0:fe7e:c800:ac5a:af08:91fd:3db3> has quit IRC (Quit: Leaving...) | 16:03 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 16:05 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 16:06 | |
| *** tre <tre!~tre@ip5f5886dd.dynamic.kabel-deutschland.de> has quit IRC (Remote host closed the connection) | 16:21 | |
| RP | dwagenk: I worried that change might cause problems :( | 16:35 |
| *** gsalazar <gsalazar!~gsalazar@194.38.148.130> has joined #yocto | 16:35 | |
| *** cb5r <cb5r!~cb5r@user/cb5r> has quit IRC (Quit: cb5r) | 16:36 | |
| *** florian_kc <florian_kc!~florian@dynamic-002-244-037-236.2.244.pool.telefonica.de> has joined #yocto | 16:37 | |
| landgraf | Etheryon: it should work but doesn't look like right way | 16:40 |
| *** florian_kc <florian_kc!~florian@dynamic-002-244-037-236.2.244.pool.telefonica.de> has quit IRC (Quit: Ex-Chat) | 16:51 | |
| *** florian <florian!~florian@dynamic-002-244-037-236.2.244.pool.telefonica.de> has joined #yocto | 16:51 | |
| *** osama3 <osama3!~osama@213.138.50.122> has joined #yocto | 17:08 | |
| * Ch^W_ has a hard time not seeing Armbian as yet another example of https://xkcd.com/927/ | 17:11 | |
| *** Etheryon <Etheryon!~textual@79.113.77.204> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…) | 17:22 | |
| *** osama3 <osama3!~osama@213.138.50.122> has quit IRC (Ping timeout: 256 seconds) | 17:29 | |
| khem | 1: gettext-0.21-r0 do_configure - 10m6s (pid 1891836) | 17:29 |
| khem | and still going | 17:29 |
| khem | 13m10s it took | 17:33 |
| RP | khem: it is known to be slow | 17:33 |
| khem | yeah luckily not many images need target gettext | 17:33 |
| khem | its probably worth looking into speeding it up sometimes | 17:34 |
| RP | khem: isn't an easy thing to fix :( | 17:41 |
| khem | hmmm | 17:44 |
| khem | yes I guessed so too | 17:44 |
| *** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 17:53 | |
| *** frieder <frieder!~frieder@i59F72694.versanet.de> has quit IRC (Remote host closed the connection) | 18:00 | |
| *** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:228d:ee61:fbb7:9bb8> has quit IRC (Remote host closed the connection) | 18:01 | |
| *** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:228d:ee61:fbb7:9bb8> has joined #yocto | 18:02 | |
| *** pasherring <pasherring!~pasherrin@2001:8a0:ec55:b200:228d:ee61:fbb7:9bb8> has quit IRC (Remote host closed the connection) | 18:08 | |
| RP | Ch^W_: https://github.com/armbian/build#compare-with-industry-standards did make me laugh at "very slow" | 18:08 |
| kergoth | That's not accurate imo. Getting started isn't slow, it's the learning curve to go from beginner to a higher level of expertise that's slow | 18:10 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 18:10 | |
| *** florian <florian!~florian@dynamic-002-244-037-236.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 18:12 | |
| RP | kergoth: agreed, just made me laugh | 18:16 |
| khem | Getting started - very slow | 18:16 |
| khem | I think the real matrix should be time to finish line 🙂 | 18:19 |
| khem | getting into mess is quite quick everyone knows that, key is how easy is it to get out | 18:19 |
| moto-timo | The long tail to deep understanding is long indeed | 18:41 |
| *** starblue <starblue!~juergen@dslb-188-100-137-041.188.100.pools.vodafone-ip.de> has joined #yocto | 18:47 | |
| *** florian <florian!~florian@dynamic-002-244-037-236.2.244.pool.telefonica.de> has joined #yocto | 18:48 | |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC (Quit: Leaving) | 18:53 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 19:02 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 19:05 | |
| dwagenk | RP: I solved the eSDK relative layer path problem and submitted a patch just now. My local eSDK build works fine now. | 19:08 |
| *** jclsn7 <jclsn7!~jclsn@213.21.36.205.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 272 seconds) | 19:18 | |
| khem | dwagenk: thanks for the patch, it helps with some custom distros to generate eSDK | 19:22 |
| *** jclsn7 <jclsn7!~jclsn@149.233.193.21.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 19:22 | |
| *** amitk <amitk!~amit@103.59.74.129> has quit IRC (Ping timeout: 272 seconds) | 19:26 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 19:35 | |
| kanavin_ | halstead, is there any movement with the AUH email issue? I've seen some mails from bots on the mailing lists, but AUH still isn't able to get through | 19:37 |
| halstead | kanavin_: If it's still unresolved now is the time to fix it. | 19:40 |
| kanavin_ | halstead, this is the current config | 19:41 |
| kanavin_ | # SMTP server | 19:41 |
| kanavin_ | smtp=mail.yoctoproject.org:25 | 19:41 |
| kanavin_ | # from whom should the mails arrive | 19:41 |
| kanavin_ | from=auh@yoctoproject.org | 19:41 |
| kanavin_ | # who should get the status mail with statistics, at the end | 19:41 |
| kanavin_ | status_recipients=openembedded-core@lists.openembedded.org | 19:41 |
| kanavin_ | # who should be CCd with upgrade emails | 19:41 |
| kanavin_ | cc_recipients=openembedded-core@lists.openembedded.org | 19:41 |
| halstead | kanavin_: It's fixed for the AB via sendmail. Those smtp settings will work but not for the lists. | 19:42 |
| halstead | kanavin_: I might be able to fix this without changes on your end. Let me try. | 19:43 |
| kanavin_ | halstead, I was wondering if I should change the server to localhost:25 there | 19:43 |
| halstead | kanavin_: not every worker is listening on localhost | 19:45 |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 19:48 | |
| RP | dwagenk: thanks. I think we may need to get some better tests for this... | 20:08 |
| fray | Does anyone know if a 'git-lfs' (native or nativesdk) recipe exists? I didn't find one, but I may have been looking in the wrong place | 20:18 |
| fray | (I have a repository that uses git-lfs, and it doesn't seem to work via the buildtools..) | 20:19 |
| sgw | zeddii: how much do you know about depmod? Changing the debug generation for kernel modules seems to have triggered an issue when they are installed in an image and depmod finds both <module>.ko and .debug/<module>.ko, which causes depmod to fail. A workaround would be for depmod to ignore .debug directories, thoughts? | 20:19 |
| fray | sgw, or move the debug modules into a different path | 20:20 |
| sgw | fray, yeah that would be another possiblity with having to change depmod, have a rootfs-postprocess that runs to move the /lib/modules/.../.debug/ files someplace | 20:21 |
| sgw | without having to change kmod, is what I meant. | 20:21 |
| fray | I was going to say, fix the package function that splits the binaries.. and move the split modules somewhere else.. | 20:22 |
| fray | there may already be a config switch for the path.. | 20:22 |
| fray | or at least a limited set of places that need modification | 20:23 |
| sgw | fray, that's some of the code that I changed for the SBOM to enable, but I don't think there's a switch to change the location. | 20:24 |
| fray | split happens to: | 20:28 |
| fray | dest = dv["libdir"] + os.path.dirname(src) + dv["dir"] + "/" + os.path.basename(src) + dv["append"] | 20:28 |
| fray | so dir and append can be modified | 20:28 |
| fray | https://git.yoctoproject.org/poky/tree/meta/classes/package.bbclass#n1068 | 20:28 |
| fray | default values are set here | 20:28 |
| fray | I don't see anything specific to kernel mdoules in that list, but it would certainly be easy to add something there and in the function "splitdebugfile" function for kernel modules | 20:29 |
| fray | we used to have some stuff there for special cases already | 20:29 |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has quit IRC (Read error: Connection reset by peer) | 20:29 | |
| fray | (i.e. there is a splitstaticdebuginfo already.. would be reasonable to do a kernel module if something special was needed) | 20:30 |
| sgw | Yeah, looking at that again, it might work | 20:30 |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::3a92> has joined #yocto | 20:30 | |
| sgw | We used to have kernel specific to skip the split/strip, which I removed for SBOM manglement | 20:30 |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::3a92> has quit IRC (Remote host closed the connection) | 20:32 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds) | 20:41 | |
| kanavin_ | halstead, let me know when I can test it then | 20:48 |
| zeddii | sgw: w0t fray said | 20:49 |
| halstead | kanavin_: Alright. | 20:53 |
| halstead | kanavin_: Not yet. Its a bit more difficult then I expected. I might switch to localhost and install MTAs on all the workers. I'll let you know. | 20:56 |
| RP | halstead: if it helps we could limit the workers we run auh on | 20:57 |
| RP | fray: there was something horrible about git-lfs which meant a recipe wasn't easy. I can't remember what now though | 20:58 |
| halstead | RP: That would make it easier. I'll grab a list. | 20:58 |
| fray | git-lfs requires go | 20:59 |
| halstead | RP: For now what if we limit to AUH the Alma workers? | 20:59 |
| kanavin_ | halstead, I don't mind that | 21:03 |
| RP | halstead: I'll defer to kanavin_ | 21:04 |
| RP | fray: that would be it :) | 21:04 |
| fray | ya, after I asked I found the go thing.. I suspect 'nativesdk' go is a complete mess [if it even exists] | 21:06 |
| RP | fray: last time this came up we didn't have go in core | 21:07 |
| fray | Ya, as far as I'm concerned it's not there either.. I REALLY have no desire to try to make this work right now | 21:09 |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0::3a92> has joined #yocto | 21:12 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4b12:b100:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection) | 21:17 | |
| Ch^W_ | RP: I am always amused by that impression... | 21:23 |
| halstead | kanavin_: If you change settings to point at localhost:25 and only run on the Alma workers that would be a good test. | 21:32 |
| kanavin_ | halstead, let me first try a manual test, then I will submit a patch for the auh config | 21:32 |
| * halstead has to run out for a bit. | 21:32 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.134> has quit IRC (Ping timeout: 240 seconds) | 21:32 | |
| *** vd <vd!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.4) | 21:33 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.188.181> has joined #yocto | 21:34 | |
| kanavin_ | halstead, sadly the email didnt show up on the oe-core list | 21:38 |
| kanavin_ | >>> smtp = SMTP('localhost', 25) | 21:39 |
| kanavin_ | >>> smtp.sendmail('auh@yoctoproject.org','alex.kanavin@gmail.com','test email from AUH') | 21:39 |
| kanavin_ | {} | 21:39 |
| kanavin_ | >>> smtp.close() | 21:39 |
| kanavin_ | the above works | 21:39 |
| kanavin_ | >>> smtp = SMTP('localhost', 25) | 21:39 |
| kanavin_ | >>> smtp.sendmail('auh@yoctoproject.org','openembedded-core@lists.openembedded.org','test email from AUH') | 21:39 |
| kanavin_ | {} | 21:39 |
| kanavin_ | >>> smtp.close() | 21:39 |
| kanavin_ | and this does not | 21:39 |
| kanavin_ | (that's python's prompt) | 21:39 |
| kanavin_ | I'm on alma8-ty-1 | 21:39 |
| kanavin_ | let me also try to send a 'well formed' email | 21:42 |
| halstead | kanavin_: okay. If that fails I'll check into it after my appointment. Anything wrong with the from address will block it | 21:43 |
| halstead | And I might need to allow that address again on the mailing list. Afk for an hour or so though. | 21:44 |
| *** vd <vd!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has joined #yocto | 21:47 | |
| kanavin_ | halstead, looks like it went through \0/ | 21:48 |
| kanavin_ | halstead, let me know if auh config should be changed to use localhost:25 then | 21:50 |
| halstead | I think that's the best way for now. | 22:04 |
| kanavin_ | RP: I'm slightly confused with https://git.yoctoproject.org/yocto-autobuilder2/tree/config.py#n135 - none of these workers exist anymore. How is e.g. selftest-fedora then assigned to fedora workers? | 22:09 |
| kanavin_ | RP: trying to figure out if pinning AUH to alma from this file (further down) would actually work | 22:09 |
| *** gsalazar <gsalazar!~gsalazar@194.38.148.130> has quit IRC (Ping timeout: 256 seconds) | 22:11 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC (Ping timeout: 256 seconds) | 22:29 | |
| *** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto | 22:38 | |
| RP | kanavin_: we leave the old distros as a record of what we once did with older releases | 22:40 |
| RP | kanavin_: workers_wine is a good example of what you need | 22:41 |
| RP | kanavin_: oh, there may be a more up to date config on the controller :/ | 22:41 |
| *** vd <vd!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.4) | 22:43 | |
| *** vd <vd!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has joined #yocto | 22:43 | |
| RP | kanavin_: pushed. There is already a workers_auh | 22:45 |
| *** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection) | 22:52 | |
| * RP feels happier we have a nearly green build again | 23:00 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Quit: Client closed) | 23:00 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 23:19 | |
| *** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 23:22 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 23:26 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Remote host closed the connection) | 23:38 | |
| *** florian <florian!~florian@dynamic-002-244-037-236.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 256 seconds) | 23:47 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 23:47 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!