Wednesday, 2021-11-10

*** GillesPP <GillesPP!~gilles@12.131.115.78.rev.sfr.net> has quit IRC (Quit: Leaving)00:00
*** florian <florian!~florian@dynamic-078-048-024-041.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds)00:05
*** BCMM <BCMM!~BCMM@user/bcmm> has joined #yocto00:17
*** BCMM <BCMM!~BCMM@user/bcmm> has quit IRC (Client Quit)00:17
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:53c9:cd00:12bf:48ff:feb8:38c8> has quit IRC (Ping timeout: 245 seconds)00:45
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)00:51
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has joined #yocto00:59
*** mvlad <mvlad!~mvlad@2a02:2f08:4d01:ef00:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)01:20
*** qschulz_ <qschulz_!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Read error: Connection reset by peer)01:32
*** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto01:34
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 264 seconds)01:51
*** chep <chep!~chep@88.168.197.200> has quit IRC (Ping timeout: 256 seconds)02:20
*** chep <chep!~chep@88.168.197.200> has joined #yocto02:22
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.)02:27
*** chep <chep!~chep@88.168.197.200> has quit IRC (Ping timeout: 250 seconds)02:35
*** chep <chep!~chep@88.168.197.200> has joined #yocto02:40
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto02:42
*** linkliu59 <linkliu59!~user_name@139.198.118.108> has quit IRC (Remote host closed the connection)02:46
*** pgowda_ <pgowda_!uid516182@id-516182.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)02:53
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Read error: Connection reset by peer)03:03
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto03:04
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…)03:22
paulgreading that "workflow" thread (via lore) - had no idea github/lab place so little value on the commit log until I read what kanavin wrote.  That seems broken IMHO.  Many times the commit log is as important  as the change itself.03:30
paulghttps://lore.kernel.org/all/CANNYZj8_zPhh_XCZrxaPvXd_Oz5kzbzHNLvT6qzvtztquKA0ew@mail.gmail.com/03:30
paulgTake that cgroup thing that was screwing the LTP runs of the AB for us this summer.  It really was just a one line fix.03:34
paulghttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e7107c5ef03:34
paulgBut without that commit log laying out wtf was going on, the change would have been (a) worthless and (b) never accepted.03:35
paulgI want to read stuff in 5-10 years - long after I've forgot what I did, and be able to understand it as if seeing it for the 1st time.03:37
jaskij[m]<paulg> "reading that "workflow" thread..." <- That is true. When looking at a typical GH/GL workflow, you do not look at individual commits in a PR, but rather the whole set of changes. Which then naturally leads to squashing the branch with something more sensible.03:38
jaskij[m]Which is entirely different from a mailing list workflow. In fact, in a mailing list workflow it would make sense to work on a local branch when testing stuff, squash it to a different branch and git-format-patch that for the e-mail03:39
paulgNot sure what you mean by "squash" in this context.03:43
jaskij[m]So you could argue that, so long as the pull/merge commit is fine, the rest is irrelevant (and for a large project, squashes are IMO necessary)03:43
jaskij[m]paulg: Take all the commits in a branch and reapply them on top of master/main as a single new commit. With possibly new commit message.03:44
paulgpeople do that?   Wow.03:45
paulgso you've thrown away the baseline for which the work was developed/tested (which a merge preserves) because you implicitly rebased to a new baseline - AND you throw away any details that the author of the original changes thought were relevant03:47
jaskij[m]My bad. Squash reapplies on the same base03:48
jaskij[m]Just that it replaces all the commits with one03:48
jaskij[m]Also, it depends on how people treat commits.03:49
jaskij[m]Okay, I'm underslept and my mind is in my code. Haven't used squash much so unsure about the rebase03:51
paulgsquash in "git rebase -i" context was  meant to fold a tweak/fixup into a larger commit.   If people are using it to junk all history - well that is just wrong.03:51
jaskij[m]Mhm. OTOH having a clean commit history requires self discipline which I know not everyone has.03:54
paulgagain - not following your use of "history" here.03:55
paulga reference to someone who develops a patch series on a branch already polluted with other non-related changes?03:56
paulgor did you mean "clean commit logs" instead?03:56
paulgeither one is easily solved with simple basic and reasonable quality expectations enforced by the maintainer (or sub-maintainer)  of the (portion of the) project.03:59
jaskij[m]Clean logs. For me, as the developer, remembering to pause and make a clean commit is something that tears away my focus from the code. So that one commit can cost me a good half hour of work. There are other options - usually involving working out the commits backwards.04:01
paulgsure - nobody says you have to write a three page essay right then and there ; I expect most people might jot a couple key points/words they want to remember and then come and (re)write the logs once they are happy with the code and testing and think it is submit-worthy.  That just makes sense.  Nobody is suggesting you stop for  a half hour and lose focus.  Just that you don't get lazy and skip doing them at the end.04:04
paulgBecause when you write a commit log, you have to justify the change to others.  And if you find you can't do that in a convincing way - well you probably need to go back and take a 2nd look at what you've done.04:06
paulgI'm sure many times that has forced me to re-think things and consider alternate plans and it usually is for the better.04:07
jaskij[m]No argument there. Although, if you're pushing your WIP branch regularly, this does require `git push --force` - something I've mentally marked as forbidden. But that opinion is right now changing, because what is wrong with cleaning up history on a not-yet-merged branch?04:09
paulgmost kernel people I've seen (and myself included in that) simply  push "feature-ABC-v1" and then "feature-ABC-v2" etc etc.  -- unless you've already established with your consumers that there will be a daily non-fast forward reset of a WIP branch (like sfr's next/master for the kernel)04:12
paulg"rules" like no force push need to be understood from why they were recommended in the 1st place and not just blindly adhered to.04:13
jaskij[m]>  push "feature-ABC-v1"  and then "feature-ABC-v2"04:14
jaskij[m]as in separate branches with different histories04:14
jaskij[m] * >04:14
jaskij[m]push "feature-ABC-v1"  and then "feature-ABC-v2"04:14
jaskij[m]as in separate branches with different histories04:14
jaskij[m]paulg: True. And you made me realize that this is one of the rules I've internalized very early on and don't remember the rationale for - if there ever was one.04:15
paulgyes v1 and v2 ;sure.  Changed/improved hisory - maybe more commits.  And quite possibly different baselines too.  Then people can tell you  "I was using v1 and it worked fine, but v2 crashes. Unless you are somehow ashamed of the earlier versions, why hide it?04:17
paulgagain I'm a kernel person - so typically a feature manages to get "merge worthy" by v5 or so, after absorbing review feedback etc etc - -- assuming it isn't crazy complex04:18
paulgAnd then it gets *merged*  (and NOT REBASED onto master) which preserves the baseline which is CRITICAL for effective use of "git bisect".04:20
jaskij[m]I actually have yet to contribute, unfortunately. There are reasons, but let's not make this discussion about me. Actually, on that topic, is there a way to find some help wanted/beginner issues?04:22
jaskij[m]Because it's been sitting on my mind that I should contribute.04:22
paulgI guess it depends on your area of interest.   But the regular yocto status mailout has a paragraph in it that talks about bugs people can pick up if they are looking to get started and helping out.04:24
paulglet me see if I can find a link.   Unless someone else here beats me to it.04:24
paulghttps://lore.kernel.org/all/066701d7d580$b9390150$2bab03f0$@gmail.com/04:26
paulgBottom paragraph     "Ways to Contribute".04:26
jaskij[m]thanks04:27
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC (Quit: Leaving.)04:46
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:322e:2ab2:9dab:b57e> has quit IRC (Remote host closed the connection)04:59
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:322e:2ab2:9dab:b57e> has joined #yocto04:59
jaskij[m]to confirm: there is no way to enable kernel compression with FIT image, is there?05:13
*** tomzy <tomzy!~tomzy@89-64-98-6.dynamic.chello.pl> has quit IRC (Quit: Connection closed)05:25
*** chep <chep!~chep@88.168.197.200> has quit IRC (Ping timeout: 240 seconds)05:52
*** chep <chep!~chep@88.168.197.200> has joined #yocto05:58
*** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Remote host closed the connection)06:02
*** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto06:03
*** davidinux <davidinux!~davidinux@84.17.59.176> has joined #yocto06:05
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 276 seconds)06:11
*** Barry[m] <Barry[m]!~barryriot@2001:470:69fc:105::900> has quit IRC (Quit: Client limit exceeded: 20000)06:20
*** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto06:21
*** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has quit IRC (Quit: Client limit exceeded: 20000)06:22
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto06:32
*** chep <chep!~chep@88.168.197.200> has quit IRC (Ping timeout: 240 seconds)06:53
*** chep <chep!~chep@88.168.197.200> has joined #yocto06:56
*** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has quit IRC (Ping timeout: 256 seconds)06:58
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto07:04
*** Granjow <Granjow!~simon@xdsl-31-164-224-239.adslplus.ch> has joined #yocto07:20
JosefHolzmayrTheyo dudX07:32
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto07:40
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 260 seconds)07:42
*** camus1 is now known as camus07:42
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto07:43
GranjowHi again! I have a makefile based recipe and I additionally want to install a config file in that recipe. However when I use FILES:${PN}_append = "myconfigfile" and install it in do_install_append(), the default make task seems to be skipped. What would be the classical approach to extending a makefile based project?07:43
*** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has joined #yocto07:43
*** Barry[m] <Barry[m]!~barryriot@2001:470:69fc:105::900> has joined #yocto07:44
*** chep <chep!~chep@88.168.197.200> has quit IRC (Ping timeout: 240 seconds)07:45
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Ping timeout: 256 seconds)07:48
*** chep <chep!~chep@88.168.197.200> has joined #yocto07:49
*** chep <chep!~chep@88.168.197.200> has quit IRC (Client Quit)07:51
*** chep <chep!~chep@88.168.197.200> has joined #yocto07:53
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto07:56
*** zpfvo <zpfvo!~fvo@89.244.125.164> has joined #yocto08:00
*** nad <nad!~nad@pr-svc-em1-014.emea.corpinter.net> has joined #yocto08:08
*** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-07-184-145-217-104.dsl.bell.ca> has quit IRC (Quit: WeeChat 3.3-dev)08:12
*** mckoan|away is now known as mckoan08:13
*** goliath <goliath!~goliath@user/goliath> has joined #yocto08:15
*** chep <chep!~chep@88.168.197.200> has quit IRC (Ping timeout: 240 seconds)08:16
*** chep <chep!~chep@88.168.197.200> has joined #yocto08:19
*** tre <tre!~tre@ip5b4343c3.dynamic.kabel-deutschland.de> has joined #yocto08:20
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto08:27
kanavinpaulg, you really haven't used github properly yet? :D man you live in a bubble08:36
qschulzjaskij[m]: if the runtime U-Boot knows about which platform it is booted on, then please go for a fitimage. If not, then check if it's possible to add this detection to runtime (e.g. a GPIO/ADC/whatever). If not, then it depends, you can either build different U-Boots and insert in its environment which dtb to build from the kernel fitimage08:46
qschulztlwoerner: I switched to honister/master for now, I'll get back to dunfell once I have something for you. Turns out mailine UBoot is half broken for us :| (depends on the toolchain being used...)08:47
qschulztlwoerner: but while you're here, our board ha U-Boot proper at a different offset in the storage medium, why do we have two reserved partitions between the SPL (idbloader.img) and U-Boot proper in the wks?08:48
*** zpfvo <zpfvo!~fvo@89.244.125.164> has quit IRC (Ping timeout: 250 seconds)08:49
qschulzpaulg: what I also don't like about GitHub CI is that it does builds/tests on the last commit of the pull request (or the last commit after a push). Or at least in the "default" configuration (i'm new to github ci).08:50
jaskij[m]qschulz: What is wrong with going fitimage build time? ie, not one fitimage with two dtbs, but two different fitimages each with one of the dtbs. Hardware detection is unfortunately not possible, as it's the same baseboard with different SoMs. It is slightly hacky, but at least I keep everything in my BSP layer instead of in U-Boot.08:50
*** zpfvo <zpfvo!~fvo@89.244.125.164> has joined #yocto08:50
tlwoernerqschulz: http://rockchip.wikidot.com/partitions08:50
*** nad <nad!~nad@pr-svc-em1-014.emea.corpinter.net> has quit IRC (Ping timeout: 256 seconds)08:52
qschulzpaulg: also... yes, I've heard some projects squash many commits together *on purpose*. git commit logs are surprisingly really not cared about. and it's hard to force people to write good ones.08:52
qschulzjaskij[m]: you can have an Image.gz in there, I think U-Boot just detects it's compressed and uncompresses it before trying to load it08:52
JosefHolzmayrTheqschulz: s/force/cluebat/g08:52
qschulzpaulg: how does this branch-v1, branch-v2 works for github/gitlab based PR? Is there a way to make a PR use a different branch after it's been opened?08:53
jaskij[m]qschulz: I know I can, the question is how to tell Yocto to use Image.gz in fitImage.08:53
*** Bardon <Bardon!~Bardon@user/Bardon> has joined #yocto08:54
qschulzGranjow: if you have the new overrid syntax, you should have FILES:${PN}:append and do_install:append. if you have the old syntax, FILES_${PN}_append and do_install_append08:54
jaskij[m]qschulz: another hacky way, if the pins are otherwise unused, I can just use the DT with the WiFi and let the probe fail.08:54
qschulzjaskij[m]: what is different between the SoMs? U-Boot is running on the Som, not the carrierboard :)08:55
jaskij[m]WiFi08:55
jaskij[m]there's two SoM variants, one includes a CYW-based WiFi08:55
jaskij[m]they're otherwise identical08:55
jaskij[m]but U-Boot needs to know which DT to pass to the kernel08:56
qschulzUsually you have a way to distinguish HW at runtime based on HW configruation. If not, tell your HW dept to do it next time :)08:56
jaskij[m]"HW dept" - we're small enough that I do all the pinouts for SoMs :P08:57
qschulzjaskij[m]: one way would be to init the SDIO (I assume it's SDIO) card for the WiFi and read the SDIO_DEVICE_ID and SDIO_MANUFACTURER_ID and base your choice of dtb from there08:57
qschulzjaskij[m]: resistors populated or not on an ADC input pin is one way to do this, allows for a big amount of configurations to be described08:58
qschulzjaskij[m]: having two different fitimages just because you have two different dtb is not really using the benefits frm fitimages :) (almost using it as if it was a uImage :D)08:59
jaskij[m]I thought fitImages replaced uImages?08:59
jaskij[m]I'll verify with the EE, but it seems those SDIO pins are unused - so yes, I can probe, or just use the same DT and let the kernel probe fail09:00
qschulzjaskij[m]: I meant the WiFi module is connected to SDIO09:00
*** Pan5ky <Pan5ky!~Pan5ky@2a02:8109:8380:224:e8ab:f0c9:4bec:bd66> has joined #yocto09:00
qschulzalso..... I think you might be able to have one kernel with two SDIO devices in the SDIO controller device tree node09:01
qschulzbecause it matches against the SDIO_DEVICE_ID and SDIO_MANUFACTURER_ID to know which driver to probe09:01
qschulzso if your power-up sequence (mmc-pwrseq) is the same for both (same pins, same timings), you can do that09:02
jaskij[m]it's.... a stupid SoM design - the WiFi module is on the SoM and connected to the SoC, but at the same time signals are present on the SoM connector so you can use them if using a no-WiFi variant09:02
qschulzjaskij[m]: yeah it's not really important to know what;s going out of the SoM, you want to know what';s on the SoM (I assume nothing changes on the carrierboard?)09:03
jaskij[m]the other device tree, if it ever uses those pins, won't be using those pins for SDIO09:03
jaskij[m](SoM is external btw)09:04
jaskij[m]and yes, carrier is the same09:04
qschulztlwoerner: well... that's new :p especially since atf is not in a separate partition but in U-Boot09:05
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)09:06
*** dev1990 <dev1990!~dev@dynamic-78-8-166-98.ssp.dialog.net.pl> has joined #yocto09:07
qschulztlwoerner: I guess I'll go with a separate wks then?09:09
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto09:16
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Ping timeout: 268 seconds)09:25
*** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Remote host closed the connection)09:25
Granjowqschulz: Thanks, worked now! Yes, still using old syntax.09:26
tlwoernerqschulz: sounds good. i'd be interested in seeing it (and am curious why the standard rockchip one doesn't work)09:27
tlwoernerqschulz: are there docs you followed to get your layout?09:27
*** mihai <mihai!~mihai@user/mihai> has joined #yocto09:28
qschulztlwoerner: I'll ask HW dept which bootstrapped the support what was the reason for this :)09:29
*** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has joined #yocto09:29
tlwoernerthanks09:30
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto09:31
jaskij[m]qschulz: alternatively, is there a way to manipulate U-Boot environment from Yocto?09:33
jaskij[m]I couldn't quite find anything online09:33
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto09:34
qschulztlwoerner: It's pretty simple why it does not work, SPL needs to know where the U-Boot proper is stored and in our defconfig we have it at a different offset than other Rockchip boards (same for serial baudrate also)09:37
qschulzjaskij[m]: Not that I know no. I mean you can always modify the files from your U-Boot sources to adapt them. Otherwise, I think you could have different uEnv.txt or boot.scr files per board and use this as boot script and keep the U-Boot binary identical for both SoMs09:38
*** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto09:39
RPrburton: vim patches are fuzzy :/09:56
jaskij[m]`bitbake -c cleansstate mc:u504-sd{,-wifi}:gobject-introspection && bitbake mc:u504-sd{,-wifi}:gobject-introspection` fails for me :/ (mc is two different machines with same tune)09:57
jaskij[m]trying to repro on a machine from meta-freescale10:01
*** dev1990 <dev1990!~dev@dynamic-78-8-166-98.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!)10:06
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto10:15
rburtonRP: ooh i left a patch out10:23
*** nad <nad!~nad@pr-svc-em1-015.emea.corpinter.net> has joined #yocto10:23
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto10:25
rburtonRP: just posted a patch which should be before the one i posted originally10:26
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Read error: Connection reset by peer)10:36
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 264 seconds)10:36
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto10:36
RPrburton: thanks, will add and retest10:39
rburtonsorry about that10:39
RPrburton: np, it happens. Usually my patches :)10:41
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)10:42
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto10:54
qschulztlwoerner: "when we did the initial patchset we didn't know about this layout or it was not defined yet. for backwards compatibility reasons, we can't change it anymore."10:55
qschulztlwoerner: for the baudrate, they just wanted to follow "the industry standard" :)10:57
*** fleg <fleg!64bf4386e9@user/fleg> has joined #yocto11:02
JosefHolzmayrTheqschulz: 2400?11:12
qschulzJosefHolzmayrThe: I don't have the ref for this joke :|11:12
qschulzJosefHolzmayrThe: 11520011:13
JosefHolzmayrTheyou're just too young.11:13
qschulzJosefHolzmayrThe: apparently not enough to prefer Github PR model :p11:13
JosefHolzmayrThehrhrhr11:13
qschulzJosefHolzmayrThe: is explaining the ref killing the joke or can I be enlightened :) ?11:16
JosefHolzmayrTheqschulz: there just was a time when baudrate "industrial standards" were like... 240011:16
JosefHolzmayrTheand there was a time when 2400 bauds were the new, crazy s**tz, because, all sane people would be like 300 bauds.11:17
qschulzJosefHolzmayrThe: I'll suggest we use those standards, more stability is never a bad thing11:18
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed)11:19
*** nad <nad!~nad@pr-svc-em1-015.emea.corpinter.net> has quit IRC (Quit: Client closed)11:19
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto11:20
qschulztlwoerner: I don't think you're going to like the question but... our board is not yet migrated to TPL and it is an issue for Yocto-built SPL apparently because its size seems to be a bit too much for the SoC to handle it correctly11:21
qschulzit's not an issue with fedora35 or debian11 aarch64, hence why it's news to us11:21
qschulzwe plan to migrate to TPL but I don't know how complex it is now, so was wondering if some weird defconfig patch wouild be ok for meta-rockchip until we get this TPL thing setup for the next release of U-Boot?11:22
RPJosefHolzmayrThe: I think I still have some USRobotics 14400, 28800 and 56k modems somewhere :)11:24
JosefHolzmayrTheRP: can't say i'm surprised...11:25
RPJosefHolzmayrThe: amazing how obsolete these things are :/11:26
JosefHolzmayrTheI totally remember 28.8 being all the rave.11:27
RPJosefHolzmayrThe: I remember the excitement at upgrading11:32
*** Pan5ky <Pan5ky!~Pan5ky@2a02:8109:8380:224:e8ab:f0c9:4bec:bd66> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)11:32
jaskij[m]qschulz: do check, iirc 115200 is the highest baudrate which works for both Linux and Windows. If you care about Windows at all that is. Above that Windows goes to "round" numbers like 250k.11:33
*** Pan5ky <Pan5ky!~Pan5ky@2a02:8109:8380:224:e8ab:f0c9:4bec:bd66> has joined #yocto11:33
jaskij[m]Memory is fuzzy since I don't use Windows for anything but gaming, but there was something like that11:34
*** Granjow <Granjow!~simon@xdsl-31-164-224-239.adslplus.ch> has quit IRC (Ping timeout: 256 seconds)11:40
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)11:41
kanavinwhat I remember about my ISA sportster 14.4 is that it would zap you when plugged to a phone line11:43
kanavinI still managed to find a buyer for it in 2003, when I moved to Helsinki and got 10Mbit cable11:43
kanavin(I had that before I had a bed or a table in my rented place, wohoo!)11:44
qschulzkanavin: priorities!11:44
kanavinqschulz, it also helps that docsis connections work instantly, not like that adsl nonsense where you need to wait weeks11:44
*** zpfvo <zpfvo!~fvo@89.244.125.164> has quit IRC (Ping timeout: 250 seconds)11:44
*** zpfvo <zpfvo!~fvo@89.244.125.164> has joined #yocto11:45
jaskij[m]If only docsis allowed more upstream channels11:46
kanavinjaskij[m], it does in the latest standard, but operators are slow to introduce it11:46
kanavinit also requires discontinuing analog TV11:46
jaskij[m]The only times I've seen analog cable TV in my life was with stolen signal11:47
kanavin"DOCSIS 4.0 : Improves DOCSIS 3.1 to use the full spectrum of the cable plant (0 MHz to ~1.8 GHz) at the same time in both upstream and downstream directions. This technology enables multi-gigabit symmetrical services while remaining backwards compatible with DOCSIS 3.1. CableLabs released the full specification in October 2017."11:47
kanavinFWIW, my current connection is docsis 3.1, 1Gbit down/50Mbit up11:48
jaskij[m]Same11:48
kanavinare you in Berlin?11:48
jaskij[m]Sopot, Poland :P11:48
kanavinhaha, the song festival place ;)11:49
jaskij[m]Yeah. And the best hotel in town has quite a bit of history behind it.11:49
qschulzkanavin: I think I had this back in 2014 in Amsterdam, I was astonished by the speed compared to what I used to have in France :)11:52
qschulzand now I cry with Austrian ISPs speed11:53
kanavinthe thing is, how do you even saturate a 1Gb link at home11:53
kanavinthere's only so many 4K videos a typical household can watch at the same time :)11:53
* qschulz coughs torrent coughs11:53
qschulzor big family with everyone running netflix 4k ?11:54
qschulzor youtube 8k :p?11:54
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto11:54
kanavinyoutube 4K streams are something like 100Mbit/sec11:55
qschulzI'm more upset by upload link, it's not nice when you have your server at home :/11:55
kanavinand if you can buy 8k monitors for all family members, you won't be doing 'yocto' ;)11:55
qschulzkanavin: you don't need 8k monitors to select 8k quality on the Youtube player :p11:56
kanavinbut you still need a computer that can handle it :)11:57
qschulzdetails, details11:57
kanavinbut seriously. I wonder what Nvidia is going to do when they reach real time ray tracing with resolutions that exceed human eye ability.11:58
jaskij[m]kanavin: One of my main points during my autumn PC upgrade was to have my Gbit downlink be the bottleneck when downloading from Steam. TBH, I only went Gbit because ISP told me the upgrade from my legacy 300 Mbit plan was an euro a month.11:58
kanavinjaskij[m], same here, I convinced my ISP to give me a promo deal which is meant for new subscribers only, so I'm paying the same price I did before, and first 6 months are free :)11:59
jaskij[m]kanavin: There's new techniques and papers coming out all the time to make stuff more realistic looking. I know a dev working on one of the major offline 3D engines and reading papers is a significant part of his work.12:01
kanavinI'm slightly anxious about the flood of deep fake videos this will enable12:03
kanavinhopefully people will learn that a video is not to be trusted12:03
jaskij[m]kanavin: I just called them up, we were shuffling some hardware and needed a new settop. Then the call center dude just offered it.12:04
jaskij[m]kanavin: I'm not hopeful. People still trust newspapers.12:04
* kanavin looks up sopot on openstreetmap12:05
kanavinlooks cool, a resort town on the coast sandwiched between gdansk and gdynia12:05
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto12:05
kanavin(both big industrial harbours by the looks of things)12:06
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed)12:06
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto12:06
*** mvlad <mvlad!~mvlad@2a02:2f08:4d01:ef00:24d7:51ff:fed6:906d> has joined #yocto12:06
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 256 seconds)12:07
*** camus1 is now known as camus12:07
jaskij[m]Yeah, I've got a fifteen minute walk to a train and then it's a twenty minute ride to either city center.12:07
kanavinthe reason I know about the song festival is that I was born in the soviet union - it was our eurovision back then12:09
jaskij[m]I actually live close enough to the venue to hear the concerts12:11
jaskij[m]They modernized it a few years back, but in early 10s every festival was a guaranteed blackout12:11
* RP was pleased to get an 80Mbit connection with fibre, UK infrastructure is rather painful :/12:12
kanavinRP: I have a friend in the UK (living in High Wycombe) whose only hope is 5G arriving to the area :(12:13
kanavinwhen we visit, we dare not ask for wifi because his data consumption is metered12:13
RPkanavin: mine is metered but a decent allowance. I went for an ISP that knows what it is doing so IPv6, static Ipv4 range I can use and so on rather than cheap raw speed12:15
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC (Read error: Connection reset by peer)12:16
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto12:16
RPkanavin: they are installing fibre to the house now in many places so I now have fibre from the pole outside12:17
RPI could also regrade the line to something faster if I wanted but I don't really use the current speed limit much12:17
rburtonRP: the control pages on A&A are great aren't they :)12:18
kanavinalso, I think there's no more free roaming for us in the UK, due to you know what12:18
kanavinbooooooo12:18
kanavinbut it goes both ways ;)12:18
RPrburton: yes, nicely thought out12:19
RPkanavin: after promising they wouldn't change that too12:20
*** Granjow <Granjow!~simon@xdsl-31-164-224-239.adslplus.ch> has joined #yocto12:23
*** Pan5ky <Pan5ky!~Pan5ky@2a02:8109:8380:224:e8ab:f0c9:4bec:bd66> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)12:27
*** Guest50 <Guest50!~Guest50@62.95.72.131> has joined #yocto12:28
Guest50hello guys, Is it popssible to set a default timestamp during the Yocto build process ?12:29
rburtonkanavin: have you looked at meson 0.60 yet?12:35
rburtonGuest50: in what sense?12:35
kanavinrburton, http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates12:36
kanavinI rarely disappoint do I \0/12:36
rburtonthats why i asked :)12:36
rburton0.60 means we can drop a bit from insane.bbclass, which pleases me12:37
kanavinit was held back by shared-mime-info making a fuss, but once someone proposed a patch there I took it even though it hasn't landed yet12:37
rburtonwhich is mostly deleting code too, so yay12:39
kanavinwebkit has a bizarre patch submission process. Every patch is an attachment in bugzilla, and there's an in-tree script that creates a bug, and attaches the patch to it. And it can't be a git commit, it has to be uncommited code; you'll write the commit message during the script execution.12:40
*** codavi <codavi!~akiCA@user/akica> has joined #yocto12:40
kanavinbut I hope it works out http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=akanavin/package-version-updates&id=db418069e5d249c2a6224fb852580894dfe9a76612:40
rburtonwell that's pretty special12:40
*** Pan5ky <Pan5ky!~Pan5ky@2a02:8109:8380:224:914c:ebb9:f47:4d5a> has joined #yocto12:40
kanavinI think that's because svn is still the primary repo, and git support is bolted on after the fact.12:41
*** Guest50 <Guest50!~Guest50@62.95.72.131> has quit IRC (Ping timeout: 256 seconds)12:41
RPGuest50: SOURCE_DATE_EPOCH may be related to what you want12:41
rburtonkanavin: feel free to grab http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/meson&id=d7750d44587f7bcffeeb834b56aa7a1948935b76 into your branch12:42
kanavinRP: if you want to stress test subversion, https://svn.webkit.org/repository/webkit/ :)12:42
rburtonoh god no!12:42
rburtondoubling the time taken for the tests in one swift change12:43
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto12:43
kanavinrburton, thanks, I usually do not cherry-pick other people's work if it isn't necessary for my own patches :)12:44
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto12:44
kanavinyou never know if the author wants to change something in the patch, and then you have an older version12:44
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 264 seconds)12:47
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)12:50
RPkanavin: welcome to the world of the maintainer ;-)12:54
*** Pan5ky <Pan5ky!~Pan5ky@2a02:8109:8380:224:914c:ebb9:f47:4d5a> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)13:01
*** nad <nad!~nad@pr-svc-em1-113.emea.corpinter.net> has joined #yocto13:02
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto13:03
*** zyga <zyga!~zyga@31.0.173.147> has joined #yocto13:03
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 240 seconds)13:13
*** zpfvo <zpfvo!~fvo@89.244.125.164> has quit IRC (Ping timeout: 246 seconds)13:18
*** zpfvo <zpfvo!~fvo@89.244.125.164> has joined #yocto13:18
*** zpfvo <zpfvo!~fvo@89.244.125.164> has quit IRC (Ping timeout: 240 seconds)13:23
*** zpfvo <zpfvo!~fvo@89.244.125.164> has joined #yocto13:23
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)13:24
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto13:27
*** Granjow <Granjow!~simon@xdsl-31-164-224-239.adslplus.ch> has quit IRC (Quit: leaving)13:28
*** zpfvo <zpfvo!~fvo@89.244.125.164> has quit IRC (Ping timeout: 264 seconds)13:49
*** zpfvo <zpfvo!~fvo@89.244.125.164> has joined #yocto13:50
tlwoernerqschulz: oddly enough, most 64-bit rockchip devices use a "default" baudrate of 1500000 (i.e. 1.5Mbaud)14:04
qschulztlwoerner: yeah I've seen it in meta-rockchip14:04
tlwoerneryour device is all sorts of crazy (haha, lol)14:05
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)14:05
qschulzbut since everything's upstream for our board, there's no need to run at this 1.5Mbaud (I assume this is different when you have a close-source TF-A or OP-TEE)14:05
tlwoernerthen again, you did say your *hw* people worked on it... (haha)14:06
*** Pan5ky <Pan5ky!~Pan5ky@2a02:8109:8380:224:914c:ebb9:f47:4d5a> has joined #yocto14:06
qschulztlwoerner: this predates me joining the company by... a lot :p14:06
qschulzbut I would have agreed to this baudrate too, most if not all boards I've ever tinkered with where running at 11520014:07
*** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto14:11
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto14:11
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto14:13
*** ilunev <ilunev!~koolkhel@185.9.184.217> has joined #yocto14:19
*** tre <tre!~tre@ip5b4343c3.dynamic.kabel-deutschland.de> has quit IRC (Remote host closed the connection)14:22
*** zpfvo <zpfvo!~fvo@89.244.125.164> has quit IRC (Ping timeout: 250 seconds)14:28
*** zpfvo <zpfvo!~fvo@89.244.125.164> has joined #yocto14:28
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto14:33
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC (Quit: Leaving)14:37
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:1992:f602:5a18:2bf3> has joined #yocto14:48
*** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Quit: Leaving)14:52
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto14:54
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)15:02
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.)15:03
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)15:05
*** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto15:07
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto15:07
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto15:08
JaMaarmpit: that was very short vacation :), fwiw the [V2]... should go bellow ---, so that it doesn't end in the final commit message15:11
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.)15:13
armpityeah.. keep forgetting about the position of the [v2]15:13
*** argonautx <argonautx!~argonautx@i5E8670B5.versanet.de> has joined #yocto15:15
*** Pan5ky <Pan5ky!~Pan5ky@2a02:8109:8380:224:914c:ebb9:f47:4d5a> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)15:17
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto15:18
*** roussinm <roussinm!~mroussin@bras-base-qubcpq1306w-grc-07-184-145-217-104.dsl.bell.ca> has joined #yocto15:27
rburtonzeddii: do you need a hand with the lopper/python/swig thing? Its the sole reason our CI is failing now so I can look if it would help.15:33
*** rber|res <rber|res!~rber|res@ppp-94-68-160-205.home.otenet.gr> has joined #yocto15:34
moto-timois FILESEXTRAPATHS:prepend := correct syntax or is this deprecated (like :append +=)?15:36
moto-timoI see it all over in meta15:36
rburtonthats right as you want THISDIR to expand *now* and not later15:37
moto-timorburton: thanks for the memory jog!15:38
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.)15:43
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto15:48
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.)15:53
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto15:58
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.)16:13
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto16:18
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed)16:19
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto16:20
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)16:20
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 240 seconds)16:24
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.)16:28
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto16:33
* RP hates that is needed16:33
*** chep <chep!~chep@88.168.197.200> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)16:33
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving)16:34
*** ar__ is now known as akica16:36
zeddiirburton: I'm out of great ideas at the moment on it, but as soon as libfdt is called, we get returned a SystemErrror Exception16:39
zeddiiit works on honister, but not master. the only significant difference is the python bump.16:40
rburtonclearly the answer is to write a pure-python devicetree library16:40
zeddiithose exist, but there are other technical reasons for libfdt.16:41
zeddiiin theory, we could try to write a recipe for the dtlib stuff from Zephyr, but that still leaves me with no root cause on libfdt.16:42
*** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat)16:43
rburtonzeddii: tempted to change dtc to build the python bindings in the main recipe and avoid the need for two recipes that need to be in sync16:48
zeddiithat would be a good idea. That's what everyone does when hacking on libfdt and bindings anyway.16:48
zeddiiThere's a standing item to try and get the libfdt python packaging on pypi, but no one has gotten to it.16:49
rburtondtc has been ported to meson too, so that should let us drop the patches too16:49
rburton*assuming* the meson stuff can drive setup.py in cross builds :)16:50
rburton(i bet it can't)16:50
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:322e:2ab2:9dab:b57e> has quit IRC (Quit: vladest)16:50
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:a9d1:af30:40cc:a547> has joined #yocto16:53
*** nad <nad!~nad@pr-svc-em1-113.emea.corpinter.net> has quit IRC (Quit: Client closed)16:55
*** zpfvo <zpfvo!~fvo@89.244.125.164> has quit IRC (Quit: Leaving.)16:58
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving)16:58
*** lucaceresoli <lucaceresoli!~ceresoli@host-79-2-93-196.business.telecomitalia.it> has quit IRC (Remote host closed the connection)17:00
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.)17:18
*** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC (Quit: Leaving)17:20
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto17:23
*** mckoan is now known as mckoan|away17:23
kanavin"While Intel is not officially supporting AVX-512 on Alder Lake, AVX-512 works if disabling all of the E cores and turning on AVX-512 for the firmware. Intel though isn't officially supporting that and with today's Alder Lake tuning patch they reaffirm no AVX-512 support. "Update mtune for alderlake, Alder Lake Intel Hybrid Technology will not support Intel AVX-512. ISA features such as Intel AVX, AVX-VNNI, Intel AVX2, and17:26
kanavinUMONITOR/UMWAIT/TPAUSE are supported." "17:26
kanavinlolwhat?17:26
kanavinhttps://www.phoronix.com/scan.php?page=news_item&px=Intel-Alder-Lake-Tuning-GCC17:26
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.)17:33
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto17:38
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.)17:53
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto17:58
*** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto18:04
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto18:17
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.)18:23
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto18:28
qschulzRP: finally took the time to answer, hopefully not too much non-sense :|18:42
frayI'm looking for a list of Yocto Project compatible requirements (things the compatiblity checker script checks for) (I already found the checklist for submitting a layer).   Is this documented somewhere?18:46
*** OutBackDingo <OutBackDingo!~quassel@46.23.84.72> has quit IRC (Quit: No Ping reply in 180 seconds.)18:55
*** OutBackDingo <OutBackDingo!~quassel@46.23.84.72> has joined #yocto18:56
jsbronderIn dunfell I'm getting sporadic failures in do_package_write_rpm for openssl (and only openssl).  It's due to rpmbuild failing.  The relevant error appears to be:18:59
jsbrondererror: create archive failed: cpio: write failed - Invalid argument18:59
jsbronderFinished binary package job, result 2, filename /home/bleh/tmp/build-glibc/w18:59
jsbronderork/skylake-64-oe-linux/openssl/1.1.1l-r0/deploy-rpms/skylake_64/openssl-1.1.1l-r0.1.skylake_64.rpm18:59
jsbronderHas anyone encountered anything similar?19:00
*** OutBackDingo <OutBackDingo!~quassel@46.23.84.72> has quit IRC (Client Quit)19:01
jsbronderI know it's coming from here, https://github.com/rpm-software-management/rpm/blob/master/build/pack.c#L97 but strace isn't giving me anything useful.19:01
*** florian <florian!~florian@dynamic-002-244-058-166.2.244.pool.telefonica.de> has joined #yocto19:02
*** OutBackDingo <OutBackDingo!~quassel@46.23.84.72> has joined #yocto19:07
khemjsbronder:  perhaps its running out of memory19:13
*** Pan5ky <Pan5ky!~Pan5ky@2a02:8109:8380:224:914c:ebb9:f47:4d5a> has joined #yocto19:13
khemor some wierd openmp bug or limitation19:13
jsbronder48 otherwise idle cores and 98G of ram.19:15
khemis it using some parallel compression algo ? if so you might want to control its greed on system resources19:15
*** florian <florian!~florian@dynamic-002-244-058-166.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 250 seconds)19:15
jsbronderbut it looks like its only using a single core.19:15
*** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto19:15
*** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Ping timeout: 240 seconds)19:17
*** camus1 is now known as camus19:17
*** kiran <kiran!~kiran@2607:fea8:5a80:ea0:1992:f602:5a18:2bf3> has quit IRC (Ping timeout: 245 seconds)19:30
RPjsbronder: seems quite strange it would only happen with openssl as that shouldn't be large enough to cause issues with threads/memory with 96GB avail19:32
RPjsbronder: would be interesting to strace a failing run and see if you can see anything odd about the trace19:32
jsbronderI have to take it back about it running in parallel, setting RPM_BUILD_NCPUS=1 seems to have resolved things for me.19:35
jsbronderThe strace didn't have anything of interest, in particular I was looking for EINVAL.  But the only failing calls were some ENOENTs, mostly rpmbuild looking for config files and a couple of EAGAINs.19:37
RPjsbronder: did you hit the max open files limit?19:37
RPjsbronder: rpm is quite different between dunfell and master now :/19:38
jsbronderI'll have the fancy new toys in Q1.  Until then I'm stuck ;)19:38
RPjsbronder: I just meant it means it is harder to know what the difference may be19:39
RPsometimes the new toys have sharp edges too19:39
khemRPM_BUILD_NCPUS=1  tells me a rpm bug19:41
khemperhaps coming down to openmp or something else, do we have openmp enabled for rpm-native in dunfell ?19:41
khemwhich distro are you on ?19:41
jsbronderubuntu 18.0419:41
jsbronderNone of the devs have hit this, it's only on the beefier jenkins machines.19:42
khemyeah it sounds more like parallelism issue than resource issue now19:42
jsbronderI don't think, but I can't confirm, that we ever saw it prior to taking oe-core from 2246b0d7a71c69eb2e89c55991d1387069895466 to current.19:44
*** argonautx <argonautx!~argonautx@i5E8670B5.versanet.de> has quit IRC (Quit: Leaving)19:45
RPjsbronder: that does add https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=ad080aadbc409c99511d602e0531952b96c06bbf19:47
kheminteresting, what are two SHAs good and bad ?19:47
RPthere is an rpm CVE and some other changes rpm related too but the above looks most relevant19:47
khemRP:  that patch seems quite a bit19:48
*** florian <florian!~florian@dynamic-002-244-058-166.2.244.pool.telefonica.de> has joined #yocto19:49
jsbronderRP: Yes, that's in there.19:49
jsbronderkhem: bad is a7520c47573cd166d441e504737492b86f5aa42e19:50
*** sethfoster <sethfoster!~sethfoste@98.116.200.111> has joined #yocto19:55
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 256 seconds)19:57
jsbronderRPM_BUILD_NCPUS is a red herring, I was able to get the same failure with it set to 1.  I suppose I'll have to trim down what's getting built and bisect.20:01
Pan5kydoes anyone have experience using dotnet with bitbake? my recipes build fine when i build them individually but when i run them in parallel the dotnet process trips up and is stuck at project restore.20:08
jsbronderwhat's throwing me for loops, is that it's only openssl that's exhibits this.  I can happily build rpms for clang or qt all day (on the days that openssl builds that is).20:11
RPjsbronder: unless there is some unusual file in openssl which trips up cpio or something but that seems odd too20:12
RPand you'd think it would fail deterministicly20:13
RPqschulz: I've done patch review on a plane before for OE without network FWIW :)20:24
RPqschulz: and thanks, it seems a well reasoned email to me20:24
*** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Ping timeout: 256 seconds)20:37
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed)20:38
*** florian <florian!~florian@dynamic-002-244-058-166.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds)20:43
*** sethfoster <sethfoster!~sethfoste@98.116.200.111> has quit IRC (Ping timeout: 240 seconds)20:51
*** sethfoster <sethfoster!~sethfoste@98.116.200.111> has joined #yocto20:56
*** Pan5ky <Pan5ky!~Pan5ky@2a02:8109:8380:224:914c:ebb9:f47:4d5a> has quit IRC (Ping timeout: 245 seconds)20:58
sethfosterHey folks. I'm using dunfell and trying to build a wics image with fixed size partitions using --fixed-size. When I try and do this, mkfs.ext4 fails with the message: Copying files into the device: __populate_fs: Could not allocate block in ext2 filesysfile "ldconfig"21:00
sethfosterHas anybody seen this before? If it's relevant, this is running in a container, and the filesystem is being written on a bind-mounted volume21:01
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 276 seconds)21:01
*** florian <florian!~florian@dynamic-002-244-058-166.2.244.pool.telefonica.de> has joined #yocto21:23
*** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto21:23
vdthe doc says that adding a layer should not modify a build. But how do you deal with package customization via bbappend, e.g. psplash? Do you have to add a custom override?21:27
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.)21:28
RPvd: usually your distro or *something* should be controlling it21:30
vdRP: are you saying that it's ok if the layer modifies the build, it is scoped to a specific distro? e.g. PSPLASH_IMAGES:somedistro = "file://..."21:35
RPvd: yes21:35
vdok then I guess it's up to you to add the layer knowing that it'll make such customization, thus you must adjust the BBFILES_PRIORITY accordingly for that customization layer21:36
RPvd: the point is that you have to opt in to the customisations by selecting the distro21:37
vdRP: ok I see. I was pushing the customization too far because I want to customize my images for specific customer, so I was adding an override for it. But I understand that a meta-customer layer would be more appropriate.21:41
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed)21:47
*** mvlad <mvlad!~mvlad@2a02:2f08:4d01:ef00:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)21:47
*** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto21:48
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto21:48
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto21:48
vdI guess you can either have a single distro and multiple layers (that you enable or not depending on the build you want), or add a new distro (e.g. foo-customer1) if you don't want to mess with BBLAYERS21:48
*** florian <florian!~florian@dynamic-002-244-058-166.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds)21:51
vdRP: are these two options equivalent to you or you'd recommend one over the other?21:51
*** goliath <goliath!~goliath@user/goliath> has joined #yocto21:52
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.)21:53
RPvd: you can use multiple overrides within one distro21:53
RPI don't know you're usage scenario so picking one isn't really for me to say ;-)21:54
RPyour21:54
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto21:55
moto_timo[m]As the Yocto Jester is famous for saying: it depends21:56
vdThe scenario is image customization for a customer, i.e. different splash screen and bootloader configuration. I was using custom overrides so far but I still need to configure them somehow. A custom distro requiring the base one seems more explicit and straight-forward rather than layers and custom overrides tweaking21:58
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto21:58
vdmoto_timo[m] I would say even it[depends]22:02
moto-timosethfoster: I haven’t used fixed size, but look at the oeqa test cases for some possible hints http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/cases/wic.py#n145022:03
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Quit: Leaving.)22:03
moto-timovd: possibly meta-customer-distro layer and meta-customer-bsp-foo layer as well. Depends on how complicated things eventually get. Most “simple hacks” have ended up biting me eventually.22:05
moto-timovd: those layers might be very trivial, just a distro layer to house the psplash customization. just a BSP layer to add device tree. The extra directories/git repos eventually seem to make life easier.22:07
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto22:08
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 240 seconds)22:09
vdmoto-timo I share this. I currently have an open-sourceable generic distro, then a private layer for our company, with customization for customers. I've just figured out that these customizations are distro customizations really (policies and branding). Splitting the machines and customer-distros in their own layer could indeed help as well.22:13
*** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has quit IRC (Read error: Connection reset by peer)22:14
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Quit: ZZZzzz…)22:16
*** JaMa <JaMa!~martin@ip-109-238-218-228.aim-net.cz> has joined #yocto22:18
*** florian <florian!~florian@dynamic-002-244-058-166.2.244.pool.telefonica.de> has joined #yocto22:28
*** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto22:35
*** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto22:58
*** akica <akica!~akiCA@user/akica> has quit IRC (Ping timeout: 256 seconds)23:00
*** hpsy <hpsy!~hpsy@user/hpsy> has quit IRC (Ping timeout: 240 seconds)23:02
*** hpsy <hpsy!~hpsy@user/hpsy> has joined #yocto23:03
*** sethfoster <sethfoster!~sethfoste@98.116.200.111> has quit IRC (Ping timeout: 240 seconds)23:07
*** florian <florian!~florian@dynamic-002-244-058-166.2.244.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds)23:17
*** nad <nad!~nad@pr-svc-em1-015.emea.corpinter.net> has joined #yocto23:32
*** zyga <zyga!~zyga@31.0.173.147> has quit IRC (Quit: Leaving)23:54
*** florian <florian!~florian@dynamic-002-244-058-166.2.244.pool.telefonica.de> has joined #yocto23:58

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