<jclsn>
LetoThe2nd: Alright, I will see what I can do
<LetoThe2nd>
jclsn: +1
<linex[m]>
in the error string the escape characters are shown, but matrix removed them
<RP>
ptsneves: see @skipIfNoNpm()
<RP>
(fetch.py in tests)
<ptsneves>
RP: thank you :)
<RP>
ptsneves: basically create a suitable test decorator
<ptsneves>
OK i saw. This is good. It is also better than what happens in the current git lfs tests where the test always executes but has different behavior conditional on git-lfs
<mcfrisk_>
Are the yoctoproject.org website source somewhere available? I'd like get "News" added to the top bar menus, maybe under "About". The "News" link and posts are hard to find otherwise.
<RP>
JaMa: I have been meaning to apply a patch
<RP>
mcfrisk_: short answer is no :/
<RP>
mcfrisk_: ask ndec ;-)
<RP>
mcfrisk_: the website is a sore point for me :/
<jpman>
Hi! I'm trying to use devtool to modify the initscripts recipe (I want it to result in a .bbappend and patch in my own layer)
<jpman>
However in the workspace/sources/initscripts folder all the files are symlinks to the oe-local-files subdirectory and if I change a file, no changes are detected by git. I don't really understand how to apply my changes?
florian_kc has joined #yocto
zpfvo has quit [Ping timeout: 248 seconds]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
jpman has quit [Quit: Client closed]
zpfvo has joined #yocto
_azcraft has joined #yocto
azcraft has quit [Ping timeout: 246 seconds]
amitk__ has joined #yocto
jpman has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
amitk_ has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
_azcraft has quit [Ping timeout: 260 seconds]
mihai has quit [Quit: Leaving]
florian_kc has quit [Quit: Ex-Chat]
florian_kc has joined #yocto
seninha has joined #yocto
azcraft has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<ccf>
Ahoj, how to use explicitly GPT instead of msdos for wic?
amitk__ has quit [Ping timeout: 260 seconds]
yannd has quit [Ping timeout: 260 seconds]
hcg has quit [Quit: Client closed]
yannd has joined #yocto
prabhakarlad has joined #yocto
d-s-e has quit [Ping timeout: 255 seconds]
rob_w has quit [Quit: Leaving]
jpman has left #yocto [#yocto]
Poppy has joined #yocto
<Poppy>
Hey, I'm using ${@bb.utils.contains('MACHINE_FEATURES', 'yyyyy', ' file://xxxxxxx.scc', '', d)} to configure linux kernel. Can I also use DISTRO_FEATURES here or it's forbidden ?
<landgraf>
ccf: Zdar! try --ptable gpt ?
tomzy_0 has joined #yocto
<tomzy_0>
Hello
<tomzy_0>
is this normal? `0: linux-yocto-5.15.78+gitAUTOINC+f475b1a9de_d3aa5916b2-r0 do_fetch - 2h24m5s (pid 32341) 87%`
<tomzy_0>
should it take ~2,5h to just fetch kernel sources?
<Poppy>
ejoerns[m] stupid question. Thx!
<ejoerns[m]>
Poppy: actually you can do anything that the parser accepts (only if that's good idea is another question ;) ). Selecting specific kernel functionality required by a distro feature sounds like a valid use case for me :) Anyway, stupid questions don't exist ;)
Poppy has quit [Quit: Client closed]
<ejoerns[m]>
RP: A short follow-up on the question of putting barebox in oe-core: You raised concerns about test coverage in the autobuilder. Could you provide me some hints on what kind of test and test cases would be required to give you a better feeling here? I am totally with you that what isn't tested is presumably broken.
<kanavin_>
ejoerns[m], as barebox is a bootloader, I suppose we need to test that it can boot a system under qemu?
<ejoerns[m]>
kanavin_: yes, could you point me at existing tests for u-boot for example? Or are there test cases that are not part of the oe-core/poky git?
<ejoerns[m]>
It would be helpful to have a blueprint for this
<ejoerns[m]>
Are we talking about something in meta/lib/oeqa/selftest ?
<kanavin_>
ejoerns[m], I don't think there's anything in oe-core for u-boot. we test that it builds, that's all.
<kanavin_>
ejoerns[m], which begs the question, why place barebox in core? Can it be in meta-oe?
<kanavin_>
ejoerns[m], the blueprint would be: - build a complete, working image with barebox for a physical target on which it is well tested, and verify that the image boots
yannd has quit [Ping timeout: 246 seconds]
<ejoerns[m]>
kanavin_: my impression was that a bootloader is a core component of a system :)
<kanavin_>
- then switch the MACHINE to qemux86_64 and build the same image until all bitbake errors are addressed
<kanavin_>
- then give that image to runqemu and see what happens until qemu boots to a command prompt
<ejoerns[m]>
kanavin_: that's a single run. That's not what I would understand as CI. I can set it up on my own build server, but my impression was that @RP was referring to something more official
<kanavin_>
- then wrap the steps into selftest (this is the easiest part)
<ejoerns[m]>
kanavin_: ah, ok.
<kanavin_>
ejoerns[m], bootloader is a core component of a system, but you need to explain why barebox fulfils a broadly useful scenario which can't be fulfilled by existing oe-core bootloader options
<kanavin_>
(this is typically the criteria for adding to oe-core)
<ejoerns[m]>
kanavin_: ok, at least I already saw that there is a runqemu helper etc. in the selftest, thus this it seems like I have to dig into using this and how to prepare a valid check for sucessful boot etc. thanks!
<ejoerns[m]>
kanavin_: yes, that this needs a little justification is clear to me. I have dropped my point of view in the corresponding mail thread already :)
<kanavin_>
ejoerns[m], I looked at barebox website and it says nothing about why pick it over u-boot (which it was originally forked from if I understand right)
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
<ejoerns[m]>
kanavin_: It is not the primary goal of barebox to measure with u-boot or tell who is better. It was forked 14 years ago, so very little of the code base is still common.
<kanavin_>
ejoerns[m], otherwise barebox can live in meta-oe. The criteria for inclusion to that are much less strict.
<ejoerns[m]>
kanavin_: we also have multiple init systems. Our idea was that a single additional bootloader recipe with limited impact will not harm but give the freedom to choose
<kanavin_>
ejoerns[m], that's what layers are for. Keep in mind that anything added to core adds to the maintainer burden too, especially if the original contributor loses interest (and they most often do).
<ejoerns[m]>
kanavin_: there are other recipes for barebox, too. We have maintained them for quite a while. Having a single valid source was also one of the motivations. We have agreed on with the maintainer of meta-barebox a while ago that having it in oe-core would be a benefit
<kanavin_>
on the other hand, this external layer seems well maintained.
<ejoerns[m]>
kanavin_: I am fully aware of this, yes
<kanavin_>
ejoerns[m], for what it's worth we support and test two different init systems, and that effectively *doubles* the workload on the CI. We can't possibly afford to test another.
<ejoerns[m]>
kanavin_: Just out of curiosity, do you know of other (more or less) established open source bootloaders living in their distinct oe layer only?
qschulz has quit [Remote host closed the connection]
ptsneves has quit [Ping timeout: 255 seconds]
qschulz has joined #yocto
tomzy_0 has quit [Quit: Client closed]
qschulz has quit [Remote host closed the connection]
<ejoerns[m]>
kanavin_: ah, good catch, haven't thought of efibootguard, yes. But it also only partly addresses the embedded device zoo. (However, I know EFI becomes more and more popular on non-x86, too)
sakoman has joined #yocto
hnez_ has joined #yocto
sgw has quit [Quit: Leaving.]
sgw has joined #yocto
ptsneves has joined #yocto
<RP>
kanavin_: whilst I know we do have a high bar to oe-core recipes, I am leaning to giving barebox a chance
<RP>
ejoerns[m]: I've wanted to see something like an ARMa bootloader + image being tested under our runqemu for a while. If we have a testcase doing that, it would probably sway me :)
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
d-s-e has joined #yocto
<kanavin_>
ejoerns[m], existing test cases for efi bootloaders under qemu are in
<kanavin_>
so you could study that as a starting point
<kanavin_>
(I have no idea why efibootpartition.py is separate, it looks like it should be folded into wic.py)
<RP>
kanavin_: I'm guessing it was written as efi testing rather than wic testing?
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
<kanavin_>
RP: it follows the same patterns as many wic tests: make a wic image with a custom wks config, then boot that
<RP>
kanavin_: right, but I suspect the intent was to test efi which happened to use wic rather than the other way around
Thorn has quit [Quit: Given the choice between you, I'll take the sea-sick crocodile.]
* RP
is still feeling rather unwell. Not sure what is going on, it isn't viral afaik :/
<kanavin_>
RP: there are numerious qemu based efi tests in wic.py too :) probably could be consolidated and cleaned up if someone has the drive
<RP>
kanavin_: fair enough :)
Haxxa has quit [Ping timeout: 255 seconds]
sakoman has quit [Quit: Leaving.]
<ejoerns[m]>
RP: thank you for being open to that idea :)
<ejoerns[m]>
kanavin_: thank you for the pointers into test code!
sakoman has joined #yocto
<ejoerns[m]>
RP: I hope you don't feel unwell from looking into test code ;) Anyway, get well soon!
<kanavin_>
ejoerns[m], I concur with RP, if you can write nice test cases for virtualized hardware, I'll warm up significantly :) we do not have anything like that for u-boot, so that'll give barebox an edge over it.
amitk has quit [Ping timeout: 252 seconds]
<ejoerns[m]>
kanavin_: hehe, let's see if I can placate you ;) Anyway, in the end we should have test cases for both I guess. But let's not promise to much first of all :D
amitk has joined #yocto
Haxxa has joined #yocto
<kanavin_>
ejoerns[m], pardon my ignorance, can barebox boot on EFI systems such as a common pc?
<ejoerns[m]>
kanavin_: u-boot should be able to boot from UEFI, too. Also to provide runtime services, etc. But I have to admit that I haven't tried myself, yet.
prabhakarlad has quit [Quit: Client closed]
zpfvo has quit [Ping timeout: 246 seconds]
prabhakarlad has joined #yocto
zpfvo has joined #yocto
Estrella has joined #yocto
<linex[m]>
how can I download 2 files from 2 different sources and have their checksums checked, I keep getting error about the checksum of one of the file being incorrect...
<linex[m]>
or can I only download one file per recipe ?
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
_azcraft has joined #yocto
<kanavin_>
linex[m], if you show the recipe lines, we can suggest how to fix them
azcraft has quit [Ping timeout: 246 seconds]
_azcraft has quit [Remote host closed the connection]
_azcraft has joined #yocto
<p34nuts[m]>
Hi, I started doing some research to implement a custom source tracing mechanism for do_unpack as RP proposed at yesterday's meeting. Even if we will not use git, I first looked at what git does to detect worktree changes without recalculating all file checksums every time, in order to possibly use the same logic: basically, git creates an file index with lstat output (no checksums) and it checks for lstat output changes (st_size, st_mtime,
<p34nuts[m]>
st_ctime, etc.). However, it's not so easy as it seems, because, at least in Linux, file timestamp resolution may be not be as reliable as one may expect - i.e. even if the filesystem allows for nanoseconds resolution, there are frequent cases in which the saved value has just seconds resolution (...). This causes a race problem when performing multiple file tree changes and indexing operations in a very short time, possibly in less than one
<p34nuts[m]>
second (like we need to do to trace do_unpack operations...), that may lead to false negatives (undetected file changes). The way git handles this is described here https://github.com/git/git/blob/master/Documentation/technical/racy-git.txt . I guess that we need to try to use the same logic... any thoughts on this?
<RP>
p34nuts[m]: I don't think we need to track changes, just track each unpack to a tmpdir and move after that single srcuri unpacks?
<p34nuts[m]>
RP: that may be tricky, because we'd need to make assumptions on how the different unpack methods handle existing file overwrites. We may assume that existing files and directories are always overwritten by the next src_uri, and reproduce the same behaviour when moving stuff after every src_uri unpack, but would that be safe?
goliath has quit [Quit: SIGSEGV]
<RP>
p34nuts[m]: I think we can safely say that each overwrites the last
<otavio>
ejoerns[m]: kanavin_: good we reached an agreement :-)
<p34nuts[m]>
<p34nuts[m]> "that may be tricky, because we'd..." <- RP: I'm concerned about corner cases, in which different src_uri unpacks create a directory with the same name, but with different files inside of it. What is the expected behavior? Merging the contents, or deleting the old files while keeping only the new ones?
<RP>
p34nuts[m]: I'd imagine a merge is the only sane outcome
dev1990 has joined #yocto
<linex[m]>
@kanavin_ thank you :)
amitk_ has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
<p34nuts[m]>
<RP> "p34nuts: I'd imagine a merge..." <- I agree, but I'm thinking about the following corner case: first http srcuri unpack creates a folder named `foo/` and puts stuff inside of it. The next (wrong) git srcuri unpack tries to checkout a repo inside `foo/`. That's a mistake by who wrote the recipe, but currently if one tries to do that they would get an error, because git refuses to clone stuff to a non-empty dir. By implementing a "unpack
<p34nuts[m]>
to tmpdir, trace stuff, move to workdir and merge stuff" process, no exception would be raised. That would be a different behaviour than the current one. Would that be acceptable?
<p34nuts[m]>
* I agree, but I'm thinking about the following corner case: first http srcuri unpack creates a folder named `foo/` and puts stuff inside of it. The next (wrong) git srcuri unpack tries to checkout a repo inside `foo/`. That's a mistake by who wrote the recipe: currently if one tries to do that they would get an error, because git refuses to clone stuff into a non-empty dir. By implementing an "unpack to tmpdir, trace stuff, move to workdir
<p34nuts[m]>
and merge stuff" process, no exception would be raised. That would be a different behaviour than the current one. Would that be acceptable?
Net147 has quit [Ping timeout: 252 seconds]
<RP>
p34nuts[m]: I think that is probably something we could live with
<p34nuts[m]>
RP: Great! That makes things much easier 🙂
seninha has quit [Ping timeout: 246 seconds]
<JaMa>
is it possible to reuse build-st with oe-selftest? or should I just delete it between tests and make sure it can reuse sstate-cache from regular build directory?
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
<moto-timo>
good question... I never figured out how to re-use, but I am not a frequent user
<RP>
JaMa: we stopped supporting it as there were just too many variables what could break things
<RP>
JaMa: on the autobuilder we just make sure if can access the sstate cache
<JaMa>
OK, will try to do the same, finally got some courage to finish the consistent build artifacts change :)
brazuca has joined #yocto
<RP>
JaMa: 5 days before feature freeze? :)
seninha has joined #yocto
<JaMa>
RP: yes, to send it when Nanbield is open :)
<RP>
JaMa: fair enough :)
<JaMa>
to be honest I don't feel so strongly about it (other than feeling bad for opening that bugzilla ticket) what I did in LGE is ugly, but works. The autobuilder failures show that there is a lot of hardcoded assumtions of the default naming scheme .. e.g. should initramfs image contain .rootfs. suffix in filename or not?
<RP>
JaMa: I'm torn on it too. We do have a lot of assumptions :/
<JaMa>
the proposed changes makes the naming more consistent and more customizable, but that requires all assumptions to respect those customizations
<JaMa>
and it gets even worse with some ugly IMAGE_FSTYPES implementations I've seen in the wild
Net147 has quit [Ping timeout: 255 seconds]
<RP>
JaMa: we don't have to do it :)
<JaMa>
but then I would have to live with the ugly implementation in webOS forever :)
<JaMa>
so I plan to fix all selftest issues which were detected on autobuilder before and send one more RFC to see what others say
<JaMa>
and then either get it merged or shed tear and drop it from my branches :)
<RP>
JaMa: fair enough. I think for a change like that it would need to be earlier in a release as layers will need to adapt
kevinrowland has joined #yocto
<JaMa>
hmm did "ptest" ever worked as an override? in libssh2 there is SRC_URI:append:ptest = " file://0001-Don-t-let-host-enviroment-to-decide-if-a-test-is-bui.patch" and the .patch file has Malformed Upstream-Status autobuilder is not complaining about AFAIK :)
<JaMa>
and yes parsing time is more visible in interactive development, but in the end I almost always have to build something which takes significantly longer :)
florian_kc has quit [Ping timeout: 255 seconds]
<JaMa>
even with this change it doesn't take long enough for me to fetch another coffee, even when I'm using a lot of layers :)
<JaMa>
and compared to 16 hours of parsing EXTERNALSRC checksums (before the recent fix) even the do_compile times aren't so bad :)
<JaMa>
need to learn how to swap floppies faster I guess
LocutusOfBorg has quit [Quit: ZNC 1.8.2+deb1 - https://znc.in]
LocutusOfBorg has joined #yocto
<RP>
JaMa: exported_keys has getVarFlag(XXX, False)
<RP>
JaMa: I removed the False in the new version
<JaMa>
but not in the one you sent to ML, if I see it right
<tlwoerner>
vvmeson: does the first v stand for "vacation"?
<RP>
JaMa: I've messed something up :/
<RP>
JaMa: sent a v2
<tlwoerner>
abelloni: thanks for the feedback. in the future i guess it would be prudent for me to test my patches against all poky machines?
florian_kc has joined #yocto
<abelloni>
it would be preferrable but it is okay to catch that with the AB
<abelloni>
I honnestly don't expect anyone to build for meta-mingw
<tlwoerner>
lol
<abelloni>
but beaglebone could have been part of your test set
<tlwoerner>
np
<JaMa>
RP: thanks, now I see the difference
<JaMa>
RP: do we want to show something in debug output when networking is enabled? my old patch had this chunk https://git.openembedded.org/bitbake-contrib/commit/?h=jansa/master&id=7aca33cb7a106957bc93ad872d79f53ba99d0212 when I was originally wondering why it stopped working (which was due to icecc.bbclass change)
goliath has quit [Quit: SIGSEGV]
<RP>
JaMa: not sure
<JaMa>
no strong opinion from me, it was useful when I was debugging this, but I don't expect this to debug these 5 lines again :)
Thorn has quit [Ping timeout: 260 seconds]
Jham has joined #yocto
Jham has quit [Client Quit]
woky_ has quit [Quit: Nothing in this world is hopeless!]
woky_ has joined #yocto
<RP>
JaMa: I think I agree, I'm not sure it would be useful in general
<RP>
JaMa: I have piles of debug patches locally :/