ChanServ changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: | Join us or Speak at Yocto Project Summit (2021.11) Nov 30 - Dec 2, more: | Join the community: | IRC logs available at | Having difficulty on the list or with someone on the list, contact YP community mgr ndec
GillesPP has quit [Quit: Leaving]
florian has quit [Ping timeout: 240 seconds]
BCMM has joined #yocto
BCMM has quit [Client Quit]
Starfoxxes has quit [Ping timeout: 245 seconds]
goliath has quit [Quit: SIGSEGV]
Starfoxxes has joined #yocto
mvlad has quit [Remote host closed the connection]
qschulz_ has quit [Read error: Connection reset by peer]
qschulz has joined #yocto
codavi has quit [Ping timeout: 264 seconds]
chep has quit [Ping timeout: 256 seconds]
chep has joined #yocto
sakoman has quit [Quit: Leaving.]
chep has quit [Ping timeout: 250 seconds]
chep has joined #yocto
sakoman has joined #yocto
linkliu59 has quit [Remote host closed the connection]
pgowda_ has quit [Quit: Connection closed for inactivity]
xmn has quit [Read error: Connection reset by peer]
xmn has joined #yocto
xmn has quit [Quit: ZZZzzz…]
<paulg> reading 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.
<paulg> Take that cgroup thing that was screwing the LTP runs of the AB for us this summer. It really was just a one line fix.
<paulg> But without that commit log laying out wtf was going on, the change would have been (a) worthless and (b) never accepted.
<paulg> I 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.
<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.
<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-mail
<paulg> Not sure what you mean by "squash" in this context.
<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)
<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.
<paulg> people do that? Wow.
<paulg> so 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 relevant
<jaskij[m]> My bad. Squash reapplies on the same base
<jaskij[m]> Just that it replaces all the commits with one
<jaskij[m]> Also, it depends on how people treat commits.
<jaskij[m]> Okay, I'm underslept and my mind is in my code. Haven't used squash much so unsure about the rebase
<paulg> squash 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.
<jaskij[m]> Mhm. OTOH having a clean commit history requires self discipline which I know not everyone has.
<paulg> again - not following your use of "history" here.
<paulg> a reference to someone who develops a patch series on a branch already polluted with other non-related changes?
<paulg> or did you mean "clean commit logs" instead?
<paulg> either one is easily solved with simple basic and reasonable quality expectations enforced by the maintainer (or sub-maintainer) of the (portion of the) project.
<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.
<paulg> sure - 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.
<paulg> Because 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.
<paulg> I'm sure many times that has forced me to re-think things and consider alternate plans and it usually is for the better.
<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?
<paulg> most 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)
<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.
<jaskij[m]> > push "feature-ABC-v1" and then "feature-ABC-v2"
<jaskij[m]> as in separate branches with different histories
<jaskij[m]> * >
<jaskij[m]> push "feature-ABC-v1" and then "feature-ABC-v2"
<jaskij[m]> as in separate branches with different histories
<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.
<paulg> yes 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?
<paulg> again 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 complex
<paulg> And then it gets *merged* (and NOT REBASED onto master) which preserves the baseline which is CRITICAL for effective use of "git bisect".
<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?
<jaskij[m]> Because it's been sitting on my mind that I should contribute.
<paulg> I 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.
<paulg> let me see if I can find a link. Unless someone else here beats me to it.
<paulg> Bottom paragraph "Ways to Contribute".
<jaskij[m]> thanks
sakoman has quit [Quit: Leaving.]
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
<jaskij[m]> to confirm: there is no way to enable kernel compression with FIT image, is there?
tomzy has quit [Quit: Connection closed]
chep has quit [Ping timeout: 240 seconds]
chep has joined #yocto
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
davidinux has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
Barry[m] has quit [Quit: Client limit exceeded: 20000]
Schlumpf has joined #yocto
Emantor[m] has quit [Quit: Client limit exceeded: 20000]
hpsy has joined #yocto
chep has quit [Ping timeout: 240 seconds]
chep has joined #yocto
Schlumpf has quit [Ping timeout: 256 seconds]
GNUmoon has joined #yocto
Granjow has joined #yocto
<JosefHolzmayrThe> yo dudX
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
rob_w has joined #yocto
<Granjow> Hi 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?
Emantor[m] has joined #yocto
Barry[m] has joined #yocto
chep has quit [Ping timeout: 240 seconds]
hpsy has quit [Ping timeout: 256 seconds]
chep has joined #yocto
chep has quit [Client Quit]
chep has joined #yocto
zyga-mbp has joined #yocto
zpfvo has joined #yocto
nad has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
mckoan|away is now known as mckoan
goliath has joined #yocto
chep has quit [Ping timeout: 240 seconds]
chep has joined #yocto
tre has joined #yocto
hpsy has joined #yocto
<kanavin> paulg, you really haven't used github properly yet? :D man you live in a bubble
<qschulz> jaskij[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 fitimage
<qschulz> tlwoerner: 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...)
<qschulz> tlwoerner: 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?
zpfvo has quit [Ping timeout: 250 seconds]
<qschulz> paulg: 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).
<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.
zpfvo has joined #yocto
nad has quit [Ping timeout: 256 seconds]
<qschulz> paulg: 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.
<qschulz> jaskij[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 it
<JosefHolzmayrThe> qschulz: s/force/cluebat/g
<qschulz> paulg: 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?
<jaskij[m]> qschulz: I know I can, the question is how to tell Yocto to use Image.gz in fitImage.
Bardon has joined #yocto
<qschulz> Granjow: 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_append
<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.
<qschulz> jaskij[m]: what is different between the SoMs? U-Boot is running on the Som, not the carrierboard :)
<jaskij[m]> WiFi
<jaskij[m]> there's two SoM variants, one includes a CYW-based WiFi
<jaskij[m]> they're otherwise identical
<jaskij[m]> but U-Boot needs to know which DT to pass to the kernel
<qschulz> Usually you have a way to distinguish HW at runtime based on HW configruation. If not, tell your HW dept to do it next time :)
<jaskij[m]> "HW dept" - we're small enough that I do all the pinouts for SoMs :P
<qschulz> jaskij[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 there
<qschulz> jaskij[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 described
<qschulz> jaskij[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)
<jaskij[m]> I thought fitImages replaced uImages?
<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 fail
<qschulz> jaskij[m]: I meant the WiFi module is connected to SDIO
Pan5ky has joined #yocto
<qschulz> also..... I think you might be able to have one kernel with two SDIO devices in the SDIO controller device tree node
<qschulz> because it matches against the SDIO_DEVICE_ID and SDIO_MANUFACTURER_ID to know which driver to probe
<qschulz> so if your power-up sequence (mmc-pwrseq) is the same for both (same pins, same timings), you can do that
<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 variant
<qschulz> jaskij[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?)
<jaskij[m]> the other device tree, if it ever uses those pins, won't be using those pins for SDIO
<jaskij[m]> (SoM is external btw)
<jaskij[m]> and yes, carrier is the same
<qschulz> tlwoerner: well... that's new :p especially since atf is not in a separate partition but in U-Boot
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dev1990 has joined #yocto
<qschulz> tlwoerner: I guess I'll go with a separate wks then?
zyga-mbp has joined #yocto
hpsy has quit [Ping timeout: 268 seconds]
kanavin has quit [Remote host closed the connection]
<Granjow> qschulz: Thanks, worked now! Yes, still using old syntax.
<tlwoerner> qschulz: sounds good. i'd be interested in seeing it (and am curious why the standard rockchip one doesn't work)
<tlwoerner> qschulz: are there docs you followed to get your layout?
mihai has joined #yocto
<qschulz> tlwoerner: I'll ask HW dept which bootstrapped the support what was the reason for this :)
kanavin has joined #yocto
<tlwoerner> thanks
leon-anavi has joined #yocto
<jaskij[m]> qschulz: alternatively, is there a way to manipulate U-Boot environment from Yocto?
<jaskij[m]> I couldn't quite find anything online
florian has joined #yocto
<qschulz> tlwoerner: 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)
<qschulz> jaskij[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 SoMs
manuel1985 has joined #yocto
<RP> rburton: vim patches are fuzzy :/
<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)
<jaskij[m]> trying to repro on a machine from meta-freescale
dev1990 has quit [Quit: Konversation terminated!]
xmn has joined #yocto
<rburton> RP: ooh i left a patch out
nad has joined #yocto
tnovotny has joined #yocto
<rburton> RP: just posted a patch which should be before the one i posted originally
zyga-mbp has quit [Read error: Connection reset by peer]
xmn has quit [Ping timeout: 264 seconds]
zyga-mbp has joined #yocto
<RP> rburton: thanks, will add and retest
<rburton> sorry about that
<RP> rburton: np, it happens. Usually my patches :)
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
<qschulz> tlwoerner: "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."
<qschulz> tlwoerner: for the baudrate, they just wanted to follow "the industry standard" :)
fleg has joined #yocto
<JosefHolzmayrThe> qschulz: 2400?
<qschulz> JosefHolzmayrThe: I don't have the ref for this joke :|
<qschulz> JosefHolzmayrThe: 115200
<JosefHolzmayrThe> you're just too young.
<qschulz> JosefHolzmayrThe: apparently not enough to prefer Github PR model :p
<JosefHolzmayrThe> hrhrhr
<qschulz> JosefHolzmayrThe: is explaining the ref killing the joke or can I be enlightened :) ?
<JosefHolzmayrThe> qschulz: there just was a time when baudrate "industrial standards" were like... 2400
<JosefHolzmayrThe> and there was a time when 2400 bauds were the new, crazy s**tz, because, all sane people would be like 300 bauds.
<qschulz> JosefHolzmayrThe: I'll suggest we use those standards, more stability is never a bad thing
vd has quit [Quit: Client closed]
nad has quit [Quit: Client closed]
vd has joined #yocto
<qschulz> tlwoerner: 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 correctly
<qschulz> it's not an issue with fedora35 or debian11 aarch64, hence why it's news to us
<qschulz> we 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?
<RP> JosefHolzmayrThe: I think I still have some USRobotics 14400, 28800 and 56k modems somewhere :)
<JosefHolzmayrThe> RP: can't say i'm surprised...
<RP> JosefHolzmayrThe: amazing how obsolete these things are :/
<JosefHolzmayrThe> I totally remember 28.8 being all the rave.
<RP> JosefHolzmayrThe: I remember the excitement at upgrading
Pan5ky has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<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.
Pan5ky has joined #yocto
<jaskij[m]> Memory is fuzzy since I don't use Windows for anything but gaming, but there was something like that
Granjow has quit [Ping timeout: 256 seconds]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kanavin> what I remember about my ISA sportster 14.4 is that it would zap you when plugged to a phone line
<kanavin> I still managed to find a buyer for it in 2003, when I moved to Helsinki and got 10Mbit cable
<kanavin> (I had that before I had a bed or a table in my rented place, wohoo!)
<qschulz> kanavin: priorities!
<kanavin> qschulz, it also helps that docsis connections work instantly, not like that adsl nonsense where you need to wait weeks
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
<jaskij[m]> If only docsis allowed more upstream channels
<kanavin> jaskij[m], it does in the latest standard, but operators are slow to introduce it
<kanavin> it also requires discontinuing analog TV
<jaskij[m]> The only times I've seen analog cable TV in my life was with stolen signal
<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."
<kanavin> FWIW, my current connection is docsis 3.1, 1Gbit down/50Mbit up
<jaskij[m]> Same
<kanavin> are you in Berlin?
<jaskij[m]> Sopot, Poland :P
<kanavin> haha, the song festival place ;)
<jaskij[m]> Yeah. And the best hotel in town has quite a bit of history behind it.
<qschulz> kanavin: 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 :)
<qschulz> and now I cry with Austrian ISPs speed
<kanavin> the thing is, how do you even saturate a 1Gb link at home
<kanavin> there's only so many 4K videos a typical household can watch at the same time :)
* qschulz coughs torrent coughs
<qschulz> or big family with everyone running netflix 4k ?
<qschulz> or youtube 8k :p?
kroon has joined #yocto
<kanavin> youtube 4K streams are something like 100Mbit/sec
<qschulz> I'm more upset by upload link, it's not nice when you have your server at home :/
<kanavin> and if you can buy 8k monitors for all family members, you won't be doing 'yocto' ;)
<qschulz> kanavin: you don't need 8k monitors to select 8k quality on the Youtube player :p
<kanavin> but you still need a computer that can handle it :)
<qschulz> details, details
<kanavin> but seriously. I wonder what Nvidia is going to do when they reach real time ray tracing with resolutions that exceed human eye ability.
<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.
<kanavin> jaskij[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 :)
<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.
<kanavin> I'm slightly anxious about the flood of deep fake videos this will enable
<kanavin> hopefully people will learn that a video is not to be trusted
<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.
<jaskij[m]> kanavin: I'm not hopeful. People still trust newspapers.
* kanavin looks up sopot on openstreetmap
<kanavin> looks cool, a resort town on the coast sandwiched between gdansk and gdynia
camus1 has joined #yocto
<kanavin> (both big industrial harbours by the looks of things)
vd has quit [Quit: Client closed]
vd has joined #yocto
mvlad has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
<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.
<kanavin> the reason I know about the song festival is that I was born in the soviet union - it was our eurovision back then
<jaskij[m]> I actually live close enough to the venue to hear the concerts
<jaskij[m]> They modernized it a few years back, but in early 10s every festival was a guaranteed blackout
* RP was pleased to get an 80Mbit connection with fibre, UK infrastructure is rather painful :/
<kanavin> RP: I have a friend in the UK (living in High Wycombe) whose only hope is 5G arriving to the area :(
<kanavin> when we visit, we dare not ask for wifi because his data consumption is metered
<RP> kanavin: 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 speed
kroon has quit [Read error: Connection reset by peer]
kroon has joined #yocto
<RP> kanavin: they are installing fibre to the house now in many places so I now have fibre from the pole outside
<RP> I could also regrade the line to something faster if I wanted but I don't really use the current speed limit much
<rburton> RP: the control pages on A&A are great aren't they :)
<kanavin> also, I think there's no more free roaming for us in the UK, due to you know what
<kanavin> booooooo
<kanavin> but it goes both ways ;)
<RP> rburton: yes, nicely thought out
<RP> kanavin: after promising they wouldn't change that too
Granjow has joined #yocto
Pan5ky has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest50 has joined #yocto
<Guest50> hello guys, Is it popssible to set a default timestamp during the Yocto build process ?
<rburton> kanavin: have you looked at meson 0.60 yet?
<rburton> Guest50: in what sense?
<kanavin> I rarely disappoint do I \0/
<rburton> thats why i asked :)
<rburton> 0.60 means we can drop a bit from insane.bbclass, which pleases me
<kanavin> it 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 yet
<rburton> which is mostly deleting code too, so yay
<kanavin> webkit 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.
codavi has joined #yocto
<kanavin> but I hope it works out
<rburton> well that's pretty special
Pan5ky has joined #yocto
<kanavin> I think that's because svn is still the primary repo, and git support is bolted on after the fact.
Guest50 has quit [Ping timeout: 256 seconds]
<RP> Guest50: SOURCE_DATE_EPOCH may be related to what you want
<rburton> kanavin: feel free to grab into your branch
<kanavin> RP: if you want to stress test subversion, :)
<rburton> oh god no!
<rburton> doubling the time taken for the tests in one swift change
ar__ has joined #yocto
<kanavin> rburton, thanks, I usually do not cherry-pick other people's work if it isn't necessary for my own patches :)
zyga-mbp has joined #yocto
<kanavin> you never know if the author wants to change something in the patch, and then you have an older version
codavi has quit [Ping timeout: 264 seconds]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP> kanavin: welcome to the world of the maintainer ;-)
Pan5ky has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nad has joined #yocto
zyga-mbp has joined #yocto
zyga has joined #yocto
bps has quit [Ping timeout: 240 seconds]
zpfvo has quit [Ping timeout: 246 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
Granjow has quit [Quit: leaving]
zpfvo has quit [Ping timeout: 264 seconds]
zpfvo has joined #yocto
<tlwoerner> qschulz: oddly enough, most 64-bit rockchip devices use a "default" baudrate of 1500000 (i.e. 1.5Mbaud)
<qschulz> tlwoerner: yeah I've seen it in meta-rockchip
<tlwoerner> your device is all sorts of crazy (haha, lol)
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<qschulz> but 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)
<tlwoerner> then again, you did say your *hw* people worked on it... (haha)
Pan5ky has joined #yocto
<qschulz> tlwoerner: this predates me joining the company by... a lot :p
<qschulz> but I would have agreed to this baudrate too, most if not all boards I've ever tinkered with where running at 115200
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
sakoman has joined #yocto
zyga-mbp has joined #yocto
ilunev has joined #yocto
tre has quit [Remote host closed the connection]
zpfvo has quit [Ping timeout: 250 seconds]
zpfvo has joined #yocto
hpsy has joined #yocto
kroon has quit [Quit: Leaving]
kiran has joined #yocto
rob_w has quit [Quit: Leaving]
Xagen has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hpsy has quit [Quit: Leaving.]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
zyga-mbp has joined #yocto
hpsy has joined #yocto
<JaMa> armpit: that was very short vacation :), fwiw the [V2]... should go bellow ---, so that it doesn't end in the final commit message
hpsy has quit [Quit: Leaving.]
<armpit> yeah.. keep forgetting about the position of the [v2]
argonautx has joined #yocto
Pan5ky has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hpsy has joined #yocto
roussinm has joined #yocto
<rburton> zeddii: 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.
rber|res has joined #yocto
<moto-timo> is FILESEXTRAPATHS:prepend := correct syntax or is this deprecated (like :append +=)?
<moto-timo> I see it all over in meta
<rburton> thats right as you want THISDIR to expand *now* and not later
<moto-timo> rburton: thanks for the memory jog!
hpsy has quit [Quit: Leaving.]
hpsy has joined #yocto
hpsy has quit [Quit: Leaving.]
hpsy has joined #yocto
hpsy has quit [Quit: Leaving.]
hpsy has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
goliath has quit [Quit: SIGSEGV]
bps has quit [Ping timeout: 240 seconds]
hpsy has quit [Quit: Leaving.]
hpsy has joined #yocto
* RP hates that is needed
chep has quit [Quit: ZNC 1.8.2 -]
tnovotny has quit [Quit: Leaving]
ar__ is now known as akica
<zeddii> rburton: I'm out of great ideas at the moment on it, but as soon as libfdt is called, we get returned a SystemErrror Exception
<zeddii> it works on honister, but not master. the only significant difference is the python bump.
<rburton> clearly the answer is to write a pure-python devicetree library
<zeddii> those exist, but there are other technical reasons for libfdt.
<zeddii> in 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.
florian has quit [Quit: Ex-Chat]
<rburton> zeddii: 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 sync
<zeddii> that would be a good idea. That's what everyone does when hacking on libfdt and bindings anyway.
<zeddii> There's a standing item to try and get the libfdt python packaging on pypi, but no one has gotten to it.
<rburton> dtc has been ported to meson too, so that should let us drop the patches too
<rburton> *assuming* the meson stuff can drive in cross builds :)
<rburton> (i bet it can't)
vladest has quit [Quit: vladest]
vladest has joined #yocto
nad has quit [Quit: Client closed]
zpfvo has quit [Quit: Leaving.]
leon-anavi has quit [Quit: Leaving]
lucaceresoli has quit [Remote host closed the connection]
hpsy has quit [Quit: Leaving.]
manuel1985 has quit [Quit: Leaving]
hpsy has joined #yocto
mckoan is now known as mckoan|away
<kanavin> UMONITOR/UMWAIT/TPAUSE are supported." "
<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, and
<kanavin> lolwhat?
hpsy has quit [Quit: Leaving.]
hpsy has joined #yocto
hpsy has quit [Quit: Leaving.]
hpsy has joined #yocto
bps has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
jmiehe has joined #yocto
hpsy has quit [Quit: Leaving.]
hpsy has joined #yocto
<qschulz> RP: finally took the time to answer, hopefully not too much non-sense :|
<fray> I'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?
OutBackDingo has quit [Quit: No Ping reply in 180 seconds.]
OutBackDingo has joined #yocto
<jsbronder> In 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:
<jsbronder> error: create archive failed: cpio: write failed - Invalid argument
<jsbronder> Finished binary package job, result 2, filename /home/bleh/tmp/build-glibc/w
<jsbronder> ork/skylake-64-oe-linux/openssl/1.1.1l-r0/deploy-rpms/skylake_64/openssl-1.1.1l-r0.1.skylake_64.rpm
<jsbronder> Has anyone encountered anything similar?
OutBackDingo has quit [Client Quit]
<jsbronder> I know it's coming from here, but strace isn't giving me anything useful.
florian has joined #yocto
OutBackDingo has joined #yocto
<khem> jsbronder: perhaps its running out of memory
Pan5ky has joined #yocto
<khem> or some wierd openmp bug or limitation
<jsbronder> 48 otherwise idle cores and 98G of ram.
<khem> is it using some parallel compression algo ? if so you might want to control its greed on system resources
florian has quit [Ping timeout: 250 seconds]
<jsbronder> but it looks like its only using a single core.
camus1 has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus1 is now known as camus
kiran has quit [Ping timeout: 245 seconds]
<RP> jsbronder: seems quite strange it would only happen with openssl as that shouldn't be large enough to cause issues with threads/memory with 96GB avail
<RP> jsbronder: would be interesting to strace a failing run and see if you can see anything odd about the trace
<jsbronder> I have to take it back about it running in parallel, setting RPM_BUILD_NCPUS=1 seems to have resolved things for me.
<jsbronder> The 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.
<RP> jsbronder: did you hit the max open files limit?
<RP> jsbronder: rpm is quite different between dunfell and master now :/
<jsbronder> I'll have the fancy new toys in Q1. Until then I'm stuck ;)
<RP> jsbronder: I just meant it means it is harder to know what the difference may be
<RP> sometimes the new toys have sharp edges too
<khem> RPM_BUILD_NCPUS=1 tells me a rpm bug
<khem> perhaps coming down to openmp or something else, do we have openmp enabled for rpm-native in dunfell ?
<khem> which distro are you on ?
<jsbronder> ubuntu 18.04
<jsbronder> None of the devs have hit this, it's only on the beefier jenkins machines.
<khem> yeah it sounds more like parallelism issue than resource issue now
<jsbronder> I don't think, but I can't confirm, that we ever saw it prior to taking oe-core from 2246b0d7a71c69eb2e89c55991d1387069895466 to current.
argonautx has quit [Quit: Leaving]
<khem> interesting, what are two SHAs good and bad ?
<RP> there is an rpm CVE and some other changes rpm related too but the above looks most relevant
<khem> RP: that patch seems quite a bit
florian has joined #yocto
<jsbronder> RP: Yes, that's in there.
<jsbronder> khem: bad is a7520c47573cd166d441e504737492b86f5aa42e
sethfoster has joined #yocto
bps has quit [Ping timeout: 256 seconds]
<jsbronder> RPM_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.
<Pan5ky> does 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.
<jsbronder> what'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).
<RP> jsbronder: unless there is some unusual file in openssl which trips up cpio or something but that seems odd too
<RP> and you'd think it would fail deterministicly
<RP> qschulz: I've done patch review on a plane before for OE without network FWIW :)
<RP> qschulz: and thanks, it seems a well reasoned email to me
zyga-mbp has quit [Ping timeout: 256 seconds]
prabhakarlad has quit [Quit: Client closed]
florian has quit [Ping timeout: 240 seconds]
sethfoster has quit [Ping timeout: 240 seconds]
sethfoster has joined #yocto
Pan5ky has quit [Ping timeout: 245 seconds]
<sethfoster> Hey 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"
<sethfoster> Has anybody seen this before? If it's relevant, this is running in a container, and the filesystem is being written on a bind-mounted volume
GNUmoon has quit [Ping timeout: 276 seconds]
florian has joined #yocto
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
<vd> the 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?
hpsy has quit [Quit: Leaving.]
<RP> vd: usually your distro or *something* should be controlling it
<vd> RP: 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://..."
<RP> vd: yes
<vd> ok 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 layer
<RP> vd: the point is that you have to opt in to the customisations by selecting the distro
<vd> RP: 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.
vd has quit [Quit: Client closed]
mvlad has quit [Remote host closed the connection]
vd has joined #yocto
hpsy has joined #yocto
xmn has joined #yocto
<vd> I 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 BBLAYERS
florian has quit [Ping timeout: 240 seconds]
<vd> RP: are these two options equivalent to you or you'd recommend one over the other?
goliath has joined #yocto
hpsy has quit [Quit: Leaving.]
<RP> vd: you can use multiple overrides within one distro
<RP> I don't know you're usage scenario so picking one isn't really for me to say ;-)
<RP> your
GNUmoon has joined #yocto
<moto_timo[m]> As the Yocto Jester is famous for saying: it depends
<vd> The 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 tweaking
hpsy has joined #yocto
<vd> moto_timo[m] I would say even it[depends]
<moto-timo> sethfoster: I haven’t used fixed size, but look at the oeqa test cases for some possible hints
hpsy has quit [Quit: Leaving.]
<moto-timo> vd: 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.
<moto-timo> vd: 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.
hpsy has joined #yocto
bps has quit [Ping timeout: 240 seconds]
<vd> moto-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.
JaMa has quit [Read error: Connection reset by peer]
xmn has quit [Quit: ZZZzzz…]
JaMa has joined #yocto
florian has joined #yocto
xmn has joined #yocto
prabhakarlad has joined #yocto
akica has quit [Ping timeout: 256 seconds]
hpsy has quit [Ping timeout: 240 seconds]
hpsy has joined #yocto
sethfoster has quit [Ping timeout: 240 seconds]
florian has quit [Ping timeout: 240 seconds]
nad has joined #yocto
zyga has quit [Quit: Leaving]
florian has joined #yocto