<JaMa>
SivaKrc: gatesgarth is EOL for over a year, try reproducing the issue in newer supported release and then you might find a fix to backport in your gatesgarth based build
florian_kc is now known as florian
florian has quit [Ping timeout: 260 seconds]
florian has joined #yocto
SivaKrc has quit [Quit: Client closed]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
d-s-e has joined #yocto
rber|res has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
d-s-e has quit [Ping timeout: 260 seconds]
d-s-e has joined #yocto
d-s-e has quit [Client Quit]
d-s-e has joined #yocto
d-s-e is now known as dse
dse is now known as d-s-e
rusam has quit [Remote host closed the connection]
halstead has quit [Read error: Connection reset by peer]
awafaa has quit [Read error: Connection reset by peer]
denix has quit [Read error: Connection reset by peer]
diamondman has quit [Read error: Connection reset by peer]
praneeth has quit [Read error: Connection reset by peer]
awafaa has joined #yocto
darknighte has quit [Read error: Connection reset by peer]
mithro has quit [Ping timeout: 246 seconds]
kergoth has quit [Ping timeout: 260 seconds]
fancer has quit [Ping timeout: 260 seconds]
armpit has quit [Read error: Connection reset by peer]
mdp has quit [Read error: Connection reset by peer]
armpit has joined #yocto
rmmr has quit [Read error: Connection reset by peer]
madisox has quit [Read error: Connection reset by peer]
halstead has joined #yocto
ldts_ has quit [Read error: Connection reset by peer]
rburton has quit [Read error: Connection reset by peer]
bradfa has quit [Read error: Connection reset by peer]
paulbarker has quit [Read error: Connection reset by peer]
dl9pf has quit [Read error: Connection reset by peer]
jonmason has quit [Read error: Connection reset by peer]
dagmcr has quit [Read error: Connection reset by peer]
NishanthMenon has quit [Read error: Connection reset by peer]
jonmason has joined #yocto
diamondman has joined #yocto
paulbarker has joined #yocto
denix has joined #yocto
ldts_ has joined #yocto
praneeth has joined #yocto
bradfa has joined #yocto
rmmr has joined #yocto
fancer has joined #yocto
mdp has joined #yocto
madisox has joined #yocto
dagmcr has joined #yocto
dl9pf has joined #yocto
rburton has joined #yocto
darknighte has joined #yocto
NishanthMenon has joined #yocto
mithro has joined #yocto
rburton has joined #yocto
rburton has quit [Changing host]
darknighte has joined #yocto
darknighte has quit [Changing host]
kergoth has joined #yocto
florian_kc has joined #yocto
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #yocto
fleg has joined #yocto
d-s-e has quit [Ping timeout: 248 seconds]
seninha has joined #yocto
wkawka has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
zpfvo has quit [Ping timeout: 260 seconds]
florian_kc has joined #yocto
<wkawka>
Hi, I have a fetching problem: bitbake cannot find revision in given branch or even upstream. I went to the repo and commit with this hash exists, however I got this communicate: This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository. Can I somehow enable bitbake to trace this commit if it
<wkawka>
is visible here or have I to search for it. How can I find it then?
mckoan is now known as mckoan|away
<qschulz>
wkawka: find the fork which has this commit
<qschulz>
wkawka: how come you decided to use this commit for your software?
<qschulz>
You had to stumble on it for some reason, how?
<wkawka>
In fact that wasn't me before, now this repo has above 1 million commits and a lot of forks...
<qschulz>
wkawka: hehehe, Linux forks :)
<qschulz>
you'll need to do some elaborate guessing based on git history
<qschulz>
depending on what you want to do, you could also find the "base" commit of this commit that belongs to the official Linux git repo
<rburton>
wkawka: if you can't find it in a branch (sometimes maintainers delete branches, which isn;t useful) then worst case set nobranch=1 in the url
<qschulz>
then have all the commits above this one as patches in your recipe
<qschulz>
wkawka: also, you could always find an old build where this used to work (did it ever work>?) and then push this to one of your git repos
<qschulz>
rburton: it's in a fork, it's this bad UX from Github
<qschulz>
which shows you a git commit from a fork in the URL of the main git repo
<qschulz>
I don't think nobranch=1 would help with that since it's not part of the git repo you're currently looking at
<wkawka>
Now I am searching it in forks, and this commit is present in every fork so far
<rburton>
(just search github's front page for the sha)
<qschulz>
wkawka: FWIW, mirror everything that you aren't hosting yourself already, even open-source upstream are sometimes making some mistakes or breaking stuff
<qschulz>
(the master->main rename for example)
RobertBerger has joined #yocto
<qschulz>
rburton: thanks for the sha lookup tip, neat
seninha has quit [Quit: Leaving]
rber|res has quit [Ping timeout: 260 seconds]
<ernstp>
I'm trying to upgrade python3-setuptools. python3-setuptools-native runs fine. python3-setuptools DEPENDS on python3-setuptools-native, but I still get an old python3-setuptools native in recipe-sysroot-native when running the python3-setuptools build
<ernstp>
the old python3-setuptools-native in the sysroot make some python import conflict with the new python3-setuptools
<rburton>
did the upgrade involve changing the build tool?
<ernstp>
Hmm, maybe I need to make a more complicated recipe, it's quite a special tool...
<rburton>
note that python3-setuptools already sets INSTALL_WHEEL_COMPILE_BYTECODE:class-native = "--no-compile-bytecode" because of problems like that
<rburton>
unless you're trying to backport the upgrade to a stable branch, which explains the problem
<ernstp>
rburton: no, just plain old inherit setuptools3
<ernstp>
rburton: on a stable branch.
<ernstp>
dunfell
<rburton>
pastebin the error would help, and what versions
<ernstp>
rburton: but I was a bit interested in the general issue of why it didn't trigger a rebuild recipe-sysroot-native
<rburton>
without the errors its impossible to say
<rburton>
but what likely happened is that the old version removed its files, but there were generated .pyc files that bitbake doesn't know about
<rburton>
new package then ships those files and they conflict
<ernstp>
Aaaah because I didn't do inherit native! :-)
<ernstp>
I just made a way too simple pypi setuptools recipe, I need to replicate all the details of the original recipe. or just bbappend instead
<rburton>
erm yeah don;t make a new recipe, take one that actually works from master
<ernstp>
bitbake -s | grep setuptools
<ernstp>
python3-setuptools :65.5.1-r0
<ernstp>
python3-setuptools-native :45.2.0-r0
<rburton>
the recipe has patches and complicated bits for good reasons
<ernstp>
was pretty clear :-)
<ernstp>
yup yup... otherwise packaging python stuff is very simple usually :-)
<ykrons>
Hi all, I have an image that build rootfs.ext4.gz and bootfs.tar.xz and I would like to have a bootfs.vfat.gz. It seems vfat is not supported by default and it is not obvious how to bootfs.tar.xz is generated today. Where can I found some documentation how to add a FSTYPE ?
<LetoThe2nd>
yo dudX
<qschulz>
ykrons: look into meta/classes/image_types.bbclass
<qschulz>
what you're after is a new IMAGE_CMD:vfat
<qschulz>
the gz compression should be handled already
<qschulz>
ykrons: to enable it, you'll need to add vfat.gz to IMAGE_FSTYPES in your image recipe or in a configuration file
<qschulz>
also add vfat and vfat.gz to IMAGE_TYPES in the image_types.bbclasss
<qschulz>
and I think that should be it
<rburton>
ykrons: wic can make fat partition iirc, (type 'msdos')
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #yocto
<rburton>
zeddii: fyi, i just looked at a perf do_install, and it's doing a lot of compilation...
<ykrons>
qschulz: thanks I will have a look and test it
<zeddii>
rburton: IIRC it always has, yes. The make targets are a bit funky, and with the supporting of every random kernel version, I never looked into it in much detail
<rburton>
zeddii: kernel make files being janky? say it isn't true!!
<ykrons>
rburton: my goal is to prepare raw images to be included in a SWU (SWUpdate) archive. I have never used wic, but my understanding is that it lets you generate your images out of yocto with wic command, so not sure it is suitable in my case
<rburton>
ykrons: its integrated, many machines use wic to build their images.
wkawka has quit [Quit: Client closed]
<d-s-e>
Hi, when I build an image the resulting filenames usually contain a timestamp, but also symlinks with simple names are created. When I build a container image this is only done for soem files, not for the rootfs-oci.tar file I need. How can I do this?
florian_kc has quit [Ping timeout: 260 seconds]
florian_kc has joined #yocto
sakoman has joined #yocto
kscherer has joined #yocto
rusam has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
AKN_R has quit [Read error: Connection reset by peer]
prabhakarlad has quit [Ping timeout: 260 seconds]
davidinux has quit [Ping timeout: 248 seconds]
davidinux has joined #yocto
zpfvo has joined #yocto
dmoseley has joined #yocto
rusam has left #yocto [Leaving...]
amgedr has joined #yocto
Schlumpf has quit [Ping timeout: 260 seconds]
<ykrons>
rburton: I have only found examples where a wic.gz is generated and it corresponds to a whole disk image including several partitions. On my side I have the need to generate a raw partition image and not a whole disk. I'm not sure it can be achieved with WIC. Is it ?
dse has joined #yocto
d-s-e has quit [Ping timeout: 260 seconds]
<kergoth>
Shouldn't need wic for that, just a .ext4 or the like, yeah?
zpfvo has quit [Ping timeout: 248 seconds]
goliath has quit [Quit: SIGSEGV]
<rburton>
zeddii: do you plan on pushing b8cd0e429bf75b673c438a8277d4bc74327df992 upstream at some point :) we've been carrying it since 2012 and just discovered it's still needed (vanilla kernel has buildpaths in the perf python module)
gsalazar has joined #yocto
<ykrons>
kergoth: yes but I'm targetting vfat filesystem, not supported by default by Yocto. rburton points that wic support fat
<kergoth>
ah, sorry, missed that. it wouldn't surprise me if wic could be set up to avoid creating a partition table, maybe check the capabilities of .wks?
<kergoth>
i know it can write raw images to specific addresses in the disk image
zpfvo has joined #yocto
rob_w has quit [Remote host closed the connection]
tlwoerner_ has quit [Quit: Leaving]
<ykrons>
ok thanks
Tokamak_ has joined #yocto
tlwoerner has joined #yocto
Tokamak has quit [Ping timeout: 255 seconds]
davidinux has quit [Ping timeout: 260 seconds]
davidinux has joined #yocto
amgedr has quit [Quit: Leaving...]
Notgnoshi has quit [Ping timeout: 268 seconds]
dse has quit [Quit: Konversation terminated!]
<qschulz>
any idea if/what for pylint is required for the host?
<qschulz>
we've got someone on the ML (rightfully) complaining that our list of required packages does not work for newer Ubuntu releases because pylint3 got renamed to pylint
<qschulz>
but it seems Ubuntu/Debian is the only one with pylint in its list of requirements
<qschulz>
the dependency was added by Scott more than 3 years ago and sadly we can't ask him anymore :/
<qschulz>
just to know if michaelo or someone else should fix this pylint3 rename for Ubuntu, but also add it to Fedora, CentOS, Suse, image requirements or if we should just remove it
zpfvo has quit [Ping timeout: 248 seconds]
rber__ has joined #yocto
<rburton>
qschulz: its not actually needed
<rburton>
the autobuilder uses it, but users don't need it
<qschulz>
rburton: thanks
Schlumpf has joined #yocto
RobertBerger has quit [Ping timeout: 246 seconds]
goliath has joined #yocto
rfuentess has quit [Read error: Connection reset by peer]
zpfvo has joined #yocto
prabhakarlad has joined #yocto
<RP>
It should an autobuilder dependency only
florian_kc has quit [Ping timeout: 252 seconds]
otavio has quit [Remote host closed the connection]
otavio has joined #yocto
frieder has quit [Remote host closed the connection]
Schlumpf has quit [Quit: Client closed]
zhmylove has quit [Quit: Leaving]
denix0 has joined #yocto
zpfvo has quit [Quit: Leaving.]
<denix0>
RP, rburton: got a weird problem with meta-arm... there are 2 versions of optee in kirkstone - newer 3.16 and a very old 3.14 that is only used by a single platform
gsalazar_ has joined #yocto
<denix0>
RP, rburton: if I don't mess with preferences, 3.16 gets built, which is expected. but once I add a bbappend in meta-ti that is not version-specific with % wildcard, I suddenly get older 3.14 built, which fails
<rburton>
that's very odd, and almost certainly not something meta-arm is doing
<rburton>
are you sure the bbappend isn't doing something thats messing up the parse?
gsalazar has quit [Ping timeout: 260 seconds]
<rburton>
wildcard appends are "interesting" and you have to be careful
gsalazar_ is now known as gsalazar
<denix0>
RP, rburton: yeah, not sure if it's a bug. my current options are: 1. make bbappend in meta-ti specific to 3.16 and set PREFERRED_VERSION as well. 2. add DEFAULT_PREFERENCE="-1" to 3.14 recipe in meta-arm
<rburton>
denix0: can you share your append?
<rburton>
does an empty append have the same behaviour?
<marek60>
weird is that on one machine it report that and on other everything is fine
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
roussinm has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
<roussinm>
I get an illegal instruction on llvm-config from meta-clang, I think it's because the native build was done on a ci machine with different cpu instruction set. And it got pulled from sstate-cache, is that possible?
nemik has joined #yocto
<roussinm>
When it compiles llvm-config it uses the g++ from hosttools.
gsalazar has joined #yocto
<rburton>
roussinm: yes, if something is stupidly using -march=native
<rburton>
roussinm: i was thinking of a relevant commit but it was your libffi one :)
<roussinm>
rburton: Indeed, I was looking for this, and I just found it, I guess clang/llvm_config could use something similar.
<roussinm>
rburton: looking at compilation logs there is no -march=native, but I guess the compiler on one of those machine isn't using an instruction set that is generic enough.
<rburton>
what distros are the machines using?
<roussinm>
Both Debian buster.
<rburton>
at least that's not something crazy :)
<rburton>
i'd start by building clang-native on each from scratch and comparing the binaries and logs. reproducible builds *should* be giving you fairly similar binaries.
<roussinm>
cpu1: X5675, cpu2: E5-2630
demirok has quit [Quit: Leaving.]
<rburton>
c'mon arm selftest, stop taking so long
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<RP>
marka: you're having fun with bitbake :)
<RP>
marka: reading about cookie monsters and wondering about the people who wrote it?
* RP
misses zecke
goliath has quit [Quit: SIGSEGV]
hays has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
roussinm has quit [Ping timeout: 260 seconds]
roussinm has joined #yocto
florian_kc has joined #yocto
seninha has quit [Remote host closed the connection]