Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #yocto
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #yocto
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #yocto
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #yocto
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #yocto
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #yocto
<LetoThe2nd>
yo dudX
frieder has joined #yocto
Wouter01001 has quit [Ping timeout: 272 seconds]
mckoan has joined #yocto
wkawka has joined #yocto
<mckoan>
good morning
goliath has joined #yocto
<wkawka>
Good morning
thomasd13 has joined #yocto
ptsneves has joined #yocto
Schlumpf has joined #yocto
manuel1985 has joined #yocto
xmn has quit [Quit: ZZZzzz…]
<qschulz>
o/
<landgraf>
(^_^)/
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
leon-anavi has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
Wouter01001 has joined #yocto
Wouter01001 has quit [Remote host closed the connection]
Wouter01001 has joined #yocto
Guest5 has joined #yocto
mvlad has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
florian has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
florian_kc has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<rburton>
rohieb: so the problem is that the bitbake worker running menuconfig isn't actually attached to your terminal
<rburton>
rohieb: if you use tmux then you can explicitly set the terminal to "start a new tmux window in the existing tmux session" but maybe screen doesn't do that. lib/oe/terminal.py is where you'd improve the screen support so it started a new window in an existing session
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #yocto
<mckoan>
is there a keyword to generate an uncompressed kernel in uImage format? KERNEL_IMAGETYPE is not the right one.
gsalazar has joined #yocto
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #yocto
Guest68 has joined #yocto
<Guest68>
Hi - where's the best place to ask about a problem with bitbake's gitsm handling for a complex git submodule repo?
<rburton>
Guest68: here
<Guest68>
Okay... a customer has a complex proprietary repo that works fine using git submodule update --init --recursive but dies strangely with bitbake and a gitsm:// source url while checking out the submodules
<Guest68>
There are a total of 57 submodules from the toplevel repo, as deep as 4 submodule levels down, with a worst path depth of 10 levels
<qschulz>
"dies strangely"?
<qschulz>
it would help if you had some error message and even better if logs of some sort
<Guest68>
Yes sorry got to collect them, I assumed I would be writing a mailing list, it's coming
<Guest68>
After being able to check out a couple of dozen repos it chokes on one complaining that "Bad owner or permissions on /etc/ssh/ssh_config.d/50-redhat.conf"
<qschulz>
Guest68: mailing list is fine too :)
<Guest68>
That file is unchanged and still works fine, it's root:root 644
<Guest68>
Which mailing list?
td79 has joined #yocto
mateuszmar2 has joined #yocto
<Guest68>
I'm going to guess bitbake-devel and write it up there. Thanks for your help.
<td79>
do_populate_spec: Error contacting Hash Equivalence Server unix:///PATHTOBUILD/build/builds/yoctobuild/hashserve.sock: [Errno 2] No such file or directory
<td79>
Can you help me with debugging? What can be happening here?
<RP>
td79: I have a suspicion that means you reached your process max open file count
<RP>
td79: try increasing it with ulimit -n
dmoseley has joined #yocto
<RP>
td79: we're still trying to work out why it breaks
<td79>
Could be it, because for some recipes it's working correctly
<td79>
I will try it, thanks
<RP>
td79: how many cores on your system?
<RP>
or what is your BB_NUMBER_THREADS I guess?
<td79>
24 and 56, we are not limiting BB_NUMBER_THREADS
<RP>
td79: Thanks, I'd just trying to collect data points. We're not sure why it seems to be doing this for some group of people only (which includes me)
<mateuszmar2>
on slide 19 it says to add BB_LOGCONFIG += “log.json” to local.conf
<mateuszmar2>
"+" character will cause FileNotFoundError because it will look for " log.json" instead of "log.json":
<mateuszmar2>
FileNotFoundError: [Errno 2] No such file or directory: ' log.json'
<mateuszmar2>
Could someone correct this in the presentation?
<rburton>
JPEW: ^^^
goliath has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
xmn has joined #yocto
whuang0389 has joined #yocto
<whuang0389>
Hi, I was wondering if it's possible to generate the license paragraph (instead of license name) of the recipes? Like the text that usually states "Permission is hereby granted blah blah blah"
v0n has joined #yocto
<qschulz>
whuang0389: you have support for NO_GENERIC_LICENSE IIRC
<qschulz>
which is the name to a file in the source directory
<qschulz>
so if you generate the file before it's used by the license mechanism.. maybe?
<qschulz>
but also.. not sure this is legally wise
<v0n>
hi there -- I'm inheriting systemd in a recipe as usual but now bitbake throws an error about Postinstall scriptlets failed. "If the intention is to defer them to first boot, then please place them into pkg_postinst_ontarget:${PN} ().". Did something changed with the systemd class? I never seen that behavior before
<rburton>
RP: so autobuilder-help sets the SDK to i686 by default and then apparently randomly sets it to x86-64 in many builder jobs. the actual bitbake.conf just defaults to a native SDK for the build host, but that is a lot newer than the logic in config.json. shall I just rip out 99% of the SDKMACHINE assignments and let them just use the host? I can't see any issues right now.
<qschulz>
v0n: I assume you do a check on whether ${D} is present
<qschulz>
I think we have a check right now
<whuang0389>
qschulz sorry im a little confused about how a NO_GENERIC_LICENSE would affect the generation of the license paragraph. (I might not be explaing this right haha). I see in my deploy folder a license.manifest which just includes package/recipe name/version/ and license (example MIT, GPLv2, etc..). Was wondering if beneath the license name if Yocto
<whuang0389>
can also generate the associated license parapraph as well
<rburton>
RP: obviously the mingw tests need an explicit SDKMACHINE
<rburton>
whuang0389: generate license packages and iirc you get the full texts
<rburton>
the manifest is a manifest
<whuang0389>
ah i see thx! ill look into that
<rburton>
whuang0389: https://git.yoctoproject.org/poky-contrib/commit/?h=ross/mut&id=af2cfb732b5d8b0c20520f9cb997b18a813aee4d is a tool i wrote to review license texts and might be useful if you want something specific, but you're not saying what your actual need is so it's hard to know
<v0n>
qschulz: my do_install:append:mydistro installs the ${BPN}.service in ${D}${systemd_system_unitdir}/${BPN}.service and FILES:${PN}:append:mydistro is set to " ${systemd_system_unitdir}/${BPN}.service"
<v0n>
I don't do anything special with ${D} myself
otavio has quit [Quit: leaving]
<qschulz>
whuang0389: I went one step too far, don't need NO_GENERIC_LICENSE, just editing/generating the file you mention in LIC_FILES_CHKSUM might be enough.. though... you also need to provide a checksum, so I don't know how thils will work out
<qschulz>
v0n: any postinstall script by any chance in the recipe, or any of the class, bbappend, .inc files it includes?
rob_w has quit [Remote host closed the connection]
<qschulz>
v0n: actually it just means that your pkgpostinst script failed, you need to check why first
<qschulz>
v0n: the whole error message should have "Details of the failure are in" and then the path to the logs
<v0n>
qschulz: no explicit message, only qt-kiosk-browser.postinst returned 1, marking as unpacked only, configuration required on target.
<rburton>
v0n: read-only rootfs?
sakoman has joined #yocto
<v0n>
rburton: I didn't add this image feature
kscherer has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
dev1990 has joined #yocto
dev1990 has quit [Client Quit]
thomasd13 has quit [Ping timeout: 240 seconds]
<v0n>
qschulz: rburton: There's also "Deferring to first boot via 'exit 1' is no longer supported." is there something I should override maybe?
<qschulz>
v0n: I don't think so, it's just that postinst scripts running at build time shouldn't fail
<v0n>
I agree
<qschulz>
before we used to fail them on purpose so they would run on the device at first boot
<ptsneves>
@RP I am trying to remove the DL_DIR default for localpaths but i am baffled at what is the purpose of local.localpaths at all. Can be removed?
dev1990 has joined #yocto
<RP>
ptsneves: no, we have to check not only where we found a source but also where we searched for it
<RP>
ptsneves: if something is inserted into an earlier location in the search path we need to know about it
<ptsneves>
@RP so do you mean that a file can be found in multiple places? What about places we searched but did not find anything, what is the reasons for this in terms of getting a list for checksums?
<ptsneves>
@RP get_file_checksums is the only user of localpaths and in turn it is only used in do_fetch[file-checksums] = "${@bb.fetch.get_checksum_file_list(d)}"
<RP>
ptsneves: no, I don't mean it can be found in multiple places
<RP>
ptsneves: you'll have see the tash hashes which handle all the input to a given task
<RP>
ptsneves: the data in bitbake's cache also has to know which file locations were searched but a file was not found. This is so that bitbake knows when it has to reparse a given recipe
<RP>
so if you add a new file somewhere else in FILESPATH, the task checksums update as it triggers a reparse
<ptsneves>
@RP but right now bitbake knows that, because it is FILESPATH
<RP>
ptsneves: how do you think it knows that though? The answer is this function
otavio has joined #yocto
<ptsneves>
@RP ok, so it confirms my understanding. In this diff https://pastebin.com/M7gRijHp i still use the FILESPATH but bypass the adding of the searched paths to checksum list. This removes multiple file existence checks. It also paves the way to remove localpaths completely. It also makes get_checksum_file_list a method of the Local fetcher, which seems appropriate
<ptsneves>
let me know if this is reasonabe
paowz_ has quit [Ping timeout: 244 seconds]
Schlumpf has quit [Quit: Client closed]
dmoseley_ has joined #yocto
dmoseley has quit [Ping timeout: 272 seconds]
mateuszmar2 has quit [Quit: Client closed]
manuel1985 has quit [Ping timeout: 272 seconds]
paowz_ has joined #yocto
<RP>
ptsneves: Please don't move it to the local fetcher only
<RP>
ptsneves: that breaks eta/classes/base.bbclass:do_fetch[file-checksums] = "${@bb.fetch.get_checksum_file_list(d)}"
<RP>
ptsneves: it also makes it hard to review any other change buried in there
frieder has quit [Remote host closed the connection]
<RP>
ptsneves: it is public *generic* API as it stands today, local only is an implementation detail
acki_ has joined #yocto
<ptsneves>
@RP All right no problem. I was thinking of changing the meta/classes/base.bblclass but i guess this would be tricky regarding poky due to bitbake being decoupled from oe. Ok Let me move things back.
<v0n>
rburton: you don't have a layer providing this host tool yet? ^^
<rburton>
why would it be in a layer?
<rburton>
my goal is to have it pip-installable
<v0n>
rburton: because it's a development tool for the project like bitbake, so I imagine having it bundle as part of my project rather than an host tool?
<rburton>
layers can't add paths to $PATH, so unless you want to do ../path/to/meta-pkgexp/pkgexp every time, it sucks
<rburton>
use the standard cmake pieces to install files, and it just works
<RP>
ptsneves: sorry, I'm trying to reply but handle meetings too
<RP>
ptsneves: that "file-checksums" flag is really important to other pieces of bitbake. In particular it helps decide when a recipe needs to be reparsed, i.e. it controls cache information
<RP>
ptsneves: if you insert a new file with a new checksum into FILESPATH, it needs to reparse and the tasks need to change checksum
<RP>
i.e. the recipe needs to rebuild with the new file
<RP>
To make this work you need to know "where it looked but didn't find" files
<v0n>
rburton: ho, could the error be because my service as Alias=display-manager.service in the [Install] section and this result in adding a symlink not included in FILES:${PN}?
<rburton>
v0n: maybe?
florian_kc has joined #yocto
<acki_>
rburton: is the install folder always "/usr"?
<rburton>
no, it's ${prefix}, which is typically /usr
acki_ has quit [Remote host closed the connection]
acki_ has joined #yocto
wkawka has quit [Quit: Client closed]
mckoan is now known as mckoan|away
florian_kc has quit [Ping timeout: 272 seconds]
manuel1985 has joined #yocto
<Xagen>
i've been working on migrating our image from dunfell to kirkstone, and i'm down to the sdk itself at the end (thank goodness)
<Xagen>
however, it's complaining about some conflicts
<Xagen>
i have linux-firmware and gcc excluded from the package
<Xagen>
and it's complaining about linux-firmware-dev, and gcc-dev
<Xagen>
i tried adding gcc-dev to PACKAGE_EXCLUDE, but that didn't seem to work
<Xagen>
the error looks like this:
<Xagen>
Error:
<Xagen>
Problem 1: package linux-firmware-dev-1:20220411-r0.noarch requires linux-firmware = 1:20220411-r0, but none of the providers can be installed
<Xagen>
- package linux-firmware-1:20220411-r0.noarch is filtered out by exclude filtering
<Xagen>
- conflicting requests
<Xagen>
the gcc one is pretty much the same, just with gcc and gcc-dev
<Xagen>
any suggestions on how to get around this?
<Xagen>
it does suggest (try to add '--skip-broken' to skip uninstallable packages), but i feel like that's not intended to be a permanent solution
manuel1985 has quit [Ping timeout: 272 seconds]
pgowda_ has quit [Quit: Connection closed for inactivity]
manuel1985 has joined #yocto
sotaoverride has quit [Ping timeout: 264 seconds]
whuang0389 has quit [Quit: Client closed]
tgamblin has quit [Ping timeout: 272 seconds]
Guest5 has quit [Quit: Client closed]
ptsneves has quit [Ping timeout: 260 seconds]
gpanders has joined #yocto
<gpanders>
What is the proper way to tell bitbake to ignore a network sstate cache for a given recipe?
<gpanders>
context: the gcc-cross recipe has different output when the FORTRAN variable is set (it builds gfortran). But the network sstate cache I'm using does not include gfortran, so even though I have FORTRAN set it keeps pulling down the prebuilt from the cache and gfortran isn't available in the package output
<gpanders>
it would be nice if changing FORTRAN changed the recipe signature such that bitbake would not try and use the network sstate cache version, but that does not seem to be happening. I'm trying to figure out how to make it do that
acki_ has quit [Remote host closed the connection]
acki_ has joined #yocto
<gpanders>
I've tried creating a gcc-cross_%.bbappend file with 'do_configure[vardeps] = "FORTRAN"' (also with do_populate_sysroot, do_package, do_compile, etc.) but that doesn't seem to have any effect, it still uses setscene from the network cache
td79 has quit [Quit: Client closed]
kscherer has quit [Remote host closed the connection]
beroset has joined #yocto
<beroset>
I'm new to using devtool and I'm having problems.
<beroset>
I did a `devtool modify asteroid-launcher` which worked.
kscherer has joined #yocto
<beroset>
Then `devtool build asteroid-launcher` which failed.
<beroset>
It says "Exception: bb.fetch2.FetchError: Fetcher failure: Recipe uses a floating tag/branch without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE)."
<Xagen>
beroset: just add the SRCREV to your recipe instead of using a tag
<beroset>
But I'm confused because I already have SRCPV in PV. :
<beroset>
```
<beroset>
SRCREV = "${AUTOREV}"
<beroset>
PR = "r1"
<beroset>
PV = "+git${SRCPV}"
<beroset>
```
<Xagen>
beroset: all i can tell you is i removed the tag from my SRC_URI, and added the commit as the SRCREV and the problem went away for my recipes that were complaining
<beroset>
Xagen: So use the specific commit instead of "${AUTOREV}"?
<Xagen>
beroset: basically. i just see what the commit was when that tag was made and use that instead
<beroset>
Trying that now. Thanks!
<beroset>
I changed the lines to these:
<beroset>
SRCREV = "2e0048a"
<beroset>
PR = "r1"
<beroset>
PV = "+git2e0048a"
<beroset>
But it's still making the same complaint.
<beroset>
There is a branch, but no tag specified in the SRC_URI.
dtometzki has joined #yocto
<Xagen>
not sure then, that was the case for all of my recipes that were complaining
<Xagen>
it was SRC_URI = "...;tag=..."
<Xagen>
and i just removed the tag and added SRCREV
<JaMa>
beroset: SRCREV needs to be full-length sha
<Xagen>
JaMa: good call on that, i was doing that already
<beroset>
JaMa: Ah! Thank you.
<Xagen>
didn't know it was a requirement though
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
<beroset>
Success!! Thanks very much Xagen and JaMa!
<Xagen>
excellent
<beroset>
After I get this working, maybe I'll poke around in the `devtool` source to see if we might provide a more informative and useful error message.
<JaMa>
it's unfortunate that SRCREV can be used for sha as well as tag/branch name and then it's difficult to distinguish if the used value is fixed sha or just a tag name which looks like sha (unfortunate people can have a tag name which happens to be 40 characters long and consisting only of [0-9a-f])
<acki_>
rburton: what other install folder exist there?
manuel1985 has quit [Ping timeout: 260 seconds]
<acki_>
except "/usr"?
<Xagen>
JaMa: why the move away from tags anyhow?
<Xagen>
tags are supposed to remain static once made, though admittedly you can change them
<JaMa>
Xagen: tags can be changed without bitbake fetcher noticing the change (and still building the older version)
<Xagen>
so it was really just to explicitly tell it what to check out so there's no confusion
<JaMa>
Xagen: that's why bitbake will always maps them to fixed sha with git ls-remote (and can cache the results which risk of building wrong sha after tag is moved)
<Xagen>
cool
<Xagen>
good to know
nemik has quit [Ping timeout: 260 seconds]
<JaMa>
and doing ls-remote everytime prevents you to build without network access and adds additional parsing time
nemik has joined #yocto
<beroset>
This project uses `SRCREV = "${AUTOREV}"` for a large number of subcomponents. Is that poor practice? Should we be using sha?
<fray>
yes you should use shas and not autorev.
<fray>
in my case, we've got automated programs to update the recipes as part of our CI loop
<JaMa>
depends, AUTOREV is still useful for development, but obviously terrible for reproducible build, good practise is to have recipes with known-to-work fixed SRCREVs and then some .inc file which sets SRCREV to AUTOREV for recipes with active develpment (which will be included only in the builds which really want latest-greatest)
sotaoverride has joined #yocto
<rburton>
acki_: /usr is common, yes
<beroset>
Thanks all, for the insights on the use of AUTOREV.
<rfs613>
JaMa: is there some clever trick to controlling the include of such *.inc files, short of editing the .bb ?
acki_ has quit [Quit: Konversation terminated!]
<v0n>
rburton: a faulty line in the .service file cause the systemctl call to (silently) fail... Fixed now.
<paulg>
silently fail. Nice.
amitk has quit [Ping timeout: 240 seconds]
florian_kc has joined #yocto
BobPungartnik has joined #yocto
BobPungartnik has quit [Remote host closed the connection]
<Xagen>
how do you know what name to add to PACKAGE_EXCLUDE? i have gcc in it, and it complains about gcc-dev needing gcc.
<Xagen>
but adding gcc-dev makes it complain about the name not matching anything
mvlad has quit [Remote host closed the connection]
manuel1985 has joined #yocto
otavio has quit [Ping timeout: 272 seconds]
<rburton>
v0n: bonus points for filing a bug and/or patching the systemctl so it doesn't do that. the one that runs at image time is our stub implementation
<rburton>
somewhere I have a branch where I was experimenting with a systemd-native recipe that just built a systemctl
<hushmoney>
why do all of the files in my rootfs.squashfs have a timestamp of unix epoch?
<rburton>
most likely because reproducible builds is using that as the fallback timestamp
<hushmoney>
oh right, reproducible build. any way to override that? cronie ends up never reading anything from /etc/cron.d because it thinks nothing has changed since unix time 0
<rburton>
it should be a recent date, but maybe the logic went bad in your setup, or you've set REPRODUCIBLE_TIMESTAMP_ROOTFS to 0?
<rburton>
easy way to verify: put tar in your IMAGE_FSTYPE and see if that has the same 1970 timestamps. if it does, then it's reproducible builds, otherwise its the squashfs generation going wrong
<hushmoney>
hmm, no the tar has a march 2018 timestamp
<hushmoney>
if i manually execute the mksquashfs command it has that same march 2018 timestamp
<landgraf>
core-image-weston adds ssh-server-dropbear feature which breaks ptest-pkgs :-/ not fun
beroset has quit [Ping timeout: 244 seconds]
beroset has joined #yocto
leon-anavi has quit [Quit: Leaving]
<beroset>
Is it required to do `undeploy-target` between successive `deploy-target` calls for `devtool`?
<beroset>
In other words, can I do multiple "deploy" steps and still have some assurance that "undeploy" will work correctly?
seninha has quit [Quit: Leaving]
seninha has joined #yocto
beroset has left #yocto [#yocto]
beroset has joined #yocto
manuel1985 has quit [Ping timeout: 276 seconds]
florian_kc has quit [Ping timeout: 240 seconds]
fitzsim has joined #yocto
piwakawaka has joined #yocto
jpuhlman_ has joined #yocto
jpuhlman has quit [Killed (strontium.libera.chat (Nickname regained by services))]
jpuhlman_ is now known as jpuhlman
<piwakawaka>
hi - quick question (I hope). I'm using PetaLinux w/ Yocto and there is a recipe "petalinux-initramfs-image", which for some reason is breaking rm_work.bb - in particular, whatever calls the rm_work task is creating a FIFO first, which then seems to end up being deleted in the do_rm_work main loop, which then causes a file not found error after
<piwakawaka>
do_rm_work has completed and an attempt to delete the FIFO fails. Yet if I add petalinux-initramfs-image to RM_WORK_EXCLUDE then this FIFO isn't created, nor is it deleted (and thus the build works). My question is - what is creating this FIFO in the temp/ dir and what could possibly be causing it to be inadvertently deleted? There's nothing in the
<piwakawaka>
petalinux-initramfs-image recipe I can see that would do this explicitly: https://pastebin.com/mCYBpjPb
<piwakawaka>
The error is essentially: ERROR: petalinux-initramfs-image-1.0-r0 do_rm_work: [Errno 2] No such file or directory: '.../build/tmp/work/zynqmp_generic-xilinx-linux/petalinux-initramfs-image/1.0-r0/temp/fifo.59670'
gpanders has left #yocto [WeeChat 3.4.1]
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
tgamblin has joined #yocto
seninha has quit [Read error: Connection reset by peer]
seninha has joined #yocto
seninha_ has joined #yocto
seninha has quit [Read error: Connection reset by peer]
seninha_ has quit [Quit: Leaving]
tombs has joined #yocto
kscherer has quit [Quit: Konversation terminated!]
<tombs>
Hi all, I am having trouble with PREFERRED/REQUIRED_VERSION on Kirkstone:
<tombs>
I set "PREFERRED_VERSION_tegra-bootfiles = "32.7.1-AB" in myimage.bb but it does not seem to have any effect (REQUIRED_VERSION likewise appears to be ignored)