<ykrons>
I was often using devshell to rework some patches and use quilt to update them. Today I would like to do the same with devtool but it seems patches are applied in the source tree and there is no way to use quilt.
<ykrons>
So what is the proper way to applied remove patches during development using devtool?
<qschulz>
JPEW: re: pyrex. I removed the container image locally, re-sourced pyrex-init-buildenv, it fetched from docker.io correctly. Then I re-sourced it once again to make sure it'd take the "local copy". It seems to work as good as before.
davidinux has joined #yocto
<qschulz>
ykrons: devtool is using git and you have a commit for each patch applied, so you can edit them manually
davidinux has quit [Read error: Connection reset by peer]
<ykrons>
qschulz: thanks. and reworking a commit will update accordingly the corresponding patch?
xmn has joined #yocto
davidinux has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus has joined #yocto
<qschulz>
ykrons: I think there's a devtool command for that (a subcommand of devtool finish?)
<qschulz>
I replace the patches manually by running git format-patch and overwrite the original patch (or add it in a bbappend)
xmn has quit [Quit: ZZZzzz…]
goliath has quit [Quit: SIGSEGV]
<ykrons>
qschulz: ok thanks
davidinux has quit [Ping timeout: 258 seconds]
davidinux has joined #yocto
camus has quit [Ping timeout: 255 seconds]
camus has joined #yocto
lucaceresoli has joined #yocto
florian has joined #yocto
davidinux has quit [Ping timeout: 252 seconds]
davidinux has joined #yocto
florian_kc has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 245 seconds]
camus1 is now known as camus
davidinux has quit [Ping timeout: 255 seconds]
davidinux has joined #yocto
rob_w has quit [Ping timeout: 240 seconds]
vmeson has quit [Ping timeout: 250 seconds]
rob_w has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wing0 has joined #yocto
goliath has joined #yocto
wing0 has quit [Quit: WeeChat 3.1]
<OutBackDingo>
ok, ive got a thought, all the newest "broken" link fetches, mostly due to github changes from master to main branches. Is there possibly a way to test like bitbake fetch world, find everything broken and fix it :)
<RP>
OutBackDingo: like "bitbake universe -c fetch"? :)
<OutBackDingo>
sure, then i can fixup all the brokenness and supply a single patch :)
mattsm is now known as Guest9382
Guest9382 has quit [Killed (osmium.libera.chat (Nickname regained by services))]
mattsm has joined #yocto
mattsm has quit [Read error: Connection reset by peer]
mattsm has joined #yocto
<wyre>
why do you think I'm having this problem when shutting down the SoM https://bpa.st/ZMJQ from the bash cli?
BobPungartnik has quit [Quit: Leaving]
LetoThe2nd has joined #yocto
<LetoThe2nd>
yo dudx
<Ad0>
upgrading from warrior to dunfell wasn't that bad
<Ad0>
what do you do though when an out of tree kernel calls functions in a newer kernel coming with the newer yocto that isn't there anymore :P I patched the kernel by reintroducing the function but that can't go on forever
<qschulz>
Ad0: you port the out of tree driver to the newer kernel
<Ad0>
yeah like know that haha
<qschulz>
check what the function was replaced with (if it was) in git log of the kernel and do the same for your out-of-tree driver
<Ad0>
yeah
<qschulz>
surround all of those changes with a nice #ifdef with the version of the kernel and you're good to go
<Ad0>
no idea what the replacement for that would be
<Ad0>
I thought the mantra was "never break anything" but they did there
<Ad0>
if the driver was in-kernel it would have stayed
<qschulz>
Ad0: the mantra is: out-of-tree driver, your shit to fix :)
<Ad0>
haha
<Ad0>
I guess
<qschulz>
the only thing that is guaranteed to stay consistent across releases is the sysfs ABI
<Ad0>
the chip supplier has to fix it but for now I patched the kernel by reintroducing the function
<qschulz>
and it's a PITA
<qschulz>
(from kernel dev pov, but very good for userspace)
<Ad0>
and that's what they do too. they have the same patch
<Ad0>
but one day that function will break
<qschulz>
Ad0: yes, and you'll need to fix it. If you want the kernel to not break your out-of-tree custom driver, upstream it
<Ad0>
hehe
dkl has quit [Quit: %quit%]
dkl has joined #yocto
jwillikers has joined #yocto
Guest26 has quit [Quit: Client closed]
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
<JPEW>
qschulz: thanks
<wyre>
what poky version do you recommend me to work with?
<rburton>
latest release
<wyre>
Hardknott?
<wyre>
the LTS is Dunfell
<rburton>
yeah either
<rburton>
LTS will still EOL at some point, but there'll be a new LTS to replace it
<rburton>
depends on what sort of cadence you want to follow
<rburton>
LTS releases are every two years. other releases are every six months, but are EOL when the next one is released.
<rburton>
So if you use a non-LTS release you need to keep up
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
rob_w has quit [Remote host closed the connection]
lucaceresoli has quit [Ping timeout: 258 seconds]
jsandman has quit [Quit: Ping timeout (120 seconds)]
tangofoxtrot has quit [Read error: Connection reset by peer]
jsandman has joined #yocto
jwillikers has quit [Remote host closed the connection]
alejandrohs has quit [Ping timeout: 265 seconds]
jwillikers has joined #yocto
vmeson has joined #yocto
alejandrohs has joined #yocto
tangofoxtrot has joined #yocto
yates_home has joined #yocto
<yates_home>
in my build folder there is an elf application that is used in run.do_uboot_mkimage: <build>/tmp/work/qemucsky-poky-linux/linux-csky/5.12-r0/recipe-sysroot-native/usr/bin/uboot-mkimage
<yates_home>
where is the source for this application?
<Ad0>
I did devtool workspace finish , but yocto insists to keep building the workspace kernel sources
<Ad0>
is there some documentation to properly finish and exit the workspace so it goes back to normal yocto sources w/patch?
lucaceresoli has joined #yocto
creich_ has joined #yocto
<yates_home>
rburton: thanks. good tip.
zyga__ has joined #yocto
mattsm has quit [Killed (sodium.libera.chat (Nickname regained by services))]
mattsm has joined #yocto
lucaceresoli has quit [Client Quit]
splatch_ has joined #yocto
chrysh_ has joined #yocto
Vonter has quit [Ping timeout: 255 seconds]
tkoskine has quit [Ping timeout: 255 seconds]
dmoseley has quit [Ping timeout: 255 seconds]
rewitt3 has quit [Ping timeout: 255 seconds]
splatch has quit [Ping timeout: 255 seconds]
florian has quit [Ping timeout: 255 seconds]
zyga_ has quit [Ping timeout: 255 seconds]
creich has quit [Ping timeout: 255 seconds]
mccc has quit [Ping timeout: 255 seconds]
shoragan has quit [Ping timeout: 255 seconds]
chrysh has quit [Ping timeout: 255 seconds]
tkoskine has joined #yocto
Vonter has joined #yocto
dmoseley has joined #yocto
<yates_home>
Ad0: it's been a long time since i used devtool, but a) properly finishing it should work and b) there is a good bit of documentation on the tool.
<Ad0>
ok
shoragan has joined #yocto
<Ad0>
I need to patch a kernel driver
florian has joined #yocto
rewitt3 has joined #yocto
<yates_home>
yeah, thats a perfect use-case, i think
<Ad0>
first off "devtool modify linux-yocto" doesn't work. I have to do virtual/kernel
<Ad0>
I have some confusion between virtual/kernel and linux-raspberrypi, etc
<Ad0>
is virtual/kernel some magic alias?
<yates_home>
Ad0: virtual/kernel is defined somewhere to be a default kernel.
<Ad0>
my kernel is called linux-raspberrypi
<Ad0>
but starting devtool with that gives error
<Ad0>
virtual/kernel works. why? :)
<Ad0>
somehow devtool finish does not give error on linux-raspberrypi
* Ad0
is very confused
Schlumpf has joined #yocto
<Ad0>
also, in warrior it started an interactive shell with screen, I can't seem to see this now
<rburton>
sounds like you're not really using linux-rpi
<Ad0>
it does run the recipes and overrides with that name
<yates_home>
Ad0: search for "PREFERRED PROVIDER" in your custom layer or your build conf's
<Ad0>
recipes-kernel/linux/linux-raspberrypi
<rburton>
oh right, you said 'first off "devtool modify linux-yocto" doesn't work.'
<rburton>
yes: you are using linux-raspberrypi
<Ad0>
no matches
<Ad0>
sorry I meant "devtool modify linux-raspberrypi"
<rburton>
to bitbake your kernel, what do you type?
<Ad0>
I don't explicitly do that I built my image
<Ad0>
I will try it again
<Ad0>
it worked now with "devtool modify linux-raspberrypi" .
<Ad0>
must have been some strange things going on in the upgrade :)
<rburton>
youd only modify linux-yocto if that was the kernel you had selected
<Ad0>
yeah
<rburton>
ideally, just use virtual/kernel everywhere
<Ad0>
so that's the alias for the current kernel
<Ad0>
yeah I should really use the virtual/kernel
<Ad0>
is it dangerous to do "devtool modify linux-raspberrypi" and then use virtual/kernel for finish , for example?
<Ad0>
also, I have a full kernel config (defconfig) I want to overwrite, what is the most appropiate way to do that in my layer? I have seen misc posts with different approaches.
<smurray>
RP JPEW: if I have a stuck bitbake-server process, any pointers on digging out why?
<JPEW>
Is it possible to attach PDB to a stuck process?
<Ad0>
thanks rburton :)
<smurray>
JPEW: I'm able to attach with gdb and poke with the python extensions, e.g. py-bt
<Ad0>
I recall that doing that gave me "defconfig was supplied both via KBUILD_DEFCONFIG and SRC_URI. Dropping SRC_URI defconfig"
<Ad0>
didn't happen in warrior, happens in dunfell
<rburton>
most likely meta-rpi using KBUILD_DEFCONFIG
<smurray>
JPEW: I was doing a run with plain master poky on a loaner machine, so I have a suspicion it might be hash equiv not shutting down, but there's like > 100 threads ;)
<Ad0>
does this mean it ditches my defconfig, or should I just ignore it
<JPEW>
smurray: Ah you are using `BB_HASHSERVE = "auto"` ?
<smurray>
indeed
<smurray>
there was a reason I asked for that run on the autobuilder
<JPEW>
Right
<smurray>
this is stock poky defaults
<JPEW>
So bitbake server itself is waiting for the hash server to exit?
<smurray>
I think that's what it means
<override>
running in to weird errors after setting up a distro. any debugging ideas would be highly appreciated. ERROR: opentrons-ot3-image-1.0-r0 do_image_complete: The recipe opentrons-ot3-image is trying to install files into a shared area when those files already exist. Those files and their manifest location are:
<override>
(matched in manifest-verdin_imx8mm-tdx-reference-minimal-image.image_complete)
<override>
sorry about the spam..
<override>
was trying to paste a pastebin link sorry so sorry
<override>
just ignore that for now actually
<JPEW>
smurray: Hmm, I wonder if the server even got the singal
<JPEW>
the SIGTERM signal that is
<override>
ok so I keep getting the "trying to install files into a shared are where the files already exisit". for wiping out tmp do we just rm -rf it or is there some better way of going about it?
<smurray>
JPEW: yeah, that's occurred to me just now as well from looking at the code
<JPEW>
smurray: Can you put a break point in the signal handler in asyncrpc/serv.py and manually send the process a SIGTERM?
<smurray>
JPEW: I'll try, not used the gdb python extensions very much before
<JPEW>
smurray: Me either
<qschulz>
override: rm -rf it, or I think just removing the inode of the directory is enough? don't remember, but I always rm -rf :)
<qschulz>
make sure you don't have your sstate-cache and downloads dir in your tmp
<override>
qschulz: not sure why but i did an rm -rf on my deploy folder too
<qschulz>
override: shouldnt deploy be in your tmp dir by default?
<override>
ohhh, maybe its not.. remeber rburton pointed that out once. my bso is putting it elsewhere
<override>
bsp*
sakoman has joined #yocto
manuel1985 has quit [Quit: Leaving]
<JPEW>
smurray: I wonder if there is still a connected client that is preventing the loop from exiting
rcw has quit [Quit: Leaving]
<smurray>
JPEW: there are no other processes at this point that I see, just this one cooker + hash equiv server set after a oe-selftest run with a bunch more errors than expected
<smurray>
JPEW: looking in cooker, it's where you'd expect, it's waiting on the join after the process.terminate
<JPEW>
Yep
bps has quit [Ping timeout: 268 seconds]
<JPEW>
Too bad the async server doesn't log when it gets a new client connection
<smurray>
yeah, I suspect it might take a bit of instrumentation to work through this
<JPEW>
smurray: How easily can you reproduce?
zyga-mbp has joined #yocto
<smurray>
JPEW: somewhat reliably, I suspect, but it takes hours since it's running oe-selftest
<smurray>
JPEW: heh, I've found examples of setting breakpoints on python function name, but they're all for py2, and of course the unicode stuff in py3 makes them obsolete
<JPEW>
Ok. I'll give you a new patch with some logging
<JPEW>
I *think* I might know what the problem is
<JPEW>
Or at least I think I can fix it if the theory is that there is a dangling client preventing the loop from exiting
Guest26 has joined #yocto
<Ad0>
rburton, "ERROR: No recipe named 'virtual/kernel' in your workspace
<Ad0>
" even if I did "devtool modify virtual/kernel"
<Ad0>
first I did "devtool modify virtual/kernel" - that worked, then "devtool build virtual/kernel".
<smurray>
JPEW: would there be an open socket around from that that I could poke around for? or I can maybe dig down to look at the asyncio loop object contents in gdb...
<JPEW>
smurray: Good call! there should be a unix domain socket in /proc/PID/fds
LetoThe2nd has quit [Quit: Connection closed for inactivity]
mihai has quit [Read error: Connection reset by peer]
<smurray>
JPEW: I notice the loop has a _stopping=False internal value
<JPEW>
Also _closed=False
<JPEW>
So I think it's not getting the signal for some reason
<smurray>
JPEW: yeah, but it's unclear to me how that SIGTERM would get dropped
<JPEW>
Either it's blocked, or the signal arrived before the server installed the handler....
<JPEW>
Hmm, I but I can test that :)
<JPEW>
smurray: What test is it failing on?
<smurray>
JPEW: I don't believe it's any specific test, that's been the problem, random failures under heavy load
mihai has joined #yocto
mihai has quit [Read error: Connection reset by peer]
mihai has joined #yocto
<JPEW>
smurray: Ok, I think maybe I can reproduce it in a simple test case, I'll push it up and see what you think
<smurray>
JPEW: if you have logging or a potential fix, I can kick off a run, would hopefully see results later this aft or in the evening
<JPEW>
K. The fix is a little more involved... but I'll work on one
<smurray>
heh, even logging to confirm the problem would be good ;)
<JPEW>
I *think* that the loop not being in the _closed state is sufficient, but yes, I'll add some logging for the signal handler
<RP>
smurray, JPEW: if/as/when there are patches you think I should merge, can you point me at them. I don't know what to with the ones in -next really now :/
<JPEW>
OK
<JPEW>
I'll take a look at the patches in -next and see what needs done after I write up the proposed fix
<smurray>
RP: I think you just have a couple of minor bits, not the whole pr server rework to use asyncrpc?
<RP>
smurray: correct, just not sure if those should be going in or not
<smurray>
RP: the bad message error message change seems innocuous enough, the 30s timeout for the client is maybe more debatable
<smurray>
RP: but if that's working on the autobuilder, then it seems unlikely to be a problem in general perhaps
xmn has joined #yocto
<JPEW>
If the theory is correct, it's only a problem under high load when bitbake-server attempts to exit before the hashserver/prserver have installed their signal handler (so unlikely in cases other than the AB)
<JPEW>
It's a race basically
<smurray>
ah, interesting
<smurray>
I have a change in my local work to shift where the loop gets created that I could maybe repurpose to block for that
<JPEW>
The fix is to mask of the SIGTERM signal before we start the server so that inherits that mask, then unblock the signal in the hashserve process after it's install the handler (which will immediately deliver any pending signals)
<smurray>
ah, much better than my thought ;)
Tokamak has joined #yocto
<JPEW>
I'm putting a wrapper in AsyncServer to do this so it's easier
<smurray>
JPEW: do you think there's still benefit to shifting the asyncio loop creation into the child process?
<JPEW>
smurray: I'm not sure
<JPEW>
Lets see if this fixes it first
<smurray>
okay
<rfs613>
what could be causing the "do_build" step of every recipe to have a dependency on "db.do_package_write_deb" ?
xmn has quit [Quit: ZZZzzz…]
florian_kc has quit [Ping timeout: 255 seconds]
<smurray>
rfs613: deb packaging is turned on, i.e. package_deb is in PACKAGE_CLASSES
<rfs613>
smurray: and this needs berkley DB?
<smurray>
rfs613: I'm not sure about dpkg, but I think dnf may, and I believe it's used even with deb
<rfs613>
smurray: hmm, okay, i'll go digging there... thanks ;-)
mranostaj has joined #yocto
xmn has joined #yocto
<smurray>
rfs613: no worries, good luck
zpfvo has quit [Remote host closed the connection]
<JPEW>
RP, smurray : Patch send to bitbake ML
florian has quit [Quit: Ex-Chat]
<JPEW>
If you comment out the signal.pthread_sigmask() in AsyncServer.serve_as_process(), you should be able to reliably reproduce the bug (the test_slow_server_start) will fail after 300 seconds)
<smurray>
JPEW: okay
zyga__ has quit [Ping timeout: 265 seconds]
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
mckoan is now known as mckoan|away
<smurray>
JPEW: I've put that on top on my plain poky setup and started a run to compare against last night's
dev1990 has joined #yocto
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
<rfs613>
noticed small typo in poky/meta/lib/oeqa/manual/toaster-managed-mode.json ... it needs s/PACKAGE_CLASES/PACKAGE_CLASSES/ ... should I report this somewhere?
bps has quit [Ping timeout: 268 seconds]
<rburton>
rfs613: you can send a patch to openembedded-core@lists.openembedded.org
jmiehe has joined #yocto
<rburton>
or file a bug in bugzilla.yoctoproject.org. the patch would be best :)
<rfs613>
I left off the 2nd hunk which added newline at end of file
kpo has joined #yocto
<override>
When we define a custom IMAGE_FSTYPE class as a bbclass, so we need to add that class to some other variable too, or is jsut having that bblass enough?
<smurray>
override: IMGCLASSES would be my guess, see meta/classes/image.bbclass
<smurray>
override: though I'm willing to believe I'm wrong, there's also IMAGE_TYPES in image_types.bbclass, which might be more relevant if it's a new fstype
<override>
ill set IMAGE_FSTYPE to thene class i just eclared and see what breaks
<smurray>
override: I think you add your class's name to IMAGE_CLASSES so it gets pulled in, and your class adds its new type to IMAGE_TYPES
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
<override>
smurray: where do i even name the custom image class? the image bbclass which came with my bsp, i dont see the type getting named anywhere
<smurray>
override: I'd need some more context, I think. Is the class adding a new output type like ext4 or the like?
<override>
yeah
<override>
lets say you make a custon image class..
whuang0389 has joined #yocto
<smurray>
override: they might just be inheriting in a recipe before setting IMAGE_FSTYPES, I'd probably grep through the BSP layer to see where it's being references
<smurray>
*referenced
<override>
been grepping, ill double check
kanavin has joined #yocto
<override>
maybe all bbclasses with a image_type_ prefixed to their name start getting picked up as possible IMAGE_FSTYPE ?
mranostaj has quit [Remote host closed the connection]
<override>
maybe im just being horribly ineloquent as I try to explain this
<override>
lets say I declare some image_type_smurray.bblcass, can I just go ahead and do something like IMAGE_FSTYPE = smurrayimg now?
<override>
thats what my bsp is leading me to belive right now
<override>
or wait, maybe I do need a IMAGE_CLASSES_append before I can start using that image type
mranostaj has joined #yocto
<override>
ok, think I got now, didnt see this when I first grepped t
dmoseley has quit [Ping timeout: 255 seconds]
<smurray>
override: cool
florian has joined #yocto
<override>
smurray: so the IMAGE_CLASSES_append bit makes sense
<override>
im just appening the new image class to it
<smurray>
yes, that makes sense
<override>
but even now the name being given in IMAGE_FSTYPE has an img at its end.. i dint get where we are defining this name..
<override>
the image class is called img_type_tezi, i append img_type_tezi to IMAGE_CLASSES_append, but then in IMAGE_FSTYPE i see teziimg getting added
<override>
is that just like some yocto magic or what?
<override>
smurray: see what im trying to get at? ^
dmoseley has joined #yocto
<smurray>
override: I'd need to see the class, my guess is they're adding teziimg to IMAGE_TYPES in it
<smurray>
override: that's what registers the type for use in IMAGE_FSTYPES, it's not based on the bbclass name
<override>
oh, let me double check.. maybe I wasnt differentiating between my IMAGE_FSTYPES and IMAGE_TYPE as i grepped for teziimg or something
frieder has quit [Remote host closed the connection]
<smurray>
override: there might be some magic somewhere, the definition of IMAGE_CMD_teziimg and the other stuff there is about what I'd expect, but as you say there's no adding of teziimg to IMAGE_TYPES or CONVERSIONTYPES
<override>
hmmm
<override>
interesting
<smurray>
I'd also be willing to believe I'm missing something about image.bbclass ;)
yates_home has quit [Remote host closed the connection]
yates has quit [Remote host closed the connection]
Tokamak has joined #yocto
<override>
smurray: do u know why this class insny including the base image class or something?
<smurray>
override: if it's providing a new type it wouldn't have to, just get added to IMAGE_CLASSES somewhere
<smurray>
override: or in their image recipe, they inherit it manually
<override>
smurray: inheriting core-image would take care of it?
<override>
and how does it work again - in recipes you inherit and in classes you require?
<smurray>
override: AIUI inheriting core-image (and this image) wouldn't drive pulling this image type class in unless it's in IMAGE_CLASSES
dev1990 has quit [Quit: Konversation terminated!]
<smurray>
override: inherit is specifically for classes, include/require are for pulling in another file
<whuang0389>
does anyone have experience configuring LLVM build for an aarch64?
<whuang0389>
i think im doing something wrong.. host-target triple comes up as x86_64-unknown-linux-gnu lol
<override>
smurray: whats AIUI again?
<whuang0389>
as i understand it
<smurray>
override: as I understand it
<whuang0389>
only thing i know in my life right now is AIUI
<override>
very nice
<override>
Im also trying to work with on a hdmi dongle side project, something kinda like amaxzon firestick or something. Would anyone have any reccomendations at all for prototype boards?
<override>
the toradex im working with right now might be an overkill i feel
<override>
want some dev board with everything video over hdmi, 4k and all
<whuang0389>
pi4?
<smurray>
if it's for a product that you'd sell, SoC availability and cost would likely be the drivers. A lot of such things use Allwinner and Amlogic SoCs, I think, but whether you can source them is a good question
<smurray>
rockchip is the other vendor that comes to mind in that cheap set top box/stick space
<override>
nice.. ill start looking into those
<smurray>
if it's for a hobby project and form factor isn't an issue, then rpi4. For an actual HDMI dongle product it'd likely be a non-starter since getting those chips is likely impossible for small players
<override>
the usecase would be for tvs in hotels rooms , so guest servies and all can use it. you can setup like a wakeup call or whatever off of it , switch to normal tv programming.
<smurray>
note that your mileage may vary for the vendors I've mentioned, some of them don't have great upstream support for various things
<override>
I can prototype with rpi4, if i can switch to something else later which can fit in a hdmi dongle form factor only by writing a new machine config filr or soemthing
<smurray>
the other possibility would be one of the i.MX8 variants, though I suspect they'd be pricier than the set top box oriented SoCs from the Chinese mfgers
<override>
smurray: if i were to start out with an rpi4 would yocto make the swithc over to imx etc super swift?
dtometzki has joined #yocto
<smurray>
override: in theory, though there's usually at least some h/w specific tweaking required around things like packages for graphics, video decode, etc. that aren't necessarily all handled in BSP layers in a consistent way
<override>
I bet, just bringing over this toradex filesystem image class to my meta-layer is proving to be no walk in the park...
<smurray>
for the Automotive Grade Linux demo images we build for a bunch of platforms, the BSP specific tweaks tend to be around stuff like that
<smurray>
the other area you'd maybe see differences would be h/w specific security features like secure boot, there's still a variety of different vendor things there you might need to account for
<override>
will start looking up all the vendors u mentioned
<override>
learning some solidworks too, so the form factor and all would be pretty involved
<override>
need some vendor doing timy soms for hdmi dongles
florian has quit [Ping timeout: 265 seconds]
<override>
smurray: on replacing that teziimg class with my own, im running into some virtual/dtb errors. whats a virtual/dtb to begin with?
<smurray>
override: I've no idea, sorry
zyga-mbp has quit [Ping timeout: 252 seconds]
<override>
no worries, looking into it
<smurray>
I know what the virtual/ mechanism is for, I didn't think upstream oe-core / poky used it for devicetrees
zyga-mbp has joined #yocto
kpo has quit [Read error: Connection reset by peer]
kpo has joined #yocto
Ad0 has quit [Ping timeout: 252 seconds]
Ad0 has joined #yocto
leon-anavi has quit [Quit: Leaving]
ant__ has joined #yocto
florian has joined #yocto
xmn has quit [Quit: ZZZzzz…]
yannd has quit [Remote host closed the connection]
camus1 has joined #yocto
camus has quit [Ping timeout: 250 seconds]
camus1 is now known as camus
whuang0389 has quit [Quit: Client closed]
<JaMa>
zeddii: around?
hpsy has quit [Quit: Leaving.]
florian has quit [Ping timeout: 252 seconds]
<JaMa>
zeddii: meta-virtualization/recipes-extended/uxen/uxen-guest-tools_4.1.7.bb:do_patch is now failing in dunfell, gatesgarth, hardknott, honister "bitbake world" builds and I'm pretty sure that it wasn't failing before (as I would notice in jenkins jobs), but the strange part is that it wasn't changed for long time (not uxen-guest-tools, quilt, module.bbclass) and definitely not in all 4 releases at the same
<JaMa>
time, any idea what might cause this sudden change?
<JaMa>
Hunk #1 FAILED at 1 (different line endings).
<JaMa>
patching file Makefile
<JaMa>
Hunk #2 FAILED at 19 (different line endings).
<JaMa>
2 out of 2 hunks FAILED -- rejects in file Makefile
<JaMa>
uxen-guest-tools/4.1.7-r0/uxen-vmsupport-linux-4.1.7/Makefile: makefile script, ASCII text, with CRLF line terminators
zyga-mbp has quit [Ping timeout: 250 seconds]
<JaMa>
it also doesn't use AUTOREV or something to silently start using different source now
zyga-mbp has joined #yocto
<smurray>
JaMa: maybe something's gone off with sha384sum? It's not tested in oe-core AFAICT, and I must admit I didn't think it was supported
<smurray>
JaMa: that plus upstream changing the zip file in place might explain a failure? I'm just spitballing, though
jwillikers has joined #yocto
<smurray>
JPEW: the oe-selftest run I started earlier with your change isn't done yet, but it's looking promising, none of those failures so far
<JPEW>
smurray: excellent! Thanks!
<smurray>
JPEW: I'll do another run overnight, perhaps racheting the -j option up a bit further, then tomorrow I can apply the PR server patches and try with those
<JPEW>
smurray: I forgot to check the patches in master-next, but the fix should be pretty easy. You'll need to change how the server is started to use the new API like hashserver
<smurray>
JPEW: yeah, I noticed that, should be straightforward enough
amitk has quit [Ping timeout: 258 seconds]
camus1 has joined #yocto
xmn has joined #yocto
camus has quit [Ping timeout: 255 seconds]
camus1 is now known as camus
<JaMa>
smurray: thanks, I didn't notice that this recipe is using sum384sum, but that would mean that sum384sum checking is completely broken (I don't expect anyone able to figure out sha384 collision to overlook accidentally changing line endings in files) :)
<smurray>
JaMa: heh, yes, it'd indeed take more than one thing being broken
ant__ has quit [Ping timeout: 240 seconds]
<JaMa>
and sha384sum isn't completely broken as well:
<JaMa>
WARNING: uxen-guest-tools-4.1.7-r0 do_fetch: Checksum mismatch for local file /jenkins/mjansa/build/webos/dunfell/downloads/uxen-vmsupport-linux-4.1.7.zip
<JaMa>
Cleaning and trying again.
<JaMa>
WARNING: uxen-guest-tools-4.1.7-r0 do_fetch: Renaming /jenkins/mjansa/build/webos/dunfell/downloads/uxen-vmsupport-linux-4.1.7.zip to /jenkins/mjansa/build/webos/dunfell/downloads/uxen-vmsupport-linux-4.1.7.zip_bad-checksum_8effdabfe14416214a250f935505250bd991f106065d899db6e19bdc8bf648f3ac0f19
<JaMa>
35c4f65fe8f798289b1a0d1e06
sbach has joined #yocto
<smurray>
JaMa: hrm, if it's working then the patch not applying is indeed quite strange
<JaMa>
my current theory is that it wasn't included in "bitbake world" for some strange reason, because now I'm looking at 2 days old "bitbake world" build for qemux86-64 and it's not shown there
sbach has quit [Remote host closed the connection]