otavio has quit [Remote host closed the connection]
ana_gasi has quit [Ping timeout: 256 seconds]
florian has quit [Ping timeout: 252 seconds]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
Guest33 has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
Guest33 has quit [Ping timeout: 256 seconds]
otavio has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 252 seconds]
troth has quit [Ping timeout: 252 seconds]
troth has joined #yocto
vd has quit [Ping timeout: 256 seconds]
vd has joined #yocto
xantoz has quit [Ping timeout: 252 seconds]
xantoz has joined #yocto
Vonter has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
xmn has quit [Ping timeout: 256 seconds]
prabhakarlad has quit [Quit: Client closed]
troth has quit [Ping timeout: 268 seconds]
vd has quit [Ping timeout: 256 seconds]
sakoman has quit [Quit: Leaving.]
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
troth has joined #yocto
Vonter has joined #yocto
troth has quit [Ping timeout: 256 seconds]
camus1 has joined #yocto
Vonter has quit [Read error: Connection reset by peer]
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
Vonter has joined #yocto
troth has joined #yocto
Kumar has joined #yocto
troth has quit [Ping timeout: 268 seconds]
vd has joined #yocto
RaulM has joined #yocto
RaulM has quit [Ping timeout: 256 seconds]
troth has joined #yocto
Vonter has quit [Read error: Connection reset by peer]
Kumar has quit [Quit: Client closed]
Vonter has joined #yocto
Kumar has joined #yocto
vd has quit [Quit: Client closed]
davidinux has quit [Ping timeout: 256 seconds]
davidinux has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
GNUmoon has quit [Ping timeout: 276 seconds]
lowfi has quit [Read error: Connection reset by peer]
<JosefHolzmayrThe>
yo dudX
kyrix has joined #yocto
ana_gasi has joined #yocto
pbergin has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
GNUmoon has joined #yocto
tre has joined #yocto
Vonter has joined #yocto
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
rfuentess has joined #yocto
rob_w has joined #yocto
pbergin_ has joined #yocto
pbergin has quit [Ping timeout: 256 seconds]
mckoan|away is now known as mckoan
mckoan is now known as MarcoCavallini
<MarcoCavallini>
good morning
Vonter has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
pgowda_ has joined #yocto
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
kayterina has joined #yocto
destmaster has joined #yocto
davidinux has quit [Ping timeout: 256 seconds]
davidinux has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
kayterina has quit [Quit: Leaving]
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
prabhakarlad has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
<wyre>
how should I set a custom environment for u-boot?
<wyre>
should I create a new recipe? 🤔
<wyre>
cannot I force u-boot to fetch the ethaddr from the hardware?
<RobertBerger>
@wyre: you could patch your existing u-boot recipe via a .bbappend
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
zyga-mbp has quit [Ping timeout: 252 seconds]
kroon has joined #yocto
zyga-mbp has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
RaulM has joined #yocto
falk0n[m] has quit [Quit: You have been kicked for being idle]
Artzaik[m] has quit [Quit: You have been kicked for being idle]
zyga-mbp has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
kroon has quit [Quit: Leaving]
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
<wyre>
RobertBerger, and what about the MAC address? 🤔
<qschulz>
wyre: either do it from the U-Boot command line (i.e. manually or from an env command) or write your own board file and patch U-Boot for this
<wyre>
qschulz, every board has its own MAC address ... so should I do something like a template and ... what mechanism could I use to fetch this MAC address automatically?
zpfvo has quit [Ping timeout: 252 seconds]
<wyre>
apparently the kernel is able to do it once the system has booted
zpfvo has joined #yocto
<qschulz>
where is this MAC address stored?
<wyre>
qschulz, I'm not sure ... the SoM has it in its sticker
<wyre>
but for sure this has to be flashed somewhere in the nic
<wyre>
hasn't it? 🤔
<qschulz>
not necessarily
<JosefHolzmayrThe>
wyre: nope. it really depends on the hardware
zpfvo has quit [Ping timeout: 245 seconds]
<qschulz>
if it was set in the NIC, why would you need to have the MAC address in the first place?
zpfvo has joined #yocto
<JosefHolzmayrThe>
can be in fusebits, in eeprom... so please go and ask your hardware vendor. its their job to support that.
<wyre>
well, I guess if the SoM has it in its sticker ... this has to be inside the SoM and ... apparently it shouldn't be flashed in the carrier EERAM or something like that
<wyre>
EEPROM, sorry
<wyre>
JosefHolzmayrThe, I see
<qschulz>
wyre: there's a fuse command in U-Boot, maybe you can access it from there
<JosefHolzmayrThe>
wyre: do you really think that some random person in manufacturing will put a sticker on the IC that holds a specific function? like the EEPROM? no way.
<qschulz>
but I assume there's some bit manipulation to be done and I couldn't be bothered doing it in the very weak U-Boot command line
<qschulz>
just create your board file and do it from there
frinke has joined #yocto
<wyre>
qschulz, could you give a link with more info about these board files? 🤔
<wyre>
but I'm afraid I'll have to build the image for each board 😥
<qschulz>
wyre: no, you will add logic to read the fuse from your board file and set the ethaddr in the env from your board file
<qschulz>
it's logic that'll be run at runtime and not build time
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<qschulz>
grep in the board/ directory for ethaddr and you'll see how vendors are handling this
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
<qschulz>
rburton: back to square one, the IT told me the server has never been above 20% of RAM in use.. the thing we'll look for now is container resources if they are limited in any way...
leon-anavi has joined #yocto
<RobertBerger>
wyre, where from you want to grab the MAC address?
Guest56 has joined #yocto
<RobertBerger>
wyre, I guess people were faster then me already ;)
<Guest56>
Hello! I`d like to find out if all tasks (like do_patch, do_compile, etc.) are performed by the same interpreter ?
<qschulz>
Guest56: either sh or python, both from your host distribution IIRC
florian has joined #yocto
<Guest56>
Thanks
<qschulz>
hence why your shell tasks/functions should be POSIX compliant as much as possible :)
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
tnovotny has joined #yocto
<rburton>
qschulz: i had a hunch it wasnt actually using ram, but allocating vast amounts
kroon has joined #yocto
<qschulz>
rburton: right now, IT has strong feeling it's max number of pids allowed
<qschulz>
they ran a bash bomb and it started failing at 2048 forks
<rburton>
oh yeah that's going to be it
<qschulz>
rburton: raised pids_limit in containers.conf to 1M let's see where this brings us :D
<rburton>
yeah try that
<rburton>
we should write this down in the docs :)
Guest56 has quit [Quit: Client closed]
<rburton>
common "my build randomly fails" problems, like max open file, max pid, etc
<dvorkindmitry>
what global variable contains current poky/yocto branch?
<rburton>
dvorkindmitry: what do you actually want exactly?
<dvorkindmitry>
rburton, I want to use branch name in SSTATE_DIR ?= "/disk2/build.${BRANCH}/sstate-cache"
<rburton>
there's no need to do that
<rburton>
if you *really* want to do that, hardcode it
<dvorkindmitry>
rburton, I have a lot of builds, different branches and don't want to name the build dirs manually :)
<rburton>
metadata_scm has base_get_metadata_git_branch which if you give it a path to a layer will show you the git description, but that isn't just the branchname reliably
<rburton>
just use a single sstate, its easier and you'll share more
<RP>
kroon: I was a little curious about your sorted() comments, the recent changes to the sig files should make them more deterministic :/
pbergin_ has quit [Quit: Leaving]
<qschulz>
dvorkindmitry: to be clear, the poky version (well, at least a version, i don't know where they get it from) is part of the sstate-cache full path
<kroon>
RP, yeah, I don't know if it is because I was comparing sigfiles from two different build paths. But I'm on master in both builds, and I needed to add sorted() in two places in siggen.py
<RP>
kroon: do you have the patch somewhere I could look at?
<RP>
kroon: it is possible the paths could do weird things unfortunately
<RP>
kroon: I'm a bit torn on what to suggest with the native/cross reproducibility changes, they are rather tough
<kroon>
RP, yeah I can send it to bitbake-devel if you want to. but there are probably more places in there that could use a sorted(), but for some reason I didn't need them
stkw0 has quit [Ping timeout: 256 seconds]
<kroon>
RP, aye. i sent a response, im not sure what we are gaining with different build path reproduciblity to be honest..
<dvorkindmitry>
rburton, can TMP dir be shared too?
zpfvo has joined #yocto
<qschulz>
dvorkindmitry: no, share DL_DIR and SSTATE_DIR
<dvorkindmitry>
qschulz, so I need at least one unique (TMPDIR) path for builds. May I use branch name without harcoding it?
<RP>
kroon: ah, yes. we never made that dump output diffable, we've assumed people would actually use the diff functions
<RP>
kroon: the data is in sets so would be unsorted there. We can change that though
<kroon>
RP, aha. and the diff functions only operate within the same build ?
<qschulz>
dvorkindmitry: what I used to do is to use dirname of the directory where I source the script, in the TMPDIR
<RP>
kroon: I suspect two different builds is a path that is not walked :)
<RP>
kroon: you were using the -t options which I personally hate too :/
<dvorkindmitry>
qschulz, my poky dir is at homedirm but build dir is at another, mounted hdd. that's why I'm thinking about paths
<rburton>
dvorkindmitry: sure, my checkouts are in $HOME but the build dirs are /yocto
<rburton>
specifically my build dirs are /yocto/ross/build-something with sstate at /yocto/sstate and dldir at /yocto/downloads
<Guest81>
Hi everyone, I'm looking for some help on my Yocto project. I want to build a nativesdk recipe which need the package "cups", so I added the BBCLASSEXTEND="nativesdk" in a cups .bbappend recipe. But now the cups recipe doesn't compile anymore "do_compile: oe_runmake failed" "undefined reference to `crypt'" it's seems to be a problem with the
<rburton>
the sstate and dldir are shared between all builds for all branches for maximum reuse
<Guest81>
linker
<dvorkindmitry>
rburton, can you share your flexible path setting? Now I am using site.conf to set only 2 absolute paths: TMPDIR and SSTATE_DIR. DL_DIR is shared
<rburton>
its exactly what you'd expect: local.conf sets DL_DIR=/yocto/downloads and SSTATE_DIR=/yocto/sstate
<rburton>
a site.conf that does the same would be sensible too
<rburton>
don't set tmpdir in site.conf and you can let it default to "tmp under the build dir"
<dvorkindmitry>
rburton, no potential problems to share SSTATE?
<rburton>
none
<rburton>
explicitly designed to do that
<rburton>
the autobuilder shared a single sstate between 20-ish workers that all build different configurations for different branches
<rburton>
more sharing == more reuse
<RP>
dvorkindmitry: it is specifically designed to handle this
<oberonc>
I add it to REDEPEND, but I get the error:
<oberonc>
RROR: Nothing RPROVIDES 'uci'
<oberonc>
*ERROR
<dvorkindmitry>
rburton, but if I'll delete current build dir and rebuild it and then use another builds, drop my previous one, sstate will take a lot of inodes and full of garbage, right?
<JosefHolzmayrThe>
oberonc: a) add the layer b) add it to your image.
<rburton>
dvorkindmitry: garbage, no. it will be fill of useful objects that can be reused
<qschulz>
dvorkindmitry: and you can do some file management to remove those you don't use often with a simple find -atime +30 -delete for example
<qschulz>
and there's a script which allows to keep only the last sstate-cache entry per recipe
<dvorkindmitry>
qschulz, If I'll delete the whole sstate dir, keeping TMPDIR untouched, will it rebuild all recipes from scratch on next run? Or it will re-create sstate?
<qschulz>
both
<rburton>
the sstate *cache* is a cache, keep it around
<qschulz>
I mean "rebuild everything from scratch" induces "re-create sstate"
<qschulz>
but yeah, as rburton says, there's no point in removing the whole ssatte dir
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rburton>
FWIW our CI's sstate-cache managed to fill up the node at 600GB last week
<rburton>
someone might have forgotten to run the prune job
<rburton>
keep it, share it, and periodically delete anything that hasn't been touched for some time (with that find, for example)
<qschulz>
rburton: cronjob with find -atime -delete should be enough shouldn;t it?
<rburton>
that's literally what we have, so yeah
<dvorkindmitry>
so delete sstate dir will force the complete rebuild?
<qschulz>
rburton: ok so raising pids_whatever worked, I don't have to limit xz and zstd threads and memory 🎉 :)
<qschulz>
dvorkindmitry: yes.. it's cache. If you don't have cache it needs to rebuild stuff
<rburton>
dvorkindmitry: do you mean 'if i delete sstate and keep tmp will it rebuild', then no, as tmp has the build in so it won't want to build anything. but the moment it needs to rebuild something it always looks in sstate first
<qschulz>
rburton: but jenkins still playing with me, my artifacts are 0B 😭 but nothing to do with Yocto :)
<rburton>
qschulz: your problem is using jenkins :)
<qschulz>
rburton: assuming they don't removing the stamps too I assume
<rburton>
right
<oberonc>
ERROR: Layer openwrt-layer is not compatible with the core layer which only supports these series: hardknott (layer is compatible with honister)
<oberonc>
anyway to fix this ?
<qschulz>
rburton: yeah... but we develop on.. gitolite, gitlab, gerrit and all.. makes it difficult to have a one size fits all system :/
<qschulz>
oberonc: checkout the correct branch for openwrt based on what you use for your core
<qschulz>
and btw, hardknott's EOL so try to update ASAP
<qschulz>
RP: I'm trying to rework package.bbclass to use recursive glob for .debug and .debug-static files... turns out this triggers something else now... this matches paths with symlinks which prints a warning..
<qschulz>
I was wondering why we don't actually include the symlink and also the file it points to instead of erroring out?
<rburton>
you often want the symlink in a different package to the file, if that's what you mean
<qschulz>
right now we print 1) a wanring that a file in a symlinked dir is in FILES and 2) error out if the target of the symlink isn't in the FILES
<coldspark29[m]>
Does anynone know a way to check if secure boot is enabled in the U-Boot shell. I need a return value for a function
<qschulz>
rburton: no, it's like: path/something/file <symlink-to-path/something>/file
<qschulz>
and you have <symlink-to-path/something>/file in FILES
<qschulz>
coldspark29[m]: I assume this is vendor specific. I know imx SoCs have something like hab_status command that should be available
<qschulz>
also, you probably want to ask on #u-boot instead :)
<coldspark29[m]>
qschulz: Yeah, that is exactly the problem. I am manually authenticating the boot script with HAB using that command, which works well. But there are production cases where secure boot is disabled and then the command isn't available and thus the boot process fails. So I need to check before if it is available. I guess I could do it with a hab command that always returns 0 when available
<qschulz>
rburton: WARNING: m4-1.4.19-r0 do_package: FILES contains file '/usr/lib/m4/m4-1.4.19/tests/.debug' which resides under a directory symlink. Please fix the recipe and use the real path for the file. this is my warning
<RP>
qschulz: I don't remember the reasons. recursive globbing never used to exist though
DavidS has joined #yocto
<RP>
qschulz: I suspect we error as we wanted users to be specific about what they wanted
<coldspark29[m]>
qschulz: HAB isn't so bad btw if you have worked through the painful process of signing etc. You can basically sign and authenticate everything
<coldspark29[m]>
;)
<qschulz>
coldspark29[m]: non-standard process is no-go for me :)
<coldspark29[m]>
I know ^^
<qschulz>
coldspark29[m]: I think you have support for test command in U-Boot command line
<coldspark29[m]>
For our next project we will also use mainline U-Boot
zyga-mbp has joined #yocto
<coldspark29[m]>
I will try thanks
<qschulz>
so you could probably run a dummy command requiring the hab command or whatever and check its return code
<qschulz>
RP: globbing is ANCIENT python... like... 3.5.... what do you mean this didn't exist in 2010's :D
<qschulz>
trying to simplify the packaging at least for the -dbg one and make it less magic :)
zyga-mbp has quit [Client Quit]
goliath has joined #yocto
zyga-mbp has joined #yocto
<rburton>
git grep noinsrt_
<rburton>
whoops :)
<qschulz>
rburton: nice password, nobody will suspect anything
<rburton>
haha
zyga-mbp has quit [Client Quit]
<RP>
qschulz: I remember having all kinds of crazniess and making it simple but magic was a big win :/
<rburton>
i can see the benefit in removing the magic and just using a recursive glob
<RP>
right, those didn't exist back then although I do wonder if the performance will be as good
<qschulz>
RP: I'll try to benchmark this, first step being to have something that works before actually benmchmarking
<qschulz>
and I assume removing all do_package sstate-cache files will be enough for me to benchmark this
<RP>
qschulz: probably just timing a few recipes with many files in the do_package step
<RP>
(before and after)
<RP>
perl, ltp and the kernel are the pathological ones that come to mind
<qschulz>
those have many .debug files?
<qschulz>
also, recursive globbing is enabled only if '**' is in the filepath, so it won't change anything for existing FILES since none are using **
<user_>
Hi
<RP>
qschulz: you'll still have to glob even if there aren't many debug files so I think this will affect recipes with large numbers of files regardless
<RP>
qschulz: finding something with large numbers of debug would also help obviously. Maybe lttng-tools
<RP>
qschulz: presumably you'll add a FILES_${PN}-dbg with it in so it will be run everywhere
<rburton>
looks like glob.glob only changes logic if the pattern actually has ** in
<rburton>
yeah, sorry, i went to check and missed you saying that already :)
<qschulz>
If recursive is true, the pattern “**” will match any files and zero or more directories, subdirectories and symbolic links to directories. If the pattern is followed by an os.sep or os.altsep then files will not match.
<qschulz>
rburton: no no, it was not clear enough since I was misunderstood :)
<rburton>
and if recursive is true but the pattern doesn't contain **, its like recursive is false
<rburton>
so its not a performance hit in the existing case
manuel1985 has joined #yocto
<rburton>
easily tested by setting recursive=true and verifying that a build takes the same time, and no changes to packaging happened
<qschulz>
and lgob.glob is already used
<qschulz>
rburton: re: jenkins... archiveArtifact archives symlinks but not what they point to...
<rburton>
useful!
<qschulz>
though they do have a followSymlinks options
<qschulz>
which does exactly what the name suggests... if you add a symlink, it fails
<qschulz>
damn Jenkins
<qschulz>
this is stupid
<qschulz>
anyway :)
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
zyga-mbp has joined #yocto
hpsy has joined #yocto
<user_>
I trying to print pdf format in the yocto base system using cups library in meta layer, but it is not printing. I am able to print the pdf format in the ubuntu system using the same filter.
zyga-mbp has quit [Client Quit]
<user_>
Is there any additional package required to print the pdf format?
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
rob_w has quit [Remote host closed the connection]
<rburton>
(just making myself feel very, very old)
<RP>
rburton: he must have been breaking things but I don't remember :/
<rburton>
it was some time ago now...
<sgw>
rburton: that was a while ago! I guess that's why paulbarker grabbed my patchset yesterday!
<rburton>
i do miss the days of smuggling beer into skamania :)
<sgw>
Right, that's the library!
hpsy has quit [Quit: Leaving.]
jmiehe has joined #yocto
<fray>
I don't remember a lot of 'smuggling', just beer..
hpsy has joined #yocto
MauroAnjo has joined #yocto
hpsy has quit [Quit: Leaving.]
sstiller has joined #yocto
<Guest81>
Hi everyone, I'm looking for some help on my Yocto project. I want to build a nativesdk recipe which need the package "cups", so I added the BBCLASSEXTEND="nativesdk" in a cups .bbappend recipe. But now the cups recipe doesn't compile anymore "do_compile: oe_runmake failed" "undefined reference to `crypt'" it's seems to be a problem with the
<Guest81>
linker
davidinux has quit [Ping timeout: 256 seconds]
davidinux has joined #yocto
<dacav>
Hi. Are yocto mailing lists on gmane, by any chance? I've found some, but the name look different than what is found on lists.yoctoproject.org
hpsy has joined #yocto
<rburton>
those might be the old lists
<rburton>
also the lists moved, so they might be using the old names
<Guest81>
So I don't understand why to add "nativesdk" as BBCLASSEXTEND generates error during compilation
akiCA has joined #yocto
<dacav>
mh, you're right: I just subscribed a random newsgroup, and the mails seem to be very old
hpsy has quit [Quit: Leaving.]
codavi has joined #yocto
troth has quit [Ping timeout: 268 seconds]
troth has joined #yocto
hpsy has joined #yocto
akiCA has quit [Ping timeout: 256 seconds]
codavi is now known as akiCA
<sgw>
dacav: check out the lore.kernel.org setup, you should be able to access nntp from there also
<dacav>
sgw: thanks!
<sgw>
that's relatively new
<dacav>
I love nntp :) Happy to know that there's fresh development on that side
hpsy has quit [Quit: Leaving.]
pbergin has joined #yocto
hpsy has joined #yocto
<paulbarker>
dacav: My talk yesterday covered that!
troth has quit [Ping timeout: 268 seconds]
rob_w has joined #yocto
Kumar has quit [Quit: Client closed]
pbergin has quit [Ping timeout: 252 seconds]
<dacav>
paulbarker: your talk?
<paulbarker>
dacav: I presented a talk on using lore.kernel.org with the Yocto mailing lists at the Yocto Project Summit yesterday
<paulbarker>
My demo used nntp to subscribe to the list and `b4` to pull down patch series
<dacav>
paulbarker: I'm quite new around here, there's a lot I don't know. I've heard about lore before, but I never used it. I should probably investigate a bit.
* dacav
is overwhelmed with info since a couple of weeks
<paulbarker>
dacav: There's a steep learning curve but a good community here and lots of info, tutorials, etc available
<paulbarker>
The talk I gave yesterday was focused on handling patches sent to the mailing list so may not be immediately applicable if you're just getting started using Yocto
<dacav>
paulbarker: it seems interesting nonetheless. I'm marking it on my todolist, to check lore, so I can come back later to it.
RobertBerger has quit [Ping timeout: 256 seconds]
rber|res has joined #yocto
<rfs613>
paulbarker: is the talk and/or slides available somewhere?
<jonmason>
possible stupid question, does halt/reboot work in poky-tiny? because its not working for me
troth has joined #yocto
<tlwoerner>
the videos of the talks will be cut up and uploaded to youtube in the next couple days (week-ish)
<rfs613>
tlwoerner: thanks!
<jonmason>
tlwoerner: too slow! what are we (not) paying you for?!?
hpsy has quit [Quit: Leaving.]
zpfvo has quit [Ping timeout: 245 seconds]
hpsy has joined #yocto
<tlwoerner>
lol
<Guest81>
do someone know if openjdk-9 is going to be added to Yocto project ?
tre has quit [Remote host closed the connection]
<fray>
lol, I keep telling Philip there is no 'space' in MontaVista.. :)
pbergin has joined #yocto
sakoman45 has joined #yocto
zpfvo has joined #yocto
<agherzan>
RP: Do you remember the proposal for backporting https://bugzilla.yoctoproject.org/show_bug.cgi?id=13183 onto `dunfell`? I'm wondering if it's something that is still planned. Also, can we cherry-pick the two commits in https://bugzilla.yoctoproject.org/show_bug.cgi?id=14054 as well? Otherwise add-layer adds broken layers without parsing their dependencies and that creates a very confusing situation: if you add a broken layer it goes without any
<agherzan>
issues (it doesn't refresh/sync the new bblayers nor catching the BBHandledException) but afterwards, if you add a new layer it breaks as the first invocation would be expected to. If that sounds reasonable, let's reopen https://bugzilla.yoctoproject.org/show_bug.cgi?id=14054 for dunfell backport. CC sakoman sakoman45
<RP>
agherzan: you need to ask sakoman about these
<agherzan>
Thanks RP . I've mentioned him above.
<RP>
agherzan: I'd put together some emails with the patches for Steve to consider
<sakoman>
agherzan: the three patches specified in 13183 are in yesterday's pull request
<sakoman>
(see bitbake mailing list)
zpfvo has quit [Ping timeout: 256 seconds]
<agherzan>
Thanks sakoman . I missed those ones.
<agherzan>
Can we also pull in the ones in 14054?
<agherzan>
They are two, they apply without any conflicts and they work alright in my testing env.
<RP>
agherzan: I just updated for those
zpfvo has joined #yocto
<RP>
sakoman: for the core pull request I wondered if we wanted all the patch status changes? :/
hpsy has quit [Quit: Leaving.]
<sakoman>
RP: I struggled with that too, but figured it made sense to have correct patch status. So I went ahead and included them -- no one commented during the review period. Not that that means much :-)
<sakoman>
If you think it is a bad idea I can drop them
zpfvo has quit [Ping timeout: 252 seconds]
<sakoman>
agherzan: I put the two in 14054 in my testing queue
zpfvo has joined #yocto
<agherzan>
sakoman: thanks. I'll keep an eye on a pull req cover in bitbake ml
<RP>
sakoman: It isn't a big deal either way but does cause rebuilds and adds some risk
jpuhlman_ has joined #yocto
jpuhlman has quit [Ping timeout: 256 seconds]
jpuhlman_ is now known as jpuhlman
<RP>
sakoman: I'm torn on it
<wyre>
could I set a systemd service as disabled by default when inheriting from systemd class? 🤔
hpsy has joined #yocto
<sakoman>
RP: if you are torn then let's drop them. I'll send a new pull request.
<RP>
sakoman: ok, I think we should only take them if we run into dependency patch issues
<sakoman>
RP: sounds like a plan
hpsy has quit [Quit: Leaving.]
hpsy has joined #yocto
DavidS has quit [Quit: Client closed]
nad has joined #yocto
nad has quit [Client Quit]
MauroAnjo has quit [Quit: Client closed]
hpsy has quit [Quit: Leaving.]
oberonc has quit [Quit: Client closed]
rob_w has quit [Remote host closed the connection]
hpsy has joined #yocto
sakoman45 has quit [Quit: Client closed]
sakoman45 has joined #yocto
<wyre>
apparently I can set SYSTEMD_AUTO_ENABLE to "disable" but ... what if my software has multiple services but I want all disabled but one of them enabled?
Guest81 has quit [Quit: Client closed]
mlalu has joined #yocto
tnovotny has quit [Quit: Leaving]
florian has quit [Quit: Ex-Chat]
kayterina[m] has quit [Quit: You have been kicked for being idle]
<vmeson>
Does anyone know Kevin Chow from TimeSys ? He's scheduled to talk at the YP summit...
<kergoth>
just set SSTATE_SKIP_CREATION=1 in the recipe, should do it
<mischief2>
is there a better solution to unbounded sstate cache growth than deleting it all or skipping creation for frequently changing recipes?
<RP>
mischief2: delete older files - it touches them when it uses them
<mischief2>
based on atime?
<kergoth>
atime is a common approach, yeah
amitk_ has joined #yocto
<mischief2>
well, that works. 700G less crap :)
amitk has quit [Ping timeout: 256 seconds]
<rfs613>
wow. Mine is "only" 17G...
<rburton>
17g isn't even trying! :)
pbergin has quit [Remote host closed the connection]
pbergin has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<kroon>
speaking of big sstate cache, is that cleanup using the access time an easy oneliner, or should it be added to sstate-cache-management.sh ?
kiran_ has joined #yocto
GNUmoon has quit [Ping timeout: 276 seconds]
<mischief2>
kroon: 'find . -type f -atime +15 -delete' is what i ran.
pbergin has quit [Quit: Leaving]
<kroon>
mischief2, aha
kyrix has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kiran_ has quit [Ping timeout: 252 seconds]
RaulM has quit [Ping timeout: 252 seconds]
florian has joined #yocto
GNUmoon has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
<vd>
which package provides ssh and scp again?
<Saur[m]>
vd: openssh and dropbear
<vd>
I thought it was part of packagegroup-core-full-cmdline but I might be dreaming
akiCA has quit [Ping timeout: 256 seconds]
florian has quit [Ping timeout: 252 seconds]
leon-anavi has quit [Quit: Leaving]
<kroon>
RP, uhm.. ok so the sstate cache is already build path independent, meaning I can use reuse sstate from one build in another build with the same configuration but in a different path ?
florian has joined #yocto
florian has quit [Ping timeout: 252 seconds]
prabhakarlad has joined #yocto
<RP>
kroon: yes, just the binaries can have hardcoded paths in them
<kroon>
RP, right, then I don't really see what benefits different build path reproducability buys us ..
<kroon>
RP, i just mean that if the build path changes, its probably because of a version update, and the content is gonna change anyway