<michaelo>
RP: sure, we could do that, but there would be just one link for all Honister point releases (for example).
<qschulz>
michaelo: the issue is that we're missing a lot of yocto- tags in Bitbake
<qschulz>
and we have different numbering schemes for yocto and bitbake
<qschulz>
so I'm not sure how to deal with this
<qschulz>
not entirely sure using YP names in bitbake docs is wise? but I don't know the policy about this
<michaelo>
qschulz: yes, maybe it's sufficient to link to the latest version of each bitbake branch as RP suggested.
<michaelo>
Let me propose a patch to continue the discussion.
<qschulz>
they are technically two differne projects managed by two different communities/maintainers (though it's probably a Venniagram very close to a circle?)
<qschulz>
Venn diagram*
<RP>
Adding the yocto tags to the bitbake docs isn't an issue, we could do that too if someone wants to work them out
<qschulz>
RP: I'm more concerned about the numbering scheme being different and how to make sense of it
<qschulz>
What happens the day we have a Bitbake 2.0? we already have yocto-2.0
<RP>
qschulz: well, yocto version != bitbake version. that would be bitbake-2.0
<qschulz>
and linking in BB docs to docs of one among (possibly) many "users" of BB is a bit odd
<RP>
qschulz: we are publishing them as part of YP
<qschulz>
RP: it was more, how do we deal with exposing this info to the user (e.g. in the URL and in the text)
<qschulz>
RP: since YP docs actually strip the yocto- prefix out of the tags for the URL
<qschulz>
RP: BB, OE and YP projects management differences are still a bit blurry to me so that might not help much with the understanding of the issue (or lack thereof)
<RP>
qschulz: bitbake is meant to be a standalone thing which is allowed it's own versions
<RP>
I've never been a fan of "make everything the same"
<qschulz>
RP: I understand, hence my surprise when I discovered we were linking at YP docs
<qschulz>
but I guess the issue was not the broken links, more that we were pointing to YP docs instead of BB docs
<qschulz>
anyways, slow-brain Tuesday (was about to type Monday... sigh), sorry for the noise
<RP>
qschulz: I think the idea was that docs.yoctoproject.org/bitbake/ was the bitbake docs area
<RP>
since bitbake doesn't have a domain
<qschulz>
RP: yes that's agreed/understood
<qschulz>
michaelo: RP: should we still have "Release series 3.4 (honister)" in BB docs? Why not "Release branch 1.52" instead?
<qschulz>
I guess I should comment this on the patch michaelo just sent
<michaelo>
qschulz: sounds good to me, thanks :)
<RP>
Saur[m]: the other approach is still causing hangs :(
gsalazar_ has joined #yocto
BCMM has joined #yocto
gsalazar has quit [Ping timeout: 246 seconds]
xmn has quit [Ping timeout: 260 seconds]
gsalazar_ has quit [Quit: Leaving]
gsalazar has joined #yocto
bonalais has quit [Quit: Connection closed for inactivity]
Schlumpf has quit [Quit: Client closed]
Schlumpf has joined #yocto
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #yocto
sstiller has joined #yocto
<sotaoverride>
how does yocto do so much better of a job creating a .zip for rootfs.ext than the usual compression utilities. YOCTO knows what portion on the rootfs is just empty space? a 1.4G rootfs.ext4 turns into a 389M rootfs.zip in yocto. Normal zip utilities cant figure what all is just empty space in a rootfs?
Schlumpf has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
<rburton>
sotaoverride: a zip file contains just the file contents, it isn't a file system
<rburton>
file systems have empty space, partition tables, inodes and so on
<rburton>
specifically the .tar.gz is just the file contents
<rburton>
the tar is all of the files, concatenated
<rburton>
its then compressed
<rburton>
the .ext4 is a true file system with layout and structure and empty space, which is then compressed
<rburton>
the tar.gz will be smaller than a ext4.gz, yes
<rburton>
as you're comparing apples and oranges. you can't mount a tar.gz and alter it
<sotaoverride>
so for some reason when I was using the mac zip utility to zip a rootfs.ext4 from my yocto build the size of the zip was still way bigger than what I see when i just append ext.zip to FS_TYPES
<qschulz>
sotaoverride: we use zip with -9 for the compression level by default
<sotaoverride>
while we are on the topic of compression why is it that with .zip files theres a way of seeing what all files are in the .zip, but you cant do the same for .gz? for instance the zipfile python modules has the infolist method to list files in a zip before actually decompressing the zip
ardo has quit [Read error: Connection reset by peer]
<rburton>
so a zip is a format which contains a number of files, and compresses them
<rburton>
.gz is just a stream compression
<rburton>
so you see .tar.gz, which is a tarball (collection of files) which is then compressed
<rburton>
if you have uncompressible files you can just use a .tar and not bother with a time consuming compress stage which won't save any space
<rburton>
or if you have a single large file (say a .ext) you can compress it
ardo has joined #yocto
<rburton>
i imagine .ext4.xz will be smaller again as xz is better than zip typically
<qschulz>
tar -tzf comp.tar.gz should list files inside a tar.gz archive
<rburton>
yeah, tar can automatically run the stream though a (de)compressor for you
<sotaoverride>
so let me get this right, a staight up .gz is a stream, and a tar.gz is a collection of of compressed files?
michalkotyla has joined #yocto
<rburton>
a .tar is a collection of files
<rburton>
typically people then compress it: .tar.gz
<rburton>
(or .tar.xz, whatever)
<sotaoverride>
got it. think i get it..
<rburton>
its the Unix Way: modular pieces. .tar is a collection of files. it can then be compressed, with any tool: xz, bz2, gz. or not, if you're archiving files which are not compressible then there's no point wasting time with pointless compression.
<rburton>
RP: any objection to me running a quick oe-selftest on the AB to test a cleanup series I have?
Schlumpf has joined #yocto
<sotaoverride>
im curious to know why .zip (which for some reason doesnt get a compression type, like tar.xz etc) has more support in python..
<sotaoverride>
is ext4.tar.gz a valid IMAGE_FSTYPE ?
<sotaoverride>
I see this when I try it out ===> tar: Cowardly refusing to create an empty archive
kroon has quit [Quit: Leaving]
sakoman has joined #yocto
<vvn>
if I want /dev/root (or other device symlinks), what is the appropriate way to do this? A udev rule parsing a kernel command line?
<qschulz>
sotaoverride: I don't think it makes sense to have an ext4.tar.gz since ext4 is one file anyway
<qschulz>
sotaoverride: ext4.gz would probably be more appropriate?
<rburton>
sotaoverride: what would .ext4.tar.gz contain? a tarball with a single file (the ext4) in? No point: use ext4.gz.
rob_w has quit [Remote host closed the connection]
<sotaoverride>
cool cool, i swear im getting the hang of this :))
<RP>
I anyone has a minute to review the server/process locking changes I just proposed, I'd welcome review...
<RP>
abelloni: I'd like to test these on the autobuilder, see if it finds any issues this time...
MrFrank has quit [Remote host closed the connection]
mak_GR has quit [Ping timeout: 272 seconds]
leon-anavi has quit [Ping timeout: 272 seconds]
MrFrank has joined #yocto
leon-anavi has joined #yocto
river has left #yocto [WeeChat 3.4.1]
BobPungartnik has joined #yocto
BobPungartnik has quit [Client Quit]
<rburton>
Has anyone run oe-selftest inside a docker? Lots of failures from TUN here, and I'm not sure I can convince IT to let me run the containers privileged.
pgowda_ has quit [Quit: Connection closed for inactivity]
Schlumpf has quit [Quit: Client closed]
<rburton>
RP: any idea why the meta_ide.py selftest is tagged with 'machine'? you did it three years ago :)
<RP>
rburton: yes, it is run on a per MACHINE basis on the autobuilder
<rburton>
cor that tiny subset of selftest took 45 minutes
leon-anavi has quit [Ping timeout: 240 seconds]
florian has quit [Quit: Ex-Chat]
mckoan is now known as mckoan|away
xmn has joined #yocto
rber|res has quit [Quit: Leaving]
<RP>
rburton: that tiny subset includes the gcc, glibc and binutils testsuites too
<RP>
rburton: meta_ide is a trivial 30s of that
<RP>
and the reason we have it is that it is basically a generic IDE environment
<rburton>
well, list-packageconfig-flags is impressively slow
geoff_ has joined #yocto
mak_GR has joined #yocto
<rburton>
abelloni: to avoid Confusion my zlib upgrade is for when master and Kirkstone have diverged
<abelloni>
ack
<abelloni>
I'll probably gives them a try anyway
mak_GR has quit [Ping timeout: 250 seconds]
<rfs613>
rburton: I just had an occurrence of bugzilla #14110 (cve-check 'write to readonly database')
<rfs613>
i'm on dunfell branch, but i have the backport of your mainline fix
<rfs613>
so indeed this confirms your comment #4 on that ticket
<rburton>
can you get the bitbake log to see what was running?
<rfs613>
alas no, the build slaves are in containers that vanish right after build
<rburton>
the output of bitbake will be sufficient
<rburton>
curious what was running in parallel
<rfs613>
actually I think your commit was *not* included, now that I look closer
<rburton>
ah
bonalais has joined #yocto
<khem>
RP: yeah thats fine, go compiler patches we are carrying are a bit jaded so we have this cat and mouse game with every major go release, especially w.r.t. idea of reproducibility differences
<khem>
right now the problem I am running into is the buildid is coming out to be different
<khem>
the buildid has 4 different hashes separated by '/'
<khem>
first two are based on actions in other words - input and last two are based on content in other words output and as we can see last two match ok which is what matters for reproducibility
<khem>
as far as OE is concerned
<khem>
but for go its important to match input IDs too since they dont want to rebuild the archives if they dont have to be, which speeds up compilation so I understand the motive
<khem>
problems with whats considered as part of checksumming input keeps changing and hence the trouble because we are cross compiling its easy to leak absolute paths via file names. libnames , compiler options, C compiler options etc.
tnovotny has quit [Quit: Leaving]
<MrSaturn>
Working with u-boot is incredibly frustrating - devtool doesn't configure/patch, devshell drops me in the git directory (no patches, configuration), and if I go into the "./work/.../build/<MACHINE>" directory all the configuration and patches are applied, but they are not respected during a build. What on earth am I doing wrong? Making patches is proving very difficult
neverpanic has quit [Quit: reboot]
leon-anavi has joined #yocto
neverpanic has joined #yocto
alejandrohs has quit [Ping timeout: 252 seconds]
alejandrohs has joined #yocto
<rburton>
MrSaturn: hm. it doesn't look like its doing anything special. try removing the 'addtask' like from cml1.bbclass?
<rburton>
that looks redundant and might be causing unexpected dependency chains
Minvera has joined #yocto
leon-anavi has quit [Quit: Leaving]
GillesM has joined #yocto
mvlad has quit [Remote host closed the connection]
Minvera has quit [Ping timeout: 260 seconds]
Minvera has joined #yocto
wesm has left #yocto [#yocto]
Minvera has quit [Remote host closed the connection]
<RP>
khem: makes sense, I just wanted to set expectations with the release
bonalais has quit [Quit: Connection closed for inactivity]
GillesM has quit [Quit: Leaving]
codavi has quit [Ping timeout: 272 seconds]
jmiehe has joined #yocto
chrysh has quit [Ping timeout: 268 seconds]
chrysh has joined #yocto
peoliye has joined #yocto
camus has quit [Ping timeout: 260 seconds]
<khem>
RP: btw. I have a fix which is working fine