<tlwoerner>
qschulz: you use devtool to git bisect between 5.14 and 5.14.11, find the issue, and send a patch upstream. then carry the patch locally ;-)
<tlwoerner>
everyone has their own "meta-tweaks" ;-)
hpsy has joined #yocto
hpsy has quit [Ping timeout: 240 seconds]
hpsy has joined #yocto
rber|res has joined #yocto
sakoman has quit [Quit: Leaving.]
goliath has quit [Quit: SIGSEGV]
RobertBerger has quit [Ping timeout: 256 seconds]
pgowda_ has joined #yocto
lexano has quit [Ping timeout: 244 seconds]
lexano has joined #yocto
Wouter0100 has quit [Read error: Connection reset by peer]
k4wsys[m] has quit [Quit: Client limit exceeded: 20000]
GNUmoon has quit [Ping timeout: 276 seconds]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
alessioigor has joined #yocto
rob_w has joined #yocto
leon-anavi has joined #yocto
troth has quit [Ping timeout: 264 seconds]
tre has joined #yocto
troth has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
k4wsys[m] has joined #yocto
alessioigor has quit [Quit: alessioigor]
troth has quit [Ping timeout: 256 seconds]
gsalazar has joined #yocto
troth has joined #yocto
gsalazar_ has joined #yocto
gsalazar has quit [Ping timeout: 240 seconds]
GNUmoon has joined #yocto
Schlumpf has joined #yocto
mvlad has joined #yocto
GNUmoon has quit [Quit: Leaving]
GNUmoon has joined #yocto
troth has quit [Ping timeout: 256 seconds]
prabhakarlad has joined #yocto
troth has joined #yocto
<qschulz>
tlwoerner: send the patch to which upstream exactly? it's in v5.14.12 and in v5.15 so not sure where I should send it?
<qschulz>
I can carry the patch in meta-tweaks too but how do you define when to include it or not when the fix is in the same Yocto branch, just in two different honister releases
<qschulz>
I assume it's not the first crappy thing we encounter, is there anything requiring a similar setup in some public layer I could take inspiration from?
hpsy has quit [Read error: Connection reset by peer]
dgral has joined #yocto
tnovotny has joined #yocto
<RP>
qschulz: I think most people just only care about x86_64 hosts :(
<RP>
qschulz: qemu would probably be your only option :/
<qschulz>
RP: yeah that's what I was afraid of, do you have know if there's any such package recipe somewhere I could have a look at? I remember seeing some qemu-wrapper thingy somewhere but I don't remember if it's related in any way to that issue?
<jaskij[m]>
So, I got around to working on that reverse dependency script. Can anyone recommend a task/package with little dependencies? Even U-boot's graph is massive.
<dgral>
Hi! Regarding branches and protocols update in SRC_URI, does it concern only github repositories ?
<qschulz>
jaskij[m]: go for a native package for starters, and probably one that includes allarch?
<qschulz>
s/includes/inherits/ ?
mckoan has quit [Ping timeout: 260 seconds]
<qschulz>
dgral: I think we aim at forcing users to explicit the branch (or use nobranch?) soon if not already done. For the protocol, I don't know? but the git protocol deprecation is github's only for now
<RP>
qschulz: the gobject-introspection code is our heaviest user of qemu user mode
<RP>
qschulz: qemu-wrapper is focused on running target binaries natively though
<jaskij[m]>
<qschulz> "jaskij: go for a native package..." <- python3-native seems much more manageable, thanks
mckoan has joined #yocto
<kanavin>
RP: one of these days I'd like to add avx to qemu usermode so we can modernize the qemu x86 targets
<kanavin>
RP: upstream has no interest in that, there's no use case for anyone except yocto it seems
<RP>
kanavin: would be nice. We've struggled to get bug fixes upstream in the usermode code :(
<kanavin>
RP: if only Apple would use that for 'apple silicon' transition :)
<RP>
jaskij[m]: FWIW the simplest is quilt-native. You can then expand to things like libtool-native and so on
<RP>
jaskij[m]: another option may be to call into bitbake's functions using tinfoil and maybe extend the tinfoil api FWIW
<RP>
jaskij[m]: the code that generates task-depends.dot is in cooker.py
<jaskij[m]>
RP: thanks for the package suggestions. As for tying into the existing API, I'll leave it as next stage.
<jaskij[m]>
RP: what do you think about introducing per package clusters? It wouldn't change much, except tasks belonging to a single package would be grouped together.
<RP>
jaskij[m]: I know little about dot format and we only really use it as a way to expose the dependency data in a semi-readable way. It seems reasonable but I'd want the files to still be readable
<jaskij[m]>
RP: readable as in human/program readable? clusters won't change much - each package would have it's tasks wrapped in `subgraph cluster_TASK_NAME {` at the beginning and a closing brace at the end
<JosefHolzmayrThe>
yo dudX
<RP>
jaskij[m]: human readable. Do you really mean TASK_NAME there? or RECIPE_NAME?
<jaskij[m]>
RECIPE_NAME, my bad
<jaskij[m]>
another possible improvement (with a single line at the top) would be to change the node shape to rectangles - way less wasted space
<RP>
jaskij[m]: that sounds reasonable
<RP>
jaskij[m]: FWIW I just sent a patch for the multiconfig task-depends.dot corruption
<jaskij[m]>
oh, cool
<jaskij[m]>
thanks
<jaskij[m]>
later on I realized that it doesn't matter much in my use case, since my multiconfigs are just different machines
<RP>
jaskij[m]: it is as well to fix it as it should work :)
manuel1985 has joined #yocto
<frosteyes>
Hi folks. I am looking into getting CUPS working in a dunfell image with sysvinit, and just noticed something "funnny"
<frosteyes>
In the do_install the comment say "Remove sysinit script and symlinks if sysvinit is not in DISTRO_FEATURES
<jaskij[m]>
RP: I guess having the packages be sorted alphabetically is part of human readability? NBD, just means I'll have to generate manually instead of using pygraphviz.
<qschulz>
frosteyes: no? third argument is return value when argument 1 contains argument 2, fourth argument is in case it's not contained in arg1. At least from recollection
<frosteyes>
qschulz: you are right..
<RP>
jaskij[m]: that and wanting deterministic output
<RP>
jaskij[m]: it did used to be unsorted but that wasn't very deterministic
<frosteyes>
Sorry - somehow the negotiating was inverted in my mind..
<qschulz>
frosteyes: it's a bit confusing in that case since if true returns false and if false returns true :)
<frosteyes>
Yes..
<frosteyes>
And I could not see any init files in the output. So thought it was this..
<frosteyes>
Will need to look further why there is no init file for starting a cups deamon :)
argonautx has joined #yocto
<jaskij[m]>
RP: noted, sorted and overall deterministic
sstiller has joined #yocto
<RP>
jaskij[m]: one key usecase is diffing the do files before and after a change
adrian_ has joined #yocto
fleg has joined #yocto
otavio has quit [Remote host closed the connection]
Schlumpf has quit [Quit: Client closed]
F_Adrian has quit [Ping timeout: 268 seconds]
<jaskij[m]>
RP: there will be two changes: 1) a few lines at the top to do basic styling 2) subgraphs, but that's only those two lines we talked about before.
<jaskij[m]>
and yes, packages will be sorted alphabetically and tasks sorted within a package
otavio has joined #yocto
goliath has joined #yocto
<JaMa>
RP: I was starting to test your PACKAGE_GLOBAL_RENAMES changes and saves quite a lot :) 138 files changed, 5 insertions(+), 1015 deletions(-)
<qschulz>
my bad, screen was blank for a while and aggressively hit my keyboard and resend the last message :|
<jaskij[m]>
RP: because of how dot/graphviz works with clusters, to make them work I'd have to first list all the tasks and only add dependencies later. It is sorted and deterministic, but probably lends itself less to diffs. I will probably just leave it as an option.
zyga-mbp has quit [Read error: Connection reset by peer]
<jaskij[m]>
IMO it is worse for readability so I'll leave it as an option in case someone truly wants to generate that SVG
zyga-mbp has joined #yocto
zyga-mbp has quit [Client Quit]
kroon has joined #yocto
<jaskij[m]>
Now I need to add filtering
<RP>
JaMa: right, it is just a shame it doesn't work so well :(
<jaskij[m]>
Almost like in those anecdotes about LoC KPIs :P
<RP>
jaskij[m]: that doesn't read so well, no :/
<jaskij[m]>
it does give a cleaner dot output if someone actually render it, so I'm going to leave it as a non-default option
<RP>
jaskij[m]: makes sense
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
jordemort has quit [Quit: Bridge terminating on SIGTERM]
zagor has quit [Quit: Bridge terminating on SIGTERM]
kayterina[m] has quit [Quit: Bridge terminating on SIGTERM]
lexano[m] has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
coldspark29[m] has quit [Quit: Bridge terminating on SIGTERM]
Spectrejan[m] has quit [Quit: Bridge terminating on SIGTERM]
agherzan has quit [Quit: Bridge terminating on SIGTERM]
JosefHolzmayrThe has quit [Quit: Bridge terminating on SIGTERM]
janvermaete[m] has quit [Quit: Bridge terminating on SIGTERM]
ejoerns[m] has quit [Quit: Bridge terminating on SIGTERM]
cperon has quit [Quit: Bridge terminating on SIGTERM]
hpsy[m] has quit [Quit: Bridge terminating on SIGTERM]
jmlemetayer[m] has quit [Quit: Bridge terminating on SIGTERM]
hmw[m] has quit [Quit: Bridge terminating on SIGTERM]
PascalBach[m] has quit [Quit: Bridge terminating on SIGTERM]
WadeBerrier[m] has quit [Quit: Bridge terminating on SIGTERM]
banana_smoothie[ has quit [Quit: Bridge terminating on SIGTERM]
xicopitz[m] has quit [Quit: Bridge terminating on SIGTERM]
Artzaik[m] has quit [Quit: Bridge terminating on SIGTERM]
dunfell[m] has quit [Quit: Bridge terminating on SIGTERM]
ericson2314 has quit [Quit: Bridge terminating on SIGTERM]
moto_timo[m] has quit [Quit: Bridge terminating on SIGTERM]
glembo[m] has quit [Quit: Bridge terminating on SIGTERM]
jwillikers[m] has quit [Quit: Bridge terminating on SIGTERM]
hjones2199[m] has quit [Quit: Bridge terminating on SIGTERM]
doquiros[m] has quit [Quit: Bridge terminating on SIGTERM]
jaskij[m] has quit [Quit: Bridge terminating on SIGTERM]
olani[m] has quit [Quit: Bridge terminating on SIGTERM]
meck[m] has quit [Quit: Bridge terminating on SIGTERM]
barath has quit [Quit: Bridge terminating on SIGTERM]
Alban[m] has quit [Quit: Bridge terminating on SIGTERM]
t_unix[m] has quit [Quit: Bridge terminating on SIGTERM]
jonesv[m] has quit [Quit: Bridge terminating on SIGTERM]
falk0n[m] has quit [Quit: Bridge terminating on SIGTERM]
timbert[m] has quit [Quit: Bridge terminating on SIGTERM]
berton[m] has quit [Quit: Bridge terminating on SIGTERM]
Jari[m] has quit [Quit: Bridge terminating on SIGTERM]
filipm[m] has quit [Quit: Bridge terminating on SIGTERM]
jqua[m] has quit [Quit: Bridge terminating on SIGTERM]
Perceval[m] has quit [Quit: Bridge terminating on SIGTERM]
dwagenk has quit [Quit: Bridge terminating on SIGTERM]
Barry[m] has quit [Quit: Bridge terminating on SIGTERM]
Emantor[m] has quit [Quit: Bridge terminating on SIGTERM]
k4wsys[m] has quit [Quit: Bridge terminating on SIGTERM]
<kroon>
In theory, should bitbake allow the following in a .conf file ? "foo:pn-core-image-minimal () { ... } \n ROOTFS_POSTPROCESS_COMMAND:append:pn-core-image-minimal = " foo;"
<rburton>
JPEW: is it known that ncurses doesn't build for mingw
<RP>
rburton: I think it is
<kroon>
(pn-override for shell functions)
<rburton>
RP: annoying as i had a lovely cleanup but the ncurses dependency breaks it
<RP>
rburton: you could fix ncurses? :)
<RP>
kroon: conf files don't support function style definitions
<rburton>
RP: i value what is left of my sanity
<kroon>
RP, ok
<RP>
rburton: fair enough, I don't think I'd be tempted to try that either
<rburton>
the bsd version of ncurses looks more tempting every time i have to look at the ncurses build
dgral has quit [Quit: Client closed]
rob_w has quit [Remote host closed the connection]
<RP>
rburton: the problem there started with "look at ncurses"
<rburton>
did you see that ncurses decides where to install pkgconfig .pc files by running pkgconfig --debug and grepping the output
<RP>
rburton: I did :(
<RP>
rburton: I'm trying not to think about it
<rburton>
ncurses is right up there for terrible software to work with
<RP>
rburton: I remember thinking a bitbake ncurses UI would be nice
jmlemetayer[m] has joined #yocto
jordemort has joined #yocto
kroon_ has joined #yocto
kroon has quit [Ping timeout: 256 seconds]
<rburton>
a :linux override should apply for target builds, native builds, and nativesdk-for-linux, right?
lexano[m] has joined #yocto
Alban[m] has joined #yocto
cperon has joined #yocto
Spectrejan[m] has joined #yocto
meck[m] has joined #yocto
kayterina[m] has joined #yocto
shoragan[m] has joined #yocto
Emantor[m] has joined #yocto
khem has joined #yocto
moto_timo[m] has joined #yocto
ejoerns[m] has joined #yocto
dwagenk has joined #yocto
jonesv[m] has joined #yocto
t_unix[m] has joined #yocto
PascalBach[m] has joined #yocto
falk0n[m] has joined #yocto
zagor has joined #yocto
k4wsys[m] has joined #yocto
hjones2199[m] has joined #yocto
coldspark29[m] has joined #yocto
<frosteyes>
qschulz: just FYI - I figured out why there is no init scripts when installing cups. The problem is a packageconfig
<JaMa>
RP: what is 'ques' op in "if op in ["append", "prepend", "postdot", "predot", "ques"]:" ?
<JaMa>
RP: nvm, found ?=
<fray>
"ques"tion
<JaMa>
(?P<lazyques>\?\?=) |
<JaMa>
(?P<ques>\?=) |
<RP>
JaMa: right, it is ?=
kiran has quit [Remote host closed the connection]
kiran has joined #yocto
<JaMa>
I was just rebasing my bitbake branch and noticed this addition compared to older version of that patch and was wondering if it's another debug left-over (when quick grep was showing mostly just [Rrequest]s and questionsions :)
<RP>
JaMa: no, I realised that ?= with append/prepend/remove was totally pointless. I should probably have resent
vladest has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
vladest has joined #yocto
kroon_ has quit [Quit: Leaving]
ilunev has joined #yocto
ilunev has quit [Remote host closed the connection]
kiran has quit [Remote host closed the connection]
kiran has joined #yocto
troth has quit [Ping timeout: 256 seconds]
tnovotny has quit [Quit: Leaving]
troth has joined #yocto
mckoan is now known as mckoan|away
prabhakarlad has joined #yocto
* RP
is curious how much of the world breaks with the new error patch I just sent out
florian has quit [Quit: Ex-Chat]
lucaceresoli has quit [Quit: Leaving]
<tlwoerner>
qschulz: if the issue is still present in linus' tree then send it there, gregkh (or his scripts) will likely grab the patch and apply it to various stable trees
<tlwoerner>
qschulz: otherwise you can send it to stable@ directly
leon-anavi has joined #yocto
ilunev has joined #yocto
ilunev has quit [Remote host closed the connection]
fleg has quit [Read error: Connection reset by peer]
ar__ is now known as akica
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
sakoman has quit [Read error: Connection reset by peer]
sakoman has joined #yocto
<jaskij[m]>
qschulz: my greatest discovery yet when it comes to readability of those rendered graphs: SVG supports tooltips, and moving the version and path there from the node does wonders
<jaskij[m]>
oh, sorry
<jaskij[m]>
mindlag
<jaskij[m]>
meant to ping RP
<jaskij[m]>
Think I'll push first version for review and testing tonight
vd has joined #yocto
vd657777 has quit [Quit: Client closed]
ilunev has joined #yocto
goliath has quit [Quit: SIGSEGV]
mvlad has quit [Remote host closed the connection]
<jaskij[m]>
Also, I need to update the README with the dependencies. pygraphviz which I'm using requires graphviz be installed
<jaskij[m]>
I'm especially looking for ideas on additional filters, although hopefully this won't turn into a query language ;)
<fray>
One thing I've noticed after running the conversion script for the variable _ to :.. lots of ":append_" or similar.. should be a pretty easy pattern to search for in the script and alert people for manual cleanup
<khem>
jaskij: can you do a screencast showing it
<jaskij[m]>
Never did one in my life
<jaskij[m]>
And when?
florian_kc has quit [Ping timeout: 264 seconds]
adrian_ has joined #yocto
leon-anavi has quit [Quit: Leaving]
<khem>
jaskij: or some screenshots
<jaskij[m]>
khem: I can add some example to the README, but it's purely a CLI tool
<jaskij[m]>
I unfortunately couldn't find a decent library to browse DAGs in a GUI
<jaskij[m]>
A full-on GUI is doable, but it would require a lot of time
deurzen has quit [Quit: Leaving]
<jaskij[m]>
how do you capture a tooltip in a screenshot?
akica has quit [Ping timeout: 268 seconds]
adrian__ has joined #yocto
adrian_ has quit [Ping timeout: 264 seconds]
aleblanc has quit [Remote host closed the connection]
lexano has quit [Ping timeout: 250 seconds]
<RP>
jaskij[m]: not looked at the code but the graphs look pretty :)
adrian__ has quit [Ping timeout: 260 seconds]
<jaskij[m]>
the ones in the README?
florian_kc has joined #yocto
<RP>
jaskij[m]: yes
<RP>
jaskij[m]: the tooltip idea should help
<jaskij[m]>
that's actually filtered down from `bitbake core-image-base -g`
<RP>
jaskij[m]: you've seen the bootchart presentation of buildstats right?
<jaskij[m]>
don't think so
<jaskij[m]>
I actually very much learned Yocto by doing. Thrown into deep water, take over a project (small companies, over promising bosses and student employees....)
<jaskij[m]>
And unfortunately haven't found work to work with Yocto full time
<RP>
jaskij[m]: it is for live builds rather than the task dependencies but allows visualisation of build bottlenecks and is interesting if you like visualisation
lexano has joined #yocto
<RP>
jaskij[m]: I've not used it for a while but just thought I'd mention it
<jaskij[m]>
oh, neat, will take a look
<RP>
jaskij[m]: there are quite a few companies looking for yocto skilled people out there
<RP>
jaskij[m]: fair enough, we definitely need better tools!
<jaskij[m]>
RP: good to know
<RP>
jaskij[m]: in some ways I'm not the right person to test as I understand the dependency trees too well :/
<RP>
I will have a play next time I have a build system powered up. Its too late for me to want to do that now!
<RP>
I know I'll get sucked into wondering if we can drop the TOPDIR references in bitbake
mattsm has quit [Ping timeout: 260 seconds]
mattsm has joined #yocto
<RP>
I was going to ask if anyone knew why we have that code but there is nobody online from that era :/
<jaskij[m]>
fair enough
<jaskij[m]>
it just replaces `label` with `tooltip` in nodes
<jaskij[m]>
also, what I like about the tooltip idea is that it basically doesn't change the dot file at all
<jaskij[m]>
RP: if you want a comparison, I've just pushed comparison images for the tooltip version
<jaskij[m]>
unfortunately, at least in FF, the tooltips don't work embedded in GitLab
<jaskij[m]>
Okay, I'm off for today.
<jaskij[m]>
RP: after some thinking, I'm inclined to leave this tool separated from BB. The dot files gives me all the data I need and it takes way less time to run standalone. If you want to include it, perhaps as a subcommand in devtool?