GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
starblue1 has quit [Ping timeout: 240 seconds]
starblue1 has joined #yocto
perdmann has quit [Ping timeout: 240 seconds]
perdmann has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
rber|res has joined #yocto
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
RobertBerger has quit [Ping timeout: 244 seconds]
jmiehe has quit [Ping timeout: 276 seconds]
camus has joined #yocto
tangofoxtrot has quit [Remote host closed the connection]
OutBackDingo has quit [Ping timeout: 268 seconds]
tangofoxtrot has joined #yocto
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #yocto
perdmann has quit [Ping timeout: 255 seconds]
perdmann has joined #yocto
OutBackDingo has joined #yocto
sakoman has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
camus has quit [Remote host closed the connection]
nemik has joined #yocto
camus has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
sakoman has quit [Quit: Leaving.]
zwelch has quit [*.net *.split]
jsandman has quit [*.net *.split]
iokill has quit [*.net *.split]
mcfrisk has quit [*.net *.split]
dlan has quit [*.net *.split]
mlaga97 has quit [*.net *.split]
iokill has joined #yocto
mlaga97 has joined #yocto
mcfrisk has joined #yocto
dlan has joined #yocto
dlan has joined #yocto
dlan has quit [Changing host]
zwelch has joined #yocto
jsandman has joined #yocto
mario-goulart has quit [*.net *.split]
ad__ has quit [*.net *.split]
vquicksilver has quit [*.net *.split]
beneth has quit [*.net *.split]
tperrot has quit [*.net *.split]
xantoz has quit [*.net *.split]
michaelo has quit [*.net *.split]
opello has quit [*.net *.split]
opello has joined #yocto
ad__ has joined #yocto
michaelo has joined #yocto
mario-goulart has joined #yocto
xantoz has joined #yocto
vquicksilver has joined #yocto
amitk has joined #yocto
vquicksilver is now known as Guest8075
tperrot has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
perdmann has quit [Ping timeout: 240 seconds]
GNUmoon2 has joined #yocto
goliath has joined #yocto
perdmann has joined #yocto
perdmann has quit [Ping timeout: 268 seconds]
seninha has quit [Ping timeout: 276 seconds]
perdmann has joined #yocto
seninha has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
ptsneves has joined #yocto
nemik has joined #yocto
seninha has quit [Quit: Leaving]
perdmann has quit [Ping timeout: 272 seconds]
perdmann has joined #yocto
Schlumpf has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
hcg has joined #yocto
rob_w has joined #yocto
zpfvo has joined #yocto
greenwhale has joined #yocto
mvlad has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
prabhakarlad has joined #yocto
<greenwhale>
If a supervisor/manager who knows nothing about technology abuses his/her power, is it better to stay quiet because she he/she has power over me or should I address it?
F_Adrian has joined #yocto
greenwhale has quit [Quit: Client closed]
greenwhale has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
greenwhale has quit [Ping timeout: 252 seconds]
adrian_ has joined #yocto
F_Adrian has quit [Ping timeout: 252 seconds]
thomasd13 has joined #yocto
zpfvo has joined #yocto
Guest8075 has quit [Quit: WeeChat 3.4.1]
vquicksilver has joined #yocto
<qschulz>
o/
xmn has quit [Ping timeout: 244 seconds]
<wkawka>
\o
<wkawka>
Can i run a task for different machine? I have to build an image which produces another image and saves it into memory. The problem is that they have another configurations, for example fstab. When building image which will be saved, it won't work properly because of being built into different machine, so I thought about changing a machine somehow
<qschulz>
wkawka: you can have different content for the same task depending on machines which is probablky the easiest way to do it
<qschulz>
e.g. do_mytask:my-machine () {} do_mystak:my-machine-2() {:} (the second makes an empty task for my-machine-2)
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
leon-anavi has joined #yocto
florian has joined #yocto
perdmann has quit [Ping timeout: 240 seconds]
nemik has quit [Ping timeout: 245 seconds]
silbe has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
perdmann has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
alessioigor has joined #yocto
zpfvo has joined #yocto
perdmann has quit [Ping timeout: 245 seconds]
perdmann has joined #yocto
* RP
wonders whether RDEPENDS:${PN}:append:pn-packagegroup-cross-canadian-${MACHINE} = ' packagegroup-rust-cross-canadian-${MACHINE}' should work or not
<RP>
and now selftest claims a test doesn't exist. It is going to be one of those days :(
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
<mihai>
that's a bit confusing
<mihai>
but somehow makes sense
<RP>
mihai: maybe but it doesn't work :)
<qschulz>
RP: packagegroup-cross-canadian-${MACHINE} is this a recipe?
<RP>
qschulz: it is
<qschulz>
with MACHINE??
<RP>
qschulz: standard for cross-canadian stuff
wkawka has quit [Quit: Client closed]
<RP>
qschulz: have I just opened a new rabbit hole for you? :)
<qschulz>
RP: hehehe
<qschulz>
RP: I forgot about the PN redefinition in the recipe itself
<qschulz>
because I couldn't imagine for a second we would have a file for each machine
<qschulz>
so... does it actually work with a redefined PN or only the actual filename of the recipe?
<RP>
qschulz: it should be the redefined PN
<qschulz>
also, should it use PROVIDES? (I guess ${PN} is put into PROVIDES so that's redundant)
<qschulz>
RP: mmmm does your machine have an underscore in its name?
<qschulz>
e.g. x86_64?
<RP>
qschulz: no, qemuarm64
<qschulz>
(throwing ideas at you :) )
<qschulz>
RP: bitbake-getvar -r packagegroup-cross-canadian-qemuarm64 RDEPENDS to see if it makes it to the variable?
<RP>
qschulz: right, I suspect some key expansion error not working well with overrides :(
<qschulz>
RP: I would do a dummy recipe which is not a packagegroup also, siknce those are specific recipes?
nemik has quit [Ping timeout: 252 seconds]
<qschulz>
to simply test this line actually works in simpler cases :)
nemik has joined #yocto
OutBackDingo has quit [Ping timeout: 240 seconds]
<RP>
qschulz: I don't think I can afford to get sidetracked yet again the nesting is corrupting my stack
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<mihai>
did a quick test
alessioigor has quit [Quit: alessioigor]
<mihai>
having MACHINE in the override is the fault
alessioigor has joined #yocto
<mihai>
it works if you specify the machine explicitly
<mihai>
maybe the var expansion is done after overrides are processed (?)
<mihai>
RP: ^
vermaete has joined #yocto
<RP>
mihai: something like that quite likely. It is odd as ${PN} does work
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
ardo has quit [Read error: Connection reset by peer]
ardo has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
vladest has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
ardo has quit [Read error: Connection reset by peer]
ardo has joined #yocto
seninha has joined #yocto
<LetoThe2nd>
yo dudX
<LetoThe2nd>
RP: _ -> : was *part* of the solution.
pgowda_ has joined #yocto
<RP>
LetoThe2nd: happy the channel could help!
vermaete has quit [Quit: Client closed]
<LetoThe2nd>
RP: +1
zpfvo has quit [Ping timeout: 240 seconds]
sotaoverride has joined #yocto
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
zpfvo has joined #yocto
<RP>
rburton, jonmason: uboot warnings on meta-arm
<abelloni>
I warned last week;)
perdmann has quit [Ping timeout: 245 seconds]
perdmann has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
<destmaster84>
File "/home/abe/fsl-community-bsp/sources/poky/scripts/devtool", line 334, in <module>
<destmaster84>
ret = main()
<destmaster84>
File "/home/abe/fsl-community-bsp/sources/poky/scripts/devtool", line 321, in main
<destmaster84>
ret = args.func(args, config, basepath, workspace)
<destmaster84>
File "/home/abe/fsl-community-bsp/sources/poky/scripts/lib/devtool/standard.py", line 826, in modify
<destmaster84>
if (os.path.exists(srcdir) and os.listdir(srcdir)) and (kernelVersion in staging_kerVer and staging_kbranch == kbranch):
<kayterina[m]>
hello, is it logical that bitbake runs a recipe's do_populate_lic_setscene on a clean build?
<rburton>
that means its pulling items from sstate
<destmaster84>
Sorry, I haven't any idea on how I can solve it? maybe running "a bitbake-c cleanall linux-engicam"
<rburton>
solve what?
<kayterina[m]>
it is from a clean directory with no sstate cache and it fails, is it possible that it is configured somewhere in the recipe?
<kayterina[m]>
from the manual I understand it is standrd from bitbake to first run setscene and check for cache, then if nothing exists, it builds
Tokamak has joined #yocto
<destmaster84>
Thanks! I've solved cleaning the sstate and running it again
destmaster84 has quit [Quit: Client closed]
<rburton>
kayterina[m]: looks for sstate cache, if found you see a setscene task unpacking it, otherwise a non-setscene task doing the real work
sakoman has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has joined #yocto
paowz_ has quit [Ping timeout: 244 seconds]
paowz_ has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<kayterina[m]>
I did a clean image build after a clean-all. I get an error in the setscene task and a warning that the real task will run instead. Here is an error in two recipes: https://pastebin.com/PVXt5Q5E
<kayterina[m]>
I do not understand why the first miss in cache results in an error and then in a warning. On a second build, it completes without errors.
<qschulz>
kayterina[m]: when a task fails, all other tasks running in parallel are finished but no other is started
<qschulz>
so it is possible it is a race
<qschulz>
but the task on which your task depends is done after the latter has failed
<qschulz>
thus in the second run, the former has been run already and re-running the latter works because your dependency exists now?
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ptsneves>
can it be that the path too big issue is actually a buildpaths contamination?
joseogando has joined #yocto
<RP>
ptsneves: it is possible. buildpaths as an error wasn't enabled last time I tried that
<ptsneves>
@RP Thanks that is useful knowledge
florian_kc has joined #yocto
joseogando has quit [Remote host closed the connection]
mckoan is now known as mckoan|away
alimon has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 268 seconds]
goliath has joined #yocto
kscherer has joined #yocto
nerdboy has quit [Read error: Connection reset by peer]
zpfvo has quit [Ping timeout: 268 seconds]
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
Schlumpf has quit [Quit: Client closed]
jpuhlman_ has joined #yocto
jpuhlman is now known as Guest3359
Guest3359 has quit [Killed (sodium.libera.chat (Nickname regained by services))]
jpuhlman_ is now known as jpuhlman
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
denisoft81 has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
Tokamak has joined #yocto
denisoft81 has quit [Quit: Leaving]
xmn has quit [Ping timeout: 252 seconds]
Estrella_ has joined #yocto
Estrella__ has joined #yocto
xmn has joined #yocto
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
Estrella has joined #yocto
alimon has quit [Remote host closed the connection]
alimon has joined #yocto
kanavin has quit [Remote host closed the connection]
perdmann has quit [Ping timeout: 252 seconds]
perdmann has joined #yocto
roussinm has joined #yocto
perdmann has quit [Ping timeout: 244 seconds]
<roussinm>
Uf my device doesn't support blkdiscard to wipe it, is the alternative is using dd? I don't know much about disk stuff...
perdmann has joined #yocto
<roussinm>
so googling a bit. I found /sys/block/X/queue/discard_max_bytes if it has >0 it should support discard, but when I used blkdiscard I get ioctl unsupported operation...
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
kanavin has joined #yocto
perdmann has quit [Ping timeout: 252 seconds]
perdmann has joined #yocto
olani has joined #yocto
<rfs613>
roussinm: maybe the controller doesn't support it, or something like that?
<rfs613>
you can certainly use dd to write 00s all across the device... this will be quite slow, and if you are truly paranoind about the data, you would want to write some random values a couple of times at least.
<roussinm>
rfs613: actually it doesn't support the --secure option, but when we try to blkdiscard without the --secure option we get this: blk_update_request: I/O error, dev mmcblk0, sector 0, op 0x3:(DISCARD) flags 0x800 phys_reg 1 prio class 0
<rfs613>
roussinm: does the device work otherwise (eg. regular reads and/or writes)? seems like it is a SD/MMC/eMMC device...
<roussinm>
rfs613: it's an emmc device. We can use DD, read, write normally yes.
<roussinm>
I found: Secure Feature support [SEC_FEATURE_SUPPORT: 0x40] and I'm trying to find out what does the 0x40 means. It seems to support some sort of security features, but not sure which.
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
olani has quit [Ping timeout: 245 seconds]
olani has joined #yocto
<rfs613>
roussinm: seems that SEC_FEATURE_SUPPORT: 0x40 means that the device supports the sanitize operation.
<perdmann>
Hi, iam messing around with RPi Yocto. The last times i always forked the kernel, this time I want to use overlays and configuration patches to make it working. So far it works pretty good. But now iam facing the first problem. The "ads1115" Overlay only configures one ADS device. How should i adapt this to use two ADS devices ? (As far as i understand, the overelays are able to fill out placeholders
<perdmann>
which are already in the "main" dtb)
<rfs613>
roussinm: but in the same register, b[0] is not set, which means it does not support secure purge operation
<roussinm>
rfs613: I'm curious how did you find that it support the sanitize operation?
<rfs613>
roussinm: this is from JEDEC standard document JESD84-B50
<roussinm>
rfs613: hmmm, paid document.
<rfs613>
roussinm: it seems that discard (and trim) are about marking blocks as 'not needed', so the flash controller is free to erase them. However it doesn't necessarily happen immediately.
kscherer has quit [Quit: Konversation terminated!]
<rfs613>
whereas sanitize is a variant that actually does erase, and may take quite a while to accomplish this.
roussinm has quit [Quit: WeeChat 3.0]
roussinm has joined #yocto
<roussinm>
rfs613: that's interesting, but it looks like that blkdiscard doesn't have an "sanitize" option.
<roussinm>
rfs613: hmm `mmc` tool has the sanitize option.
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
olani has quit [Ping timeout: 252 seconds]
perdmann has quit [Ping timeout: 255 seconds]
perdmann has joined #yocto
leon-anavi has quit [Quit: Leaving]
mrnuke has quit [Ping timeout: 268 seconds]
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
mrnuke has joined #yocto
perdmann has quit [Ping timeout: 252 seconds]
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #yocto
perdmann has joined #yocto
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
amitk has quit [Ping timeout: 268 seconds]
florian_kc has joined #yocto
ptsneves has quit [Ping timeout: 245 seconds]
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #yocto
mvlad has quit [Remote host closed the connection]