LetoThe2nd changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Community: https://www.yoctoproject.org/community | IRC logs: http://irc.yoctoproject.org/irc/ | Having difficulty on the list, with someone on the list or on IRC, contact Yocto Project Community Manager Letothe2nd | CoC: https://www.yoctoproject.org/community/code-of-conduct
dgriego has quit [Quit: Computer going to sleep]
dgriego has joined #yocto
<paulg> kanavin_, you have got me there. I tagged your RFC as something I needed to look into since it had the potential to make setup/configure suck so much less.
<paulg> I just haven't got there yet, unfortunately.
<paulg> Believe me, I know. I was there in 200 trying to sell people on how kernel configuration should be BSP oriented and not about generic options like CGL or blah-blah file system this-or-that.
<paulg> s/200/2005/
<paulg> some guy I know who name rhymes with "wed" was there as my witness, and both of us got set on fire for suggesting "git" was suitable for mainstream use.
Superfish57 has joined #yocto
Superfish57 has quit [Client Quit]
qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
tammranil has quit [Remote host closed the connection]
tammranil has joined #yocto
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
xmn has quit [Quit: xmn]
xmn has joined #yocto
xmn has quit [Quit: xmn]
frgo has joined #yocto
frgo has quit [Ping timeout: 260 seconds]
Xagen has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
uartz has quit [Ping timeout: 252 seconds]
zwelch has quit [Remote host closed the connection]
zwelch has joined #yocto
ehussain has joined #yocto
ehussain has quit [Remote host closed the connection]
uartz has joined #yocto
enok has joined #yocto
enok has quit [Client Quit]
enok71 has joined #yocto
enok71 is now known as enok
frgo has joined #yocto
frgo has quit [Ping timeout: 260 seconds]
druppy has joined #yocto
enok has quit [Remote host closed the connection]
uartz has quit [Ping timeout: 268 seconds]
druppy has quit [Ping timeout: 244 seconds]
frgo has joined #yocto
Articulus has joined #yocto
frgo has quit [Ping timeout: 265 seconds]
Articulus has quit [Quit: Leaving]
frgo has joined #yocto
CrazyGecko has joined #yocto
LodeDiper77 has joined #yocto
LodeDiper77 has left #yocto [#yocto]
savolla has joined #yocto
goliath has joined #yocto
frieder has joined #yocto
florian_kc is now known as florian
leon-anavi has joined #yocto
mckoan|away is now known as mckoan
florian_kc has joined #yocto
savolla has quit [Quit: WeeChat 4.4.3]
savolla has joined #yocto
rfuentess has joined #yocto
Kubu_work has joined #yocto
vThor has quit [Excess Flood]
vThor has joined #yocto
vThor has joined #yocto
vThor has quit [Changing host]
<kanavin_> RP: yeah I had to abruptly drop out :(
ablu has quit [Ping timeout: 260 seconds]
<leon-anavi> hi derRichard, following up the conversation from yesterday about bmap, did you run into the same problem when flashing the image with the "--nobmap" option?
ablu has joined #yocto
<derRichard> leon-anavi: well, i tried hard all night, i was unable to reproduce the issue in anyway. sadly, i don't know what was before on the sdcard.
<derRichard> filling before flashing with /dev/urandom also didn't help to trigger the issue :-/
<leon-anavi> I spoke with other people and no one complained about the same. I think it was because of mismatch with the old content of the microSD card that you tried.
<leon-anavi> Therefore I still think it will be beneficial to leave a comment in the similar issue in GitHub about bmaptool. The one that we discussed yesterday.
enok has joined #yocto
<derRichard> leon-anavi: but bmaptool is not to blame
savolla has quit [Quit: WeeChat 4.4.3]
<derRichard> before i don't know what's really goging on i'm reluctant
<derRichard> what also puzzles me is that u-boot failed with an internal error (-EFAULT) in the bootflow logic
savolla has joined #yocto
<leon-anavi> well, it worked out with dd and you had this issue that we cannot reproduce anymore with bmap...
<derRichard> maybe my sdcard reader is wonky and ate some bits while i used bmap? :D
savolla has quit [Quit: WeeChat 4.4.3]
enok has quit [Ping timeout: 272 seconds]
<RP> derRichard: as long as it doesn't find and add them back later :)
<derRichard> ;-)
enok has joined #yocto
enok has quit [Client Quit]
enok71 has joined #yocto
enok71 has quit [Ping timeout: 252 seconds]
Jones42 has joined #yocto
enok has joined #yocto
savolla has joined #yocto
grma has joined #yocto
npcomp has quit [Ping timeout: 244 seconds]
jpuhlman has quit [Read error: Connection reset by peer]
jpuhlman has joined #yocto
savolla has quit [Quit: WeeChat 4.4.3]
savolla has joined #yocto
henrik_ has joined #yocto
enok has quit [Ping timeout: 260 seconds]
savolla has quit [Quit: WeeChat 4.4.3]
florian_kc has quit [Ping timeout: 260 seconds]
florian_kc has joined #yocto
enok has joined #yocto
savolla has joined #yocto
Jones42 has quit [Quit: Client closed]
savolla has quit [Client Quit]
savolla has joined #yocto
ehussain has joined #yocto
ctraven has joined #yocto
ctraven is now known as sotaoverride
florian_kc has quit [Read error: Connection reset by peer]
ptsneves has joined #yocto
Starfoxxes has joined #yocto
florian has quit [Ping timeout: 252 seconds]
pbergin has joined #yocto
savolla has quit [Quit: WeeChat 4.4.3]
savolla has joined #yocto
florian has joined #yocto
florian_kc has joined #yocto
enok has quit [Quit: enok]
enok has joined #yocto
enok has quit [Ping timeout: 248 seconds]
enok has joined #yocto
enok has quit [Client Quit]
enok has joined #yocto
florian_kc has quit [Ping timeout: 244 seconds]
florian_kc has joined #yocto
pvogelaar has joined #yocto
florian_kc has quit [Read error: Connection reset by peer]
florian has quit [Ping timeout: 244 seconds]
ahussain has joined #yocto
ehussain has quit [Ping timeout: 260 seconds]
ahussain is now known as ehussain
ahussain has joined #yocto
florian has joined #yocto
ehussain has quit [Ping timeout: 248 seconds]
ahussain is now known as ehussain
florian_kc has joined #yocto
savolla has quit [Quit: WeeChat 4.4.3]
savolla has joined #yocto
ehussain has quit [Remote host closed the connection]
ehussain has joined #yocto
Jones42 has joined #yocto
beneth has joined #yocto
ehussain has quit [Ping timeout: 244 seconds]
ptsneves has quit [Ping timeout: 252 seconds]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<jonmason> RP: sounding an idea off of you. In the YP Docs for patches (https://docs.yoctoproject.org/contributor-guide/recipe-style-guide.html#patch-upstream-status). What if we added a "[reason]" after "Pending"? I think having to justify why it's not been at least submitted might make people think twice about just throwing it out there and walking away
<jonmason> We're having that issue in meta-arm and I'm about to rage spam people about it
<jonmason> if you don't hate it, i'll do a patch to the docs
<RP> jonmason: to be honest Pending was only there to grandfather in the whole mess of patches we already had
<RP> jonmason: we can't really mandate it without adding that to all the existing patches as things like patchtest will compain
<RP> jonmason: how about noting that Pending usually designates an older patch from before upstream status was effectively required?
cyxae has joined #yocto
Xagen has joined #yocto
wdouglass has joined #yocto
<wdouglass> Hello, i have a recipe that has a configure step that looks like
<wdouglass> do_configure() {
<wdouglass>         :
<wdouglass> }
<wdouglass> what does that single colon mean?
<JPEW> wdouglass: ":" is the shell equivalent of "noop". Its useful when the syntax requires a statement, but you don't want to do anything
<wdouglass> ahh, so like `pass` in python. ok cool, thanks!
<JPEW> wdouglass: Correct
<jonmason> RP: what if we saying "[reason]" is only required for patches post walnascar?
<RP> jonmason: I think we just have to recommend a reason be given. Otherwise patchtest is going to have a hard time knowing when to complain
PhoenixMage has quit [Ping timeout: 260 seconds]
PhoenixMage has joined #yocto
* mcfrisk appends "Upstream-Status: Pending" to a lot patches under development. maybe should disable the qacheck instead... gets harder with 10's of patches, rebases, revisions etc. Need for it is clear though
florian_kc has quit [Ping timeout: 260 seconds]
<mcfrisk> hmm, git hook to automatically add it after diffstat, that could help
uartz has joined #yocto
<paulg> The whole "Upstream-Status" thing, which I never was a fan of, really becomes transparently pointless once you delegate it to scripts and robots.
<JPEW> paulg: It's really useful, and much better than the alternative where we have no idea what state things were in
<RP> paulg: and yet it actually helps an awful lot
<mcfrisk> yes but it's needed when developing the patches. writing it manually to 21 patches is not too much work, but still annoying to forget when build fails.
<JPEW> paulg: Also generates really useful metrics
<RP> I can acutally prove it with numbers too, https://valkyrie.yocto.io/pub/non-release/patchmetrics/ "Patch Upstream-Status Counts"
<paulg> ooh! metrics!
* JPEW suspects paulg has a science background
<JPEW> paulg: Yep. It's always the scientists that get really excited about the graphs :)
<RP> is it sad I know what epitaxy is without looking it up
<jonmason> Upstream-status is extremely useful to me
<jonmason> it helps me keep internal people accountable for upstreaming their stuff
<JPEW> RP: Nah, it's just a awesome party trick.... in the right circles :)
* zeddii just uses inappropriate for all his patches :)
<jonmason> and actually use logic on why they aren't upstreaming
<jonmason> zeddii: sshhhhhh
<jonmason> don't let them know about that
<zeddii> it is the medium, not the message that paulg and I object to. but I won't rehash that.
<jonmason> I have a script that I send to management with Pending patches and how old they are
<RP> The key point is that it makes people at least think about whether something should be upstreamed
<RP> zeddi and paulg aren't the people who need that kind of hint
florian_kc has joined #yocto
<jonmason> yes, this is usually not needed
<jonmason> but there are...groups who need something for a release, that's like 2 days away
<paulg> zeddi and paulg aren't the people who take a hint from anybody.
<jonmason> "we'll get back to it"
<jonmason> and now they are 3 years old
<JPEW> paulg: There's still hope for you
<zeddii> I don't actually care about that, if I haven't noticed them in three years, I don't care.
<jonmason> without naming names, there is a plaform with 50 u-boot patches that are over a year old
<zeddii> if they've caused me pain, they'll either be updated, or chucked in the bin.
<jonmason> zeddii: are there any patches you maintain for the kernel?
<jonmason> I thought we were running stock upstream
<jonmason> ;-)
<rfs613> only 50 patches? amateurs ;-)
<paulg> I'll admit, twenty+ years ago I was all altruistic - thinking "every patch needs to be pushed upstream". But then phones came along, with a hardware TTL of less than five years. Do you really want/need the burden of that shit upstream? No. And so my perspective on the issue shifted.
<zeddii> paulg was dr death in the kernel for several years, so he walked the talk!
<jonmason> having to port someone's half-assed patch to a new version gets old really quickly
<RP> paulg: some stuff is really hard but there is a huge number of trivial things which really should just be sent
<JPEW> paulg: Also there is a huge difference between a phone manufacturer choosing to take on technical debt like that and what OpenEmbedded should do :)
<jonmason> honestly, you could just "Submit" it and throw it over the wall to a mailing list and run away
<jonmason> it'd like 5 seconds extra work for a mailing list
<jonmason> and not "Pending"
<paulg> oh yeah, 'cause there is nothing maintainers like more than a "dump-n-run"
<jonmason> better than never knowing an issue exists
pidge has quit [Ping timeout: 244 seconds]
pidge has joined #yocto
<paulg> actually, no. Because it wastes the maintainer's time - it wastes the time of the readers of the stream.
<RP> paulg: depends on the issue. Gnarly kernel patches are one thing but many of the smaller projects so prefer to know they broke musl or something
<paulg> sure - trivial build breakage are another thing - but if you aren't willing to stand behind your submission and defend it technically, then just please fuck off.
<RP> paulg: I'm feeling really bad I didn't follow up on a go patch I submitted a few years ago and it timed out :(
<RP> they use gerrit though and I just can't work that which was half the problem
<paulg> RP, when you are standing at the pearly gates, they will ask you about that go patch you never followed through on.
<RP> paulg: I suspect that won't be the first thing!
<fray> lol
<jonmason> Just imagine if god cared more about technical debt than being a good person. It seems like it should be an xkcd comic
<jonmason> "You're going to purgatory to burn off all of the patches you did"
<JPEW> jonmason: "But is was a devout patch reviewer at Our Mother of the Mailing List!"
CrazyGecko has quit [Ping timeout: 244 seconds]
<JPEW> s/is/I/
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jonmason> JPEW: you coveted your neighbors green CI
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Read error: Connection reset by peer]
<jonmason> JPEW: if you need sbom issue repro's, I have tons of them - https://gitlab.com/jonmason00/meta-arm/-/jobs/9151395195
Xagen has joined #yocto
<JPEW> jonmason: Ya, That would be helpful. I'm currently stuck in Compliance regulation hell, but I'll try to make some time to look at that later today
<jonmason> seems like clang makes it happen a ton in my CI
<JPEW> K. You have my os.walk() patch applied?
<jonmason> did that make it into master yet?
<jonmason> if not, no
<jonmason> not 100% reproducible AFAICT
<jonmason> as I just keep retrying and it works evertually
<RP> JPEW: so you want me to look at meta-mingw if you're busy? You're probably best used on the sbom stuff
<RP> s/so/do/
<JPEW> I did push the pending patch, I hadn't gotten around to looking at the patch refreshes :/
<JPEW> Unrelated: a recent change in bitbake requires Python 3.9 (I'll post SHA-1 shortly); should we bump it?
<JPEW> Looks like it was backported to scarthgap, so at a minuimum we'll need to replace the code there
<fray> I thought we were already requiring (scarthgap on) 3.9 or 3.10 on.. maybe I'm remembering wrong
<JPEW> It's still 3.8 on scarthgap according to the check and docus
<JPEW> docs
<RP> JPEW: which bitbake change? :/
<fray> ok, then I am remembering wrong
enok has quit [Remote host closed the connection]
<jonmason> JPEW: seems like juno and clang repro the issue fairly regularily. I'm going to see if doing that locally helps to repro it
<JPEW> RP: c51f01a35 ("cooker: Make cooker 'skiplist' per-multiconfig/mc")
<JPEW> removeprefix() was added in 3.9
<JPEW> It's relatively easy to write a replacement, just wasn't sure if that was preferable to bumping the minimum version on master
<RP> JPEW: we need to check which versions we have on the autobuilder distros
<RP> it would be nice to use newer versions but it really depends where the distros are
<fray> 3.12 of course if the host-tools are used
<RP> we don't just use hosttools everywhere
<fray> yup
<JPEW> I suspect the distros with Python < 3.9 are using hosttools and maybe that's why we didn't see it
<fray> that's what I was guessing as well
<RP> JPEW: Ubuntu 20.04 uses 3.8
<JPEW> That track, since that's also where we see the error
<RP> JPEW: we don't use hosttools on 20.04 so we've been lucky
<fray> ya, my primary builder is 22.04 which is 3.10 so that explains why I haven't seen it...
<JPEW> OK, so probably the best option is to replace and keep the minimum 3.8 ?
<RP> JPEW: unless we want to change 20.04 to use hosttols
<RP> er, buildtools
<fray> Ya, for scarthgap I think so.
<RP> we certainly shouldn't do that for stable
<JPEW> Ya, for sure
<fray> looking at the hunk with the removeprefix, at first glance, it looks like it was just an optimziation of the existing code.. remove that hunk and I think it will still work right (tm)
<fray> hmm there might be one line in the hunk in query.py that is needed.. the skiplist = changed how it was being set, the new version might be required with the ither lines not
<JPEW> I have someone who can make the patch, I just was curious if needed a different fix on master
<fray> personally I'm OK if master moved to 3.9 or even newer.. it's only scarthgap (and maybe styhead) we need to worry about
<fray> (IMHO)
<JPEW> fray: Sure... I don't necessarily want to make a lot of work for the AB maintainers over one line though
<fray> ya
<JPEW> RP: Is making ubuntu 20.04 use buildtools as simple as adding "ubuntu2004*": "${BUILDTOOLS_URL}" to "buildtools" in config.json in yocto-autobuild-helper?
pbergin_ has joined #yocto
pbergin_ has quit [Remote host closed the connection]
pbergin has quit [Ping timeout: 244 seconds]
nvil has joined #yocto
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
<denix> is it normal to have duplicates in OVERRIDES list? I'm seeing "aarch64" twice - first coming from TRANSLATED_TARGET_ARCH and second from MACHINEOVERRIDES which gets populated from the corresponding tunes files
druppy has joined #yocto
ehussain has joined #yocto
CrazyGecko has joined #yocto
<denix> the only issue is that pn-XXX and layer-XXX overrides come in between those two, making it unclear which one takes precedence
druppy has quit [Ping timeout: 244 seconds]
<RP> JPEW: that and changing the min version requirements in various places
<RP> denix: it shouldn't be an issue and there is a defined ordering for that, forcevariable is strongest
<denix> RP: yeah, I know about the order. it appears if there are duplicates, the stronger one gets handled. it's unfortunate that "aarch64" is both a target arch and one of the actual tunes...
<denix> e.g. in ARM32 the overrides list will have "...:arm:pn-XXX:layer-XXX:armv7a:..." while in ARM64 it will have "...:aarch64:pn-XXX:layer-XXX:aarch64:..."
<denix> a very corner-case scenario, but if you use :arm and :aarch64 overrides along with :pn-XXX or :layer-XXX, they will work differently between 32 and 64 bit platforms
frieder has quit [Remote host closed the connection]
nvil has quit [Quit: Client closed]
nvil has joined #yocto
ehussain has quit [Remote host closed the connection]
florian_kc has joined #yocto
mckoan is now known as mckoan|away
leon-anavi has quit [Remote host closed the connection]
<RP> denix: that is very unfortunate :/
<RP> denix: this is why we've tried to prefix many of the overrides like pn-
florian_kc has quit [Ping timeout: 252 seconds]
Tyaku has quit [Quit: Lost terminal]
amitk_ has joined #yocto
amitk has quit [Ping timeout: 272 seconds]
wdouglass has left #yocto [#yocto]
Jones42 has quit [Quit: Client closed]
Guest5521 has joined #yocto
Guest5521 is now known as npcomp
florian_kc has joined #yocto
<NishanthMenon> I was trying to build poky core-image-sato for genericarm64 with the intent of enabling img powervr and ran into this error - not sure if anyone has any suggestions (kas configuration file and error linked here) https://usercontent.irccloud-cdn.com/file/ZGF2PHDL/error.txt https://usercontent.irccloud-cdn.com/file/zOetmsx6/poky.yml
Jones42 has joined #yocto
cyxae has quit [Quit: cyxae]
cyxae has joined #yocto
frgo_ has joined #yocto
frgo_ has quit [Remote host closed the connection]
frgo_ has joined #yocto
frgo_ has quit [Read error: Connection reset by peer]
frgo_ has joined #yocto
frgo has quit [Ping timeout: 244 seconds]
goliath has quit [Quit: SIGSEGV]
frgo_ has quit [Ping timeout: 260 seconds]
florian_kc is now known as florian
tec4 has quit [Quit: bye!]
frgo has joined #yocto
tec4 has joined #yocto
Starfoxxes has quit [Remote host closed the connection]
ptsneves has joined #yocto
goliath has joined #yocto
prabhakalad has quit [Ping timeout: 252 seconds]
prabhakalad has joined #yocto
prabhakalad has quit [Ping timeout: 272 seconds]
nvil has quit [Quit: Client closed]
Jones42 has quit [Ping timeout: 240 seconds]
olani has joined #yocto
<khem> NishanthMenon: your kas config looks ok, the error however is unusual, some how while generating rpm for ofono and rustlib it failed to add correct rdepends to rpm metadata
<khem> do you see any crashes on your build system ?
<NishanthMenon> khem: nope
<NishanthMenon> I can try and trigger a clean build again and see..
<khem> how about cleaning ofono and trying to rebuild again ?
<khem> and see if this helps
<khem> if clean rebuild of ofono fixes ofono errors then its some transient failure which could be hard to tell
<khem> perhaps the container layer from kas could be doing something who knows
jclsn has quit [Quit: WeeChat 4.5.1]
<NishanthMenon> Ok. I will try. Thanks for the hint.
jclsn has joined #yocto
<JPEW> khem: Does the YP compatible badge logo in meta-clang have to have the unicode TM in the filename? It's messing up our CI
<khem> I dont think so, I stuck whatever was handed to my by Josef, feel free to rename it and patch the README
<khem> and what kind of CI do you use which cant handle UTF
<JPEW> khem: git ls-files in some scripts
<khem> hmm ok
khem has quit [Quit: WeeChat 4.5.1]
frgo has quit [Ping timeout: 245 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
Xagen has quit [Client Quit]
DvorkinDmitry has joined #yocto
<DvorkinDmitry> how to correctly disable busybox in the image recipe?
cabazon has joined #yocto
cyxae has quit [Quit: cyxae]
ptsneves has quit [Ping timeout: 260 seconds]
frgo has joined #yocto
druppy has joined #yocto
frgo has quit [Ping timeout: 244 seconds]
rfuentess has quit [Remote host closed the connection]
khem has joined #yocto
Kubu_work has quit [Quit: Leaving.]
frgo has joined #yocto
frgo has quit [Ping timeout: 252 seconds]
olani has quit [Ping timeout: 268 seconds]
mbulut has joined #yocto
florian has quit [Ping timeout: 260 seconds]
enok has joined #yocto
frgo has joined #yocto
frgo has quit [Ping timeout: 260 seconds]
prabhakalad has joined #yocto
nsbdfl has quit [Ping timeout: 260 seconds]
cabazon has quit [Quit: Client closed]
druppy has quit [Ping timeout: 244 seconds]
frgo has joined #yocto
enok has quit [Ping timeout: 252 seconds]
florian has joined #yocto
Xagen has joined #yocto
frgo has quit [Ping timeout: 248 seconds]
nsbdfl_ has joined #yocto
savolla has quit [Quit: WeeChat 4.4.3]
frgo has joined #yocto
frgo has quit [Read error: Connection reset by peer]
frgo has joined #yocto
ajfriesen162 has joined #yocto
ajfriesen16 has quit [Ping timeout: 244 seconds]
ajfriesen162 is now known as ajfriesen16
florian has quit [Ping timeout: 244 seconds]